RFC8573: Message authentication code for the network time protocol

The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.https://www.rfc-editor.org/rfc/rfc8573.htmlPublished versio

Multiplexing scheme updates for QUIC

RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket

TinyMT32 Pseudorandom Number Generator (PRNG) (RFC 8682)

RFC 8682, Standards Track, TSVWG (Transport Area) working group of IETF (Internet Engineering Task Force), https://www.rfc-editor.org/rfc/rfc8682.htmlThis document describes the TinyMT32 Pseudorandom Number Generator (PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller Linear Congruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications

RFC 8930: On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network: IETF Standard

Il s'agit d'un standard IETF.International audienceThis document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs)

Description of the CUDF Format

This document contains several related specifications, together they describe the document formats related to the solver competition which will be organized by Mancoosi. In particular, this document describes: - DUDF (Distribution Upgradeability Description Format), the document format to be used to submit upgrade problem instances from user machines to a (distribution-specific) database of upgrade problems; - CUDF (Common Upgradeability Description Format), the document format used to encode upgrade problems, abstracting over distribution-specific details. Solvers taking part in the competition will be fed with input in CUDF format

RFC 9302 Locator/ID Separation Protocol (LISP) Map-Versioning

IETFThis document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism. This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document

RTP Control Protocol (RTCP) Feedback for Congestion Control

An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control

Sending Multiple Types of Media in a Single RTP Session

This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP specifications (RFCs 3550 and 3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session

Forward Error Correction (FEC) Framework Extension to Sliding Window Codes (RFC 8680)

RFC 8680, Standards Track, TSVWG (Transport Area) working group of IETF (Internet Engineering Task Force), https://www.rfc-editor.org/rfc/rfc8680.htmlRFC 6363 describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However FECFRAME as per RFC 6363 is restricted to block FEC codes. The present document extends FECFRAME to support FEC Codes based on a sliding encoding window, in addition to Block FEC Codes, in a backward compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency

Sending multiple RTP streams in a single RTP session: grouping RTP control protocol (RTCP) reception statistics and other feedback

RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP Control Protocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios