Summary
- RFC 5163's PDU-Concat places several usually short PDUs under one common ULE type and, when present, one NPA destination, reducing repeated overhead while making validation and loss correlated.
- A trustworthy operating record must separate bundle admission, timed emission, integrity, member-length reconciliation, extraction, onward forwarding and higher-layer acceptance; none of those receipts can stand in for the next.
Four short packets are perfectly formed. A fifth says it is longer than the bytes left inside the envelope. A receiver cannot forward the fragment and hope the next layer will make sense of it. Under RFC 5163, that final mismatch can stop the whole SubNetwork Data Unit before any member leaves the validation boundary.
That is the quiet trade inside PDU-Concat. The extension was designed for a sensible reason: many small Protocol Data Units headed toward the same Network Point of Attachment otherwise repeat link-layer framing and processing. Put them in one SNDU, carry their common type once, carry one destination when it is present, and recover efficiency.
The overhead disappears. The independence does not survive unchanged.
The saving comes from shared context
PDU-Concat is mandatory extension type 3 in the ULE Next-Header registry. Its outer header declares the length of the complete SNDU. One PDU-Concat-Type describes every enclosed member; recursive PDU-Concat is forbidden, and all members must have the same ULE type. Each member then contributes only a 15-bit byte length and its payload.
If an NPA address is present, the receiver must associate that same address with every member. If the address is absent, every member is processed without one. Earlier extension headers, such as TimeStamp, apply to the composite bundle rather than becoming a private field for each member.
These are not incidental restrictions. They are where the efficiency comes from. Type, destination and selected group-level metadata are no longer repeated. The receiver can reject an unwanted destination once and skip several PDUs in one operation.
But the common NPA is only a link-layer receiver selector. RFC 4259 explicitly warns that NPA filtering is weak security: it may be software controlled and can resemble promiscuous Ethernet reception. The address does not authenticate the sender, authorize the contents or prove that every enclosed IP packet has the same network-layer destination. Shared framing context is not shared trust.
One length ledger closes the bundle
The receiver cannot treat PDU-Concat as a sack of unrelated byte strings. It must recognise the declared PDU type, verify every member length and ensure that the sum of processed lengths agrees with the length in the SNDU base header. Unsupported types must be discarded and should produce a PDU-Type error.
RFC 5163 says the receiver should discard the whole SNDU when the total and member sizes are inconsistent and should record a PDU-Concat size-mismatch error. It separately says the receiver must not forward a partial PDU whose declared length exceeds the unprocessed bytes remaining. The distinction in normative strength matters. The whole-bundle rule is a SHOULD; the ban on forwarding the impossible tail is a MUST NOT.
Integrity does not collapse those checks into one. ULE validates a CRC-32 over the SNDU; fragmented GSE places CRC-32 in the final fragment and removes it after reassembly. A correct integrity check can show that the received bytes match their protected envelope. It does not show that the internal member-length ledger is coherent, that the PDU type is supported or that the NPA matches the receiver.
That creates an evidence chain, not one green status:
- the encapsulator admitted same-type PDUs to a pending bundle;
- a threshold or size trigger caused emission;
- the receiver completed ULE or GSE framing and integrity checks;
- it recognised the mandatory extension and member type;
- every member fit inside the remaining payload;
- the length sum reconciled to the outer length;
- complete members were extracted and forwarded; and
- each higher layer produced its own result.
A registry entry proves only that a number was assigned. A successful CRC proves only its integrity scope. An accepted bundle proves neither application execution nor user outcome.
Waiting is part of the protocol cost
Concatenation needs time to find companions. RFC 5163 therefore calls for a bounded, configurable PDU Packing Threshold. A larger threshold may improve efficiency, but it adds jitter and may increase corruption probability. When the threshold expires without another PDU, the encapsulator must send the queued members immediately.
There is no universal correct threshold in the RFC. A value that makes sense for a stream of tiny control packets may be unacceptable for traffic whose deadline is already close. The gain should be expressed as saved header bytes and reduced receiver work. The cost should be expressed as added waiting time and the number of otherwise independent PDUs exposed to one envelope failure.
TS-Concat makes the same tension visible in a different format. It carries one or more fixed 188-byte MPEG-2 TS packets. If the remaining length is not an integral multiple of 188, the receiver must discard every encapsulated TS packet. Its packing threshold is also bounded and configurable. This is not evidence that bundling is unsafe; it is evidence that efficiency has an explicit failure granularity.
Optional does not mean unimportant, and mandatory does not mean sufficient
RFC 4326 makes optional extension headers skippable because their H-LEN reveals their size. RFC 5163's TimeStamp is such an option. A receiver may process it or skip it, but must continue to the next header and forward the PDU. Its 32-bit microsecond counter can support order checking, one-way delay with a synchronised sender clock, jitter analysis and loss analysis with additional sender information.
PDU-Concat is different. It changes how the remaining bytes are divided into PDUs, so a receiver that does not understand it cannot safely jump to an imagined payload. Mandatory extension handling protects parse meaning; it does not guarantee that the bundle will pass its subsequent checks.
Sources
- https://www.rfc-editor.org/rfc/rfc5163.html
- https://www.rfc-editor.org/rfc/rfc5163.txt
- https://www.rfc-editor.org/info/rfc5163
- https://datatracker.ietf.org/doc/rfc5163/
- https://datatracker.ietf.org/doc/rfc5163/history/
- https://datatracker.ietf.org/doc/rfc5163/references/
- https://www.rfc-editor.org/errata/rfc5163
- https://www.rfc-editor.org/rfc/rfc4326.html
- https://www.rfc-editor.org/rfc/rfc4259.html
- https://www.rfc-editor.org/rfc/rfc4947.html
- https://www.rfc-editor.org/rfc/rfc5458.html
- https://www.rfc-editor.org/rfc/rfc7280.html
- https://www.iana.org/assignments/ule-next-headers/ule-next-headers.xhtml
- https://www.etsi.org/deliver/etsi_ts/102600_102699/10260601/01.03.01_60/ts_10260601v010301p.pdf
- https://www.rfc-editor.org/rfc/rfc2119.html
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
