ICNRG H. Asaeda Internet-Draft H.H. Hlaing Updates: 8569, 8609 (if approved) NICT Intended status: Experimental M.E. Mosko Expires: 3 March 2027 30 August 2026 CCNx Content Versioning draft-irtf-icnrg-ccnxversioning-01 Abstract This document defines a method for content versioning in CCNx, enabling the differentiation of content published under the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [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 3 March 2027. 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. Asaeda, et al. Expires 3 March 2027 [Page 1] Internet-Draft CCNx Content Versioning August 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 4. Version TLV Type . . . . . . . . . . . . . . . . . . . . . . 4 5. Version Query . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Version Response . . . . . . . . . . . . . . . . . . . . . . 6 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1. CCNx Name Segment Type Registry . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In Information-Centric Networking protocols such as CCNx, a content name may be cryptographically bound to the associated payload. Content versioning allows consumers to distinguish successive objects published under the same base name and to request a specific version. This document specifies a content versioning scheme for CCNx. Content versions are explicitly named by defining a new CCNx Name Segment type to carry the version information. Each version number is an unsigned integer that increments by 1 for successive versions. Given a name with a serial number in a version TLV in a CCNx Name Segment, the next (or any prior) version number can be ascertained accordingly. If a consumer does not already know the full name (including the version number) of an existing version of the content, this document describes a Version Query for discovering the current (latest) version number of content. A Version Response is a Content Object whose Payload contains a CCNx Link identifying the full name of the current version, i.e., the latest version known to the responder. The current version number is carried in the Version TLV of the Link target Name. Notably, content versioning is not mandatory in CCNx, nor are consumers required to specify a version number to retrieve unversioned content. Asaeda, et al. Expires 3 March 2027 [Page 2] Internet-Draft CCNx Content Versioning August 2026 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] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Definitions This document follows the definitions provided in [RFC8793] for general ICN-related terms and in [RFC8569] and [RFC8609] for CCNx- specific terms. Moreover, the following terms are defined: *Versioned content* Content assigned a version number in its name, allowing differentiation by version. *Unversioned content* Content that is not assigned a version number and remains undistinguished by version. *Version Query* An Interest message sent from a consumer to a producer to retrieve the latest version number of specific content. The packet type for a Version Query is PT_INTEREST. It does not request the content object itself. *Version Response* A Content Object sent in response to a Version Query. Its Payload contains a CCNx Link whose target name identifies the latest version of the requested content known to the responder. The Version TLV in the target name carries the current version number. The packet type of a Version Response is PT_CONTENT. The Version Response does not carry the payload of the referenced versioned content. 3. Protocol Description This document introduces one new CCNx Name Segment TLV: the Version TLV. As the Version TLV is optional, consumers can send Interest packets without including it (see below). Nevertheless, if consumers wish to retrieve a specific version of content (e.g., the latest version), they MUST specify the version number in the Version TLV and send an Interest packet with this information. Asaeda, et al. Expires 3 March 2027 [Page 3] Internet-Draft CCNx Content Versioning August 2026 Version numbers establish a sequential order of names and are represented as unsigned integers. They are encoded using network byte order with the minimum necessary bytes. The value of "0" is represented as a single byte (%x00). Version numbers are incremented for consecutive versions of preceding name segments. There is no predefined upper limit for version numbers; the maximum is determined solely by the available number of bytes allocated in the name component. Versioned content is retrieved by including the version as a CCNx Name Segment TLV in the Interest name. By convention, it makes sense to make it a trailing Name Segment (possibly followed by a chunk number if [I-D.irtf-icnrg-ccnxchunking] is employed). Producers or forwarders (e.g., caching routers) respond with the corresponding packet using the standard CCNx Content Object to Interest matching rules from Section 9 of [RFC8569]. If a consumer sends an Interest including a Version TLV for unversioned content, the content name is mismatched; therefore, the Interest packet is discarded. Similarly, if a consumer sends an Interest without a Version TLV for versioned content, the content name is mismatched, and the Interest packet is discarded. If a consumer requests versioned content by specifying an unknown version number in a Version TLV, the Interest packet is discarded. If consumers want to ensure that they get the latest version's content, they need to specify the latest version number of the content. To query the latest version number of versioned content, this document defines an Interest-Data exchange called Version Query- Response (described in Section 5 and Section 6). When a consumer sends an Interest for versioned content with a Version TLV of length zero, the producer returns a Version Response. The Version Response is a Content Object with a PayloadType of T_PAYLOADTYPE_LINK. Its Payload contains exactly one CCNx Link (Section 6 of [RFC8569]) whose target Name identifies the latest version known to the responder. The target name MUST contain a non-empty Version TLV. The value of that Version TLV is the current version number. The addition of content versioning does not affect the operation of CCNx forwarders, only consumers and producers that desire to support versioned content. The specifications outlined in this document are implemented in Cefore [Asaeda2019][Cefore]. 4. Version TLV Type CCNx versioning introduces a new CCNx Name Segment type: Version. The Version TLV is used to identify content versions and to carry the current version number in a Version Response Link target. Asaeda, et al. Expires 3 March 2027 [Page 4] Internet-Draft CCNx Content Versioning August 2026 +======+===========+=========+======================================+ | Type | Abbrev | Name | Description | +======+===========+=========+======================================+ | TBA | T_VERSION | Version | The version number, encoded as an | | by | | Number | unsigned integer in network byte | | IANA | | | order without leading zeros. A | | | | | zero-length Version TLV is used | | | | | only in a Version Query. A | | | | | Version TLV in a Version Response | | | | | Link target MUST have a non-zero | | | | | Length and carries the current | | | | | version number. | +------+-----------+---------+--------------------------------------+ Table 1: Version 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_VERSION | Length | +---------------+---------------+---------------+--------------+ | variable length integer / +---------------+---------------+ Figure 1: Version TLV An Interest packet may include a chunk number [I-D.irtf-icnrg-ccnxchunking], as well as content name and version number. If the version number is included in the CCNx Name TLV, the Version TLV specifying the version number MUST immediately follow the last T_NAMESEGMENT specifying the content name. For an Interest requesting versioned content, if both a version number and a chunk number are included, the Version TLV MUST be followed by the ChunkNumber TLV. On the other hand, as specified in Section 5, a Version Query MUST NOT include a ChunkNumber TLV. Below are examples of version names using the labeled content identity URI scheme in human-readable form (ccnx:). In the ccnx: URI form, it is denoted as "Ver". In the following example, the content producer publishes a JPG with version number 1. ccnx:/Name=ietf.org/Name=abc.jpg/Ver=1 The following examples indicate content identified using its name, version number, and chunk number. Asaeda, et al. Expires 3 March 2027 [Page 5] Internet-Draft CCNx Content Versioning August 2026 ccnx:/Name=ietf.org/Name=abc.jpg/Ver=1/Chunk=0 -- ccnx:/Name=ietf.org/Name=abc.jpg/Ver=1/Chunk=1 EndChunkNumber=3 ccnx:/Name=ietf.org/Name=abc.jpg/Ver=1/Chunk=2 -- ccnx:/Name=ietf.org/Name=abc.jpg/Ver=1/Chunk=3 EndChunkNumber=3 5. Version Query Consumers can ascertain the latest known version number of versioned content by issuing a Version Query. A Version Query is a standard CCNx Interest that includes CCNx Name Segment TLV(s) specifying the content name and a Version TLV with no version number (i.e., the Length field in the Version TLV is set to 0) (see Figure 2). A Version Query normally travels towards the publisher via CCNx routing. A producer or another node that knows the current version may respond with a Version Response described in Section 6. 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_VERSION | Length (= 0x00) | +---------------+---------------+---------------+--------------+ Figure 2: Version Query containing Version TLV with no version number A Version Query MUST NOT include a ChunkNumber TLV. The query applies to the content identified by the Name Segments preceding the zero-length Version TLV and not to an individual chunk. As described in Section 6, a Version Query does not always result in a Version Response. The absence of a Version Response does not by itself indicate that the specified content is unversioned, because the Version Query or Version Response may have been lost, or no reachable responder may support this specification. 6. Version Response A producer or another node that knows the current version sends a Version Response in reply to a Version Query. An intermediate forwarder may also satisfy the Version Query with a valid cached Version Response, as described below. A Version Response is a standard CCNx Content Object. Its Name MUST exactly match the Name of the Version Query, including the zero- length Version TLV. The Content Object MUST specify T_PAYLOADTYPE_LINK as its PayloadType. For a Version Response, the Payload MUST contain exactly one CCNx Link. CCNx Link semantics are Asaeda, et al. Expires 3 March 2027 [Page 6] Internet-Draft CCNx Content Versioning August 2026 defined in Section 6 of [RFC8569], and the corresponding encoding is specified in Section 3.3.4 of [RFC8609]. A Version Response identifies only the current version known to the responder, even if the responder knows earlier versions of the content. The Link target Name MUST identify content corresponding to the latest version known to the responder. The Link target Name is an independent CCNx Name and is not interpreted relative to the Version Response Name. It MUST contain a non-empty Version TLV whose value is the current version number. A version number of zero is encoded as a one-octet value of %x00 and MUST NOT be represented by a zero- length Version TLV. The Link SHOULD include a ContentObjectHashRestriction, a KeyIdRestriction, or both. Any restriction carried in the Link applies to the content object identified by the Link target Name and not to the Version Response itself. Upon receiving a valid Version Response, the consumer may issue an Interest using the Link target Name and any restrictions carried in the Link to retrieve the current versioned content. A consumer that requires only the current version number may instead extract it from the Version TLV in the Link target Name without retrieving the referenced content. If the responder does not know a current version for the content specified in the Version Query, or if the content is unversioned, it silently discards the Version Query without returning a Version Response. A Version Response MAY include a Recommended Cache Time (RCT) and MUST include an ExpiryTime. An intermediate forwarder may cache a Version Response and use it to satisfy a matching Version Query in accordance with the cache-control rules of [RFC8569]. The ExpiryTime of a Version Response SHOULD reflect the responder's expectation of how long the Link target will remain the current version; it does not specify the expiry time of the content object identified by the Link target. A Version Response SHOULD be signed by a key trusted for the namespace of the content specified in the Version Query. This allows a consumer to verify that the Link identifying the current version was issued by an authorized responder. 7. Example Suppose that a producer publishes the following versioned content: Asaeda, et al. Expires 3 March 2027 [Page 7] Internet-Draft CCNx Content Versioning August 2026 ccnx:/Name=ietf.org/Name=abc.jpg/Ver=42 A consumer that does not know the current version sends a Version Query with the following Name: ccnx:/Name=ietf.org/Name=abc.jpg/Ver= The empty value of Ver denotes a zero-length Version TLV and does not denote version number zero. The producer returns a Version Response whose Content Object Name is identical to the Version Query Name. The PayloadType is T_PAYLOADTYPE_LINK, and the Payload contains a Link whose target is the full name of version 42: Content Object Name: ccnx:/Name=ietf.org/Name=abc.jpg/Ver= PayloadType: T_PAYLOADTYPE_LINK Link Target Name: ccnx:/Name=ietf.org/Name=abc.jpg/Ver=42 The current version number is therefore 42, as encoded in the Version TLV of the Link target Name. The consumer may subsequently issue an Interest for the Link target Name. 8. IANA Considerations This document requests one assignment from the "CCNx Name Segment Types" registry in the "Content-Centric Networking (CCNx)" registry group. The registration procedure is "RFC Required", which requires only that this document be published as an RFC. 8.1. CCNx Name Segment Type Registry This document defines one CCNx Name Segment type, T_VERSION, whose suggested value is %x0004. 9. Security Considerations A forged Version Response could direct a consumer to an incorrect or outdated version of content. A consumer therefore should verify the Validation of a Version Response according to the trust model applicable to the requested namespace before using the Link target Name or extracting its Version TLV. Asaeda, et al. Expires 3 March 2027 [Page 8] Internet-Draft CCNx Content Versioning August 2026 A ContentObjectHashRestriction or KeyIdRestriction carried in the Link applies to the content object identified by the Link target and does not authenticate the Version Response itself. Therefore, such a restriction does not replace Validation of the Version Response. A previously valid Version Response may become stale when a newer version is published. Responders should select an ExpiryTime that limits the period during which a cached Version Response may identify an older version as current. Consumers requiring a stronger guarantee that the returned version is current may need an additional application-specific mechanism. 10. Acknowledgements The authors would like to thank David Oran for his valuable comments and suggestions on this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, . [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, . 11.2. Informative References Asaeda, et al. Expires 3 March 2027 [Page 9] Internet-Draft CCNx Content Versioning August 2026 [Asaeda2019] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: Software Platform Enabling Content-Centric Networking and Beyond", IEICE Transactions on Communications, Vol.E102-B, No.9, DOI 10.1587/transcom.2018EII0001, September 2019, . [Cefore] "Cefore", . [I-D.irtf-icnrg-ccnxchunking] Mosko, M. and H. Asaeda, "CCNx Content Object Chunking", Work in Progress, Internet-Draft, draft-irtf-icnrg- ccnxchunking-05, 15 June 2026, . [I-D.irtf-icnrg-reflexive-forwarding] Oran, D. R., KUTSCHER, D., Asaeda, H., and K. Calvert, "Reflexive Forwarding for CCNx and NDN Protocols", Work in Progress, Internet-Draft, draft-irtf-icnrg-reflexive- forwarding-02, 23 September 2025, . [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology", RFC 8793, DOI 10.17487/RFC8793, June 2020, . Authors' Addresses Hitoshi Asaeda National Institute of Information and Communications Technology Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp Htet Htet Hlaing National Institute of Information and Communications Technology Koganei, Tokyo 184-8795 Japan Email: htethtethlaing@nict.go.jp Asaeda, et al. Expires 3 March 2027 [Page 10] Internet-Draft CCNx Content Versioning August 2026 Marc Mosko Kensington, California 94707 United States of America Email: marc@mosko.org Asaeda, et al. Expires 3 March 2027 [Page 11]