Internet-Draft Penguin Intended status: Standards Track International UPA Expires: August 15, 2027 August 11, 2026 NG-Multicast-Publishing Protocol draft-iupa-ngg-multicast-publishing-01 Abstract This document defines the NG-Multicast-Publishing protocol, which is used to distribute free eBooks, publication metadata, and copyright information over IPv4/IPv6 multicast networks in an efficient and reliable manner. The protocol employs a one-to-many, unidirectional communication model and supports Any-Source Multicast (ASM). It is intended for use by libraries, educational institutions, and individual receivers worldwide. Design goals include very low resource consumption, no requirement for an uplink channel, permanently assigned multicast addresses, and end-to-end integrity verification. 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 expires on August 15, 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. OID Allocations . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The International United Publishing Association (IUPA) is committed to providing free ISBN registration, eBook publishing, and copyright registration to creators worldwide. To achieve efficient global distribution of publications, IUPA has designed the NG-Multicast- Publishing protocol. The protocol is based on IP multicast technology and allows a single publisher to transmit content simultaneously to an unlimited number of subscribers. It is particularly suitable for low-bandwidth, high-latency environments. 1.1. Design Goals * Permanent Addresses: Use globally unique multicast addresses permanently assigned by IANA; no dynamic configuration is needed. * Source-Independent: Any authorised publisher can send to the same group address; receivers do not need to know the source in advance. * Lightweight: The protocol header is extremely small (8 bytes), making it suitable for low-power devices. * Integrity Guarantee: End-to-end checksum with support for retransmission requests. * Scalability: From a few to millions of receiving devices without impacting the publisher's bandwidth. 2. Terminology Publisher: An entity that produces and sends publications, typically an author, a publishing house, or the IUPA platform. Receiver: A client that joins the multicast group and receives publications, such as a library server or a personal device. Publication: A complete transmission unit comprising metadata, content data, and integrity information. Multicast Group Address: The permanent address assigned by IANA for all transmissions. Message: A protocol data unit, of which three types are defined. 3. Protocol Overview 3.1. Transport Model The protocol uses the Any-Source Multicast (ASM) model as defined in [RFC4604]. A publisher sends UDP datagrams to the well-known multicast group address, and any receiver that has joined the group can receive them. The protocol does not require receivers to send any acknowledgements or data requests. 3.2. Multicast Addresses This protocol requires globally unique multicast addresses permanently assigned by IANA, following the guidelines in [RFC5771] for IPv4 and [RFC2375] for IPv6. IUPA has applied for both IPv4 and IPv6 addresses under the name "NG-Multicast-Publishing". The actual address values will be filled in once assigned. 3.3. Transport Layer The protocol runs over UDP. Default port: 4096. 4. Message Formats 4.1. Common Header All messages contain a fixed 8-byte header: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Publisher ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (1 byte): Protocol version; current value is 0x01. Message Type (1 byte): Defines the type of message. Publisher ID (4 bytes): A globally unique publisher identifier assigned by IUPA. 0x00000000 is reserved. Sequence Number (2 bytes): Message sequence number used for ordering and loss detection. Each publisher maintains its own counter, starting at 1 and incrementing by one. Payload Length (2 bytes): Length of the payload in bytes. 4.2. Message Types +-----------+---------------------+------------------------------+ | Type Value| Name | Description | +-----------+---------------------+------------------------------+ | 0x01 | Announcement | Contains publication | | | | metadata | | 0x02 | Data Chunk | Carries a fragment of the | | | | content | | 0x03 | Integrity Check | Contains a checksum over the | | | | entire publication | +-----------+---------------------+------------------------------+ 4.3. Announcement Payload The payload is a UTF-8 encoded JSON object with the following structure: { "title": "The Great Book", "author": "Jane Doe", "isbn13": "978-3-16-148410-0", "isbn10": "3-16-148410-X", "publisherCode": "978-3-16", "language": "en", "publicationDate": "2026-08-11", "chunkCount": 256, "checksumAlgorithm": "sha256" } 4.4. Data Chunk Payload The payload is raw binary data. The chunk size is specified in the Announcement message (default 1400 bytes). The last chunk may be smaller than the specified size. 4.5. Integrity Check Payload The payload contains a 32-byte SHA-256 hash value (in binary), computed over all data from the Announcement through the last Data Chunk, concatenated in transmission order. 5. Protocol Operation 5.1. Publishing Process 1. The publisher sends an Announcement message containing the publication metadata and the total number of data chunks. 2. The publisher sends one or more Data Chunk messages, each carrying a fixed-size fragment of the content (recommended 1400 bytes), in sequential order. 3. The publisher sends an Integrity Check message containing the SHA-256 hash of the entire publication. 5.2. Reception Process 1. The receiver joins the multicast group and listens on the port. 2. Upon receiving an Announcement, the receiver records the metadata and allocates a temporary reassembly buffer for that publication. 3. The receiver collects Data Chunk messages by Sequence Number and fills the buffer. 4. Upon receiving the Integrity Check, the receiver computes the hash of the received data and compares it with the provided one. If they match, the publication is successfully received; if not, or if some chunks are missing, the receiver enters the recovery procedure. 5.3. Recovery Mechanism If a receiver detects lost or corrupted data, it does not send any message to the publisher. Instead, it waits for the publisher to perform periodic retransmissions (e.g., every 5 minutes, the entire publication is repeated). The publisher may change the Sequence Number on each retransmission so that the receiver can identify duplicates. 6. Security Considerations 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 [RFC2119]. Source Authentication: Not implemented at the protocol layer. Instead, the IUPA platform assigns temporary Publisher IDs and keys at the application layer. Publishers attach an HMAC signature to the Announcement, and receivers can verify it using a pre-configured public key. Data Integrity: Provided by the SHA-256 hash in the Integrity Check message. Denial-of-Service (DoS): Any host can send data to the multicast group. Receivers SHOULD process only messages with a verified Publisher ID and SHOULD limit the size of reassembly buffers. Replay Attack Prevention: Publishers SHOULD include a timestamp or nonce in the Announcement payload, and receivers SHOULD discard messages with timestamps outside an acceptable window. This is especially important given the unidirectional nature of the protocol. 7. IANA Considerations This protocol requires IANA to assign the following resources: * One permanent IPv4 multicast address (request name: "NG-Multicast-Publishing", application already submitted). * One permanent IPv6 multicast address (request name: "NG-Multicast-Publishing", application already submitted). * Private Enterprise Number (PEN) 66468 has already been assigned for the OID tree used by this protocol. * The OID tree: all protocol-related management objects are located under 1.3.6.1.4.1.66468. 8. References 8.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, . [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, . [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, . [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, . Appendix A. OID Allocations IUPA's Private Enterprise Number (PEN) is 66468. The protocol management objects are located under the following OID prefixes: 1.3.6.1.4.1.66468.1.3.1.1 -> Announcement message type 1.3.6.1.4.1.66468.1.3.1.2 -> Data Chunk message type 1.3.6.1.4.1.66468.1.3.1.3 -> Integrity Check message type 1.3.6.1.4.1.66468.1.2.4.1 -> eBook formats (ePub, PDF) 1.3.6.1.4.1.66468.1.2.4.2 -> Default chunk size 1.3.6.1.4.1.66468.1.2.4.3 -> Checksum algorithm (SHA-256) Acknowledgments The author thanks the Preparatory Committee of the International United Publishing Association (IUPA) for their support. Penguin, founder of IUPA, provided the core vision for the protocol design. Author's Address Penguin International United Publishing Association (IUPA) Copenhagen, Denmark Email: njDQE2023@163.com