CCNx Content Object Chunking
draft-irtf-icnrg-ccnxchunking-05

ICNRG                                                         M.E. Mosko
Internet-Draft                                                          
Updates: 8569, 8609 (if approved)                              H. Asaeda
Intended status: Experimental                                       NICT
Expires: 17 December 2026                                   15 June 2026

                      CCNx Content Object Chunking
                    draft-irtf-icnrg-ccnxchunking-05

Abstract

   This document specifies a chunking protocol for dividing a user
   payload into CCNx Content Objects.  It defines a name segment type to
   identify each sequential chunk number and a Content Object field to
   identify the last available chunk number.  This includes
   specification for the naming convention to use for the chunked
   payload and a field added to a Content Object to represent the last
   chunk of an object.  This document updates RFC8569 and RFC8609.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Mosko & Asaeda          Expires 17 December 2026                [Page 1]
Internet-Draft                CCNx chunking                    June 2026

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  CCNx Chunking . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Protocol Specification  . . . . . . . . . . . . . . . . .   3
     3.2.  Cryptographic Material  . . . . . . . . . . . . . . . . .   6
     3.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  TLV Types . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  ChunkNumber TLV . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  EndChunkNumber and ChunkSize TLVs . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  CCNx Name Segment Type Registry . . . . . . . . . . . . .   9
     6.2.  CCNx Message Type Registry  . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   CCNx Content Objects [RFC8569] are sized to amortize cryptographic
   operations over user data while simultaneously staying a reasonable
   size for transport over today's networks.  This means a Content
   Object is typically sized to fit within the path MTU of the
   underlying transport.  A producer MUST ensure that the size of each
   Content Object does not exceed the effective path MTU.  Determination
   of the path MTU is outside the scope of this specification and may
   rely on local configuration or path MTU discovery mechanisms.  In
   environments where the path MTU is unknown, producers SHOULD
   conservatively select a Content Object size that avoids
   fragmentation.  If a publisher has a larger amount of data to
   associate with a single Name, the data may be chunked with this
   chunking protocol.  This protocol uses state in the Name and in an
   optional field within the Content Object.  A chunked object may also
   have an external metadata that describes the original pre-chunked
   object.

   For example, a video file may be several gigabytes of data.  To
   publish the video, one would divide it up into transport-sized
   Content Objects.  Each Content Object would have a common name prefix
   plus a chunk number.

Mosko & Asaeda          Expires 17 December 2026                [Page 2]
Internet-Draft                CCNx chunking                    June 2026

   CCNx uses two types of messages: Interests and Content Objects
   [RFC8569].  An Interest carries the hierarchically structured Name of
   a Content Object which serves as a request to return that object.  A
   Content Object contains the Name, the object's Payload, and the
   cryptographic information used to bind the Name to the payload.

   This document introduces three new protocol elements to CCNx by
   updating [RFC8609].

   *ChunkNumber*  A new CCNx Name Segment TLV for conveying chunk
      numbers.

   *EndChunkNumber*  A new CCNx Message Type TLV for conveying the last
      chunk number of the content.

   *ChunkSize*  A new CCNx Message Type TLV for specifying a constant
      payload size.

   Experiments employing ICN protocols like CCNx all require a
   consistent way to represent objects larger than can be carried as a
   single protocol message.  This specification provides such
   capabilities for simple cases where the flexibility of a Manifest
   approach like that in FLIC [I-D.irtf-icnrg-flic] are not strictly
   needed.  Experiments will shed light on how to best optimize the
   fetching of large objects using CCNx Interest/Data exchanges.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119] and
   [RFC8174] when, and only when, they appear in all capitals, as shown
   here.

3.  CCNx Chunking

3.1.  Protocol Specification

   Chunking, as used in this specification, means serializing user data
   into one or more chunks, each encapsulated in a CCNx Content Object.
   A chunk is a contiguous byte range within the user data.  One segment
   in the Name of each Content Object represents the chunk number.
   Chunks are denoted by a serial counter, beginning at 0 and
   incrementing by 1 for each contiguous chunk.  A field in the Content
   Object indicates that a chunk is the last chunk of the object.

