Network Working Group J. Chen Internet-Draft Independent Researcher Intended status: Informational 21 Nov 2025 Expires: 25 Nov 2026 Dynamic No-Entry Zone Dissemination in IPv6 Vehicular Networks draft-jun-chen-ipwave-dynamic-no-entry-zone-00 Abstract This document defines the Dynamic No-Entry Zone (DNEZ) information element and its dissemination mechanism using IPv6-based vehicular networks. A DNEZ is a temporary lane-level polygonal area generated by a stopped or faulty vehicle to indicate a region that surrounding vehicles may need to avoid. The primary use case is to provide redundancy when roadside perception systems fail due to occlusion, weather, or infrastructure limitations. The DNEZ is disseminated using geographically-scoped IPv6 multicast (GeoBroadcast) as defined in RFC 9366. Receiving vehicles or Road Side Units (RSUs) may rebroadcast the message to extend coverage. Local interpretation and usage of the DNEZ is implementation-specific and outside the scope of this document. 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." Copyright Notice Copyright (c) 2025 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. Table of Contents 1. Introduction ................................................ 3 1.1. Requirements Language ................................. 3 2. Terminology ............................................... 4 3. Dynamic No-Entry Zone (DNEZ) Definition .................. 4 3.1. Polygon Construction ................................ 4 3.2. DNEZ Attributes ..................................... 5 4. Dissemination Using IPv6 GeoNetworking .................. 5 5. Local Relevance and Polygon Inclusion Check ............. 6 6. Security Considerations .................................. 6 7. IANA Considerations ...................................... 7 8. Normative References ..................................... 7 Author's Address ............................................ 7 1. Introduction When an automated or highly automated vehicle stops unexpectedly due to a critical fault, surrounding vehicles must be informed promptly and accurately to prevent secondary collisions. Traditional roadside perception systems may fail in tunnels, heavy rain, fog, or due to occlusion. This document defines the Dynamic No-Entry Zone (DNEZ) as a temporary lane-level polygonal area generated by the stopped vehicle. The DNEZ is disseminated using IPv6 geographically-scoped messages defined in [RFC9366]. The mechanism provides a fully distributed, infrastructure-independent redundancy channel that complements existing Collective Perception and Decentralized Environmental Notification services. How a receiving vehicle or RSU reacts to a DNEZ is deliberately left out of scope. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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. 2. Terminology Dynamic No-Entry Zone (DNEZ) A temporary polygonal area indicating a region that surrounding vehicles may need to avoid. RSU Road Side Unit equipped with IPv6 and V2X communication capabilities. 3. Dynamic No-Entry Zone (DNEZ) Definition A DNEZ is encoded as a sequence of geographical points defining a closed polygon together with associated metadata. 3.1. Polygon Construction A stopped vehicle SHOULD construct the polygon as follows: o Obtain its current position and heading using GNSS and/or sensor fusion. o Retrieve lane-level geometry from a local high-definition map or recent MAP messages. o Define the polygon with a rear boundary typically 50-200 m behind the vehicle and a front boundary at or slightly in front of the vehicle. The polygon MUST be closed and use WGS84 coordinates. 3.2. DNEZ Attributes The following attributes SHOULD be included: o Generation timestamp o Expiration timestamp or duration (maximum recommended 10 min) o Cause code (e.g., vehicle breakdown, accident) o Confidence level o Originating vehicle temporary identifier 4. Dissemination Using IPv6 GeoNetworking The DNEZ SHALL be disseminated using the GeoBroadcast mechanism defined in [RFC9366] with a destination area that fully covers the polygon plus a safety margin (typically 300-1000 m). The originating vehicle SHALL broadcast immediately and MAY repeat with decreasing frequency until expiration. Any receiving RSU or vehicle inside or near the destination area MAY rebroadcast the message once. Duplicate detection based on originator identifier and sequence number SHALL be implemented. 5. Local Relevance and Polygon Inclusion Check Receivers SHOULD test whether their position lies inside the DNEZ polygon using the odd-even ray casting algorithm or equivalent. Usage of the result is implementation-specific and outside the scope of this document. 6. Security Considerations DNEZ messages carry safety-of-life implications and MUST be secured using existing V2X security mechanisms such as IEEE 1609.2 or ETSI ITS security. Receivers MUST verify signatures, certificate validity, and geographical/temporal relevance before processing. Misbehavior detection and position plausibility checks SHOULD be applied. 7. IANA Considerations This document has no IANA actions. 8. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9366] Jeong, J. and Y. Shen, "IPv6 GeoNetworking Address Configuration", RFC 9366, DOI 10.17487/RFC9366, October 2023, . Author's Address Jun Chen Independent Researcher Email: bot@botrun.cn