FLUTE version 2 (RFC 6726) signalling, off by default: step one of three, no conformance claimed - #65
Open
jordijoangimenez wants to merge 1 commit into
Conversation
This was referenced Aug 11, 2026
Closed
jordijoangimenez
marked this pull request as draft
August 14, 2026 10:27
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
from
August 22, 2026 12:57
6237b31 to
b5be461
Compare
jordijoangimenez
changed the title
jordijoangimenez
changed the base branch from
development
to
feature/wave3-rfc6726-compliance-fixes
August 22, 2026 12:59
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
from
August 22, 2026 13:16
b5be461 to
26dacc2
Compare
github-project-automation
Bot
moved this from In Progress
to Done
in MBMS: Support for FLUTE
jordijoangimenez
changed the base branch from
feature/flute-v1-profile-conformance
to
development
August 22, 2026 13:24
This was referenced Aug 22, 2026
jordijoangimenez
changed the title
jordijoangimenez
changed the base branch from
development
to
feature/wave3-rfc6726-compliance-fixes
August 22, 2026 15:25
jordijoangimenez
marked this pull request as ready for review
August 22, 2026 15:38
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
4 times, most recently
from
August 22, 2026 18:44
798ddf8 to
1e97d70
Compare
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
from
August 22, 2026 18:44
1e97d70 to
5a9496c
Compare
jordijoangimenez
force-pushed
the
feature/wave3-rfc6726-compliance-fixes
branch
2 times, most recently
from
August 22, 2026 19:02
637cf46 to
12fb037
Compare
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
2 times, most recently
from
August 22, 2026 19:50
e033e91 to
0d009e8
Compare
jordijoangimenez
force-pushed
the
feature/wave3-rfc6726-compliance-fixes
branch
from
August 22, 2026 20:01
c7306fc to
e6bbe48
Compare
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
4 times, most recently
from
August 23, 2026 07:00
6e90d9f to
22baee6
Compare
jordijoangimenez
force-pushed
the
feature/wave3-rfc6726-compliance-fixes
branch
from
August 23, 2026 07:29
4c3e556 to
e6bbe48
Compare
…ault Change type New feature, not for 3GPP MBMS use. This branch is the FLUTE version 2 delta and nothing else. Basis The two versions are separate protocols, not a compatible upgrade. RFC 3926 clause 3.4.1: "This document specifies FLUTE version 1. Hence in any ALC packet that carries FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '1'." RFC 6726 clause 11.1: "Therefore, an implementation that relies on [RFC3926] and RFC 3451 will not be backwards compatible with FLUTE as specified in this document." RFC 6726 clause 3.1, which is why the receive side checks against a configured value rather than accepting whatever arrives: "If multiple FLUTE sessions are sent to a channel, then receivers MUST determine the FLUTE protocol version, based on version fields and the (source IP address, TSI) pair carried in the ALC/LCT header of the packet." On the LCT generation, RFC 6726 clause 11.1: "In [RFC5651], these fields MUST be set to zero and MUST be ignored by receivers (instead, the EXT_TIME Header Extensions can convey this information if needed)." On the identifier sequence, RFC 6726 clause 3.4.1: "After reaching the maximum value (2^20-1), the numbering starts from the smallest FDT Instance ID value assigned to an expired FDT Instance." and "Senders MUST NOT reuse an FDT Instance ID value that is already in use for a non-expired FDT Instance." On expiry, RFC 6726 clause 3.3: "both a sender and a receiver easily determine to which (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which the expiration time is closest in time to the current time." On a shared Content-Location, RFC 6726 clause 3.4.2: "the element appearing in the FDT Instance with the greater FDT Instance ID is considered to declare a newer instance (e.g., version) of the same" On security, RFC 6726 clause 7.5 takes its service set from ALC, where RFC 5775 requires anti-replay support alongside authentication and integrity. Change A per-session FLUTE version, settable on the Transmitter and Receiver, defaulting to 1, carried into the ALC parser, the FDT and the receiver's object handling. Every behavioural difference below is reached only when a caller selects version 2, so a version 1 or 3GPP session is unchanged in every respect. Signalling: transmit writes the selected version into the EXT_FDT nibble, receive accepts only the configured version, and the RFC 6726 FDT namespace is enabled. LCT generation: under version 2 the two bits RFC 3451 used for the Sender Current Time and Expected Residual Time fields contribute no header words and nothing is stepped over, so an extension placed after the TOI is reached. Under version 1 the RFC 3451 reading is untouched. Transmit has always sent both bits zero, since the header buffer is calloc'd. FDT Instance ID: version 2 wraps to the smallest expired identifier, refuses one still live, and reports exhaustion, which RFC 6726 clause 3.4.1 leaves to the implementation. Version 1 keeps RFC 3926's wrap to zero. Expiry: read into the era nearest the current time, version 2 only. Shared Content-Location: the receiver records which instance declared each file and keeps the one from the greater instance ID rather than whichever completed first, version 2 only. IpSec sets a replay window. That one is version-independent and benefits both. Four further obligations were checked against the specifications and found already met, so no code changed for them: EXT_TIME and EXT_AUTH recognition, the RFC 3450 to RFC 5775 move, the FDT schema body, and ESP authentication and integrity. README-FLUTE-V2.md records each, how it was established, and where the reading is weaker than a test. The default is what keeps this safe: 1 is the version TS 26.346 clause L.4.1 references, so a session that does not ask for version 2 behaves exactly as it does on the version 1 branch. Separation, deliberate Rebuilt on the FLUTE version 1 compliance branch rather than on the FEC branches, so it carries no Raptor and no RaptorQ: zero files of either. The Raptor and RaptorQ test suites are deliberately not registered in tests/CMakeLists.txt here, and the reason is stated at that line. Verification T1: 62 cases pass at the build root, 12 of them in the FluteV2 suite, covering both readings of the LCT bits, the three branches of the version 2 identifier sequence, and the worked example RFC 6726 clause 3.3 gives for the era calculation. Quotations checked with tools/verify-citations.py in --strict mode. T2: ip xfrm state show on an installed association reports "replay-window 32" beside the enc and auth-trunc lines. 32 is the ceiling the legacy attribute expresses, the kernel holding its replay bitmap in a __u32; a request for 64 is clamped. Not in this change Congestion control, which RFC 5775 requires for every packet in a session and which this library does not implement. It is a building block, not a patch, and until it exists no RFC 6726 conformance is claimed for this branch and none can be. It is the only remaining item.
jordijoangimenez
force-pushed
the
feature/flute-v2-support
branch
from
August 23, 2026 07:38
22baee6 to
654e052
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Advances #81. Does not close it, and must not be set to.
Dependencies and issues
Depends on: #62, and is based on its branch, so #62 merges first.
Paired with: #61, #64, #68 and #98, independent of this one, either order.
Closes on merge: nothing. It advances #81 by one of the three steps that issue lists, and #81 must
stay open afterwards.
What is in this pull request
One commit. A per-session FLUTE version, defaulting to 1, plus every version 2 rule that differs
from version 1 except congestion control. Nothing here is reachable from a version 1 or 3GPP
session; each difference is behind the selector.
ExpiresChecked and already met, so no code changed: EXT_TIME and EXT_AUTH recognition (RFC 5651 asks
only that they be recognised, not parsed); the RFC 3450 to RFC 5775 move, whose two substantive
items were already present; the FDT schema body, whose attribute set matches and whose 3GPP extras
the schema itself admits; and ESP authentication and integrity.
README-FLUTE-V2.mdrecords eachof these, how it was established, and where the evidence is a reading rather than a test.
Not implemented: congestion control. RFC 5775 requires it for every packet in a session. It is
a building block, not a patch. No RFC 6726 conformance is claimed for this branch and none can be
until that exists. It is the only remaining item.
What this is not
This is not FLUTE version 2 support, and makes no conformance claim. #81 separates that into three
steps and this is the first. RFC 6726 requires RFC 5775 and RFC 5651 beneath the FDT; this library's ALC
and LCT layers are still RFC 3450 and RFC 3451, and neither of the newer documents is held by us, so no
version 2 conformance can be asserted either way, whatever the version field says.
What this earns is that the version stops being hardcoded.
Version 1 stays the default because the profile this library's consumers operate, TS 26.517 clause 6.2.1
pointing at TS 26.346 annex L, is scoped to RFC 3926 throughout. That was @davidjwbbc's point on #62, and
it is why this material was split out of that branch rather than merged into it.
Verification
T1: 77 cases passing, including that a version 2 session signals 2 and a version 1 session is unchanged.
No live verification: there is no version 2 peer to test against, and none is claimed.
Merge order
After #62. Independent of the FEC branches.