Last Call: (Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'YANG Groupings for TCP Clients and TCP Servers' to Proposed Standard (draft-ietf-netconf-tcp-client-server-24.txt)
The IESG has approved the following document: - 'YANG Groupings for TCP Clients and TCP Servers' (draft-ietf-netconf-tcp-client-server-24.txt) as Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ Technical Summary This document defines three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. Working Group Summary This document has been progressing in the working group for a long time and reflects a good consensus. Document Quality The document is of good quality. Personnel The Document Shepherd for this document is Per Andersson. The Responsible Area Director is Robert Wilton. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (YANG Groupings for TCP Clients and TCP Servers) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Groupings for TCP Clients and TCP Servers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered TCP Maintenance and Minor Extensions (tcpm)
The TCP Maintenance and Minor Extensions (tcpm) WG in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. TCP Maintenance and Minor Extensions (tcpm) --- Current status: Active WG Chairs: Yoshifumi Nishida Michael Tüxen Ian Swett Assigned Area Director: Martin Duke Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: t...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: https://mailarchive.ietf.org/arch/browse/tcpm/ Group page: https://datatracker.ietf.org/group/tcpm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tcpm/ TCP is currently one of the Internet's predominant transport protocols. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track. * The WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. The preferred venue for Congestion control work is generally CCWG or ICCRG. However, TCPM can take on such work in coordination with those groups, especially if it relies on TCP-specific protocol elements. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Nov 2022 - Submit RFC6937bis document to the IESG for publication as a Proposed Standard RFC Dec 2022 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC Jan 2023 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Dec 2023 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC Oct 2024 - Submit document on adding acknowledgement rate handling for TCP to the IESG for publication as Experimental RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: TCP Maintenance and Minor Extensions (tcpm)
The TCP Maintenance and Minor Extensions (tcpm) WG in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-11. TCP Maintenance and Minor Extensions (tcpm) --- Current status: Active WG Chairs: Yoshifumi Nishida Michael Tüxen Ian Swett Assigned Area Director: Martin Duke Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: t...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: https://mailarchive.ietf.org/arch/browse/tcpm/ Group page: https://datatracker.ietf.org/group/tcpm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tcpm/ TCP is currently the Internet's predominant transport protocol. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. The preferred venue for Congestion control work is generally CCWG or ICCRG. However, TCPM can take on such work in coordination with those groups, especially if it relies on TCP-specific protocol elements. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Nov 2022 - Submit RFC6937bis document to the IESG for publication as a Proposed Standard RFC Dec 2022 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC Jan 2023 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Dec 2023 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC Oct 2024 - Submit document on adding acknowledgement rate handling for TCP to the IESG for publication as Experimental RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9406 on HyStart++: Modified Slow Start for TCP
A new Request for Comments is now available in online RFC libraries. RFC 9406 Title: HyStart++: Modified Slow Start for TCP Author: P. Balasubramanian, Y. Huang, M. Olson Status: Standards Track Stream: IETF Date: May 2023 Mailbox:pravb.i...@gmail.com, hua...@microsoft.com, maol...@microsoft.com Pages: 9 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-hystartplusplus-14.txt URL:https://www.rfc-editor.org/info/rfc9406 DOI:10.17487/RFC9406 This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses increase in round-trip delay as a heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9401 on The Addition of the Death (DTH) Flag to TCP
A new Request for Comments is now available in online RFC libraries. RFC 9401 Title: The Addition of the Death (DTH) Flag to TCP Author: S. Toyosawa Status: Informational Stream: Independent Date: 1 April 2023 Mailbox:s2.toyos...@gmail.com Pages: 6 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-deathflag-01.txt URL:https://www.rfc-editor.org/info/rfc9401 DOI:10.17487/RFC9401 This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'HyStart++: Modified Slow Start for TCP' to Proposed Standard (draft-ietf-tcpm-hystartplusplus-14.txt)
The IESG has approved the following document: - 'HyStart++: Modified Slow Start for TCP' (draft-ietf-tcpm-hystartplusplus-14.txt) as Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/ Technical Summary This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Traditional slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses a delay increase heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit. Working Group Summary The document has broad agreement, in particular from TCP implementers. There was no controversy. Document Quality There are implementations for the TCP stacks in FreeBSD, Linux, and Windows, and a QUIC implementations Quiche from CloudFlare and s2n-quic from AWS.? Personnel The document shepherd is Michael Tuexen. The AD is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (HyStart++: Modified Slow Start for TCP) to Proposed Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'HyStart++: Modified Slow Start for TCP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-01-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Traditional slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses a delay increase heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9329 on TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets
A new Request for Comments is now available in online RFC libraries. RFC 9329 Title: TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets Author: T. Pauly, V. Smyslov Status: Standards Track Stream: IETF Date: November 2022 Mailbox:tpa...@apple.com, s...@elvis.ru Pages: 30 Obsoletes: RFC 8229 I-D Tag:draft-ietf-ipsecme-rfc8229bis-09.txt URL:https://www.rfc-editor.org/info/rfc9329 DOI:10.17487/RFC9329 This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'TCP Encapsulation of IKE and IPsec Packets' to Proposed Standard (draft-ietf-ipsecme-rfc8229bis-09.txt)
The IESG has approved the following document: - 'TCP Encapsulation of IKE and IPsec Packets' (draft-ietf-ipsecme-rfc8229bis-09.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ Technical Summary This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document updates the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. Working Group Summary This work started in 2018 with document "Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2", but during the process IPsecME WG decided to make bis document of RFC8229 instead as some of the clarifications were actually modifying the protocol. The first version of the rfc8229bis document was published as individual draft in May 2020 as individual draft, and it was adopted by the WG in April 2021. Updates were made in response to AD Review, GENART, TSV, and SECDIR review. Document Quality There are several implementations of the RFC8229 and during those implementations few issues were found that required modifications. Because of that this RFC8229bis document was created, when it was obvious that simple clarifications are not enough. There are already some implementations implementing changes described in this bis document. Personnel Shepherd: Tero Kivinen Responsible AD: Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A YANG Model for Transmission Control Protocol (TCP) Configuration and State' to Proposed Standard (draft-ietf-tcpm-yang-tcp-09.txt)
The IESG has approved the following document: - 'A YANG Model for Transmission Control Protocol (TCP) Configuration and State' (draft-ietf-tcpm-yang-tcp-09.txt) as Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/ Technical Summary This document specifies a minimal YANG model for TCP on devices that are configured by network management protocols. The YANG model defines a container for all TCP connections and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342). Working Group Summary The draft has been active for over 3 years. At first, some raised concerns that other TCP related YANG models might create conflicts or overlap, and that attempting a model for all of TCP would be complicated and time-consuming, and TCP implementations would not provide a YANG-based configuration interface. Therefore, the focus is limited to a small set of parameters and TCP configuration on BGP routers, where YANG is already in use. There have been no other controversial points that required long arguments. There is a solid consensus in the WG for publication. Document Quality There are prototype implementations. A YANG Doctors review is in progress. This work was requested by people in the BGP community, so we expect industry adoption. Personnel The Shepherd is Yoshifumi Nishida. The Responsible AD is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
STD 7, RFC 9293 on Transmission Control Protocol (TCP)
A new Request for Comments is now available in online RFC libraries. STD 7 RFC 9293 Title: Transmission Control Protocol (TCP) Author: W. Eddy, Ed. Status: Standards Track Stream: IETF Date: August 2022 Mailbox:w...@mti-systems.com Pages: 98 Obsoletes: RFC 793, RFC 879, RFC 2873, RFC 6093, RFC 6429, RFC 6528, RFC 6691 Updates:RFC 1011, RFC 1122, RFC 5961 See Also: STD 7 I-D Tag:draft-ietf-tcpm-rfc793bis-28.txt URL:https://www.rfc-editor.org/info/rfc9293 DOI:10.17487/RFC9293 This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (TCP Encapsulation of IKE and IPsec Packets) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'TCP Encapsulation of IKE and IPsec Packets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-05-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document updates the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9235 on TCP Authentication Option (TCP-AO) Test Vectors
A new Request for Comments is now available in online RFC libraries. RFC 9235 Title: TCP Authentication Option (TCP-AO) Test Vectors Author: J. Touch, J. Kuusisaari Status: Informational Stream: IETF Date: May 2022 Mailbox:to...@strayalpha.com, jkuusisa...@infinera.com Pages: 25 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-ao-test-vectors-09.txt URL:https://www.rfc-editor.org/info/rfc9235 DOI:10.17487/RFC9235 This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC- SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Transmission Control Protocol (TCP) Specification' to Internet Standard (draft-ietf-tcpm-rfc793bis-28.txt)
The IESG has approved the following document: - 'Transmission Control Protocol (TCP) Specification' (draft-ietf-tcpm-rfc793bis-28.txt) as Internet Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ Technical Summary This is an update to RFC793, the core specification for TCP, which is 40 years old. It also replaces some RFCs that update 793, including the TCP-related bits of RFC 1122. Working Group Summary This has taken 6 years. The objective was to not actually change how TCP works, for obvious reasons. Nevertheless, there are many deviations between the specification and practice in the real world. The consensus was to document these issues rather than attempt to correct them here. For more, please see the (exceptional) Shepherd Writeup. Document Quality You almost certainly, have at least one, if not several, TCP implementations on your body right now, and are right now reading text that was delivered via TCP. Personnel The document shepherd is Michael Scharf . The responsible Area Director is Martin Duke . ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 235, RFC 9210 on DNS Transport over TCP - Operational Requirements
A new Request for Comments is now available in online RFC libraries. BCP 235 RFC 9210 Title: DNS Transport over TCP - Operational Requirements Author: J. Kristoff, D. Wessels Status: Best Current Practice Stream: IETF Date: March 2022 Mailbox:j...@dataplane.org, dwess...@verisign.com Pages: 29 Updates:RFC 1123, RFC 1536 See Also: BCP 235 I-D Tag:draft-ietf-dnsop-dns-tcp-requirements-15.txt URL:https://www.rfc-editor.org/info/rfc9210 DOI:10.17487/RFC9210 This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. This document is a product of the Domain Name System Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'TCP-AO Test Vectors' to Informational RFC (draft-ietf-tcpm-ao-test-vectors-09.txt)
The IESG has approved the following document: - 'TCP-AO Test Vectors' (draft-ietf-tcpm-ao-test-vectors-09.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/ Technical Summary This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC- SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal. Working Group Summary This is a niche interest, so there was less TCPM review than usual, but there was also no controversy. Document Quality The test vectors here have been verified by multiple sources. TCP-AO is often used in routers. Personnel The Shepherd is Michael Scharf. The responsible AD is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'A YANG Model for Transmission Control Protocol (TCP) Configuration' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-03-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a minimal YANG model for TCP on devices that are configured by network management protocols. The YANG model defines a container for all TCP connections and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9174 on Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4
A new Request for Comments is now available in online RFC libraries. RFC 9174 Title: Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 Author: B. Sipos, M. Demmer, J. Ott, S. Perreault Status: Standards Track Stream: IETF Date: January 2022 Mailbox:brian.sipos+i...@gmail.com, dem...@gmail.com, o...@in.tum.de, simon.perrea...@logmein.com Pages: 62 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dtn-tcpclv4-28.txt URL:https://www.rfc-editor.org/info/rfc9174 DOI:10.17487/RFC9174 This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms. This document is a product of the Delay/Disruption Tolerant Networking Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (TCP-AO Test Vectors) to Informational RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP-AO Test Vectors' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-02-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: one based on SHA-1 and the other on AES-128. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DNS Transport over TCP - Operational Requirements' to Best Current Practice (draft-ietf-dnsop-dns-tcp-requirements-15.txt)
The IESG has approved the following document: - 'DNS Transport over TCP - Operational Requirements' (draft-ietf-dnsop-dns-tcp-requirements-15.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ Technical Summary This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature. For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability. Working Group Summary This document has been around in various forms for some time, and has been extensively reviewed in the WG by both protocol experts and DNS operators. THe authors are experienced DNS protocol designers and operators as well, and responded to every issue raised in the WG discussion over time. Document Quality This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature. For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability. Personnel Suzanne Woolf is the Document Shepherd Warren Kumari is RAD ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (DNS Transport over TCP - Operational Requirements) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Transport over TCP - Operational Requirements' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 1123. This document strongly encourages the operational practice of permitting DNS messages to be carried over TCP on the Internet as a best current practice. Such encouragement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP, as well as over an encrypted TLS session. The document also considers the consequences with this form of DNS communication and the potential operational issues that can arise when this best current practice is not upheld. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (Proposed Standard - Internet Engineering Task Force (IETF)) rfc8490: DNS Stateful Operations (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7873: Domain Name System (DNS) Cookies (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7828: The edns-tcp-keepalive EDNS0 Option (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7477: Child-to-Parent Synchronization in DNS (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6762: Multicast DNS (Proposed Standard - Internet Engineering Task Force (IETF)) rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc2181: Clarifications to the DNS Specification (Proposed Standard - Internet Engineering Task Force (IETF)) rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc1995: Incremental Zone Transfer in DNS (Proposed Standard - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9040 on TCP Control Block Interdependence
A new Request for Comments is now available in online RFC libraries. RFC 9040 Title: TCP Control Block Interdependence Author: J. Touch, M. Welzl, S. Islam Status: Informational Stream: IETF Date: July 2021 Mailbox:to...@strayalpha.com, mich...@ifi.uio.no, safiq...@ifi.uio.no Pages: 29 Obsoletes: RFC 2140 I-D Tag:draft-ietf-tcpm-2140bis-11.txt URL:https://www.rfc-editor.org/info/rfc9040 DOI:10.17487/RFC9040 This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCP Control Blocks, among similar concurrent or consecutive connections. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Transmission Control Protocol (TCP) Specification) to Internet Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'Transmission Control
Protocol (TCP) Specification'
as Internet Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-08-02. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
This document specifies the Transmission Control Protocol (TCP). TCP
is an important transport layer protocol in the Internet protocol
stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793.
This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC
1122, and should be considered as a replacement for the portions of
that document dealing with TCP requirements. It also updates RFC
5961 by adding a small clarification in reset handling while in the
SYN-RECEIVED state. The TCP header control bits from RFC 793 have
also been updated based on RFC 3168.
RFC EDITOR NOTE: If approved for publication as an RFC, this should
be marked additionally as "STD: 7" and replace RFC 793 in that role.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
No IPR declarations have been submitted directly on this I-D.
The document contains these normative downward references.
See RFC 3967 for additional information:
rfc6633: Deprecation of ICMP Source Quench Messages (Proposed Standard -
Internet Engineering Task Force (IETF))
rfc6298: Computing TCP's Retransmission Timer (Proposed Standard - Internet
Engineering Task Force (IETF))
rfc5681: TCP Congestion Control (Draft Standard - Internet Engineering Task
Force (IETF))
rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP
(Proposed Standard - Internet Engineering Task Force (IETF))
rfc2675: IPv6 Jumbograms (Proposed Standard - Internet Engineering Task
Force (IETF))
rfc2474: Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers (Proposed Standard - Internet Engineering Task Force
(IETF))
rfc1191: Path MTU discovery (Draft Standard - Legacy stream)
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'TCP Control Block Interdependence' to Informational RFC (draft-ietf-tcpm-2140bis-11.txt)
The IESG has approved the following document: - 'TCP Control Block Interdependence' (draft-ietf-tcpm-2140bis-11.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ Technical Summary This informational document describes TCP Control Block Interdependence, i.e. sharing of a part of TCP state among similar concurrent or consecutive connections. Many TCP implementations use such sharing to help improve convergence to steady-state operation. The memo documents known caching mechanisms and provides guidance to TCP implementers. 2140bis updates and replaces RFC 2140's description of interdependent TCP control blocks. The document describes local heuristics inside a TCP endpoint that do not affect interoperability between different TCP implementations. As described in the document, different TCP/IP stacks internally cache different TCP parameters, and there is no known best approach. As a result, 2140bis is submitted as informational document, like RFC 2140. Working Group Summary The document is an outcome of the TCPM working group and has been discussed in TCPM for a long time. There is strong consensus in the TCPM working group that an up-to-date description of TCP Control Block Interdependence is useful - instead of the outdated content of RFC 2140. Section 11 describes the updates compared to RFC 2140. Various TCP implementers provided feedback about actually implemented mechanisms and contributed e.g. to the summary in Section 10. Before adoption in TCPM there were discussions about the target status of this document, most notably about the question whether to publish 2140bis as BCP. However, many implementers pushed back against a BCP in this space, given that there is no known "best" caching heuristic and different operating systems have successfully used different strategies for a long time. As different choices by implementers do not result in interoperability issues, there is no apparent need for normative IETF guidance. As a result, the TCPM consensus is to update and replace the informational RFC 2140 by an informational document. A small number of TCPM contributors has performed comprehensive reviews of the document, both before and during WGLC. Given the informational status, parts of the working group may not care much about the content of the document. Nonetheless, the shepherd believes that there is strong consensus in the TCPM working group to publish the main body of the document as informational RFC, as it contains valuable information on how to efficiently implement TCP. A notable exception is appendix C, which is based on text from an expired individual Internet-Draft (draft-touch-tcpm-automatic-iw), for which there is no known implementation at the time of publication. During and after WGLC, some TCPM contributors expressed concerns about appendix C and in particular about its length. While everybody agrees that it makes sense to discuss sharing of the TCP initial window in this document, small parts of the TCPM working group believe that a link to the expired draft and some summary discussion would be sufficient instead of a full specification of the algorithm. Some improvements in the appendix were made to address these WGLC comments, but the authors prefer to keep a full description of an algorithm in appendix C instead of a summary only. All in all, this discussion was between a small number of TCPM contributors only. The vast majority in the TCPM working group stays silent on that question. The TCPM consensus whether to include a full description of an example algorithm in appendix C is rough, and, as a result, appendix C has no strong backing inside the TCPM working group. Nonetheless, the example in appendix C is only a minor part of the overall document. Document Quality TCP control block interdependence is widely deployed, and this memo attempts to update the Informational RFC to reflect modern practices. Personnel The document shepherd is Michael Scharf . The responsible Area Director is Martin Duke . ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9006 on TCP Usage Guidance in the Internet of Things (IoT)
A new Request for Comments is now available in online RFC libraries. RFC 9006 Title: TCP Usage Guidance in the Internet of Things (IoT) Author: C. Gomez, J. Crowcroft, M. Scharf Status: Informational Stream: IETF Date: March 2021 Mailbox:carle...@entel.upc.edu, jon.crowcr...@cl.cam.ac.uk, michael.sch...@hs-esslingen.de Pages: 24 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lwig-tcp-constrained-node-networks-13.txt URL:https://www.rfc-editor.org/info/rfc9006 DOI:10.17487/RFC9006 This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use. This document is a product of the Light-Weight Implementation Guidance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8985 on The RACK-TLP Loss Detection Algorithm for TCP
A new Request for Comments is now available in online RFC libraries. RFC 8985 Title: The RACK-TLP Loss Detection Algorithm for TCP Author: Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha Status: Standards Track Stream: IETF Date: February 2021 Mailbox:ych...@google.com, ncardw...@google.com, nandi...@google.com, priyar...@google.com Pages: 29 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-rack-15.txt URL:https://www.rfc-editor.org/info/rfc8985 DOI:10.17487/RFC8985 This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4' to Proposed Standard (draft-ietf-dtn-tcpclv4-26.txt)
The IESG has approved the following document: - 'Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4' (draft-ietf-dtn-tcpclv4-26.txt) as Proposed Standard This document is the product of the Delay/Disruption Tolerant Networking Working Group. The IESG contact persons are Martin Duke and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/ Technical Summary This document describes the Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 (TCPCLv4) for use with the Bundle Protocol Version 7 (BPv7) [I-D.ietf-dtn-bpbis]. The BPv7 implements a store-and-forward overlay network suitable for delay-tolerant message exchange. The protocol data unit for the BPv7 is the "bundle". BPv7 agents require convergence layer adapters (CLAs) to send and receive "bundles" using the service of some "native" link, network, or Internet protocol. Both the BPv7 and its CLAs reside at the application layer of the Internet model protocol stack [RFC1122]. The TCPCLv4 describes a CLA that sends and received bundles using the well-known Transmission Control Protocol (TCP). This specification describes the format and processing of the protocol data units passed between entities participating in TCPCLv4 communications. Working Group Summary: TCPCLv4 is descended from an experimental IRTF specification TCPCLv3 [RFC7242]. Implementation experience with TCPCLv3 identified limitations such as ambiguity in bundle acknowledgment and refusal, non-normative discussion on how to incorporate TLS, and minor inefficiencies associated with sequencing. TCPCLv4 was created to address those limitations and prepare the specification for non-experimental use. Technical discussions over the last 3 years have been well informed and focused on TLS negotiations, overall protocol agent state machines, and a protocol extension mechanism. There is no controversy related to the adoption of the specification; DTNWG consensus on the draft is strong. Document Quality: The workflow for TCPCLv4 remained largely unchanged from that of TCPCLv3 for which reference implementations exist. Co-author B. Sipos has created a reference implementation of TCPCLv4 to demonstrate features and ensure the clarity of the draft. Much of the recent review provided by the DTNWG focused on increasing the overall clarity of the specification to ensure no ambiguities exist for implementers. There have been no problems discovered with the reference implementation for this draft. Personnel: The Document Shepherd is Ed Birrane. The Responsible Area Director is Magnus Westerlund. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (TCP Control Block Interdependence) to Informational RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Control Block Interdependence' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-02-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'TCP Usage Guidance in the Internet of Things (IoT)' to Informational RFC (draft-ietf-lwig-tcp-constrained-node-networks-13.txt)
The IESG has approved the following document: - 'TCP Usage Guidance in the Internet of Things (IoT)' (draft-ietf-lwig-tcp-constrained-node-networks-13.txt) as Informational RFC This document is the product of the Light-Weight Implementation Guidance Working Group. The IESG contact persons are Erik Kline and Éric Vyncke. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ Technical Summary This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs, defined in RFC7228), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. Working Group Summary Nothing noteworthy. Document Quality This document is not a protocol specification, and it intends to provide guidance on how to implement and configure TCP stack, as well as on how TCP is advisable to be used by applications. This document has been reviewed thoroughly by the experts in both LWIG and TCPM working groups during the WGLC. Markku Kojo, a long-time IETF transport expert, has provided a thorough review. Many others provided comments which have been reflected in the current version of this draft. Personnel Shepherd: Zhen Cao Responsible AD: Erik Kline ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The RACK-TLP loss detection algorithm for TCP' to Proposed Standard (draft-ietf-tcpm-rack-15.txt)
The IESG has approved the following document:
- 'The RACK-TLP loss detection algorithm for TCP'
(draft-ietf-tcpm-rack-15.txt) as Proposed Standard
This document is the product of the TCP Maintenance and Minor Extensions
Working Group.
The IESG contact persons are Martin Duke and Magnus Westerlund.
A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/
Technical Summary
This document presents the RACK-TLP loss detection algorithm for TCP.
RACK-TLP uses per-segment transmit timestamps and selective
acknowledgements (SACK) and has two parts: RACK ("Recent
ACKnowledgment") starts fast recovery quickly using time-based
inferences derived from ACK feedback. TLP ("Tail Loss Probe")
leverages RACK and sends a probe packet to trigger ACK feedback to
avoid retransmission timeout (RTO) events. Compared to the widely
used DUPACK threshold approach, RACK-TLP detects losses more
efficiently when there are application-limited flights of data, lost
retransmissions, or data packet reordering events. It is intended to
be an alternative to the DUPACK threshold approach.
Working Group Summary
The general approach was uncontroversial. As the algorithm is quite
intricate, there were many comments to clarify the text and the
pseudocode.
Document Quality
The core mechanisms described in the document are implemented in FreeBSD,
Linux, and Windows. They are in active use on these platforms. RACK can also be
used by other transport protocols. QUIC loss recovery uses the same ideas and
there exists also an implementation for SCTP within a simulation environment.
Personnel
The document shepherd is Michael Tüxen. The Responsible AD is Martin Duke
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4) to Proposed Standard
The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4' as Proposed Standard This is a second IETF last call due to extensive changes since previous IETF last call. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-01-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a reliable transport of such bundles. This version of TCPCL also includes security and extensibility mechanisms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (The RACK-TLP loss detection algorithm for TCP) to Proposed Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection
algorithm for TCP'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
This document presents the RACK-TLP loss detection algorithm for TCP.
RACK-TLP uses per-segment transmit timestamps and selective
acknowledgements (SACK) and has two parts: RACK ("Recent
ACKnowledgment") starts fast recovery quickly using time-based
inferences derived from ACK feedback. TLP ("Tail Loss Probe")
leverages RACK and sends a probe packet to trigger ACK feedback to
avoid retransmission timeout (RTO) events. Compared to the widely
used DUPACK threshold approach, RACK-TLP detects losses more
efficiently when there are application-limited flights of data, lost
retransmissions, or data packet reordering events. It is intended to
be an alternative to the DUPACK threshold approach.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/
No IPR declarations have been submitted directly on this I-D.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC
The IESG has received a request from the Light-Weight Implementation Guidance WG (lwig) to consider the following document: - 'TCP Usage Guidance in the Internet of Things (IoT)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-09-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8803 on 0-RTT TCP Convert Protocol
A new Request for Comments is now available in online RFC libraries. RFC 8803 Title: 0-RTT TCP Convert Protocol Author: O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans Status: Experimental Stream: IETF Date: July 2020 Mailbox:olivier.bonavent...@tessares.net, mohamed.boucad...@orange.com, sgund...@cisco.com, sh@kt.com, benjamin.hesm...@tessares.net Pages: 47 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-converters-19.txt URL:https://www.rfc-editor.org/info/rfc8803 DOI:10.17487/RFC8803 This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
TCP Maintenance and Minor Extensions (tcpm) WG Virtual Meeting: 2020-04-29
The TCP Maintenance and Minor Extensions (tcpm) Working Group will hold a virtual interim meeting on 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=ma838311f033ebe35fefacc0d50658988 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8684 on TCP Extensions for Multipath Operation with Multiple Addresses
A new Request for Comments is now available in online RFC libraries. RFC 8684 Title: TCP Extensions for Multipath Operation with Multiple Addresses Author: A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch Status: Standards Track Stream: IETF Date: March 2020 Mailbox:alan.f...@gmail.com, costin.rai...@cs.pub.ro, m.hand...@cs.ucl.ac.uk, olivier.bonavent...@uclouvain.be, cpaa...@apple.com Pages: 68 Obsoletes: RFC 6824 I-D Tag:draft-ietf-mptcp-rfc6824bis-18.txt URL:https://www.rfc-editor.org/info/rfc8684 DOI:10.17487/RFC8684 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. This document is a product of the Multipath TCP Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: '0-RTT TCP Convert Protocol' to Experimental RFC (draft-ietf-tcpm-converters-19.txt)
The IESG has approved the following document: - '0-RTT TCP Convert Protocol' (draft-ietf-tcpm-converters-19.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Mirja Kühlewind and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ Technical Summary This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The proxy can be installed in managed networks by a network operator, for instance to help the deployment of Multipath TCP. Working Group Summary While Multipath TCP is an important use case, the Convert Protocol can actually be used for several TCP extensions. As the protocol is highly related to TCP standards and not specific to Multipath TCP, it was decided to home this document in the TCPM working group. The TCPM working group requests publication as Experimental document because the protocol targets controlled environments in which all network attachments are managed by the same administrative entity. Document Quality The document has been presented and discussed repeatedly in TCPM and as a result the protocol has changed several times. One frequently discussed design choice is whether and how to use TCP Fast Open (TFO). Appendix C explains the rationale for the final solution. There have also been some discussions whether such a proxy is really useful and needed. Some few contributors to the working group were not convinced by the MPTCP use case. During WGLC, Philip Eardley (chair of the MPTCP WG) has performed a comprehensive review, which was subsequently addressed in a number of document updates. The shepherd has reviewed the document before WGLC and verified that all WGLC comments are addressed. In addition to that, several contributors from vendors and network operators have explicitly expressed their support before and during WGLC. It has also been mentioned that the protocol is of interest to 3GPP. In TCPM, there is very strong but not unanimous support for publication as experimental document. There is at least one known implementation: Tessares has an open-sourced a library (https://github.com/Tessares/libconvert) and a closed-source Hybrid Access Gateway (HAG) that uses this library directly to act as an MPTCP Converter. Korea Telekom (KT) has reported to TCPM the results of a PoC using these implementations (see https://tessares.pr.co/181810-kt-tessares-successfully-test-5g-low-latency-multi-radio-access-technology-in-a-commercial-5g-network). Other vendors have also expressed interest, but there is no publicly known second implementation. Personnel The document shepherd is Michael Scharf. The responsible Area Director is Mirja Kuehlewind. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Multipath TCP (mptcp)
The Multipath TCP (mptcp) WG in the Transport Area has concluded. The IESG contact persons are Mirja Kuehlewind and Magnus Westerlund. The mailing list will remain open. This group was closed as it fulfilled its charter and milestones in specifying and revising the MPTCP protocol. Future maintenance or extension work for MPTCP will be done in the TCP Maintenance and Minor Extensions (tcpm) working group, see https://datatracker.ietf.org/group/tcpm/about/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered TCP Maintenance and Minor Extensions (tcpm)
The TCP Maintenance and Minor Extensions (tcpm) WG in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. TCP Maintenance and Minor Extensions (tcpm) --- Current status: Active WG Chairs: Yoshifumi Nishida Michael Scharf Michael Tüxen Assigned Area Director: Mirja Kühlewind Transport Area Directors: Mirja Kühlewind Magnus Westerlund Mailing list: Address: t...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: https://mailarchive.ietf.org/arch/browse/tcpm/ Group page: https://datatracker.ietf.org/group/tcpm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tcpm/ TCP is currently the Internet's predominant transport protocol. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. * The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative TCP congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. TCP's congestion control algorithms are the model followed by other IETF transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Apr 2020 - Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as a Proposed Standard RFC May 2020 - Submit document on Retransmission Timeout Considerations as Best Current Practice RFC Jun 2020 - Submit RFC793bis document to the IESG for publication as Internet Standard Jul 2020 - Submit document on TCP Control Block Interdependence to the IESG for publication as Informational RFC Aug 2020 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC Sep 2020 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Nov 2020 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (0-RTT TCP Convert Protocol) to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - '0-RTT TCP Convert Protocol' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels, whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3616/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4) to Proposed Standard
The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2019-11-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a revised protocol for the TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The protocol revision is based on implementation issues in the original TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol contents, encodings, and convergence layer requirements in Bundle Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a reliable transport of such bundles. Several new IANA registries are defined for TCPCLv4 which define some behaviors inherited from TCPCLv3 but with updated encodings and/or semantics. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'TCP Extensions for Multipath Operation with Multiple Addresses' to Proposed Standard (draft-ietf-mptcp-rfc6824bis-18.txt)
The IESG has approved the following document: - 'TCP Extensions for Multipath Operation with Multiple Addresses' (draft-ietf-mptcp-rfc6824bis-18.txt) as Proposed Standard This document is the product of the Multipath TCP Working Group. The IESG contact persons are Mirja Kühlewind and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ Technical Summary Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. Working Group Summary After creating the Experimental RFC6824, the primary goal of the MPTCP working group has been to create a bis version of the protocol document on the Standards track, incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM.This process led to several changes, a couple of which make RFC6824bis incompatible with RFC6824. Hence this document obsoletes RFC6824. There is WG agreement to move ahead with publishing the document. Document Quality This document has been reviewed by various people. There is one (non-public) implementation and other implementers of RFC6824 have indicated that they will implement against the new RFC. The original MPTCP spec has been widely implemented and deployed and the Linux implementation is publicly available. The bis document has been implemented in Linux, but permission to release this code has not been forthcoming. The WG is OK with publishing the RFC at this stage rather than waiting further, and vendors /implementers have indicated that they will implement against the new RFC. Personnel Philip Eardley is the Document Shepherd and Mirja Kuehlewind is the Responsible Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of TCP Increased Security (TCPINC)
The TCP Increased Security (TCPINC) WG in the Transport Area has concluded. The IESG contact person is Mirja Kühlewind. The mailing list will be closed. With the publication of the two main RFCs the group concluded most of their charter (actually all of the initial milestones). The only left milestone on an extended API document was added to the charter later, in order to separate this part of the on-ongoing work form the protocol specification itself. However, there is no on-going work on this milestone right now, and the group is not planning to complete this document. Therefore the group will close without any further action on the remaining document. Closure of the group will also close the mailing list as there has not been a lot of traffic on the mailing list over the last 1-2 years. As tcpinc is part of the TCP protocol, any future questions on the protocol itself or maintenance can be brought to the TCP Maintenance and Minor Extensions (tcpm) mailing list: t...@ietf.org WG: https://datatracker.ietf.org/wg/tcpinc/about/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tcpinc/
RFC 8548 on Cryptographic Protection of TCP Streams (tcpcrypt)
A new Request for Comments is now available in online RFC libraries. RFC 8548 Title: Cryptographic Protection of TCP Streams (tcpcrypt) Author: A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith Status: Experimental Stream: IETF Date: May 2019 Mailbox:bit...@google.com, dan...@beech-grove.net, m.hand...@cs.ucl.ac.uk, d...@uun.org, s...@sourcegraph.com, eric.sm...@kestrel.edu Pages: 32 Characters: 75149 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpinc-tcpcrypt-15.txt URL:https://www.rfc-editor.org/info/rfc8548 DOI:10.17487/RFC8548 This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection. This document is a product of the TCP Increased Security Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 8547 on TCP-ENO: Encryption Negotiation Option
A new Request for Comments is now available in online RFC libraries. RFC 8547 Title: TCP-ENO: Encryption Negotiation Option Author: A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith Status: Experimental Stream: IETF Date: May 2019 Mailbox:bit...@google.com, dan...@beech-grove.net, m.hand...@cs.ucl.ac.uk, d...@uun.org, eric.sm...@kestrel.edu Pages: 31 Characters: 72176 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpinc-tcpeno-19.txt URL:https://www.rfc-editor.org/info/rfc8547 DOI:10.17487/RFC8547 Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. This document is a product of the TCP Increased Security Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: (TCP Extensions for Multipath Operation with Multiple Addresses) to Proposed Standard
The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'TCP Extensions for Multipath Operation with Multiple Addresses' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-04-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1842/ https://datatracker.ietf.org/ipr/1843/ https://datatracker.ietf.org/ipr/3242/ The document contains these normative downward references. See RFC 3967 for additional information: rfc6182: Architectural Guidelines for Multipath TCP Development (Informational - IETF stream)
Document Action: 'Cryptographic protection of TCP Streams (tcpcrypt)' to Experimental RFC (draft-ietf-tcpinc-tcpcrypt-15.txt)
The IESG has approved the following document: - 'Cryptographic protection of TCP Streams (tcpcrypt)' (draft-ietf-tcpinc-tcpcrypt-15.txt) as Experimental RFC This document is the product of the TCP Increased Security Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/ Technical Summary This document specifies tcpcrypt, a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data may be transmitted. However, this cost can be avoided between two hosts that have recently established a previous tcpcrypt connection. Working Group Summary Initially in the wg, there were two competing proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication removed (tcpinc-use-TLS). As both tcpcrypt and tcpinc-use-TLS are independent and fully-realized protocols, this led to an inability to achieve consensus. After the split off of tcp-eno, an extension notably to negotiate multiple TCP stream encryption protocols, allowing potentially for runtime negotiation of either tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol), the working group chairs made a call for adoption of both tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that both protocols could be concurrently deployed. However, due to competing demands for the TLS community, including for the editor of the tcpinc-use-TLS draft, especially for completion of TLS 1.3 work in early 2016, the tcpinc-use-TLS scheme was not further maintain (at least up to now). This was discussed in the tcpinc WG, and the resulting rough consensus of the WG was that the appropriate course of action was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure that ENO could eventually support a TLS profile. Document Quality There is only one current implementation of tcpcrypt (together with tcpeno), that being the reference implementation by the Stanford team. At least one other implementation effort is in progress. The inability to achieve consensus damaged the WG, as parties looking for a solution in this space grew weary of the lack of progress. Many who initially expressed interest in working on independent implementations lost interest and moved on to other work. The WG chairs believe that a reliable implementation distributed as part of a major operating system based on this experimental documen is the best approach to rekindling interest in this project and for encouraging the development of additional interoperating implementations. Personnel The document shepherd is Kyle Rose. The responsible AD is Mirja Kühlewind. IESG Note Based on comments received during IETF last cast, the latest version of this document (-08) now recommends a different AEAD algorithm as MIT. There is still some on-going discussion with the SEC ADs if only one MIT is acceptable. There is consensus in the working group to move forward with only one but they are also open for other recommendations as feedback from the IESG evaluation.
RFC 8511 on TCP Alternative Backoff with ECN (ABE)
A new Request for Comments is now available in online RFC libraries. RFC 8511 Title: TCP Alternative Backoff with ECN (ABE) Author: N. Khademi, M. Welzl, G. Armitage, G. Fairhurst Status: Experimental Stream: IETF Date: December 2018 Mailbox:nae...@ifi.uio.no, mich...@ifi.uio.no, garmit...@netflix.com, go...@erg.abdn.ac.uk Pages: 12 Characters: 27408 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-alternativebackoff-ecn-12.txt URL:https://www.rfc-editor.org/info/rfc8511 DOI:10.17487/RFC8511 Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'TCP Alternative Backoff with ECN (ABE)' to Experimental RFC (draft-ietf-tcpm-alternativebackoff-ecn-12.txt)
The IESG has approved the following document: - 'TCP Alternative Backoff with ECN (ABE)' (draft-ietf-tcpm-alternativebackoff-ecn-12.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ Technical Summary The recently published RFC 8311 (Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation) allows a TCP sender to react to an ECN signal in a different way than to a inferred loss signal if the behaviour is documented in an experimental RFC. This document describes such an experiment in which the reduction of the congestion window in response to an ECN signal is smaller than in response to an inferred packet loss. Therefore the TCPM working group requests publication as an experimental document. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality The document has been discussed several times in working group meetings without any major controversy. There were also no substantial problems reported during the working group last call and it is implemented for FreeBSD (the code has been committed to the FreeBSD code base). The risk of running this experiment is relatively low, since the reaction to a loss is not changed. There is very strong consensus in the TCPM working group that this document should be published. Personnel The document shepherd is Michael Tüxen . The responsible Area Director is Mirja Kühlewind .
Last Call: (TCP Alternative Backoff with ECN (ABE)) to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Alternative Backoff with ECN (ABE)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-08-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay- product is large. The reception of a Congestion Experienced (CE) ECN mark indicates that an AQM mechanism is used at the bottleneck, and therefore the bottleneck network queue is likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. This specification therefore defines an experimental change to the TCP reaction specified in RFC3168, as permitted by RFC 8311. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8323 on CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
A new Request for Comments is now available in online RFC libraries. RFC 8323 Title: CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Author: C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed. Status: Standards Track Stream: IETF Date: February 2018 Mailbox:c...@tzi.org, sle...@zebra.com, hannes.tschofe...@gmx.net, har...@tzi.org, bilhanan.silvera...@tut.fi, brianray...@hotmail.com Pages: 54 Characters: 110771 Updates:RFC 7641, RFC 7959 I-D Tag:draft-ietf-core-coap-tcp-tls-11.txt URL:https://www.rfc-editor.org/info/rfc8323 DOI:10.17487/RFC8323 The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets' to Proposed Standard (draft-ietf-core-coap-tcp-tls-11.txt)
The IESG has approved the following document: - 'CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets' (draft-ietf-core-coap-tcp-tls-11.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ Technical Summary The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. Working Group Summary The document has gone through multiple expert reviews over the years and was last presented on multiple IETF sessions. The discussion on whether the document should use coaps+ws:// versa coap+wss:// URI scheme was rather protracted, but the WG finally came to a conclusion. The decision to allocate several new URI schemes for different underlying transports has caused some controversy, but was finally settled after a discussion with IESG and URI experts. Document Quality Several vendors are interested in implementing the specification. Personnel Document Shepherd: Jaime Jiménez <jaime.jime...@ericsson.com> Responsible Area Director: Alexey Melnikov
RFC 8257 on Data Center TCP (DCTCP): TCP Congestion Control for Data Centers
A new Request for Comments is now available in online RFC libraries. RFC 8257 Title: Data Center TCP (DCTCP): TCP Congestion Control for Data Centers Author: S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd Status: Informational Stream: IETF Date: October 2017 Mailbox:sb...@microsoft.com, dtha...@microsoft.com, pr...@microsoft.com, l...@netapp.com, glenn.j...@morganstanley.com Pages: 17 Characters: 37357 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-dctcp-10.txt URL:https://www.rfc-editor.org/info/rfc8257 DOI:10.17487/RFC8257 This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: (TCP-ENO: Encryption Negotiation Option) to Experimental RFC
The IESG has received a request from the TCP Increased Security WG (tcpinc) to consider the following document: - 'TCP-ENO: Encryption Negotiation Option' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-10-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (Cryptographic protection of TCP Streams (tcpcrypt)) to Experimental RFC
The IESG has received a request from the TCP Increased Security WG (tcpinc) to consider the following document: - 'Cryptographic protection of TCP Streams (tcpcrypt)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-10-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies tcpcrypt, a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data may be transmitted. However, this cost can be avoided between two hosts that have recently established a previous tcpcrypt connection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' to Informational RFC (draft-ietf-tcpm-dctcp-10.txt)
The IESG has approved the following document: - 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' (draft-ietf-tcpm-dctcp-10.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ Technical Summary This informational memo describes Datacenter TCP (DCTCP). DCTCP is an improvement to TCP congestion control for datacenter traffic that uses Explicit Congestion Notification (ECN). DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters, but it must not be deployed over the public Internet without additional measures. The document is published to document an implementation in the Microsoft Windows Server 2012 operating system. The Linux and FreeBSD operating systems have also implemented support for DCTCP. Working Group Summary The TCPM working group has reviewed the document regarding clarity and comprehensiveness of the protocol specification, e.g. in corner cases. The document has been discussed multiple times in the working group without any major controversy. During the working group last call there have been several detailed reviews, and those comments have been addressed in the most recent version. All in all, there is very strong consensus in the TCPM working group that this document should be published. Document Quality The document describes DCTCP as implemented in Microsoft Windows Server 2012. Since the publication of the first versions of the document, the Linux and FreeBSD operating systems have also implemented support for DCTCP. The specification should also enable implementation in other TCP stacks. The objective of this informational memo is to document an alternative TCP congestion control algorithm that is known to be widely deployed. It is consensus in the TCPM working group that a DCTCP standard would require further work. A precise documentation of running code enables follow-up experimental or standards track RFCs. Personnel The document shepherd is Michael Scharf <michael.sch...@nokia.com>. The responsible Area Director is Mirja Kuehlewind <i...@kuehlewind.net>.
RFC 8229 on TCP Encapsulation of IKE and IPsec Packets
A new Request for Comments is now available in online RFC libraries. RFC 8229 Title: TCP Encapsulation of IKE and IPsec Packets Author: T. Pauly, S. Touati, R. Mantha Status: Standards Track Stream: IETF Date: August 2017 Mailbox:tpa...@apple.com, samy.tou...@ericsson.com, raman...@cisco.com Pages: 25 Characters: 56294 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-tcp-encaps-10.txt URL:https://www.rfc-editor.org/info/rfc8229 DOI:10.17487/RFC8229 This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Protocol Action: 'TCP Encapsulation of IKE and IPsec Packets' to Proposed Standard (draft-ietf-ipsecme-tcp-encaps-10.txt)
The IESG has approved the following document: - 'TCP Encapsulation of IKE and IPsec Packets' (draft-ietf-ipsecme-tcp-encaps-10.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ Technical Summary This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. Working Group Summary The draft came to the working group out of a need to standardize a push towards adding TCP support for IKE that was coming from several sources (VPN vendors and cellular carriers using IKE for telephony services). Some of the major changes that the WG made early on compared to existing proposals from external bodies was to remove the reliance on encapsulating IKE traffic within TLS. Much of the other WG discussion later on in review revolved around how to best manage the connection establishment and teardown transitions. Document Quality There are several early implementations of the protocol that were made to test interoperability (notably, Cisco and Apple). The draft also received input from vendors that have previously deployed proprietary versions of IPsec over TCP. Personnel The Document Shepherd is Tero Kivinen. The responsible ADs are Kathleen Moriarty (with Eric Rescorla taking custody for IESG revies).
Last Call: (TCP Encapsulation of IKE and IPsec Packets) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'TCP Encapsulation of IKE and IPsec Packets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-04-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets) to Proposed Standard
The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-04-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates [RFC7641] for use with these transports. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8041 on Use Cases and Operational Experience with Multipath TCP
A new Request for Comments is now available in online RFC libraries. RFC 8041 Title: Use Cases and Operational Experience with Multipath TCP Author: O. Bonaventure, C. Paasch, G. Detal Status: Informational Stream: IETF Date: January 2017 Mailbox:olivier.bonavent...@uclouvain.be, cpaa...@apple.com, gregory.de...@tessares.net Pages: 30 Characters: 75260 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mptcp-experience-07.txt URL:https://www.rfc-editor.org/info/rfc8041 DOI:10.17487/RFC8041 This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements. This document is a product of the Multipath TCP Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'Use Cases and Operational Experience with Multipath TCP' to Informational RFC (draft-ietf-mptcp-experience-07.txt)
The IESG has approved the following document: - 'Use Cases and Operational Experience with Multipath TCP' (draft-ietf-mptcp-experience-07.txt) as Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ Technical Summary This document discusses both use cases and operational experience with Multipath TCP in real world networks. It lists several prominent use cases for which Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases. Working Group Summary The WG consensus is good. Document Quality The document has been written by several of the people who have implemented the MPTCP protocol and who are intimately involved in its deployment. The document is very informative. Personnel The Document Shepherd is Philip Eardley. The Responsible Area Director is Mirja Kühlewind.
RFC 7974 on An Experimental TCP Option for Host Identification
A new Request for Comments is now available in online RFC libraries. RFC 7974 Title: An Experimental TCP Option for Host Identification Author: B. Williams, M. Boucadair, D. Wing Status: Experimental Stream: Independent Date: October 2016 Mailbox:brandon.willi...@akamai.com, mohamed.boucad...@orange.com, dwing-i...@fuggles.com Pages: 20 Characters: 48381 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-williams-exp-tcp-host-id-opt-08.txt URL:https://www.rfc-editor.org/info/rfc7974 DOI:http://dx.doi.org/10.17487/RFC7974 Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Last Call: (Use Cases and Operational Experience with Multipath TCP) to Informational RFC
The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'Use Cases and Operational Experience with Multipath TCP' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-09-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses both use cases and operational experience with Multipath TCP in real world networks. It lists several prominent use cases for which Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 7930 on Larger Packets for RADIUS over TCP
A new Request for Comments is now available in online RFC libraries. RFC 7930 Title: Larger Packets for RADIUS over TCP Author: S. Hartman Status: Experimental Stream: IETF Date: August 2016 Mailbox:hartmans-i...@mit.edu Pages: 10 Characters: 22676 Updates:RFC 6613 I-D Tag:draft-ietf-radext-bigger-packets-07.txt URL:https://www.rfc-editor.org/info/rfc7930 DOI:http://dx.doi.org/10.17487/RFC7930 The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval. This document is a product of the RADIUS EXTensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing to Historic
The IESG has approved changing the status of the following document: - TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing (rfc1347) to Historic This document action is documented at: https://datatracker.ietf.org/doc/status-change-ip-versions-5-8-9-to-historic/ A URL of the affected document is: https://datatracker.ietf.org/doc/rfc1347/ Status Change Details: A variety of alternative architectures have been proposed as the successor to IPv4. Many of these proposals have been published as RFCs and allocated IP version numbers by IANA. This status change formally moves RFC 1347, RFC 1819, RFC 1621,and RFC 1622 to Historic status. As a part of this status change, IANA is directed to change IP version numbers 5, 8, and 9 to Reserved in the IP Version Numbers registry (http://www.iana.org/assignments/version-numbers/version-numbers.xhtml) and add this status-change document to their references. Additionally, version number 7 is to be marked Reserved and its reference updated to include RFC 6814. Personnel Suresh Krishnan is the responsible Area Director.
Document Action: 'Larger Packets for RADIUS over TCP' to Experimental RFC (draft-ietf-radext-bigger-packets-07.txt)
The IESG has approved the following document: - 'Larger Packets for RADIUS over TCP' (draft-ietf-radext-bigger-packets-07.txt) as Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Stephen Farrell, Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Technical Summary: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packets proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. Working Group Summary: The document advanced through the working group stage smoothly. The amount of review it got was not overwhelming, but enough people participated to make it a solid and credible review and consensus overall. Document Quality: The document was reviewed by key contributors of the radext working group. It has not undergone an external review yet. There should be a review of the new Protocol-Error packet type during the IETF Last Call and IESG evaluation, since the allocation of a new packet type requires IESG approval. At least one vendor (FreeRADIUS) has indicated an interest to implement this specification. Personnel: The Document Shepherd is Stefan Winter <stefan.win...@restena.lu>. The responsible Area Director is Kathleen Moriarty (kathleen.moriarty.i...@gmail.com); currently Stephen Farrell (stephen.farr...@cs.tcd.ie).
RFC 7786 on TCP Modifications for Congestion Exposure (ConEx)
A new Request for Comments is now available in online RFC libraries. RFC 7786 Title: TCP Modifications for Congestion Exposure (ConEx) Author: M. Kuehlewind, Ed., R. Scheffenegger Status: Experimental Stream: IETF Date: May 2016 Mailbox:mirja.kuehlew...@tik.ee.ethz.ch, rs.i...@gmx.at Pages: 20 Characters: 48439 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-conex-tcp-modifications-10.txt URL:https://www.rfc-editor.org/info/rfc7786 DOI:http://dx.doi.org/10.17487/RFC7786 Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). This document is a product of the Congestion Exposure Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7850 on Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles
A new Request for Comments is now available in online RFC libraries. RFC 7850 Title: Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles Author: S. Nandakumar Status: Standards Track Stream: IETF Date: April 2016 Mailbox:snand...@cisco.com Pages: 7 Characters: 15190 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-proto-iana-registration-06.txt URL:https://www.rfc-editor.org/info/rfc7850 DOI:http://dx.doi.org/10.17487/RFC7850 The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7805 on Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status
A new Request for Comments is now available in online RFC libraries. RFC 7805 Title: Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status Author: A. Zimmermann, W. Eddy, L. Eggert Status: Informational Stream: IETF Date: April 2016 Mailbox:alexan...@zimmermann.eu.com, w...@mti-systems.com, l...@netapp.com Pages: 8 Characters: 15754 Obsoletes: RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, RFC 6013 Updates:RFC 7414 I-D Tag:draft-ietf-tcpm-undeployed-03.txt URL:https://www.rfc-editor.org/info/rfc7805 DOI:http://dx.doi.org/10.17487/RFC7805 This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013. Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 7828 on The edns-tcp-keepalive EDNS0 Option
A new Request for Comments is now available in online RFC libraries.
RFC 7828
Title: The edns-tcp-keepalive EDNS0 Option
Author: P. Wouters,
J. Abley,
S. Dickinson,
R. Bellis
Status: Standards Track
Stream: IETF
Date: April 2016
Mailbox:pwout...@redhat.com,
jab...@dyn.com,
s...@sinodun.com,
r...@isc.org
Pages: 11
Characters: 24282
Updates/Obsoletes/SeeAlso: None
I-D Tag:draft-ietf-dnsop-edns-tcp-keepalive-06.txt
URL:https://www.rfc-editor.org/info/rfc7828
DOI:http://dx.doi.org/10.17487/RFC7828
DNS messages between clients and servers may be received over
either UDP or TCP. UDP transport involves keeping less state
on a busy server, but can cause truncation and retries over
TCP. Additionally, UDP can be exploited for reflection attacks.
Using TCP would reduce retransmits and amplification. However,
clients commonly use TCP only for retries and servers typically
use idle timeouts on the order of seconds.
This document defines an EDNS0 option ("edns-tcp-keepalive")
that allows DNS servers to signal a variable idle timeout.
This signalling encourages the use of long-lived TCP connections
by allowing the state associated with TCP transport to be managed
effectively with minimal impact on the DNS transaction time.
This document is a product of the Domain Name System Operations
Working Group of the IETF.
This is now a Proposed Standard.
STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. Distribution of this
memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
https://www.ietf.org/mailman/listinfo/ietf-announce
https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
Association Management Solutions, LLC
Protocol Action: 'IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.' to Proposed Standard (draft-ietf-mmusic-proto-iana-registration-06.txt)
The IESG has approved the following document: - 'IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.' (draft-ietf-mmusic-proto-iana-registration-06.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Barry Leiba, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ Technical Summary The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. Working Group Summary There was nothing worth noting in the working group process. Document Quality Flemming Andreasen, Bo Burman and Cullen Jennings reviewed the document and found no issues. Personnel The Document Shepherd is Bo Burman. The Responsible AD is Ben Campbell.
Last Call: (Larger Packets for RADIUS over TCP) to Experimental RFC
The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'Larger Packets for RADIUS over TCP' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-03-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: (IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.) to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'IANA registrations of SDP 'proto' attribute for transporting RTP Media over TCP under various RTP profiles.' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-02-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/ SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-proto-iana-registration/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 7765 on TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
A new Request for Comments is now available in online RFC libraries. RFC 7765 Title: TCP and Stream Control Transmission Protocol (SCTP) RTO Restart Author: P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl Status: Experimental Stream: IETF Date: February 2016 Mailbox:per.hur...@kau.se, anna.brunst...@kau.se, apetl...@simula.no, mich...@ifi.uio.no Pages: 15 Characters: 35361 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-rtorestart-10.txt URL:https://www.rfc-editor.org/info/rfc7765 DOI:http://dx.doi.org/10.17487/RFC7765 This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07
The IESG has completed a review of draft-williams-exp-tcp-host-id-opt-07 consistent with RFC5742. The IESG recommends that 'Experimental Option for TCP Host Identification' NOT be published as an Experimental RFC. The IESG has concluded that this document violates IETF procedures about pervasive monitoring (RFC 7258) and should therefore not be published without IETF review and IESG approval. This work is related to IETF work done in the INTAREA WG. The IESG would also like the Independent Submissions Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Document Action: 'Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status' to Informational RFC (draft-ietf-tcpm-undeployed-03.txt)
The IESG has approved the following document: - 'Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status' (draft-ietf-tcpm-undeployed-03.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ Technical Summary This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013. Additionally, this document reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and RFC 1071 to "Informational" status. Working Group Summary The inclusion of the TCPMUX document (RFC 1078) raised some discussion earlier, because implementations of TCPMUX have been reported in some OS distributions, although it is not in use to our knowledge. There was consensus in the TCPM WG that because of the operational and security concerns in TCPMUX, it should also be declared Historic. Document Quality Document was reviewed by multiple TCPM WG participants. Given its administrative nature, there has been no controversy over it, and it is generally supported by the TCPM community. Personnel Document shepherd is Pasi Sarolahti. Responsible Area Director is Martin Stiemerling.
Protocol Action: 'DNS Transport over TCP - Implementation Requirements' to Proposed Standard (draft-ietf-dnsop-5966bis-06.txt)
The IESG has approved the following document: - 'DNS Transport over TCP - Implementation Requirements' (draft-ietf-dnsop-5966bis-06.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ Technical Summary The document specifies the requirements for support TCP as a transport protocol for DNS. It also provides guidelines on optimizing performance of DNS over TCP. This document obsoletes RFC 5966. Working Group Summary This document was actively discussed and reviewed, partially because this is a revision of an older RFC, but also as more DNS falls back to TCP (DNSSEC) and the need for DNS to support the DNS-over-TLS work in DPRIVE working group. The community feels updating the older RFC is well needed. This also include the initial author of RFC5966. The document had a broad discussion as the wording of several points were more accurately described. Once these issues were resolved, consensus was strong with no complaints. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli
Last Call: (DNS Transport over TCP - Implementation Requirements) to Internet Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Transport over TCP - Implementation Requirements' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-12-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC5966. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'TCP and SCTP RTO Restart' to Experimental RFC (draft-ietf-tcpm-rtorestart-10.txt)
The IESG has approved the following document: - 'TCP and SCTP RTO Restart' (draft-ietf-tcpm-rtorestart-10.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ Technical Summary This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. Working Group Summary It is the consensus of the TCPM working group to document this alternative algorithm, given the potential performance benefit. The work has mostly been driven by the authors, but the document has been reviewed in detail by several experts and the content has been modified accordingly. Performance experiments in simulations and testbeds have been performed and published by the authors and the experimental results have been reviewed in several TCPM meetings. At the time of writing, there is only limited deployment experience. Two issues have been discussed extensively in the working group. First, any reduction of the retransmission timeout duration inherently comes along with a risk of negative impact on TCP performance, e.g. in mobile networks with highly variable RTT. The current understanding is that this risk is low and that the algorithm is conservative and relatively robust, but further experimentation has to confirm this. Second, the Linux operation system uses the "Tail Loss Probe" method discussed in Section 6, which is similar but more complex. This method was not adopted in TCPM since it depends on FACK error recovery method, which has not been standardizes so far. Document Quality This document was also last called in TSVWG, since it specifies an algorithm that can be applied both to TCP and SCTP. As a result of WGLC comments the applicability to SCTP has been better explained, including the SCTP API. One issue is that TCP and SCTP use slightly different terminology for comparable concepts. In order to keep the document simple, it was decided not to add another, duplicated description of the algorithm using SCTP terminology. Personnel The document shepherd is Michael Scharf <michael.scharf@alcatel- lucent.com>. The responsible Area Director is Martin Stiemerling <mls.i...@gmail.com>.
Last Call: (The edns-tcp-keepalive EDNS0 Option) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'The edns-tcp-keepalive EDNS0 Option'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2015-11-30. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
DNS messages between clients and servers may be received over either
UDP or TCP. UDP transport involves keeping less state on a busy
server, but can cause truncation and retries over TCP. Additionally,
UDP can be exploited for reflection attacks. Using TCP would reduce
retransmits and amplification. However, clients commonly use TCP
only for fallback and servers typically use idle timeouts on the
order of seconds.
This document defines an EDNS0 option ("edns-tcp-keepalive") that
allows DNS servers to signal a variable idle timeout. This
signalling facilitates a better balance of UDP and TCP transport
between individual clients and servers, reducing the impact of
problems associated with UDP transport and allowing the state
associated with TCP transport to be managed effectively with minimal
impact on the DNS transaction time.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ballot/
No IPR declarations have been submitted directly on this I-D.
Last Call: (TCP and SCTP RTO Restart) to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP and SCTP RTO Restart' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-conex-tcp-modifications-09.txt (TCP modifications for Congestion Exposure) to Experimental RFC
The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'TCP modifications for Congestion Exposure' draft-ietf-conex-tcp-modifications-09.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-08-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1922/
New Non-WG Mailing List: TCP Prague -- Evolution of DCTCP designed to live alongside other TCP variants and derivatives
A new IETF non-working group email list has been created. List address: tcppra...@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/tcpprague/ To subscribe: https://www.ietf.org/mailman/listinfo/tcpprague Purpose: This mailing list is to coordinate parallel implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of Data Centre TCP (DCTCP) designed to live alongside other TCP variants and derivatives. DCTCP has demonstrated how minimal latency could be, but it is only applicable in controlled environments such as data centers. This is because the congestion control in DCTCP dominates existing variants (Reno, Cubic, etc) and DCTCP redefines the meaning of TCP-ECN feedback. The defining features of TCP Prague will be: o Designed to exploit the full potential of ECN in the network o Marking frequency invariant with flow rate. For additional information, please contact the list administrators.
Document Action: 'Updating TCP to support Rate-Limited Traffic' to Experimental RFC (draft-ietf-tcpm-newcwv-13.txt)
The IESG has approved the following document: - 'Updating TCP to support Rate-Limited Traffic' (draft-ietf-tcpm-newcwv-13.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ Technical Summary This document describes an experimental proposal to allow TCP senders to restart data transfer quickly following an idle or less active period. This approach is expected to benefit applications that unable to send at the maximum rate permitted by the congestion window for some reasons. As a result, it aims to provide incentives for long-lived connections and to remove ad-hoc tweaks in some applications that try to maintain a large cwnd for future data transmissions. The approach can be viewed as an updated version of RFC2861 and it obsoletes RFC2861. Working Group Summary The draft has been discussed for around 4 years. There has been explicit support for the draft since the beginning. Main discussion points were some detailed mechanisms in the logic that are related to estimating path capacity and preserving congestion window size during applications are idle or less active. The initial intended status of the draft was PS, but it has been changed to Experimental as a result of the discussions. Linux kernel has the codes which address the same issue. Their algorithms are slightly different from the document. There had been discussions between the linux kernel implementers and the document authors; however, they haven't reached the consensus to replace the existing kernel codes until more solid evidences are found. The WG's conclusion is to publish the draft as an experimental and explore its efficiency and feasibility of this approach. Document Quality The document has been reviewed and discussed by multiple participants in the WG. Some discussions points raised by reviewers are listed in Section 9.1. The patches to FreeBSD and Linux kernel have been made by the efforts from the authors and other group. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Martin Stiemerling
Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-05
The IESG has completed a review of draft-williams-exp-tcp-host-id-opt-05 consistent with RFC5742. The IESG recommends that 'Experimental Option for TCP Host Identification' draft-williams-exp-tcp-host-id-opt-05.txt NOT be published as an Experimental RFC. The IESG has concluded that this document violates IETF procedures about pervasive monitoring (RFC 7258) and should therefore not be published without IETF review and IESG approval. This work is related to IETF work done in the INTAREA WG. The IESG would also like the RFC-Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Last Call: draft-ietf-tcpm-newcwv-10.txt (Updating TCP to support Rate-Limited Traffic) to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Updating TCP to support Rate-Limited Traffic' draft-ietf-tcpm-newcwv-10.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-05-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a mechanism to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ballot/ No IPR declarations have been submitted directly on this I-D.
WG Review: TCP Maintenance and Minor Extensions (tcpm)
The TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-23. TCP Maintenance and Minor Extensions (tcpm) Current Status: Active WG Chairs: Michael Scharf michael.sch...@alcatel-lucent.com Yoshifumi Nishida nish...@sfc.wide.ad.jp Pasi Sarolahti pasi.sarola...@iki.fi Assigned Area Director: Martin Stiemerling mls.i...@gmail.com Mailing list Address: t...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/ Charter: TCP is currently the Internet's predominant transport protocol. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative TCP congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Aug 2013 - Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC Nov 2013 - Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone) Nov 2013 - Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC Mar 2014 - Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC Mar 2015 - Submit document obsoleting undeployed TCP extensions to the IESG for publication as an Informational RFC Aug 2015 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC
RFC 7414 on A Roadmap for Transmission Control Protocol (TCP) Specification Documents
A new Request for Comments is now available in online RFC libraries. RFC 7414 Title: A Roadmap for Transmission Control Protocol (TCP) Specification Documents Author: M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann Status: Informational Stream: IETF Date: February 2015 Mailbox:m.d...@f5.com, bra...@isi.edu, w...@mti-systems.com, e...@interruptsciences.com, alexander.zimmerm...@netapp.com Pages: 57 Characters: 130622 Obsoletes: RFC 4614 I-D Tag:draft-ietf-tcpm-tcp-rfc4614bis-08.txt URL:https://www.rfc-editor.org/info/rfc7414 This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'TCP Fast Open' to Experimental RFC (draft-ietf-tcpm-fastopen-10.txt)
The IESG has approved the following document: - 'TCP Fast Open' (draft-ietf-tcpm-fastopen-10.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ Technical Summary This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. Working Group Summary This document was extensively discussed and reviewed by the TCPM working group and there is strong support to publish the document. While being an experimental document, the TCPM working group decided to ask IESG for approving an IANA allocation of a new TCP option codepoint. Document Quality The protocol extension described in this document is implemented and deployed in the Linux TCP/IP stack, and it is supported by the Chrome Web browser and all Google servers. Experimental results have been discussed in the TCPM working group. An early SECDIR review concluded that the document had no substantive issues. Personnel The Document Shepherd is Michael Scharf michael.sch...@alcatel-lucent.com. The Responsible Area Director is Martin Stiemerling mls.i...@gmail.com.
RFC 7323 on TCP Extensions for High Performance
A new Request for Comments is now available in online RFC libraries. RFC 7323 Title: TCP Extensions for High Performance Author: D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed. Status: Standards Track Stream: IETF Date: September 2014 Mailbox:david.bor...@quantum.com, bra...@isi.edu, v...@google.com, r...@netapp.com Pages: 49 Characters: 106013 Obsoletes: RFC 1323 I-D Tag:draft-ietf-tcpm-1323bis-21.txt URL:https://www.rfc-editor.org/rfc/rfc7323.txt This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein. This document obsoletes RFC 1323 and describes changes from it. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
Document Action: 'A Roadmap for Transmission Control Protocol (TCP) Specification Documents' to Informational RFC (draft-ietf-tcpm-tcp-rfc4614bis-08.txt)
The IESG has approved the following document: - 'A Roadmap for Transmission Control Protocol (TCP) Specification Documents' (draft-ietf-tcpm-tcp-rfc4614bis-08.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ Technical Summary Due to long-term development efforts, understanding TCP is becoming difficult as it consists of many separated RFCs. This document provides a summary of the various documents related to TCP standards, guidelines and best current practices. The objective of the document is to provide a roadmap for TCP standards so that implementers and other parties can reach proper information smoothly and quickly. Working Group Summary This document is the update from RFC4614 which has been published for the same purpose. As the information in RFC4614 is getting stale, there has been consensus in the WG to publish a new version. One discussion point was whether we will keep publishing this type of documents from time to time or find a way to provide up-to-date information through dynamic contents such as Wiki or perpetual I-D. After some discussions, we have concluded to publish this document as an RFC. The consensus was clear as we need further discussions for the other methods and there was no strong support for them. Document Quality The document has been reviewed and discussed by multiple participants in the WG. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Martin Stiemerling
Last Call: draft-ietf-tcpm-fastopen-09.txt (TCP Fast Open) to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Fast Open' draft-ietf-tcpm-fastopen-09.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-tcpm-tcp-rfc4614bis-05.txt (A Roadmap for Transmission Control Protocol (TCP) Specification Documents) to Informational RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'A Roadmap for Transmission Control Protocol (TCP) Specification Documents' draft-ietf-tcpm-tcp-rfc4614bis-05.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-06-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains a roadmap to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 7242 on Delay-Tolerant Networking TCP Convergence-Layer Protocol
A new Request for Comments is now available in online RFC libraries. RFC 7242 Title: Delay-Tolerant Networking TCP Convergence-Layer Protocol Author: M. Demmer, J. Ott, S. Perreault Status: Experimental Stream: IRTF Date: June 2014 Mailbox:dem...@cs.berkeley.edu, j...@netlab.tkk.fi, si...@per.reau.lt Pages: 22 Characters: 53818 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-irtf-dtnrg-tcp-clayer-09.txt URL:http://www.rfc-editor.org/rfc/rfc7242.txt This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG). This document is a product of the Delay-Tolerant Networking Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP
A new IETF non-working group email list has been created. List address: tcpcr...@ietf.org Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/ To subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt Purpose: The goal of this mailing list is to discuss encryption of TCP sessions, without necessarily requiring endpoint authentication in all cases (but while also making endpoint authentication possible). The initial purpose of the mailing list is to discuss the scope and a potential charter of a WG that would work on the definition of TCP extensions to support such encryption, or to find an existing WG to perform the work. For additional information, please contact the list administrators.
Results of IETF-conflict review for draft-irtf-dtnrg-tcp-clayer-08
The IESG has completed a review of draft-irtf-dtnrg-tcp-clayer-08 consistent with RFC5742. The IESG has no problem with the publication of 'Delay Tolerant Networking TCP Convergence Layer Protocol' draft-irtf-dtnrg-tcp-clayer-08.txt as an Experimental RFC. The IESG has concluded that there is no conflict between this document and IETF work. The IESG would also like the IRTF to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: http://datatracker.ietf.org/doc/conflict-review-irtf-dtnrg-tcp-clayer/ A URL of the reviewed Internet Draft is: http://datatracker.ietf.org/doc/draft-irtf-dtnrg-tcp-clayer/ The process for such documents is described in RFC 5743 Thank you, The IESG Secretary
Last Call: draft-ietf-tcpm-1323bis-19.txt (TCP Extensions for High Performance) to Proposed Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Extensions for High Performance' draft-ietf-tcpm-1323bis-19.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-02-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, PAWS (Protection Against Wrapped Sequences) and RTTM (Round Trip Time Measurement), that are also described herein. This document obsoletes RFC1323 and describes changes from it. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ballot/ No IPR declarations have been submitted directly on this I-D.