Mosko & Asaeda          Expires 17 December 2026                [Page 3]
Internet-Draft                CCNx chunking                    June 2026

   This document introduces the new CCNx Name Segment TLV, ChunkNumber,
   for conveying chunk numbers.  The ChunkNumber is the serial order of
   the chunks.  It MUST begin at 0 and MUST be incremented by 1.  The
   value of the ChunkNumber TLV is a network byte order compact encoding
   of the chunk number.

   This document also introduces the new CCNx Message Type TLV,
   EndChunkNumber.  The EndChunkNumber indicates the last chunk number
   of the chunked user data.  It MUST be included in the Content Object
   which is the last chunk of user data, where the ChunkNumber TLV value
   and the EndChunkNumber TLV value MUST be the same.  The value of the
   EndChunkNumber value is the same format as the ChunkNumber name
   segment.  For example, if 3000 bytes of user data is split with a
   1200 byte block size, there will be 3 chunks: 0, 1, and 2.  The
   EndChunkNumber is 2.

   The EndChunkNumber field MAY be present in any of the object's
   chunks, such as to assist in pipelining Interests.  It MAY be placed
   repeatedly across multiple chunks to maximize the fetching
   flexibility of a consumer.

   The value of the EndChunkNumber MAY be increased by subsequent
   EndChunkNumber fields.  However, it SHOULD NOT be decreased.  If a
   publisher wishes to terminate creation of chunks before reaching the
   last chunk, it should publish empty Content Objects to fill out to
   the maximum EndChunkNumber ever published.  These padding chunks MUST
   contain the real last chunk number in the EndChunkNumber with an
   empty Payload TLV.  This mechanism for early termination is to
   accommodate circumstances where a data creation by the producer ended
   before expected.

   A consumer retrieves chunked objects by issuing Interests for
   sequential chunk numbers.  If a consumer issues an Interest with a
   chunk number greater than the EndChunkNumber, no Content Object
   exists for that chunk.  Therefore, no response is generated for such
   an Interest.

   It may occur that a publisher never includes an EndChunkNumber, and
   thus has never published the last chunk.  This may happen due to an
   error or network conditions that do not allow finding the last chunk.
   If a consumer times out trying to retrieve chunks, it SHOULD report
   an error to the user and terminate.  This is similar to a TCP client
   not hearing a FIN.

   If the user data fits within one Content Object and the publisher
   uses the Chunking protocol, the publisher MUST assign a name to the
   content with "Chunk=0" and includes "EndChunkNumber=0" (assuming the
   Payload is in the first chunk).

Mosko & Asaeda          Expires 17 December 2026                [Page 4]
Internet-Draft                CCNx chunking                    June 2026

   In addition, this document introduces the new CCNx Message Type TLV,
   ChunkSize, for specifying a constant payload size.  Chunking MAY use
   a fixed block size, where only the last chunk MAY use a smaller block
   size.  This is required to allow a reader to seek to a specific byte
   offset once it knows the block size.  If the first (Chunk 0) object
   has the field ChunkSize, then the series of chunked objects uses a
   fixed payload size.  ChunkSize MUST only appear in Chunk 0, if it is
   used.  Chunk number 0 MAY be used to carry metadata (e.g.,
   cryptographic information).  When metadata is present, user data MAY
   begin at a subsequent chunk number greater than 0.  When metadata is
   not present, user data MAY begin at chunk number 0.  Producers SHOULD
   place metadata in leading chunks and user data in subsequent chunks
   in order to simplify consumer processing.

   Consistency checks apply both within a single Content Object and
   across multiple Content Objects belonging to the same chunked object.
   Any mismatch between the value of the length field of the Payload TLV
   and the ChunkSize TLV is considered an error of chunk creation by the
   producer, except for the last chunk, which may have a smaller payload
   size.  Such mismatched Content Objects MUST be discarded by the
   consumer.  If a consumer observes inconsistent ChunkSize or
   EndChunkNumber values across multiple Content Objects, it SHOULD
   treat the object as invalid, as this may indicate corruption or
   malicious modification.  Implementations SHOULD discard inconsistent
   Content Objects and MAY apply local recovery policies.

   Because of the possible use of a fixed block size, the inclusion of
   certain cryptographic fields in the same Content Objects as user data
   would throw off the ability to seek.  Therefore, it is RECOMMENDED
   that all required cryptographic data, such as public keys or key name
   links, be included in the leading chunks before the first byte of
   user data.  User data SHOULD then run continuously.  If the publisher
   included ChunkSize in Chunk 0, then all Payload sizes must be of
   ChunkSize except the last, which may be smaller.

   The placement of cryptographic metadata in leading chunks may result
   in misalignment between user data offsets and the nominal chunk size.
   Consumers SHOULD NOT assume that user data offsets are aligned to
   multiples of the chunk size.  Producers SHOULD use dedicated metadata
   chunks to minimize such misalignment.

   Data produced using the chunking protocol may also be represented via
   a Manifest (e.g., FLIC [I-D.irtf-icnrg-flic]).  An advantage of using
   a Manifest is that all cryptographic data is in the manifest, which
   then links to each chunk via a full hash name.  This means that the
   chunked user data can devote all available Content Object bytes after
   the name to the user data.

