Last Call: (Export of UDP Options Information in IP Flow Information Export (IPFIX)) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Export of UDP Options Information in IP Flow Information Export (IPFIX)' 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 for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (ops...@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-tsvwg-udp-options: Transport Options for UDP (None - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry' 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 provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ 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 9566 on Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP
A new Request for Comments is now available in online RFC libraries. RFC 9566 Title: Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP Author: B. Varga, J. Farkas, A. Malis Status: Informational Stream: IETF Date: April 2024 Mailbox:balazs.a.va...@ericsson.com, janos.far...@ericsson.com, agma...@gmail.com Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-detnet-mpls-over-ip-preof-11.txt URL:https://www.rfc-editor.org/info/rfc9566 DOI:10.17487/RFC9566 This document describes how the DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for the DetNet MPLS data plane and the mechanisms defined by MPLS-over-UDP technology. This document is a product of the Deterministic Networking 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
Document Action: 'Operations, Administration, and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane' to Informational RFC (draft-ietf-detnet-ip-oam-13.txt)
The IESG has approved the following document: - 'Operations, Administration, and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane' (draft-ietf-detnet-ip-oam-13.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Jim Guichard, Andrew Alston, John Scudder and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam/ Technical Summary This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. Working Group Summary The normal WG process has been followed and the documents reflect WG consensus with nothing special worth mentioning. Document Quality While there is interest in this specification from multiple vendors, there are no publicly known implementations yet. The document is one of the key deliverables of the WG. Personnel The Document Shepherd for this document is János Farkas. The Responsible Area Director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9565 on An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element
A new Request for Comments is now available in online RFC libraries. RFC 9565 Title: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element Author: M. Boucadair Status: Standards Track Stream: IETF Date: March 2024 Mailbox:mohamed.boucad...@orange.com Pages: 7 Obsoletes: RFC 7125 I-D Tag:draft-ietf-opsawg-rfc7125-update-07.txt URL:https://www.rfc-editor.org/info/rfc9565 DOI:10.17487/RFC9565 RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated. This document removes stale information from the IANA "IPFIX Information Elements" registry and avoids future conflicts with the authoritative IANA "TCP Header Flags" registry. This document obsoletes RFC 7125. This document is a product of the Operations and Management Area Working Group 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: 'Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP' to Informational RFC (draft-ietf-detnet-mpls-over-ip-preof-11.txt)
The IESG has approved the following document: - 'Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP' (draft-ietf-detnet-mpls-over-ip-preof-11.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Jim Guichard, Andrew Alston, John Scudder and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-ip-preof/ Technical Summary This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for DetNet MPLS Data Plane and the mechanisms defined by MPLS-over-UDP technology. Working Group Summary This was nothing notable to report during the WG consensus processes. Document Quality This is an information document related to internal implementation of MPLS PREOF [RFC8964] and the mechanisms defined in [RFC9025]. No specific implementations have been discussed or disclosed. Personnel The Document Shepherd for this document is Lou Berger. The Responsible Area Director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element' to Proposed Standard (draft-ietf-opsawg-rfc7125-update-07.txt)
The IESG has approved the following document: - 'An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element' (draft-ietf-opsawg-rfc7125-update-07.txt) as Proposed Standard This document is the product of the Operations and Management Area 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-opsawg-rfc7125-update/ Technical Summary RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated. This document removes stale information from the IPFIX registry and avoids future conflicts with the authoritative TCP Header Flags registry. This document obsoletes RFC 7125. Working Group Summary There was one point of controversy, but that has been resolved. Otherwise, there is nothing else worth noting. Document Quality This work represents a cleanup of the tcpControlBits as it relates to IPFIX so that operators can interpret flow data more accurately. Implementations insofar as TCP and IPFIX have existed for a long time. Implementations for this update are very likely. Personnel The Document Shepherd for this document is Joe Clarke. 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: (Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane' 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 2024-02-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 defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam/ 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: (Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP' 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 2023-12-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 describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for DetNet MPLS Data Plane and the mechanisms defined by MPLS-over-UDP technology. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-ip-preof/ 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: 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' to Best Current Practice (draft-ietf-tsvwg-ecn-encap-guidelines-22.txt)
The IESG has approved the following document: - 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' (draft-ietf-tsvwg-ecn-encap-guidelines-22.txt) as Best Current Practice This document is the product of the Transport and Services 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-tsvwg-ecn-encap-guidelines/ Technical Summary The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the advice to subnetwork designers about ECN in RFC 3819. Working Group Summary Sebastian Moeller repeatedly questioned on the mailing list the use of recommendations that were based on an earlier BCP, i.e. RFC 7141, saying that some of the earlier concepts recommended in RFC 7141 were yet to be implemented. The chairs and editors are content that the current revision has considered this feedback and looked into these topics, and that citing RFC 7141 is consistent with good practice. Document Quality This is a BCP that is not directly implementable, but 4 RFCs and 3 I-Ds reference it. Personnel The Document Shepherd for this document is Gorry Fairhurst. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' to Proposed Standard (draft-ietf-tsvwg-rfc6040update-shim-23.txt)
The IESG has approved the following document: - 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' (draft-ietf-tsvwg-rfc6040update-shim-23.txt) as Proposed Standard This document is the product of the Transport and Services 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-tsvwg-rfc6040update-shim/ Technical Summary RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. Working Group Summary The WG reached consensus following a WGLC that concluded on 25th April 2021, and rev 14 was thought to resolve the WG comments. This document has a dependency on ietf-tsvwg-ecn-encap-guidelines, and that document has stalled publication of this draft. Since rev-14, the author has continued to correct text and respond to Shepherd comments. Document Quality There are a wide variety of tunnel specifications and implementations, some of these are thought to follow the design described in this document. Personnel The Document Shepherd for this document is Gorry Fairhurst. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9502 on IGP Flexible Algorithm in IP Networks
A new Request for Comments is now available in online RFC libraries. RFC 9502 Title: IGP Flexible Algorithm in IP Networks Author: W. Britto, S. Hegde, P. Kaneriya, R. Shetty, R. Bonica, P. Psenak Status: Standards Track Stream: IETF Date: November 2023 Mailbox:bwill...@juniper.net, shrad...@juniper.net, pkane...@juniper.net, mraj...@juniper.net, rbon...@juniper.net, ppse...@cisco.com Pages: 21 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lsr-ip-flexalgo-16.txt URL:https://www.rfc-editor.org/info/rfc9502 DOI:10.17487/RFC9502 This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding. This document is a product of the Link State Routing 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 9487 on Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)
A new Request for Comments is now available in online RFC libraries. RFC 9487 Title: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) Author: T. Graf, B. Claise, P. Francois Status: Standards Track Stream: IETF Date: November 2023 Mailbox:thomas.g...@swisscom.com, benoit.cla...@huawei.com, pierre.franc...@insa-lyon.fr Pages: 23 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsawg-ipfix-srv6-srh-14.txt URL:https://www.rfc-editor.org/info/rfc9487 DOI:10.17487/RFC9487 This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with. This document is a product of the Operations and Management Area Working Group 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
New Non-WG Mailing List: nipc (non-IP control)
A new IETF non-working group email list has been created. List address: n...@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/nipc/ To subscribe: https://www.ietf.org/mailman/listinfo/nipc Purpose: This mailing list is intended to discuss IP-based application-layer gateway interfaces of non-IP devices, such as BLE, Zigbee, enOcean, and others. This list belongs to IETF area: ART For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) to Best Current Practice
The IESG has received a request from the Transport and Services Working Group WG (tsvwg) to consider the following document: - 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' 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 2023-11-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 The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the advice to subnetwork designers about ECN in RFC 3819. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5129: Explicit Congestion Marking in MPLS (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6040: Tunnelling of Explicit Congestion Notification (Proposed Standard - Internet Engineering Task Force (IETF)) draft-ietf-trill-ecn-support: TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support (None - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim) to Proposed Standard
The IESG has received a request from the Transport and Services Working Group WG (tsvwg) to consider the following document: - 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' 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-11-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 RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ 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 9484 on Proxying IP in HTTP
A new Request for Comments is now available in online RFC libraries. RFC 9484 Title: Proxying IP in HTTP Author: T. Pauly, Ed., D. Schinazi, A. Chernyakhovsky, M. Kühlewind, M. Westerlund Status: Standards Track Stream: IETF Date: October 2023 Mailbox:tpa...@apple.com, dschinazi.i...@gmail.com, acher...@google.com, mirja.kuehlew...@ericsson.com, magnus.westerl...@ericsson.com Pages: 37 Updates:RFC 9298 I-D Tag:draft-ietf-masque-connect-ip-13.txt URL:https://www.rfc-editor.org/info/rfc9484 DOI:10.17487/RFC9484 This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. This document is a product of the Multiplexed Application Substrate over QUIC Encryption 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: (An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element' 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-10-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 RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated. This document removes stale information from the IPFIX registry and avoids future conflicts with the authoritative TCP Header Flags registry. This document obsoletes RFC 7125. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/ 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
BCP 238, RFC 9455 on Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes
A new Request for Comments is now available in online RFC libraries. BCP 238 RFC 9455 Title: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes Author: Z. Yan, R. Bush, G. Geng, T. de Kock, J. Yao Status: Best Current Practice Stream: IETF Date: August 2023 Mailbox:yanzhi...@cnnic.cn, ra...@psg.com, ggg...@jnu.edu.cn, tdek...@ripe.net, ya...@cnnic.cn Pages: 6 See Also: BCP 238 I-D Tag:draft-ietf-sidrops-roa-considerations-08.txt URL:https://www.rfc-editor.org/info/rfc9455 DOI:10.17487/RFC9455 When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es). This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix. This document is a product of the SIDR 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
Protocol Action: 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' to Proposed Standard (draft-ietf-lsr-ip-flexalgo-16.txt)
The IESG has approved the following document: - 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' (draft-ietf-lsr-ip-flexalgo-16.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ Technical Summary An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. The base IGP Flex-Algorithm specification describes how it is used with Segment Routing (SR) data planes - SR MPLS and SRv6. This document extends IGP Flex-Algorithm, so that it can be used with regular IPv4 and IPv6 forwarding. Working Group Summary From the shepherd writeup: We had a great discussion of the use cases and terminology and, as a result, there will be changes in the version submitted for publication. One individual WG member strongly suggested a solution that wouldn't interoperate with routers not supporting Flex Algo. However, it is not uncommon for this WG member to be in the minority. Document Quality From the shepherd writeup: Cisco IOS-XR has an implementation that is shipping for IS-IS. Juniper has an implementation that has not yet shipped. Personnel The Document Shepherd for this document is Acee Lindem. The Responsible Area Director is John Scudder. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)' to Proposed Standard (draft-ietf-opsawg-ipfix-srv6-srh-14.txt)
The IESG has approved the following document: - 'Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)' (draft-ietf-opsawg-ipfix-srv6-srh-14.txt) as Proposed Standard This document is the product of the Operations and Management Area 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-opsawg-ipfix-srv6-srh/ Technical Summary This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of Segment Routing over IPv6 (SRv6) related information such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 endpoint behavior that traffic is being forwarded with. Working Group Summary No controversy is to be reported for the draft. The authors were responsive in dealing with the comments raised by reviewers. One aspect that required some cycles is related to the IANA actions. For example, previous versions of the specification requested the creation of new registries that are redundant with existing IANA registries. That design was problematic. That issue and similar ones were fixed in subsequent iterations of the draft after consulting with the IANA. Document Quality Yes. At least, the following implementations were disclosed: * open-source flow collector pmacct: [https://github.com/pmacct/pmacct] * VPP: [https://github.com/insa-unyte/vpp-srh-onpath-telemetry] * Huawei VRP Personnel The Document Shepherd for this document is Mohamed Boucadair. The Responsible Area Director is Robert Wilton. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Proxying IP in HTTP' to Proposed Standard (draft-ietf-masque-connect-ip-13.txt)
The IESG has approved the following document: - 'Proxying IP in HTTP' (draft-ietf-masque-connect-ip-13.txt) as Proposed Standard This document is the product of the Multiplexed Application Substrate over QUIC Encryption 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-masque-connect-ip/ Technical Summary This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as a proxy. This document updates RFC 9298. Working Group Summary There was some controversy on the mechanics of CONNECT-IP prior to the work being adopted by the group. However, all of those points have since been resolved with a balance of essential core behavior and room for extensions. Document Quality Yes, there are several interoperable implementations of the document, including from Google [1], Ericsson, and Apple. Some of them are open source [1] whereas others are closed source. [1] https://github.com/google/quiche/tree/main/quiche/quic/masque Personnel The shepherd is Christopher Wood. The AD is Martin Duke. The IANA experts for the registries in this document are Tommy Pauly (tpa...@apple.com) and Magnus Westerlund (magnus.westerl...@ericsson.com). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Avoidance of ROA Containing Multiple IP Prefixes' to Best Current Practice (draft-ietf-sidrops-roa-considerations-08.txt)
The IESG has approved the following document: - 'Avoidance of ROA Containing Multiple IP Prefixes' (draft-ietf-sidrops-roa-considerations-08.txt) as Best Current Practice This document is the product of the SIDR 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-sidrops-roa-considerations/ Technical Summary When using the RPKI, address space holders need to issue ROA object(s) to authorize one or more ASes to originate routes to IP prefix(es). This memo discusses operational problems which may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix. Working Group Summary There was consensus in the SIDROPS WG to progress this document. After WGLC there were some additional changes made to further improve the document, including discussing scaling and tightening the recommendation text. The chairs confirmed that the changes were editorial, and still had WG consensus. Document Quality ROAs that follow the recommendation in this memo have been tested with several tools; no errors or concerns were found. This is unsurprising, as ROAs that follow the recommendation are the standard / base case (basically the document is recommending that people avoid a less common feature without good reason). Personnel Russ Housley is DS Warren Kumari is RAD! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (IGP Flexible Algorithms (Flex-Algorithm) In IP Networks) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' 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-05-16. 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 An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. The base IGP Flex-Algorithm specification describes how it is used with Segment Routing (SR) data planes - SR MPLS and SRv6. This document extends IGP Flex-Algorithm, so that it can be used with regular IPv4 and IPv6 forwarding. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4317/ https://datatracker.ietf.org/ipr/4519/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Avoidance of ROA Containing Multiple IP Prefixes) to Best Current Practice
The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Avoidance of ROA Containing Multiple IP Prefixes' as Best Current Practice Note that this is the second IETF LC for this document - this first one went through as Informational, but the (strong) feedback from the IESG Eval was that it read much more like a BCP. 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-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 When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate routes to IP address prefix(es). This memo discusses operational problems which may arise from ROAs containing multiple IP prefixes and recommends that each ROA contains a single IP prefix. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3779: X.509 Extensions for IP Addresses and AS Identifiers (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6482: A Profile for Route Origin Authorizations (ROAs) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc8211: Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) (Informational - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Moved to Historic: RFC 2407 on The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2407 has been reclassified as Historic. A new Request for Comments is now available in online RFC libraries. RFC 2407 Title: The Internet IP Security Domain of Interpretation for ISAKMP Author: D. Piper Status: Historic Stream: IETF Date: November 1998 Pages: 32 Updates/Obsoletes/SeeAlso: None URL:https://www.rfc-editor.org/info/rfc2407 DOI:10.17487/RFC2407 This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. This document is a product of the IP Security Protocol Working Group of the IETF. HISTORIC: This memo defines a Historic Document 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: (Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)' 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-05-04. 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 introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of Segment Routing over IPv6 (SRv6) related information such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 endpoint behavior that traffic is being forwarded with. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/ 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: (Proxying IP in HTTP) to Proposed Standard
The IESG has received a request from the Multiplexed Application Substrate over QUIC Encryption WG (masque) to consider the following document: - 'Proxying IP in HTTP' 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-03-15. 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 how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as a proxy. This document updates RFC 9298. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/ 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: (Avoidance for ROA Containing Multiple IP Prefixes) to Informational RFC
The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Avoidance for ROA Containing Multiple IP Prefixes' 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 2023-02-24. 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 When using the RPKI, address space holders need to issue ROA object(s) to authorize one or more ASes to originate routes to IP prefix(es). This memo discusses operational problems which may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/ 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 9349 on Definitions of Managed Objects for IP Traffic Flow Security
A new Request for Comments is now available in online RFC libraries. RFC 9349 Title: Definitions of Managed Objects for IP Traffic Flow Security Author: D. Fedyk, E. Kinzie Status: Standards Track Stream: IETF Date: January 2023 Mailbox:dfe...@labn.net, ekin...@labn.net Pages: 19 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-mib-iptfs-11.txt URL:https://www.rfc-editor.org/info/rfc9349 DOI:10.17487/RFC9349 This document describes managed objects for the management of IP Traffic Flow Security additions to Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec. This document provides a read-only version of the objects defined in the YANG module for the same purpose, which is in "A YANG Data Model for IP Traffic Flow Security" (RFC 9348). 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
RFC 9348 on A YANG Data Model for IP Traffic Flow Security
A new Request for Comments is now available in online RFC libraries. RFC 9348 Title: A YANG Data Model for IP Traffic Flow Security Author: D. Fedyk, C. Hopps Status: Standards Track Stream: IETF Date: January 2023 Mailbox:dfe...@labn.net, cho...@chopps.org Pages: 25 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-yang-iptfs-11.txt URL:https://www.rfc-editor.org/info/rfc9348 DOI:10.17487/RFC9348 This document describes a YANG module for the management of IP Traffic Flow Security (IP-TFS) additions to Internet Key Exchange Protocol version 2 (IKEv2) and IPsec. 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
RFC 9347 on Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)
A new Request for Comments is now available in online RFC libraries. RFC 9347 Title: Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) Author: C. Hopps Status: Standards Track Stream: IETF Date: January 2023 Mailbox:cho...@chopps.org Pages: 31 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-iptfs-19.txt URL:https://www.rfc-editor.org/info/rfc9347 DOI:10.17487/RFC9347 This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in Encapsulating Security Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage. 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
RFC 9333 on Minimal IP Encapsulating Security Payload (ESP)
A new Request for Comments is now available in online RFC libraries. RFC 9333 Title: Minimal IP Encapsulating Security Payload (ESP) Author: D. Migault, T. Guggemos Status: Informational Stream: IETF Date: January 2023 Mailbox:daniel.miga...@ericsson.com, gugge...@mnm-team.org Pages: 13 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lwig-minimal-esp-12.txt URL:https://www.rfc-editor.org/info/rfc9333 DOI:10.17487/RFC9333 This document describes the minimal properties that an IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303. Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation. This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description. 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
Protocol Action: The Internet IP Security Domain of Interpretation for ISAKMP to Historic
The IESG has approved changing the status of the following document: - The Internet IP Security Domain of Interpretation for ISAKMP (rfc2407) to Historic This protocol action is documented at: https://datatracker.ietf.org/doc/status-change-ikev1-to-historic/ A URL of the affected document is: https://datatracker.ietf.org/doc/rfc2407/ Status Change Details: IKEv1 [RFC2409] and its related documents for ISAKMP [RFC2408] and IPsec DOI [RFC2407] were obsoleted by IKEv2 [RFC4306] in December 2005. IKEv2 has now seen wide deployment and provides a full replacement for all IKEv1 functionality. No new modifications or new algorithms have been accepted for IKEv1 for at least a decade. IKEv2 addresses various issues present in IKEv1, such as IKEv1 being vulnerable to amplification attacks. It is therefore timely to mark these IKEv1 specifications as Historic. Upon approval and its publication as an RFC, draft-ietf-ipsecme-ikev1-algo-to-historic should replace this status change document as the reference for the status change event. Personnel Roman Danyliw 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 IP Wireless Access in Vehicular Environments (ipwave)
The IP Wireless Access in Vehicular Environments (ipwave) WG in the Internet Area has concluded. The IESG contact persons are Erik Kline and Éric Vyncke. Thanks very much to the IPWAVE chairs, document authors, document reviewers, and the community at large. With the advancement of the Problem Statement and Use Cases document, the milestones have been met. This working group is now closed but the mailing list will remain open. Thanks to all for your time and energy. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for IP Traffic Flow Security' to Proposed Standard (draft-ietf-ipsecme-mib-iptfs-11.txt)
The IESG has approved the following document: - 'Definitions of Managed Objects for IP Traffic Flow Security' (draft-ietf-ipsecme-mib-iptfs-11.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-mib-iptfs/ Technical Summary This document describes managed objects for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. Working Group Summary This document has been presented and discussed on list. No objections to this work have been raised. Document Quality This document is an SNMP MIB model definition and is derived from the YANG model defined in draft-ietf-ipsecme-yang-iptfs. Personnel * Document Shepherd: Tero Kivinen. * Responsible Area Director: Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Minimal IP Encapsulating Security Payload (ESP)' to Informational RFC (draft-ietf-lwig-minimal-esp-12.txt)
The IESG has approved the following document: - 'Minimal IP Encapsulating Security Payload (ESP)' (draft-ietf-lwig-minimal-esp-12.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-minimal-esp/ Technical Summary This document describes the minimal properties IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard RFC4303 ESP. Such a minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP. Instead, a minimal implementation is expected to be optimized for constrained environment while remaining interoperable with implementations of RFC 4303 ESP. In addition, this document also provides some considerations to implement minimal ESP in a constrained environment which includes limiting the number of flash writes, handling frequent wakeup / sleep states, limiting wakeup time, or reducing the use of random generation. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. RFC 4303 remains the authoritative description. Working Group Summary There were several rounds of feedback, including from the incoming SEC AD. Authors feel feedback has been incorporated, with the focus being that the document is defining an ESP profile for resource-constrained devices. Document Quality Nothing of note. Thanks to all the Last Call feedback and directorate reviews received so far. Personnel Mohit Sethi is the document Shepherd. Erik Kline is the responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A YANG Data Model for IP Traffic Flow Security' to Proposed Standard (draft-ietf-ipsecme-yang-iptfs-11.txt)
The IESG has approved the following document: - 'A YANG Data Model for IP Traffic Flow Security' (draft-ietf-ipsecme-yang-iptfs-11.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-yang-iptfs/ Technical Summary This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. Working Group Summary There is WG consensus to publish this document. It is the YANG companion to draft-ietf-ipsecme-iptfs-13. Document Quality YANG doctors and GENART reviews suggested helpful refinements to the YANG model. Personnel * Document Shepherd -- Tero Kivinen * Responsible Area Director -- Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security' to Proposed Standard (draft-ietf-ipsecme-iptfs-19.txt)
The IESG has approved the following document: - 'IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security' (draft-ietf-ipsecme-iptfs-19.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-iptfs/ Technical Summary This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non-constant send-rate usage. Working Group Summary Various aspects of the document were discussed and debated, with multiple revisions incorporating the results. There was no controversy though, and there is good WG consensus. Document Quality At least one implementation will be open sourced, with interest by others in implementing. There were multiple thorough reviews by experts in the WG. Personnel Document Shepherd: Tero Kivinen Responsible Area Director: Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Definitions of Managed Objects for IP Traffic Flow Security) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Definitions of Managed Objects for IP Traffic Flow Security' 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-10-04. 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 managed objects for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3410: Introduction and Applicability Statements for Internet-Standard Management Framework (Informational - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Data Model for IP Traffic Flow Security) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'A YANG Data Model for IP Traffic Flow Security' 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-08-04. 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 yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/ 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: (IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security' 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-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 mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ 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 9160 on Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
A new Request for Comments is now available in online RFC libraries. RFC 9160 Title: Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) Author: T. Graf Status: Informational Stream: IETF Date: December 2021 Mailbox:thomas.g...@swisscom.com Pages: 5 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt URL:https://www.rfc-editor.org/info/rfc9160 DOI:10.17487/RFC9160 This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol is used within a Segment Routing domain. In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for Path Computation Element (PCE), IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. This document is a product of the Operations and Management Area Working Group 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 9097 on Metrics and Methods for One-Way IP Capacity
A new Request for Comments is now available in online RFC libraries. RFC 9097 Title: Metrics and Methods for One-Way IP Capacity Author: A. Morton, R. Geib, L. Ciavattone Status: Standards Track Stream: IETF Date: November 2021 Mailbox:a...@research.att.com, ruediger.g...@telekom.de, len...@att.com Pages: 33 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ippm-capacity-metric-method-12.txt URL:https://www.rfc-editor.org/info/rfc9097 DOI:10.17487/RFC9097 This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical Maximum IP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement. This document is a product of the IP Performance Measurement 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 9136 on IP Prefix Advertisement in Ethernet VPN (EVPN)
A new Request for Comments is now available in online RFC libraries. RFC 9136 Title: IP Prefix Advertisement in Ethernet VPN (EVPN) Author: J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi Status: Standards Track Stream: IETF Date: October 2021 Mailbox:jorge.raba...@nokia.com, wim.henderi...@nokia.com, jdr...@juniper.net, w...@juniper.net, saja...@cisco.com Pages: 31 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-bess-evpn-prefix-advertisement-11.txt URL:https://www.rfc-editor.org/info/rfc9136 DOI:10.17487/RFC9136 The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network. In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used. This document is a product of the BGP Enabled Services 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 9056 on Deterministic Networking (DetNet) Data Plane: IP over MPLS
A new Request for Comments is now available in online RFC libraries. RFC 9056 Title: Deterministic Networking (DetNet) Data Plane: IP over MPLS Author: B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen Status: Standards Track Stream: IETF Date: October 2021 Mailbox:balazs.a.va...@ericsson.com, lber...@labn.net, dfe...@labn.net, stewart.bry...@gmail.com, jouni.nos...@gmail.com Pages: 11 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-detnet-ip-over-mpls-09.txt URL:https://www.rfc-editor.org/info/rfc9056 DOI:10.17487/RFC9056 This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network. This document is a product of the Deterministic 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
Document Action: 'Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)' to Informational RFC (draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt)
The IESG has approved the following document: - 'Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)' (draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt) as Informational RFC This document is the product of the Operations and Management Area 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-opsawg-ipfix-mpls-sr-label-type/ Technical Summary This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol used within a Segment Routing domain. In particular, this document defines four code points for the IPFIX mplsTopLabelType Information Element for IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. Working Group Summary This is a short simple document defining some new IPFIX code points, once adopted it proceeded relatively smoothly through the WG process. Document Quality The document has received sufficient reviews for a short document. My expectation is that this code points will be deployed relatively quickly after they have been defined. I would like to thank the Med (the doc shepherd) for his reviews and clear shepherd's writeup. Personnel The document shepherd is Mohamed Boucadair 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: (Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)) to Informational RFC
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)' 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-07-20. 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 introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol used within a Segment Routing domain. In particular, this document defines four code points for the IPFIX mplsTopLabelType Information Element for IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/ 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: 'Metrics and Methods for One-way IP Capacity' to Proposed Standard (draft-ietf-ippm-capacity-metric-method-12.txt)
The IESG has approved the following document: - 'Metrics and Methods for One-way IP Capacity' (draft-ietf-ippm-capacity-metric-method-12.txt) as Proposed Standard This document is the product of the IP Performance Measurement 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-ippm-capacity-metric-method/ Technical Summary This memo revisits the problem of Network Capacity metrics first examined in RFC 5136. The memo specifies a more practical Maximum IP-layer Capacity metric definition catering for measurement purposes, and outlines the corresponding methods of measurement. Working Group Summary The working group has consensus to publish this document. There was no particular controversy in the working group regarding this document, but the group did provide useful and detailed feedback and review. Document Quality This document represents a standardized definition of concepts that have existed and been documented informationally previously (RFC 5136). This document covers the background and motivation for providing a clearer definition of the metric and method for IP capacity. There is one implementation, as described in Section 8.4 (which will be deleted before publication). Personnel Tommy Pauly is the Document Shepherd. Martin Duke is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9023 on Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)
A new Request for Comments is now available in online RFC libraries. RFC 9023 Title: Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) Author: B. Varga, Ed., J. Farkas, A. Malis, S. Bryant Status: Informational Stream: IETF Date: June 2021 Mailbox:balazs.a.va...@ericsson.com, janos.far...@ericsson.com, agma...@gmail.com, s...@stewartbryant.com Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-detnet-ip-over-tsn-07.txt URL:https://www.rfc-editor.org/info/rfc9023 DOI:10.17487/RFC9023 This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs. This document is a product of the Deterministic Networking 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 9025 on Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP
A new Request for Comments is now available in online RFC libraries. RFC 9025 Title: Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP Author: B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant Status: Standards Track Stream: IETF Date: April 2021 Mailbox:balazs.a.va...@ericsson.com, janos.far...@ericsson.com, lber...@labn.net, agma...@gmail.com, stewart.bry...@gmail.com Pages: 8 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-detnet-mpls-over-udp-ip-08.txt URL:https://www.rfc-editor.org/info/rfc9025 DOI:10.17487/RFC9025 This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology. This document is a product of the Deterministic 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
RFC 8821 on PCE-Based Traffic Engineering (TE) in Native IP Networks
A new Request for Comments is now available in online RFC libraries. RFC 8821 Title: PCE-Based Traffic Engineering (TE) in Native IP Networks Author: A. Wang, B. Khasanov, Q. Zhao, H. Chen Status: Informational Stream: IETF Date: April 2021 Mailbox:wang...@chinatelecom.cn, bhassa...@yahoo.com, qz...@ethericnetworks.com, huaimo.c...@futurewei.com Pages: 12 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-teas-pce-native-ip-17.txt URL:https://www.rfc-editor.org/info/rfc8821 DOI:10.17487/RFC8821 This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP). This document is a product of the Traffic Engineering Architecture and Signaling 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
Document Action: 'DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)' to Informational RFC (draft-ietf-detnet-ip-over-tsn-07.txt)
The IESG has approved the following document: - 'DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)' (draft-ietf-detnet-ip-over-tsn-07.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-over-tsn/ Technical Summary This document describes how the Deterministic Networking IP data plane can operate over a TSN sub-network data plane. This document does not define new procedures or processes. Working Group Summary Nothing notable. Document Quality The document is an Informational document. Early implementations of IP over DetNet were demonstrated by WG members. Personnel Who is the Document Shepherd for this document? Lou Berger Who is the Responsible Area Director? Deborah Brungard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DetNet Data Plane: MPLS over UDP/IP' to Proposed Standard (draft-ietf-detnet-mpls-over-udp-ip-08.txt)
The IESG has approved the following document: - 'DetNet Data Plane: MPLS over UDP/IP' (draft-ietf-detnet-mpls-over-udp-ip-08.txt) as Proposed Standard This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-udp-ip/ Technical Summary This document specifies the MPLS Deterministic Networking data plane operation and encapsulation over an IP network. The approach is modeled on the operation of MPLS and over UDP/IP packet switched networks. Working Group Summary No controversy, pretty much just putting the pieces together. Document Quality At this time there are no shipping implementations of DetNet per se, however clearly IP and MPLS are mature technologies. Personnel Who is the Document Shepherd for this document? Ethan Grossman Who is the Responsible Area Director? Deborah Brungard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Path Computation Element (PCE) based Traffic Engineering (TE) in Native IP Networks' to Informational RFC (draft-ietf-teas-pce-native-ip-17.txt)
The IESG has approved the following document: - 'Path Computation Element (PCE) based Traffic Engineering (TE) in Native IP Networks' (draft-ietf-teas-pce-native-ip-17.txt) as Informational RFC This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ Technical Summary This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism. It defines the Central Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP). Working Group Summary No concerns. Document Quality The document quality is sufficient for Informational status. Personnel Who is the Document Shepherd for this document? Lou Berger Who is the Responsible Area Director? Deborah Brungard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Metrics and Methods for One-way IP Capacity) to Proposed Standard
The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'Metrics and Methods for One-way IP Capacity' 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 2021-02-16. 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 revisits the problem of Network Capacity metrics first examined in RFC 5136. The memo specifies a more practical Maximum IP-layer Capacity metric definition catering for measurement purposes, and outlines the corresponding methods of measurement. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7799: Active and Passive Metrics and Methods (with Hybrid Types In-Between) (Informational - IETF stream) rfc7312: Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) (Informational - IETF stream) rfc6815: Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful (Informational - IETF stream) rfc5136: Defining Network Capacity (Informational - IETF stream) rfc3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics (Informational - IETF stream) rfc2544: Benchmarking Methodology for Network Interconnect Devices (Informational - Legacy stream) rfc8337: Model-Based Metrics for Bulk Transport Capacity (Experimental - IETF stream) rfc8468: IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework (Informational - IETF stream) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)' 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-05. 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 Deterministic Networking IP data plane when operating over a TSN sub-network. This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-over-tsn/ 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 8828 on WebRTC IP Address Handling Requirements
A new Request for Comments is now available in online RFC libraries. RFC 8828 Title: WebRTC IP Address Handling Requirements Author: J. Uberti, G. Shieh Status: Standards Track Stream: IETF Date: January 2021 Mailbox:jus...@uberti.name, guow...@gmail.com Pages: 9 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-rtcweb-ip-handling-12.txt URL:https://www.rfc-editor.org/info/rfc8828 DOI:10.17487/RFC8828 This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations. This document is a product of the Real-Time Communication in WEB-browsers 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 8939 on Deterministic Networking (DetNet) Data Plane: IP
A new Request for Comments is now available in online RFC libraries. RFC 8939 Title: Deterministic Networking (DetNet) Data Plane: IP Author: B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant Status: Standards Track Stream: IETF Date: November 2020 Mailbox:balazs.a.va...@ericsson.com, janos.far...@ericsson.com, lber...@labn.net, dfe...@labn.net, s...@stewartbryant.com Pages: 21 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-detnet-ip-07.txt URL:https://www.rfc-editor.org/info/rfc8939 DOI:10.17487/RFC8939 This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). This document is a product of the Deterministic 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: (PCE in Native IP Network) to Informational RFC
The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'PCE in Native IP Network' 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-12-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 defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism. It defines the Central Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3144/ https://datatracker.ietf.org/ipr/3134/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DetNet Data Plane: IP over MPLS' to Proposed Standard (draft-ietf-detnet-ip-over-mpls-09.txt)
The IESG has approved the following document: - 'DetNet Data Plane: IP over MPLS' (draft-ietf-detnet-ip-over-mpls-09.txt) as Proposed Standard This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-over-mpls/ Technical Summary This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet switched network. Working Group Summary No controversy, pretty much just putting the pieces together. Document Quality At this time there are no shipping implementations of DetNet per se, however clearly IP and MPLS are mature technologies. Several major vendors have been core to the development of DetNet, including Cisco, Huawei, and Ericsson so it is assumed that they plan to implement it. Personnel Who is the Document Shepherd for this document? Ethan Grossman Who is the Responsible Area Director? Deborah Brungard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 230, RFC 8900 on IP Fragmentation Considered Fragile
A new Request for Comments is now available in online RFC libraries. BCP 230 RFC 8900 Title: IP Fragmentation Considered Fragile Author: R. Bonica, F. Baker, G. Huston, B. Hinden, O. Troan, F. Gont Status: Best Current Practice Stream: IETF Date: September 2020 Mailbox:rbon...@juniper.net, fredbaker.i...@gmail.com, g...@apnic.net, bob.hin...@gmail.com, o...@cisco.com, fg...@si6networks.com Pages: 23 See Also: BCP 230 I-D Tag:draft-ietf-intarea-frag-fragile-17.txt URL:https://www.rfc-editor.org/info/rfc8900 DOI:10.17487/RFC8900 This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. This document is a product of the Internet Area Working Group 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
Last Call: (DetNet Data Plane: MPLS over UDP/IP) to Proposed Standard
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'DetNet Data Plane: MPLS over UDP/IP' 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-09-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 the MPLS Deterministic Networking data plane operation and encapsulation over an IP network. The approach is modeled on the operation of MPLS and over UDP/IP packet switched networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-udp-ip/ 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 8805 on A Format for Self-Published IP Geolocation Feeds
A new Request for Comments is now available in online RFC libraries. RFC 8805 Title: A Format for Self-Published IP Geolocation Feeds Author: E. Kline, K. Duleba, Z. Szamonek, S. Moser, W. Kumari Status: Informational Stream: Independent Date: August 2020 Mailbox:e...@loon.com, kdul...@google.com, zsz...@google.com, smo...@google.com, war...@kumari.net Pages: 23 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-google-self-published-geofeeds-09.txt URL:https://www.rfc-editor.org/info/rfc8805 DOI:10.17487/RFC8805 This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. 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: 'DetNet Data Plane: IP' to Proposed Standard (draft-ietf-detnet-ip-07.txt)
The IESG has approved the following document: - 'DetNet Data Plane: IP' (draft-ietf-detnet-ip-07.txt) as Proposed Standard This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ Technical Summary This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery. Procedures and control information that is common to all DetNet data planes can be found in ietf-detnet-data-plane-framework. Working Group Summary There were many technical debates in the process of creating this draft, but all were resolved with a clear consensus. It took awhile to get there but there is nothing worth noting. Document Quality The IPv4 and IPv6 protocols are used without modification. At this time there are no shipping implementations of DetNet per se. The DetNet WG (including David Black, DetNet Technical Advisor) have made extensive reviews of the present drafts. Personnel Who is the Document Shepherd for this document? Ethan Grossman Who is the Responsible Area Director? Deborah Brungard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8777 on DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery
A new Request for Comments is now available in online RFC libraries. RFC 8777 Title: DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery Author: J. Holland Status: Standards Track Stream: IETF Date: April 2020 Mailbox:jakeholland@gmail.com Pages: 33 Updates:RFC 7450 I-D Tag:draft-ietf-mboned-driad-amt-discovery-13.txt URL:https://www.rfc-editor.org/info/rfc8777 DOI:10.17487/RFC8777 This document updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined. This document is a product of the MBONE Deployment 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
Protocols for IP Multicast (pim) WG Virtual Meeting: 2020-04-21 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Protocols for IP Multicast (pim) Working Group will hold a virtual interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles (16:00 to 18:00 UTC). Agenda: WG Administration Stig Mike 10 min Beau Williamson Dino Farinacci 10 min draft-ietf-pim-igmp-mld-extension Stig Venaas 10 min draft-asaeda-pim-multiif-igmpmldproxy Luis Contreras 10 min Path MTU Discovery Tathagata Nandy 10 min MLDv2 LL addr advertisementsToerless Eckert 10 min draft-voyer-pim-sr-p2mp-policy Hooman Bidgoli 10 min ASM to SSM Worldwide migration Gyan Mishra 15 min Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m917b6342691876baf54b1b5aef9c31f4 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (DetNet Data Plane: IP over MPLS) to Proposed Standard
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'DetNet Data Plane: IP over MPLS' 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-04-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 specifies the Deterministic Networking data plane when operating in an IP over MPLS packet switched network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-over-mpls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-over-mpls/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
IP Performance Measurement (ippm) WG Virtual Meeting: 2020-04-01
The IP Performance Measurement (ippm) Working Group will hold a virtual interim meeting on 2020-04-01 from 08:00 to 09:30 America/Los_Angeles. Agenda: Working Group Documents TimeLength What Who 15:00 10m Welcome, Note Well, Agenda, Status Chairs 15:10 15m draft-ietf-ippm-capacity-metric-method A. Morton 15:25 10m draft-ietf-ippm-multipoint-alt-mark G. Fioccola 15:35 5m draft-ietf-ippm-stamp-option-tlv G. Mirsky 15:40 30m draft-ietf-ippm-ioam-data F. Brockners draft-ietf-ippm-ioam-flags draft-ietf-ippm-ioam-ipv6-options draft-ietf-ippm-ioam-direct-export Other work Individual drafts and topics that have received notable list discussion. TimeLength What Who 16:10 10m draft-geib-ippm-connectivity-monitoring R. Geib 16:20 10m draft-song-ippm-postcard-based-telemetry Information about remote participation: https://ietf.webex.com/meet/ippm ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocols for IP Multicast (pim) WG Virtual Meeting: 2020-04-21
The Protocols for IP Multicast (pim) Working Group will hold a virtual interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles. Agenda: TBD. We will hold a joint 2 hour meeting with mboned wg. Information about remote participation: Remote participation information will be obtained at the time of approval ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8738 on Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
A new Request for Comments is now available in online RFC libraries. RFC 8738 Title: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension Author: R.B. Shoemaker Status: Standards Track Stream: IETF Date: February 2020 Mailbox:rol...@letsencrypt.org Pages: 5 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-acme-ip-08.txt URL:https://www.rfc-editor.org/info/rfc8738 DOI:10.17487/RFC8738 This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. This document is a product of the Automated Certificate Management Environment 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 8735 on Scenarios and Simulation Results of PCE in a Native IP Network
A new Request for Comments is now available in online RFC libraries. RFC 8735 Title: Scenarios and Simulation Results of PCE in a Native IP Network Author: A. Wang, X. Huang, C. Kou, Z. Li, P. Mi Status: Informational Stream: IETF Date: February 2020 Mailbox:wang...@chinatelecom.cn, huan...@bupt.edu.cn, ko...@lsec.cc.ac.cn, li_zhenqi...@hotmail.com, mipeng...@huawei.com Pages: 16 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-teas-native-ip-scenarios-12.txt URL:https://www.rfc-editor.org/info/rfc8735 DOI:10.17487/RFC8735 Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios. One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios. This document is a product of the Traffic Engineering Architecture and Signaling 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: (DetNet Data Plane: IP) to Proposed Standard
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'DetNet Data Plane: IP' 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-03-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 specifies the Deterministic Networking data plane when operating in an IP packet switched network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/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
WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) --- Current status: Active WG Chairs: Yoav Nir Tero Kivinen Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: ip...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD
Protocol Action: 'DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery' to Proposed Standard (draft-ietf-mboned-driad-amt-discovery-13.txt)
The IESG has approved the following document: - 'DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery' (draft-ietf-mboned-driad-amt-discovery-13.txt) as Proposed Standard This document is the product of the MBONE Deployment Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/ Technical Summary This document extends Automatic Multicast Tunnelling (AMT, RFC 7450) to allow the relay discovery process to use a new AMTRELAY DNS resource record for discovering source-specific multicast channels. This allows a set of AMT relays that can receive and forward multicast traffic from a sender to be advertised via reverse IP entries in DNS, hence the DNS Reverse IP AMT Discovery or DRIAD name. Working Group Summary There was no particular controversy in the WG process, and consensus was good. Document Quality The document is well written, explaining the basic mode of operation clearly, and including many example use cases. Personnel Tim Chown (tim.ch...@jisc.ac.uk) is DS Warren Kumari is RAD! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (DNS Reverse IP AMT Discovery) to Proposed Standard
The IESG has received a request from the MBONE Deployment WG (mboned) to consider the following document: - 'DNS Reverse IP AMT Discovery' 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-12-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 updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by extending the relay discovery process to use a new DNS resource record named AMTRELAY when discovering AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/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: 'ACME IP Identifier Validation Extension' to Proposed Standard (draft-ietf-acme-ip-08.txt)
The IESG has approved the following document: - 'ACME IP Identifier Validation Extension' (draft-ietf-acme-ip-08.txt) as Proposed Standard This document is the product of the Automated Certificate Management Environment Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ Technical Summary The ACME-IP draft extends the Automatic Certificate Management Environment (ACME) with support for IP address type identifiers in addition to DNS type identifiers. The draft additionally specifies how the existing ACME challenge types (HTTP-01 and DNS-01) and the ACME-TLS-ALPN challenge type (TLS-ALPN-01) interact with IP address identifiers. Working Group Summary The description of using tls-alpn-01 for IP identifiers was fixed to respect RFC 6066's restriction on IP addresses in SNI by defining the ip-addr.arpa format to use instead. Earlier versions of the draft included a reverse-DNS challenge type. Within the working group there were concerns raised about the accuracy of the reverse DNS zone information that this challenge type relied on. A decision was made to remove this challenge type from the draft to allow forward progress on the remaining uncontroversial parts of the draft. Document Quality The document is short and concise. The interaction between the existing challenge types interact this new identifier type is well specified. I am not aware of any existing implementations but at least one ACME server operator (Let's Encrypt) intends to implement the draft in a test capacity (with the Pebble ACME server) in the near future. Personnel The document shepard is Daniel McCarney. The responsible area director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IP Fragmentation Considered Fragile' to Best Current Practice (draft-ietf-intarea-frag-fragile-17.txt)
The IESG has approved the following document: - 'IP Fragmentation Considered Fragile' (draft-ietf-intarea-frag-fragile-17.txt) as Best Current Practice This document is the product of the Internet Area Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ Technical Summary This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. Working Group Summary The document has been reviewed thoroughly in the intarea working group. While some issues were raised, all have been addressed. Document Quality A Gen-art review has been received, and suggestions acted upon. There were early intdir and (solicited) tsvart reviews. Issues raised there were also addressed. There are a number of other review team requests outstanding and overdue. There were no specific expert reviews. Personnel The document Shepherd is Joel Halpern. The responsible Area Director is Suresh Krishnan. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Scenarios and Simulation Results of PCE in Native IP Network) to Informational RFC
The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Scenarios and Simulation Results of PCE in Native IP Network' 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 2019-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 Requirements for providing the End to End(E2E) performance assurance are emerging within the service provider network. While there are various technology solutions, there is no one solution which can fulfill these requirements for a native IP network. One universal (E2E) solution which can cover both intra-domain and inter-domain scenarios is needed. One feasible E2E traffic engineering solution is the use of a Path Computation Elements (PCE) in a native IP network. This document describes various complex scenarios and simulation results when applying a PCE in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/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: 'WebRTC IP Address Handling Requirements' to Proposed Standard (draft-ietf-rtcweb-ip-handling-12.txt)
The IESG has approved the following document: - 'WebRTC IP Address Handling Requirements' (draft-ietf-rtcweb-ip-handling-12.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ Technical Summary This draft provides information and requirements for how IP addresses should be handled by WebRTC implementations. This is a companion draft to the two security-related drafts, but it was kept separate to this draft to change more quickly. The security drafts are standards track and so is this one. Working Group Summary This document has been extensively reviewed both on the list at a numerous in-person WG meetings. This document is controversial because it deals with privacy and user consent issues related to Browsers. There are strong feelings about the draft’s contents and what we have arrived at is rough consensus. Document Quality WebRTC, including its underlying security and privacy model, has been implemented by all major web browsers. Personnel Sean Turner is the Shepherd. Adam Roach is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8602 on Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses
A new Request for Comments is now available in online RFC libraries. RFC 8602 Title: Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses Author: J. Arkko, T. Hardie Status: Standards Track Stream: IETF Date: July 2019 Mailbox:jari.ar...@piuha.net, ted.i...@gmail.com Pages: 3 Characters: 4619 Updates:RFC 3219 I-D Tag:draft-arkko-trip-registry-update-01.txt URL:https://www.rfc-editor.org/info/rfc8602 DOI:10.17487/RFC8602 This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information. This memo updates RFC 3219. 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: 'SR-MPLS over IP' to Proposed Standard (draft-ietf-mpls-sr-over-ip-07.txt)
The IESG has approved the following document: - 'SR-MPLS over IP' (draft-ietf-mpls-sr-over-ip-07.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ Technical Summary This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. Working Group Summary The working group process has been very smooth and straight forward. We have very good support for the document. Document Quality Do not currently know if there are implementations of this specification. An implementation poll has been sent to the MPLS working group, the shepherd write-up will be updated if receive more information. Personnel Who is the Document Shepherd for this document? Loa Andersson Who is the Responsible Area Director? Deborah Brungard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (IP Fragmentation Considered Fragile) to Best Current Practice
The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'IP Fragmentation Considered Fragile' 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 i...@ietf.org mailing lists by 2019-07-04. 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 IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc1191: Path MTU discovery (Draft Standard - Legacy stream) rfc4821: Packetization Layer Path MTU Discovery (Proposed Standard - IETF stream) draft-ietf-tsvwg-datagram-plpmtud: Packetization Layer Path MTU Discovery for Datagram Transports (None - IETF stream) rfc6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (Proposed Standard - IETF stream) rfc6437: IPv6 Flow Label Specification (Proposed Standard - IETF stream) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (ACME IP Identifier Validation Extension) to Proposed Standard
The IESG has received a request from the Automated Certificate Management Environment WG (acme) to consider the following document: - 'ACME IP Identifier Validation Extension' 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-06-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 specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8549 on Export of BGP Community Information in IP Flow Information Export (IPFIX)
A new Request for Comments is now available in online RFC libraries. RFC 8549 Title: Export of BGP Community Information in IP Flow Information Export (IPFIX) Author: Z. Li, R. Gu, J. Dong Status: Standards Track Stream: IETF Date: April 2019 Mailbox:li_zhenqi...@hotmail.com, gurong_c...@outlook.com, jie.d...@huawei.com Pages: 18 Characters: 43692 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-opsawg-ipfix-bgp-community-12.txt URL:https://www.rfc-editor.org/info/rfc8549 DOI:10.17487/RFC8549 By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export (IPFIX) to export BGP community information, including the BGP Standard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092. According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering. This document is a product of the Operations and Management Area Working Group 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
Last Call: (SR-MPLS over IP) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'SR-MPLS over IP' 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-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 MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source routing paradigm in which the sender of a packet is allowed to partially or completely specify the route the packet takes through the network by imposing stacked MPLS labels on the packet. SR-MPLS could be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while preserving backward compatibility with SR-MPLS. This document describes how SR-MPLS capable routers and IP-only routers can seamlessly co-exist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- UDP as defined in RFC 7510. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3210/ https://datatracker.ietf.org/ipr/3211/
Last Call: (WebRTC IP Address Handling Requirements) to Proposed Standard
The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC IP Address Handling Requirements' 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-02-15. 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 information and requirements for how IP addresses should be handled by WebRTC implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'Export BGP community information in IP Flow Information Export (IPFIX)' to Proposed Standard (draft-ietf-opsawg-ipfix-bgp-community-12.txt)
The IESG has approved the following document: - 'Export BGP community information in IP Flow Information Export (IPFIX)' (draft-ietf-opsawg-ipfix-bgp-community-12.txt) as Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ Technical Summary This document defines a set of IPFIX Information Elements used for exporting traffic accounting data based on BGP community information. It is targeted for one large use case of traffic accounting, and it has no intentions to define a universal all-purpose accounting mechanism. The document does not define and does not endorse any specific network design for this functionality, instead it focuses on protocol extensions only. Working Group Summary The document has been discussed for a while, receiving multiple detailed reviews and as a result changing over time quite significantly. There were disagreements in the community on the general applicability of the specified mechanism and as a result the scope of the document is reduces to cover specific use cases only. The resulting document had a broad consensus agreement within the WG. Document Quality There is an indication of a single implementation being available, and some limited deployment experience. The document has received several directorate reviews during the lifecycle, and also several individual in-depth reviews. Personnel Document Shepherd is Tianran Zhou. Responsible Area Director is Ignas Bagdonas. IANA Note The document adds new entries into existing IPFIX IE registries. The document does not create any new IANA registries.
RFC 8468 on IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework
A new Request for Comments is now available in online RFC libraries. RFC 8468 Title: IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework Author: A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde Status: Informational Stream: IETF Date: November 2018 Mailbox:acmor...@att.com, joachim.fab...@tuwien.ac.at, nalini.elk...@insidethestack.com, mackerm...@bcbsm.com, vinay...@gmail.com Pages: 15 Characters: 35970 Updates:RFC 2330 I-D Tag:draft-ietf-ippm-2330-ipv6-06.txt URL:https://www.rfc-editor.org/info/rfc8468 DOI:10.17487/RFC8468 This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation. This document is a product of the IP Performance Measurement 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 8487 on Mtrace Version 2: Traceroute Facility for IP Multicast
A new Request for Comments is now available in online RFC libraries. RFC 8487 Title: Mtrace Version 2: Traceroute Facility for IP Multicast Author: H. Asaeda, K. Meyer, W. Lee. Ed. Status: Standards Track Stream: IETF Date: October 2018 Mailbox:asa...@nict.go.jp, kerry.me...@me.com, wee...@weesan.com Pages: 41 Characters: 96547 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mboned-mtrace-v2-26.txt URL:https://www.rfc-editor.org/info/rfc8487 DOI:10.17487/RFC8487 This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply. This document is a product of the MBONE Deployment 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
WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) --- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: ip...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Split-DNS is a common configuration for VPN deployments in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address
Last Call: (Export BGP community information in IP Flow Information Export (IPFIX)) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Export BGP community information in IP Flow Information Export (IPFIX)' 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 2018-09-24. 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 By introducing new Information Elements (IEs), this draft extends the existing BGP related IEs to enable IPFIX [RFC7011] to export the BGP community information, including the information of BGP standard community [RFC1997], BGP extended community [RFC4360], and BGP large community [RFC8092]. Network traffic information can then be accumulated and analysed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions according to the network operator's BGP community planning. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering. To clarify, no new BGP community attribute is defined in this document and this document has no purpose to replace BGP Monitoring Protocol (BMP) defined in RFC7854. The IEs introduced in this document are used by IPFIX together with other IEs to facilitate the IPFIX collector analyzing the network traffic at the BGP community granularity without running the heavy BGP protocol. When needed, the mediator or collector can use the IEs introduced in this document to report the BGP community related traffic flow information it gets either from exporters or through local correlation to other IPFIX devices. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2964/ https://datatracker.ietf.org/ipr/3165/
WG Review: IP Security Maintenance and Extensions (ipsecme)
The IP Security Maintenance and Extensions (ipsecme) WG in the Security 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 2018-09-06. IP Security Maintenance and Extensions (ipsecme) --- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: ip...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar quantum resistant properties to those of IKEv1. Split-DNS is a common configuration for VPN deployments in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS, however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related
Protocol Action: 'Mtrace Version 2: Traceroute Facility for IP Multicast' to Proposed Standard (draft-ietf-mboned-mtrace-v2-25.txt)
The IESG has approved the following document: - 'Mtrace Version 2: Traceroute Facility for IP Multicast' (draft-ietf-mboned-mtrace-v2-25.txt) as Proposed Standard This document is the product of the MBONE Deployment Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ Technical Summary This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. Working Group Summary This draft has received solid support within the working group and no major controversies were noted. Document Quality This draft has received significant input and comments during the working group meetings and on the mailing list. During working group last call, several issues were brought up by one reviewer, but the author addressed all issues. Personnel Lenny Giuliano is the Document Shepherd. Warren Kumari is the Responsible Area Director. (Originally this was Ron Bonica)
Protocol Action: 'IP Prefix Advertisement in EVPN' to Proposed Standard (draft-ietf-bess-evpn-prefix-advertisement-11.txt)
The IESG has approved the following document: - 'IP Prefix Advertisement in EVPN' (draft-ietf-bess-evpn-prefix-advertisement-11.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ Technical Summary This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. Working Group Summary The process through the WG was normal; nothing specific to highlight. Document Quality There are at least 3 commercial implementations of this specification. Personnel Document Shepherd: Zhaohui (Jeffrey)Zhang (zzh...@juniper.net) Responsible Area Director: Alvaro Retana (aretana.i...@gmail.com)
RFC 8386 on Privacy Considerations for Protocols Relying on IP Broadcast or Multicast
A new Request for Comments is now available in online RFC libraries. RFC 8386 Title: Privacy Considerations for Protocols Relying on IP Broadcast or Multicast Author: R. Winter, M. Faath, F. Weisshaar Status: Informational Stream: IETF Date: May 2018 Mailbox:rolf.win...@hs-augsburg.de, fa...@conntac.net, fabian.weissh...@hs-augsburg.de Pages: 13 Characters: 32238 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-intarea-broadcast-consider-09.txt URL:https://www.rfc-editor.org/info/rfc8386 DOI:10.17487/RFC8386 A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols. This document is a product of the Internet Area Working Group 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 8367 on Wrongful Termination of Internet Protocol (IP) Packets
A new Request for Comments is now available in online RFC libraries. RFC 8367 Title: Wrongful Termination of Internet Protocol (IP) Packets Author: T. Mizrahi, J. Yallouz Status: Informational Stream: Independent Date: 1 April 2018 Mailbox:ta...@marvell.com, j...@alumni.technion.ac.il Pages: 6 Characters: 11450 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-tj-wrongful-termination-00.txt URL:https://www.rfc-editor.org/info/rfc8367 DOI:10.17487/RFC8367 Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them. 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: (IP Prefix Advertisement in EVPN) to Proposed Standard
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'IP Prefix Advertisement in EVPN' 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 2018-04-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 EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 8344 on A YANG Data Model for IP Management
A new Request for Comments is now available in online RFC libraries. RFC 8344 Title: A YANG Data Model for IP Management Author: M. Bjorklund Status: Standards Track Stream: IETF Date: March 2018 Mailbox:m...@tail-f.com Pages: 34 Characters: 59931 Obsoletes: RFC 7277 I-D Tag:draft-ietf-netmod-rfc7277bis-03.txt URL:https://www.rfc-editor.org/info/rfc8344 DOI:10.17487/RFC8344 This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document obsoletes RFC 7277. This document is a product of the Network Modeling 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
Document Action: 'Privacy considerations for protocols relying on IP broadcast and multicast' to Informational RFC (draft-ietf-intarea-broadcast-consider-09.txt)
The IESG has approved the following document: - 'Privacy considerations for protocols relying on IP broadcast and multicast' (draft-ietf-intarea-broadcast-consider-09.txt) as Informational RFC This document is the product of the Internet Area Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ Technical Summary A number of application-layer protocols make use of IP broadcasts or multicast messages for functions like local service discovery or name resolution. When using broadcasts or multicast messages, a passive observer in the same broadcast/multicast domain can trivially record these messages and analyze their content. This document highlights potential privacy issues that occur when protocol designers make use of broadcast / multicast messages to exchange information that can expose individuals to privacy threats. Working Group Summary The document was discussed at length in the WG, following some experiments that were made over the IETF network. Because of the obviousness of the issues and usefulness of the document, there was little real discussion about the intention the document. There were comments for completeness from C. Huitema, T. Chown, T. Hebert, J. Touch, and the document shepherd, and these were all addressed. Document Quality The document is based on protocol behavior observed during experiments on operational networks (including the IETF meeting network) Personnel The document shepherd is Juan Carlos Zuniga. The responsible Area Director is Suresh Krishnan.