Mosko & Asaeda          Expires 17 December 2026                [Page 5]
Internet-Draft                CCNx chunking                    June 2026

3.2.  Cryptographic Material

   Chunk 0 MAY include the public key or key name link used to verify
   the chunked data.  It is RECOMMENDED to use the same key for the
   whole set of chunked data.  If a publisher uses multiple keys, then
   the public key or key name link for all keys SHOULD be in the leading
   chunks before any user data.  Each subsequent chunk only needs to
   include the KeyId and signature.

   The size of each Content Object, including payload, keys, signatures,
   and all TLVs, is constrained by the path MTU.  This consideration
   becomes particularly relevant when large cryptographic signatures
   (e.g., post-quantum signatures) are used.

   As noted above, using a Manifest eliminates the need for
   cryptographic material in the user-data Content Objects.

3.3.  Examples

   Here are some examples of chunked Names using the Labeled Content
   Identifier URI scheme in human readable form (ccnx:).

   In this example, the content producer publishes a JPG that takes 4
   Chunks.  The EndChunkNumber is missing in the first content object
   (Chunk 0), but is known and included when Chunk 1 is published.  It
   is omitted in Chunk 2, then appears in Chunk 3, where it is
   mandatory.

   ccnx:/Name=example.com/Name=picture.jpg/Chunk=0  --
   ccnx:/Name=example.com/Name=picture.jpg/Chunk=1  EndChunkNumber=3
   ccnx:/Name=example.com/Name=picture.jpg/Chunk=2  --
   ccnx:/Name=example.com/Name=picture.jpg/Chunk=3  EndChunkNumber=3

   In this example, the publisher is publishing an audio stream that
   ends before expected so the publisher fills empty Content Objects out
   to the maximum ChunkNumber, stating the correct EndChunkNumber.
   Chunks 4, 5, and 6 do not contain any new user data.

   ccnx:/Name=example.com/Name=talk.wav/Chunk=0  --
   ccnx:/Name=example.com/Name=talk.wav/Chunk=1  EndChunkNumber=6
   ccnx:/Name=example.com/Name=talk.wav/Chunk=2  --
   ccnx:/Name=example.com/Name=talk.wav/Chunk=3  EndChunkNumber=3
   ccnx:/Name=example.com/Name=talk.wav/Chunk=4  EndChunkNumber=3
   ccnx:/Name=example.com/Name=talk.wav/Chunk=5  EndChunkNumber=3
   ccnx:/Name=example.com/Name=talk.wav/Chunk=6  EndChunkNumber=3

Mosko & Asaeda          Expires 17 December 2026                [Page 6]
Internet-Draft                CCNx chunking                    June 2026

4.  TLV Types

   This section specifies the TLV types used by CCNx chunking.  All
   integer fields defined in this section, including those illustrated
   in the figures, use the variable-length integer encoding defined by
   the CCNx TLV format [RFC8609].  TBA by IANA (see Section 6).

4.1.  ChunkNumber TLV

   CCNx chunking defines one new CCNx Name Segment type in the IANA
   Registry: ChunkNumber.

   +======+=========+==========+=======================================+
   | Type |  Abbrev |   Name   | Description                           |
   +======+=========+==========+=======================================+
   | TBA  | T_CHUNK |  Chunk   | The Chunk number of the               |
   |  by  |         |  Number  | associated Content Object.  It is     |
   | IANA |         | (Section | an unsigned integer in network        |
   |      |         |   4.1)   | byte order without leading zeros.     |
   |      |         |          | The value of zero is represented      |
   |      |         |          | as the single byte %x00.              |
   +------+---------+----------+---------------------------------------+

                            Table 1: ChunkNumber

   In ccnx: URI form, it is denoted as "Chunk", like the example shown
   in Section 3.3.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+---------------+--------------+
   |           T_CHUNK             |             Length           |
   +---------------+---------------+---------------+--------------+
   |     variable length integer   /
   +---------------+---------------+

                         Figure 1: ChunkNumber TLV

4.2.  EndChunkNumber and ChunkSize TLVs

   CCNx chunking defines two new CCNx Message types in the IANA
   Registry: EndChunkNumber and ChunkSize.

Mosko & Asaeda          Expires 17 December 2026                [Page 7]
Internet-Draft                CCNx chunking                    June 2026

   +======+==============+================+============================+
   | Type |    Abbrev    |      Name      | Description                |
   +======+==============+================+============================+
   | TBA  |  T_ENDCHUNK  | EndChunkNumber | The value in the           |
   |  by  |              | (Section 4.2)  | EndChunkNumber TLV         |
   | IANA |              |                | indicates the last         |
   |      |              |                | chunk number.  It is       |
   |      |              |                | an unsigned integer in     |
   |      |              |                | network byte order         |
   |      |              |                | without leading zeros.     |
   |      |              |                | The value of zero is       |
   |      |              |                | represented as the         |
   |      |              |                | single byte %x00.          |
   +------+--------------+----------------+----------------------------+
   | TBA  | T_CHUNK_SIZE |   ChunkSize    | The fixed payload size     |
   |  by  |              | (Section 4.2)  | of user data up to the     |
   | IANA |              |                | last chunk.  It MUST       |
   |      |              |                | be a positive integer.     |
   +------+--------------+----------------+----------------------------+

                   Table 2: EndChunkNumber and ChunkSize

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+---------------+--------------+
   |          T_ENDCHUNK           |             Length           |
   +---------------+---------------+---------------+--------------+
   |     variable length integer   /
   +---------------+---------------+

                        Figure 2: EndChunkNumber TLV

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+---------------+--------------+
   |         T_CHUNK_SIZE          |             Length           |
   +---------------+---------------+---------------+--------------+
   |     variable length integer   /
   +---------------+---------------+

                          Figure 3: ChunkSize TLV

5.  Acknowledgements

   The authors would like to thank Ken Calvert, David Oran, and Joerg
   Ott for their valuable comments and suggestions on this document.

Mosko & Asaeda          Expires 17 December 2026                [Page 8]
Internet-Draft                CCNx chunking                    June 2026

6.  IANA Considerations

   As per [RFC8126], this section makes an assignment in one existing
   registry in the "Content-Centric Networking (CCNx)" registry group.
   This document registers the following values:

   *  ChunkNumber (T_CHUNK) for the CCNx Name Segment Type registry

   *  EndChunkNumber (T_ENDCHUNK) for the CCNx Message Type registry

   *  ChunkSize (T_CHUNK_SIZE) for the CCNx Message Type registry

   The registration procedure is "RFC Required".

6.1.  CCNx Name Segment Type Registry

   This document defines one message type, T_CHUNK, whose suggested
   value is %x0005.

6.2.  CCNx Message Type Registry

   This document defines two message types, T_ENDCHUNK and T_CHUNK_SIZE,
   whose suggested values are %x0008 and %0x0009, respectively.

7.  Security Considerations

   The addition of chunking for large application objects does not
   change the existing methods used in CCNx for authenticating user
   data, as it employs Content Objects in the same way as for non-
   chunked data.  Therefore, existing signing and encryption mechanisms
   may be used without modification.

   This specification does not mandate whether integrity protection is
   applied at the chunk level or at the object level.  Implementations
   MAY use per-chunk signatures or object-level validation mechanisms.

   If individual chunks are signed, each Content Object MUST carry its
   own signature.  If integrity verification is deferred until multiple
   chunks are received, this may increase exposure to resource
   exhaustion attacks.  This may require buffering multiple chunks
   before verification.  Implementations SHOULD consider mechanisms such
   as early validation or resource limits.  If validation fails,
   implementations MAY terminate processing of the affected chunked
   object.

8.  References

8.1.  Normative References

Mosko & Asaeda          Expires 17 December 2026                [Page 9]
Internet-Draft                CCNx chunking                    June 2026

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8569]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Semantics", RFC 8569,
              DOI 10.17487/RFC8569, July 2019,
              <https://www.rfc-editor.org/info/rfc8569>.

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,
              <https://www.rfc-editor.org/info/rfc8609>.

8.2.  Informative References

   [I-D.irtf-icnrg-flic]
              Tschudin, C., Wood, C. A., Mosko, M., and D. R. Oran,
              "File-Like ICN Collections (FLIC)", Work in Progress,
              Internet-Draft, draft-irtf-icnrg-flic-07, 3 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
              flic-07>.

Authors' Addresses

   Marc Mosko
   Kensington, California 94707
   United States of America
   Email: marc@mosko.org

   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Tokyo
   184-8795
   Japan
   Email: asaeda@nict.go.jp

Mosko & Asaeda          Expires 17 December 2026               [Page 10]