# drafts

name: draft-templin-6man-mla
rev: 32
title: IPv6 Addresses for Ad Hoc Networks
time: 2026-02-16T16:41:12Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-20T16:41:12Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.457866+00:00
source: ietf
source_id: 136129
source_url: https://datatracker.ietf.org/doc/draft-templin-6man-mla/
doc_status: active
abstract:
  Ad Hoc networks present an IPv6 addressing challenge due to the
     undetermined neighborhood properties of their interfaces.  IPv6 nodes
     must assign locally-unique and topology-independent IPv6 addresses
     when topology-oriented IPv6 address delegation services are either
     absent or only intermittently available.  This document introduces a
     new IPv6 address type (termed the "Multilink Local Address (MLA)")
     that nodes can autonomously assign to interfaces to support Ad Hoc
     network operations.

full_text:
  Network Working Group                                 F. L. Templin, Ed.
  Internet-Draft                              Boeing Research & Technology
  Updates: rfc4007, rfc5889, rfc6724 (if approved)        15 February 2026
  Intended status: Standards Track                                        
  Expires: 19 August 2026


                     IPv6 Addresses for Ad Hoc Networks
                         draft-templin-6man-mla-32

  Abstract

     Ad Hoc networks present an IPv6 addressing challenge due to the
     undetermined neighborhood properties of their interfaces.  IPv6 nodes
     must assign locally-unique and topology-independent IPv6 addresses
     when topology-oriented IPv6 address delegation services are either
     absent or only intermittently available.  This document introduces a
     new IPv6 address type (termed the "Multilink Local Address (MLA)")
     that nodes can autonomously assign to interfaces to support Ad Hoc
     network operations.

  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 19 August 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.  Code Components



  Templin                  Expires 19 August 2026                 [Page 1]


  Internet-Draft                  IPv6 MLAs                  February 2026


     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  IPv6 Ad Hoc Network Local Addressing  . . . . . . . . . . . .   4
     3.  Assigning an MLA to an Interface  . . . . . . . . . . . . . .   5
     4.  MLAs in the Scoped Addressing Architecture  . . . . . . . . .   5
     5.  MLAs for Ad Hoc Networks  . . . . . . . . . . . . . . . . . .   7
     6.  Address Selection . . . . . . . . . . . . . . . . . . . . . .   7
     7.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
     11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
       12.2.  Informative References . . . . . . . . . . . . . . . . .  10
     Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  11
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction

     When two or more IPv6 [RFC8200] nodes come together to form an Ad Hoc
     network, they must be able to assign unique addresses to their
     interfaces and exchange IPv6 packets with peers even if there is no
     Internetworking infrastructure present.  A classical example is a
     Mobile Ad-hoc Network (MANET) where wireless nodes within a common
     radio frequency locality discover multihop routes to support peer-to-
     peer communications.  However, arbitrary collections of fixed nodes
     interconnected by sparse collections of physical links also qualify.
     See [RFC5889] for further characteristics of Ad Hoc networks.

     Ad Hoc networks often include IPv6 nodes that configure interface
     attachments to links with undetermined connectivity properties such
     that multihop traversal may be necessary to span the network.  The
     transitive property of connectivity for conventional shared media
     links is therefore not assured, while nodes must still be able to
     configure IPv6 addresses that are unique within the local Ad Hoc
     network.  This is true even for nodes that configure multiple
     interface attachments to the same Ad Hoc network as a localized
     multihop/multilink forwarding domain.

     By its nature, the term "Ad Hoc network" implies logical groupings
     whereas the historical term "site" suggested physical boundaries such
     as a building or a campus.  In particular, Ad Hoc networks can self-



  Templin                  Expires 19 August 2026                 [Page 2]


  Internet-Draft                  IPv6 MLAs                  February 2026


     organize autonomously even if they overlap with other (logical)
     networks, split apart to form multiple smaller networks or join
     together to form larger networks.  Clustering can be applied as a
     means to divide larger MANETs into smaller logical groupings, noting
     that Ad Hoc network ecosystems are often in a constant state of flux
     and likely to change over time.  An address type that can be used by
     nodes that move freely between logical Ad Hoc network boundaries is
     therefore necessary.

     The term "Ad Hoc" used throughout this document extends to include
     isolated local IPv6 networks where peer to peer communications may
     require multihop and/or multilink traversal regardless of whether the
     network is particularly mobile or spontaneously organized.  For any
     such isolated network (i.e., one for which Internetworking proxy/
     servers are either absent or only intermittently available), a
     topology-independent IPv6 addressing scheme that allows peer nodes to
     communicate internally is necessary.  Therefore, all nodes that
     connect to such isolated IPv6 networks should be prepared to operate
     according to this multilink Ad Hoc addressing model when necessary.
     Each node then coordinates multihop forwarding services at an
     IPv6-based architectural sublayer termed the "adaptation layer" below
     the Internetworking layer but above the true link layer.

     Section 6 of the "IP Addressing Model in Ad Hoc Networks" [RFC5889]
     states that: "an IP address configured on this (Ad Hoc) interface
     should be unique, at least within the routing domain" and: "no on-
     link subnet prefix is configured on this (Ad Hoc) interface".  The
     section then continues to explain why IPv6 Link-Local Addresses
     (LLAs) are of limited utility on links with undetermined
     connectivity, to the point that they cannot be used exclusively
     within Ad Hoc network domains.  (Note that [RFC5498] provides IANA
     allocations for MANET protocols as a complementary publication.)

     [RFC5889] suggests Global Unicast [RFC4291] (aka "GUA") and Unique-
     Local [RFC4193] (aka "ULA") addresses as Ad Hoc network addressing
     candidates.  However, GUAs and ULAs are topology-oriented address
     types that must be obtained through either administrative actions or
     an address autoconfiguration service based on IPv6 proxy/servers that
     connect Ad Hoc networks to larger Internetworks.  (In particular
     topology-oriented address types are typically obtained through DHCPv6
     messages and/or Router Advertisement Prefix Information Options with
     prefix length shorter than 128.)  Since such Internetworking services
     may not always be available, however, this document asserts that a
     topology-independent and unique Ad Hoc network local IPv6 address
     type is needed.  The address type may include multiple sub-types,
     some of which may be coordinated with address registration services
     and others that may be partially or fully self-generated.




  Templin                  Expires 19 August 2026                 [Page 3]


  Internet-Draft                  IPv6 MLAs                  February 2026


     The key feature of these Ad Hoc network adaptation layer IPv6
     addresses is that they must have excellent statistical uniqueness
     properties such that there is little/no chance of conflicting with an
     address assigned by another node.  The addresses need not include
     topology-oriented prefixes, since the (newly-formed) Ad Hoc networks
     may not (yet) connect to established Internetworking topologies.

     Ad Hoc network nodes must be able to use adaptation layer IPv6
     addresses for continuous local communications and/or to coordinate
     topology-oriented addresses for assignment on other interfaces.  A
     new "Multilink Local" scope for the IPv6 scoped addressing
     architecture [RFC4007] with scope greater than LLA but lesser than
     ULA/GUA is therefore needed.  This document therefore defines a new
     unique local unicast address variant known as the "Multilink Local
     Address (MLA)".

     MLAs that require global uniqueness assurance shall be based on the
     construct specified in [RFC9374].  The MLA is based on a
     cryptographic hash of a node's public key regarded as its full
     identify.  The MLA is regarded as a unique identity tag that, when
     assigned to an interface, becomes a valid IPv6 address with
     multilink-local scope.  The MLA must be assured globally unique and
     routable at least within a limited domain to support MANET
     Internetworking [I-D.templin-manet-inet].

  2.  IPv6 Ad Hoc Network Local Addressing

     The IPv6 addressing architecture specified in [RFC4007], [RFC4193]
     and [RFC4291] defines the supported IPv6 unicast/multicast/anycast
     address types with various scopes.  The IPv6 address assignment
     policy is further clarified in [RFC9812].

     ULAs and GUAs are typically obtained through Stateless Address
     AutoConfiguration (SLAAC) [RFC4862] and/or the Dynamic Host
     Configuration Protocol for IPv6 (DHCPv6) [RFC8415], but these
     services require the presence of IPv6 Internetworking infrastructure
     which may not be continuously or even intermittently available in
     spontaneously-formed Ad Hoc networks.

     Interface attachments to Ad Hoc networks have the interesting
     property that a multihop router R will often need to forward packets
     between nodes A and B even though R uses the same interface in the
     inbound and outbound directions.  Since nodes A and B may not be able
     to communicate directly even though both can communicate directly
     with R, the transitive property for link connectivity is not assured
     and the IPv6 Neighbor Discovery (ND) Redirect service cannot
     guarantee reliable direct paths.  Conversely, R may need to forward
     packets between nodes A and B via different interfaces within an Ad



  Templin                  Expires 19 August 2026                 [Page 4]


  Internet-Draft                  IPv6 MLAs                  February 2026


     Hoc network that includes multiple distinct links/regions.  Due to
     these indeterminant multilink properties, exclusive use of IPv6 LLAs
     is also out of scope.

     This document therefore introduces a new IPv6 MLA address type based
     on a well-formed IPv6 prefix "TBD::/N" (see: IANA Considerations).
     After a node creates an MLA, it can use the address within the
     context of spontaneously-organized Ad Hoc networks in which two or
     more nodes come together in the absence of stable supporting
     infrastructure and can still exchange IPv6 packets with little or no
     chance of address collisions.  The node can limit MLA usage to
     bootstrapping the assignment of topology-oriented IPv6 addresses
     through other means mentioned earlier.  The node can instead extend
     its MLA usage to longer term patterns such as sustained
     communications with single-hop neighbors on a local link or even
     between multihop peers in an Ad Hoc network.

  3.  Assigning an MLA to an Interface

     IPv6 MLAs are topology-independent and can therefore be assigned to
     interfaces with a /128 prefix length (i.e., as a singleton address).
     The node can then begin to use an MLA as the Source/Destination
     Address of IPv6 packets that are forwarded over an interface
     attachment to an Ad Hoc network multihop forwarding region.

     A node can specifically assign an MLA to MANET interfaces to support
     the operation of Ad Hoc network routing protocols and also to an
     Overlay Multilink Network (OMNI) Interface [I-D.templin-6man-omni3]
     to support extended MANET Internetworking with remote peers over an
     OMNI virtual link.

     MLAs may then serve as a basis for multihop forwarding and/or for
     local neighborhood discovery over other IPv6 interface types.  Due to
     their uniqueness properties, the node can assign MLAs as optimistic
     addresses per [RFC4429], however it should take actions to deconflict
     if it detects in-service duplication.

  4.  MLAs in the Scoped Addressing Architecture

     With reference to a debate that concluded in the earliest years of
     the third millennium, a case could be made for reclaiming the
     deprecated site-local address prefix "fec0::/10" for use as a top-
     level MLA prefix.  However, some implementations still honor the
     deprecation and continue to regard the prefix as a defunct historical
     artifact.






  Templin                  Expires 19 August 2026                 [Page 5]


  Internet-Draft                  IPv6 MLAs                  February 2026


     [RFC3879] documents the deprecation rationale including the assertion
     that "Site is an Ill-Defined Concept".  However, the concept of an Ad
     Hoc network is a coherent logical one based on time-varying
     (multilink) connectivity and not necessarily one constrained by
     physical boundaries.  Especially in Ad Hoc networks that employ a
     proactive local routing protocol the list of available adaptation
     layer addresses in each network is continuously updated for temporal
     consistency.

     For example, an IPv6 node may connect to multiple distinct Ad Hoc
     networks with a first set of interfaces connected to network "A", a
     second set of interfaces connected to network "B", etc.  According to
     the scoped IPv6 addressing architecture [RFC4007], the node would
     assign a separate MLA to virtual interfaces associated with each Ad
     Hoc network interface set A, B, etc. and maintain separate Ad Hoc
     network multihop routing protocol instances for each set.  MLAs A, B,
     etc. then provide a basis for unique router IDs for the separate
     routing protocol instances, but the IPv6 node may elect to
     redistribute discovered adaptation layer routes between the
     instances.  The uniqueness properties of MLAs must therefore
     transcend logical Ad Hoc network boundaries to the extent that global
     uniqueness assurances are necessary when the scope for MANET dynamics
     extends to the entire Internet.

     A means for entering Ad Hoc network local IPv6 Zone Identifiers in
     user interfaces is necessary according to [RFC9844].  Examples of an
     Ad Hoc network local unicast address qualified by a zone identifier
     are as follows:

        TBD::884e:9d2a:73fc:2d94%netA

        TBD::c63d:9724:fca:1237%netB

     This document updates the IPv6 scoped addressing architecture
     [RFC4007] by introducing a "Multilink-Local" unicast addressing
     scope.  In particular, this document adds a third unicast address
     scope to Section 4 of [RFC4007] as follows:

     *  Multilink-Local scope, for uniquely identifying a node's attached
        Ad Hoc networks.

     The size relationship among scopes is further updated as:

     *  For unicast scopes, link-local is a smaller scope than Multilink-
        Local, which is a smaller scope than global.

     In [RFC4007], Section 5 under: "Zones of the different scopes are
     instantiated as follows", add the new bullet:



  Templin                  Expires 19 August 2026                 [Page 6]


  Internet-Draft                  IPv6 MLAs                  February 2026


     *  Each Ad Hoc network and the interfaces attached to that Ad Hoc
        network comprise a single zone of Multilink-Local scope (for
        unicast).

  5.  MLAs for Ad Hoc Networks

     This document updates [RFC5889] to add a new address type "Multilink-
     Local" to the list of IPv6 address types found in Section 1 as:

     *  For IPv6, these addresses may be global [RFC3587], Unique-Local
        [RFC4193], Multilink-Local [RFCXXXX] or Link-Local [RFC4291].

  6.  Address Selection

     "Default Address Selection for Internet Protocol Version 6 (IPv6)"
     [RFC6724] provides a policy table that specifies precedence values
     and preferred Source Address prefixes for specific Destination
     Addresses.  "Preference for IPv6 ULAs over IPv4 addresses in RFC6724"
     [I-D.ietf-6man-rfc6724-update] updates the policy table entries for
     ULAs, IPv4 Addresses and the 6to4 prefix (2002::/16).

     This document proposes a further update to the policy table for IPv6
     MLAs.  The proposed update appears in the table below:

   draft-ietf-6man-rfc6724-update                           Updated
  Prefix        Precedence Label        Prefix        Precedence Label
  ::1/128               50     0        ::1/128               50     0
  ::/0                  40     1        ::/0                  40     1
  ::ffff:0:0/96         20     4        ::ffff:0:0/96         20     4
  2002::/16              5     2        2002::/16              5     2
  2001::/32              5     5        2001::/32              5     5
  fc00::/7              30    13        fc00::/7              30    13
  ::/96                  1     3        ::/96                  1     3
  fec0::/10              1    11        fec0::/10              1    11
  3ffe::/16              1    12        3ffe::/16              1    12
                                        TBD::/N                4    14 (*)
  (*) value(s) changed in update

       Figure 1: Policy Table Update for Multilink Local Addresses

     With the proposed updates, this new MLA address type appears as a
     lesser precedence than IPv6 GUAs, IPv6 ULAs and IPv4 addresses but as
     a greater precedence than deprecated IPv6 prefixes.








  Templin                  Expires 19 August 2026                 [Page 7]


  Internet-Draft                  IPv6 MLAs                  February 2026


  7.  Requirements

     IPv6 nodes assign unique MLAs to an IPv6 virtual interface (e.g., an
     OMNI interface) configured over underlying interface attachments to
     Ad Hoc networks.  If the node becomes aware that a tentative self-
     generated MLA is already in use by another node, it instead generates
     and assigns a new MLA.  If the node becomes aware that an MLA for
     which it holds a certificate through an official registration service
     is already in use by another node, it should log and report the
     incident to the registration service authority.

     IPv6 routers MAY forward IPv6 packets with adaptation layer MLA
     Source or Destination Addresses over multiple hops within the same Ad
     Hoc network as an adaptation layer function.

     IPv6 routers MUST NOT forward packets with adaptation layer MLA
     Source or Destination Addresses to a link outside the packet's Ad Hoc
     network of origin, although MLAs MAY occur as network layer IPv6
     Source or Destination Addresses in packets forwarded between disjoint
     MANETs via the virtual overlay.

  8.  Implementation Status

     In progress.

  9.  IANA Considerations

     This document requests that IANA designate 2001:30::/28 as the MLA
     IPv6 prefix for TBD::/N the same as defined for [RFC9374] in the
     'iana-ipv6-special-registry'.  Future documents may request
     additional prefixes.

  10.  Security Considerations

     IPv6 MLAs include either very large pseudo-random bit strings with
     ample statistical unique properties or bit strings that are
     algorithmically generated and coordinated with a registration service
     for administratively-ensured uniqueness.  In the latter case, the
     only apparent opportunity for duplication would be through either
     intentional or unintentional misconfiguration.

     Certain MLA types may have cryptographically generated portions tied
     to a certificate with the node's public key while other portions of
     the address identify a registration service where address proof-of-
     ownership can be confirmed.  This stands in contrast to autonomously
     assigned and fully self-generated MLAs while relying entirely on
     statistical uniqueness properties.




  Templin                  Expires 19 August 2026                 [Page 8]


  Internet-Draft                  IPv6 MLAs                  February 2026


     An IPv6 node that configures an MLA and assigns it to a virtual
     interface with an optimistic expectation of uniqueness should
     therefore be prepared to deconflict legitimate duplications.

  11.  Acknowledgements

     This work was inspired by continued investigations into 5G MANET
     operations in cooperation with the Virginia Tech National Security
     Institute (VTNSI).

     Emerging discussions both in-person and on the IPv6 maintenance
     (6man) and MANET mailing lists continue to shape updated versions of
     this document.  The author acknowledges all whose useful comments
     have helped further the understanding of this proposal.

     Honoring life, liberty and the pursuit of happiness.

  12.  References

  12.1.  Normative References

     [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
                B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
                DOI 10.17487/RFC4007, March 2005,
                <https://www.rfc-editor.org/info/rfc4007>.

     [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
                Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
                <https://www.rfc-editor.org/info/rfc4193>.

     [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 4291, DOI 10.17487/RFC4291, February
                2006, <https://www.rfc-editor.org/info/rfc4291>.

     [RFC5889]  Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing
                Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
                September 2010, <https://www.rfc-editor.org/info/rfc5889>.

     [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
                "Default Address Selection for Internet Protocol Version 6
                (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
                <https://www.rfc-editor.org/info/rfc6724>.

     [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", STD 86, RFC 8200,
                DOI 10.17487/RFC8200, July 2017,
                <https://www.rfc-editor.org/info/rfc8200>.




  Templin                  Expires 19 August 2026                 [Page 9]


  Internet-Draft                  IPv6 MLAs                  February 2026


     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/info/rfc9374>.

  12.2.  Informative References

     [I-D.ietf-6man-rfc6724-update]
                Buraglio, N., Chown, T., and J. Duncan, "Prioritizing
                known-local IPv6 ULAs through address selection policy",
                Work in Progress, Internet-Draft, draft-ietf-6man-rfc6724-
                update-25, 11 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
                rfc6724-update-25>.

     [I-D.templin-6man-aero3]
                Templin, F., "Automatic Extended Route Optimization
                (AERO)", Work in Progress, Internet-Draft, draft-templin-
                6man-aero3-52, 23 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-templin-6man-
                aero3-52>.

     [I-D.templin-6man-omni3]
                Templin, F., "Transmission of IP Packets over Overlay
                Multilink Network (OMNI) Interfaces", Work in Progress,
                Internet-Draft, draft-templin-6man-omni3-73, 6 February
                2026, <https://datatracker.ietf.org/doc/html/draft-
                templin-6man-omni3-73>.

     [I-D.templin-manet-inet]
                Templin, F. and D. J. Jakubisin, "MANET Internetworking:
                Problem Statement and Gap Analysis", Work in Progress,
                Internet-Draft, draft-templin-manet-inet-02, 12 January
                2026, <https://datatracker.ietf.org/doc/html/draft-
                templin-manet-inet-02>.

     [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
                Addresses", RFC 3879, DOI 10.17487/RFC3879, September
                2004, <https://www.rfc-editor.org/info/rfc3879>.

     [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
                for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
                <https://www.rfc-editor.org/info/rfc4429>.

     [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
                Address Autoconfiguration", RFC 4862,
                DOI 10.17487/RFC4862, September 2007,
                <https://www.rfc-editor.org/info/rfc4862>.



  Templin                  Expires 19 August 2026                [Page 10]


  Internet-Draft                  IPv6 MLAs                  February 2026


     [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
                (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March
                2009, <https://www.rfc-editor.org/info/rfc5498>.

     [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
                Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
                <https://www.rfc-editor.org/info/rfc6296>.

     [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
                Richardson, M., Jiang, S., Lemon, T., and T. Winters,
                "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
                RFC 8415, DOI 10.17487/RFC8415, November 2018,
                <https://www.rfc-editor.org/info/rfc8415>.

     [RFC9812]  Carpenter, B., Krishnan, S., and D. Farmer, "Clarification
                of IPv6 Address Allocation Policy", BCP 242, RFC 9812,
                DOI 10.17487/RFC9812, October 2025,
                <https://www.rfc-editor.org/info/rfc9812>.

     [RFC9844]  Carpenter, B. and R. Hinden, "Entering IPv6 Zone
                Identifiers in User Interfaces", RFC 9844,
                DOI 10.17487/RFC9844, August 2025,
                <https://www.rfc-editor.org/info/rfc9844>.

  Appendix A.  Change Log

     << RFC Editor - remove prior to publication >>

     Differences from earlier versions:

     Draft -31 to -32
        *  Further clarifications on MLAs as identity tags.

     Draft -30 to -31
        *  Introduced MANET Internetworking.

     Draft -29 to -30
        *  Promote RFC9374 as the normative specification for
           administratively coordinated MLAs.

     Draft -28 to -29
        *  Updated abstract, introduction and references.

     Draft -27 to -28
        *  Removed section on "Obtaining and Assigning IPv6 ULAs/GUAs" as
           out of scope for this document.

        *  Version update.



  Templin                  Expires 19 August 2026                [Page 11]


  Internet-Draft                  IPv6 MLAs                  February 2026


     Draft -26 to -27
        *  Significant updates to requirements.

        *  Relaxed "1x1" assignment of MLAs to a single MANET.

        *  Included references for candidate MLA types.

     Draft -24 to -26
        *  Stress address deconfliction instead of deprecation when
           address duplication is detected.

        *  Security considerations for MLA types that support remote
           attestation.

        *  Discussion of site as an ill-defined concept in contrast to
           "Multilink Local Scope".

     Draft -23 to -24
        *  Change reference to RFC6296.

        *  Added more explanation about Ad Hoc Networks.

        *  MLAs now assigned only to a virtual interface associated with
           the Ad-Hoc network and not the physical interfaces themselves.

        *  Added specifics of how this document updates other RFCs.

  Author's Address

     Fred L. Templin (editor)
     Boeing Research & Technology
     P.O. Box 3707
     Seattle, WA 98124
     United States of America
     Email: fltemplin@acm.org
















  Templin                  Expires 19 August 2026                [Page 12]


name: draft-bernardos-cats-isac-uc
rev: 01
title: Integrated Sensing and Communications (ISAC) for CATS
time: 2026-01-05T07:09:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-04T23:17:49Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.500444+00:00
source: ietf
source_id: 143317
source_url: https://datatracker.ietf.org/doc/draft-bernardos-cats-isac-uc/
doc_status: active
abstract:
  Integrated Sensing and Communications (ISAC) represents a paradigm
     shift in wireless networks, where sensing and communication functions
     are jointly designed and optimized.  By leveraging the same spectral
     and hardware resources, ISAC enables advanced capabilities such as
     environment perception, object tracking, and situational awareness,
     while maintaining efficient and reliable data transmission.  This
     integration holds great potential for applications in areas such as
     autonomous systems, smart cities, and industrial automation, where
     precise sensing and low-latency communication are critical.  This
     document presents the ISAC as a typical CATS scenario to facilitate
     discussions on the potential challenges and requirements.

full_text:
  CATS WG                                                    CJ. Bernardos
  Internet-Draft                                                      UC3M
  Intended status: Standards Track                               A. Mourad
  Expires: 4 January 2026                                     InterDigital
                                                                  T. Jiang
                                                                      CMCC
                                                               3 July 2025


           Integrated Sensing and Communications (ISAC) for CATS
                      draft-bernardos-cats-isac-uc-01

  Abstract

     Integrated Sensing and Communications (ISAC) represents a paradigm
     shift in wireless networks, where sensing and communication functions
     are jointly designed and optimized.  By leveraging the same spectral
     and hardware resources, ISAC enables advanced capabilities such as
     environment perception, object tracking, and situational awareness,
     while maintaining efficient and reliable data transmission.  This
     integration holds great potential for applications in areas such as
     autonomous systems, smart cities, and industrial automation, where
     precise sensing and low-latency communication are critical.  This
     document presents the ISAC as a typical CATS scenario to facilitate
     discussions on the potential challenges and requirements.

  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 4 January 2026.

  Copyright Notice

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




  Bernardos, et al.        Expires 4 January 2026                 [Page 1]


  Internet-Draft           ISAC use case for CATS                July 2025


     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 Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Computing Aware distributed sensing for Integrated Sensing and
             Communications  . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  CATS of ETSI ISAC . . . . . . . . . . . . . . . . . . . .   3
       2.2.  CATS of 3GPP ISAC . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Relation to CATS  . . . . . . . . . . . . . . . . . . . .   7
       2.4.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   7
       2.5.  Additional remarks  . . . . . . . . . . . . . . . . . . .   8
     3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
     6.  Informative References  . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Integrated Sensing and Communications (ISAC) is emerging as a key
     enabler for next-generation wireless networks, integrating sensing
     and communication functionalities within a unified system.  By
     leveraging the same spectral, hardware, and computational resources,
     ISAC enhances network efficiency while enabling new capabilities such
     as high-resolution environment perception, object detection, and
     situational awareness.  This paradigm shift is particularly relevant
     for applications requiring both reliable connectivity and precise
     sensing, such as autonomous vehicles, industrial automation, and
     smart city deployments.  Given its strategic importance, ISAC has
     gained significant traction in standardization efforts.













  Bernardos, et al.        Expires 4 January 2026                 [Page 2]


  Internet-Draft           ISAC use case for CATS                July 2025


     While the ETSI Industry Specification Group (ISG) on ISAC has been
     established to explore technical requirements and use cases, the 3GPP
     organization has approved the 5G study work in its release 20 (rel-
     20) and initiated the investigation on ISAC-related features
     [TR.23.700-14].  Moreover, 3GPP has agreed to continue the sensing
     related research on future 6G systems.  Furthermore, research
     initiatives within the IEEE and IETF are investigating how ISAC can
     be integrated into network architectures, spectrum management, and
     protocol design, making it a critical area of development in the
     evolution of wireless networks.

     This document presents the ISAC as a typical CATS scenario, being
     supplementary to the CATS use cases as in
     [I-D.ietf-cats-usecases-requirements], to facilitate discussions on
     the potential challenges, and requirements.  Further, the document
     references the new draft on CATS reference model
     [IETF-CATS-RefModel-ACN] to briefly discuss how the ISAC case may
     leverage the model.

  2.  Computing Aware distributed sensing for Integrated Sensing and
      Communications

     Integrated Sensing and Communications (ISAC) enables wireless
     networks to perform simultaneous data transmission and environmental
     sensing.  In a distributed sensing scenario, multiple hardware
     network entities, such as base stations, access points, or edge
     devices (e.g., wireless terminal equipment), and intelligent agents
     deployed as software instances on the entities (e.g., AI-agents) --
     collect raw sensing data from the environment.  These data can
     include radio frequency (RF) reflections, Doppler shifts, channel
     state information (CSI), or other physical-layer features that
     provide insights into object movement, material composition, or
     environmental conditions.  To extract meaningful information, the
     collected raw data must be aggregated and processed by a designated
     computing node with sufficient computational resources.  This
     requires efficient coordination between sensing nodes and computing
     resources to ensure timely and accurate analysis, making it a
     relevant scenario for Computing-Aware Traffic Steering (CATS) in
     IETF.

  2.1.  CATS of ETSI ISAC

     This use case aligns with ongoing efforts in standardization bodies
     such as the ETSI ISAC Industry Specification Group (ISG),
     particularly Work Item #5 (WI#5), titled 'Integration of Computing
     with ISAC'.  WI#5 focuses on exploring different forms of computing
     integration within ISAC systems, including sensing combined with
     computing, communications combined with computing, and the holistic



  Bernardos, et al.        Expires 4 January 2026                 [Page 3]


  Internet-Draft           ISAC use case for CATS                July 2025


     integration of ISAC with computing.  The considerations outlined in
     this document complement ETSI's work by examining how computing-aware
     networking solutions, as developed within CATS, can optimize the
     processing and routing of ISAC sensing data.

     As an example, we can consider a network domain with multiple sites
     capable of hosting the ISAC computing "service", each with
     potentially different connectivity and computing characteristics.
     Figure 1 shows an exemplary scenario.  Considering the connectivity
     and computing latencies (just as an example of metrics), the best
     service site is #n-1 in the example used in the Figure.  Note that in
     the figure we still use the old terminology in which by ICR we mean
     Ingress CATS-Forwarder [I-D.ietf-cats-framework], and by ECR we mean
     Egress CATS-Forwarder.





































  Bernardos, et al.        Expires 4 January 2026                 [Page 4]


  Internet-Draft           ISAC use case for CATS                July 2025


                                  ________________
                                 (     ---------- )
                                (      |        |  )
                              (     ---------- |   )
        ________________     (     |        | |    )     _______________
       (     ---------- )    (   ---------- | |    )    (    ---------- )
      (      |        |  )   (   |service | |-     )   (     |        |  )
     (     ---------- |   )  (   |contact | |      )  (    ---------- |  )
     (     |        | |   )  (   |instance|--      )  (    |        | |  )
     (   ---------- | |   )   (  ----------       )   (  ---------- | |  )
     (   |service | |-    )    ( Serv. site #N-1 )    (  |service | |-   )
     (   |contact | |     )     -------+----------     (  |contact | |   )
     (   |instance|--    )   Computing  \              (  |instance|--   )
      (  ----------     )    delay:4ms   \              ( ----------     )
       ( Serv. site #1 )           --------+--           ( Serv. site #N )
        -------+--------       ----| ECR#N-1 |----        ---------+-----
                \  Computing --     -----------    --  Computing  /
                 \ delay:10ms      Networking          delay:5ms /
               ---+-----           delay:7ms              ------+--
             ( | ECR#1 |            //                    | ECR#N | )
            (  ---------           //                     ---------  )
           ( Networking           //                       Networking )
          (  delay:5ms           //                         delay:15ms )
         (                      //                                      )
         (                     //                                       )
          (                   //                                       )
           (                 //                                       )
            (               //                                       )
             (       ---------                     ---------        )
              -------| ICR#1 |---------------------| ICR#2 |--------
                     ---------           __         ---------
                     (·)   (·)        / (  )           (·)
                    (·)   -------   -  (    )         (·)
                   (·)    | UE2 | /     (__) \      (·)
                  (·)     -------    /         -   -------
                 (·)               /  (sensing  \  | UE3 |
               -------   ---------                 -------
               | UE1 | /
               -------

                          Figure 1: Exemplary scenario










  Bernardos, et al.        Expires 4 January 2026                 [Page 5]


  Internet-Draft           ISAC use case for CATS                July 2025


  2.2.  CATS of 3GPP ISAC

     3GPP has specified in the stage-1 document [TR.22.870] the
     requirements & objectives of ISAC service.  Fundamentally, the ISAC
     service includes offering wide area multi-dimensional sensing that
     provides spatial information about non-connected objects as well as
     connected devices and their movements and surroundings.
     Successively, the 3GPP SA2 WG has approved a study item (SID) in its
     rel-20 and initiated the investigation on ISAC-related features
     [TR.23.700-14].  Moreover, 3GPP has agreed to continue the sensing
     related research on the on-going 6G studies.

     The Figure 2 describes a possible sensing architecture that conforms
     to the architectural assumptions as in [TR.23.700-14].  The figure
     shows that there could be multiple authorized sensing entities, e.g.,
     (R)ANs, TEs (with sensors).  Also, a new sensing function, i.e.,
     SeNF, is promoted.  Note the name of the sensing function is still up
     for discussion.

            SeNF: Sensing Network Function
            Sensing Entities: TE (Terminal Equip), (g)RAN
                   ...........................................
                   :                                +-----+  :   +-------+
                   :                                | NEF |------| AF/AS |
                   :      +-----+                   +-----+  :   +-------+
                   :      | AMF |                     |      :
                   :      +-----+                     |      :
                   :         |       +------+      +-----+   :
                   :   ......|.......| SeNF |------| PCF |   :
                   :   :     |       +------+      +-----+   :
                   :   :     |      /                        :
         +------+  :   :     |     /                         :
         | TE#1 |......:     |    /                          :
         +------+  :   :     |   /                           :
         +------+......:  +------+        +-----+            :  +--------+
         | TE#2 |--:------|(g)RAN|--------| UPF |------------:--|  Data  |
         +------+  :      +------+        +-----+            :  | Network|
                   :                                         :  +--------+
                   :.........................................:


                    Figure 2: 3GPP ISAC exemplary scenario

     There might be multiple SeNFs in a wireless network, with each SeNF
     capable of handling both the CP and UP of the sensing service.  A
     SeNF can process received sensing data, aggregate sensing reports,
     run detection algorithms, and filter noise - to produce the sensing
     result that meets the service request.  A SeNF may also expose the



  Bernardos, et al.        Expires 4 January 2026                 [Page 6]


  Internet-Draft           ISAC use case for CATS                July 2025


     sensing results to external App servers (namely AS'es).  Given the
     complex yet computationally-heavy tasks as conducted by the SeNF, the
     selection of an optimal SeNF (among all SeNF candidates) embodies the
     principles of CATS.

     Sensing entities on (authorized) UEs may instantiate as software AI-
     agents with sensing functionality.  If there is a large amount of
     collected sensing measurement data, then there might be a need to
     expose (i.e., transmit) the data to (external) service instances
     (e.g., in local premise) for optimized processing (if the local
     compute power at an agent is insufficient or is overloaded).  After
     that can the processed sensing results be sent to the original
     sensing requestor for further processing.  This kind of task
     redirection for better processing efficiency conforms to what the
     CATS strives for.

  2.3.  Relation to CATS

     In the distributed sensing scenario, the sensed data collected by
     multiple nodes must be efficiently routed to a computing node capable
     of processing it.  The choice of the computing node depends on
     several factors, including computational load, network congestion,
     and latency constraints.  CATS mechanisms can optimize the selection
     of the processing node by dynamically steering the traffic based on
     computing resource availability and network conditions.
     Additionally, as sensing data is often time-sensitive, CATS can
     ensure low-latency paths while balancing computational demands across
     different processing entities.  This capability is essential for
     real-time applications such as cooperative perception for autonomous
     systems, industrial monitoring, and smart city infrastructure.

     Further, the draft [IETF-CATS-RefModel-ACN] has proposed a CATS
     reference model that operates on general reference points for the
     signaling exchanges of various types of metrics, i.e., network,
     compute and the new AI-agent metrics as defined in the draft.  The
     ISAC scenario for CATS may leverage the model for better operations.
     For example, the IETF Draft of CATS reference model for ACN defines
     the reference points or RPs, e.g., the RPs between C-PS --- C-NMA,
     C-PS --- C-SMA, and AIA (AI-agent) --- C-PS, etc.  The ISAC scenario
     may leverage the AI-agent logics and extend the RPs to sensing: AIA
     (sensing) --- C-PS.  In some scenario in the context of 3GPP, here
     the C-PS can even be a 3rd-party entity like AF/AS.

  2.4.  Requirements

     Several challenges need to be addressed for efficient distributed
     sensing in ISAC-enabled networks:




  Bernardos, et al.        Expires 4 January 2026                 [Page 7]


  Internet-Draft           ISAC use case for CATS                July 2025


     *  Traffic Steering and Resource Allocation: Ensuring that sensing
        data is directed to the most suitable computing node while
        considering both network conditions and processing availability.

     *  Latency Sensitivity: Many ISAC applications require near-real-time
        processing, necessitating low-latency and high-reliability data
        forwarding strategies.

     *  Data Synchronization: Sensing nodes may have different
        perspectives on the environment, requiring synchronization and
        fusion of data streams before processing.

     *  Scalability: As the number of participating sensing nodes
        increases, mechanisms must efficiently distribute and balance the
        computational workload.

     *  Security and Privacy: Sensed data may contain sensitive
        information, requiring mechanisms for secure transmission and
        processing.

     *  Holistic Reference Model: Potentially a general CATS reference
        model with reference points for the signaling exchanges of various
        types of metrics among CATS entities and sensing entities.

  2.5.  Additional remarks

     The integration of ISAC-based distributed sensing into CATS
     frameworks may require enhancements in computing-aware routing
     protocols, traffic steering algorithms, signaling mechanisms, and
     potentially the integration of the CATS reference model.
     Standardization efforts could focus on defining metrics for
     computing-aware path selection that is based not only on the existing
     CATS metrics but also with any future extensions (e.g., 'AI-agent
     metrics' in [IETF-CATS-RefModel-ACN]), developing mechanisms for
     real-time coordination between sensing and computing nodes, and
     ensuring interoperability with existing network architectures.
     Furthermore, coordination with ETSI & 3GPP may help align the
     development of computing-aware ISAC networking solutions with ongoing
     standardization efforts in computing integration, ensuring cross-
     industry compatibility and deployment feasibility.

  3.  IANA Considerations

     N/A.







  Bernardos, et al.        Expires 4 January 2026                 [Page 8]


  Internet-Draft           ISAC use case for CATS                July 2025


  4.  Security Considerations

     TBD.

  5.  Acknowledgments

     The work of Carlos J.  Bernardos in this document has been partially
     supported by the Horizon Europe MultiX (Grant Agreement No.
     101192521) and Hexa-X-II (Grant Agreement No. 101095759) projects.

  6.  Informative References

     [I-D.ietf-cats-framework]
                Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
                Drake, "A Framework for Computing-Aware Traffic Steering
                (CATS)", Work in Progress, Internet-Draft, draft-ietf-
                cats-framework-10, 24 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cats-
                framework-10>.

     [I-D.ietf-cats-usecases-requirements]
                Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
                "Computing-Aware Traffic Steering (CATS) Problem
                Statement, Use Cases, and Requirements", Work in Progress,
                Internet-Draft, draft-ietf-cats-usecases-requirements-07,
                10 June 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-cats-usecases-requirements-07>.

     [IETF-CATS-RefModel-ACN]
                Jiang, T., et al., "CATS Reference Model for AI-Agent
                Communication Network",  
                https://datatracker.ietf.org/doc/draft-jiang-cats-
                reference-acn, June 2025.

     [TR.22.870]
                "3GPP TR 22.870 v0.3.0: Study on 6G Use Cases and Service
                Requirements; Stage 1, Rel-20",  3GPP TR 22.870, May 2025.

     [TR.23.700-14]
                "3GPP TR 23.700-14 v0.2.0: Study on Stage 2 for Integrated
                Sensing and Communication",  3GPP TR 23.700-14, June 2025.

  Authors' Addresses








  Bernardos, et al.        Expires 4 January 2026                 [Page 9]


  Internet-Draft           ISAC use case for CATS                July 2025


     Carlos J. Bernardos
     Universidad Carlos III de Madrid
     Av. Universidad, 30
     28911 Leganes, Madrid
     Spain
     Phone: +34 91624 6236
     Email: cjbc@it.uc3m.es
     URI:   http://www.it.uc3m.es/cjbc/


     Alain Mourad
     InterDigital Europe
     Email: Alain.Mourad@InterDigital.com
     URI:   http://www.InterDigital.com/


     Tianji Jiang
     China Mobile
     Email: tianjijiang@yahoo.com
































  Bernardos, et al.        Expires 4 January 2026                [Page 10]


name: draft-ahn-opsawg-5g-security-i2nsf-framework
rev: 00
title: An Integrated Security Service System for 5G Networks using an I2NSF Framework
time: 2026-01-09T07:09:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T08:20:44Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.505004+00:00
source: ietf
source_id: 146863
source_url: https://datatracker.ietf.org/doc/draft-ahn-opsawg-5g-security-i2nsf-framework/
doc_status: active
abstract:
  This document presents an integrated framework for automated security
     management in 5G edge networks using the Interface to Network
     Security Functions (I2NSF) architecture.  The proposed system
     leverages Intent-Based Networking (IBN) to allow users or
     administrators to declare high-level security intents, which are then
     translated into enforceable network and application policies.
     Network-level policies are delivered to 5G core components via the
     Network Exposure Function (NEF), while application-level policies are
     enforced directly at user equipment through distributed IBN
     Controllers.  This architecture supports adaptive, context-aware, and
     distributed policy enforcement, enabling real-time response to
     dynamic edge conditions and user mobility scenarios such as
     handovers.  By integrating closed-loop monitoring and analytics, the
     system ensures consistent and autonomous security across
     heterogeneous 5G environments.

full_text:
  Operations and Management Area Working Group                 Y. Ahn, Ed.
  Internet-Draft                                             J. Jeong, Ed.
  Intended status: Informational                   Sungkyunkwan University
  Expires: 8 January 2026                                           Y. Kim
                                                       Soongsil University
                                                               7 July 2025


    An Integrated Security Service System for 5G Networks using an I2NSF
                                 Framework
              draft-ahn-opsawg-5g-security-i2nsf-framework-00

  Abstract

     This document presents an integrated framework for automated security
     management in 5G edge networks using the Interface to Network
     Security Functions (I2NSF) architecture.  The proposed system
     leverages Intent-Based Networking (IBN) to allow users or
     administrators to declare high-level security intents, which are then
     translated into enforceable network and application policies.
     Network-level policies are delivered to 5G core components via the
     Network Exposure Function (NEF), while application-level policies are
     enforced directly at user equipment through distributed IBN
     Controllers.  This architecture supports adaptive, context-aware, and
     distributed policy enforcement, enabling real-time response to
     dynamic edge conditions and user mobility scenarios such as
     handovers.  By integrating closed-loop monitoring and analytics, the
     system ensures consistent and autonomous security across
     heterogeneous 5G environments.

  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 8 January 2026.





  Ahn, et al.              Expires 8 January 2026                 [Page 1]


  Internet-Draft  An Integrated Security Service System fo       July 2025


  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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  An I2NSF-Based Architecture for 5G Edge Security
             Management  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  The Procedure for I2NSF-Based 5G Edge Security Management . .   7
     5.  Security Considerations Sections  . . . . . . . . . . . . . .  11
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Introduction

     Network softwarization has become a fundamental approach for
     delivering network services across various infrastructures, including
     5G mobile networks [TS-23.501], cloud computing platforms, and edge
     computing environments.  This paradigm is enabled through key
     technologies such as Network Functions Virtualization (NFV)
     [ETSI-NFV] and Software-Defined Networking (SDN) [RFC7149].  In
     addition, Intent-Based Networking (IBN) [RFC9315]
     [Survey-IBN-CST-2023] serves as a foundation for implementing
     intelligent behaviors in both network-level and application-level
     services.  As networks continue to evolve in this software-driven
     direction, the emergence of 5G introduces new challenges,
     particularly in the realm of security.

     As mobile networks evolve toward 5G, the increasing complexity of
     network functions and the widespread deployment of edge devices such
     as IoT nodes, user equipment (UE), and application functions (AFs)



  Ahn, et al.              Expires 8 January 2026                 [Page 2]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     [TS-23.501] introduce significant challenges to existing security
     models.  These environments are inherently dynamic, heterogeneous,
     and latency-sensitive, making it difficult for traditional rule-based
     configurations, which are typically static and manually managed, to
     respond effectively to changing conditions.  In particular, security
     operations at the edge require more contextual awareness, automation,
     and adaptability than ever before.

     Intent-Based Networking (IBN) provides a promising paradigm to meet
     these requirements.  It enables operators or users to declare high-
     level goals, or intents, which the system can automatically translate
     into enforceable security and network policies [TS-28.312].  These
     policies may range from abstract service-level objectives to fine-
     grained access control rules.  By automating this translation and
     enforcement process, the network gains the ability to respond
     autonomously to operational demands without requiring manual
     intervention.  This model supports closed-loop control, where real-
     time feedback mechanisms continuously refine and adapt system
     behavior based on evolving context and intent.

     This document defines an intent-based framework for edge security
     management in the context of 5G systems.  The framework builds upon
     the service-based architecture (SBA) defined in 3GPP 5G and beyond,
     and introduces a layered approach that includes intent translation,
     policy generation, enforcement, and monitoring.  It integrates
     seamlessly with existing 3GPP network functions such as the Policy
     Control Function (PCF) [TS-29.520], Access and Mobility Management
     Function (AMF), Session Management Function (SMF), and Network Data
     Analytics Function (NWDAF) [TS-23.288].  The aim is to deliver
     scalable and adaptive security control across heterogeneous edge
     domains through policy-driven orchestration.

     Furthermore, the framework is designed to support mobility scenarios,
     including handovers between gNBs and session migration across
     multiple User Plane Functions (UPFs).  By dynamically enforcing
     intents at the edge, the system maintains consistent and context-
     aware security postures even in the presence of mobility events.
     This capability strengthens the resilience and responsiveness of the
     network while laying a foundation for secure, automated, and
     intelligent 5G services.  The proposed framework also aligns with
     long-term goals of zero-touch security, AI-driven orchestration, and
     intent-based policy automation within future mobile network
     infrastructures.








  Ahn, et al.              Expires 8 January 2026                 [Page 3]


  Internet-Draft  An Integrated Security Service System fo       July 2025


  2.  Terminology

     This section provides definitions of the key terms and concepts used
     throughout this document.  The terminology is intended to establish a
     common understanding of the architectural elements, interfaces, and
     operational principles discussed in the context of intent-based
     security management in 5G networks.  These terms are used to describe
     5G Network automation based on the Intent-Based Networking (IBN) and
     Interface to Network Security Functions (I2NSF) framework.

     *  Intent: It refers to a set of operational objectives and expected
        outcomes that a network should fulfill, expressed in a declarative
        manner without specifying the implementation details or the exact
        procedures to achieve them [RFC9315].  Intents can be represented
        using XML [RFC6020] [RFC7950] or YAML [YAML] formats, and may be
        delivered to the target components through protocols such as
        NETCONF [RFC6241], RESTCONF [RFC8040], or via standard REST APIs
        [REST].

     *  IBN User Function (IUF): It is typically accessed via a web-
        browser interface, which allows Mobile Object administrators to
        input network intents for the IBN Control Function (ICF).  These
        intents serve as strategic objectives that guide the generation of
        security and network policies within the system.

     *  IBN Control Function (ICF): The ICF operates as a core component
        of the I2NSF architecture deployed within the 5G network.  It is
        responsible for managing and orchestrating security enforcement
        functions by translating the intents from the IUF into actionable
        policies, and by selecting appropriate 5G Network Functions (NFs)
        for their execution.

     *  Developer's Management Function (DMF): It is a component within
        the Interface to Network Security Functions (I2NSF) framework that
        acts as a provider of Network Security Functions (NSFs).  It's
        responsible for registering the capabilities of these NSFs with
        the Security Controller, essentially making them available for use
        in enforcing security policies.

     *  Security Control Function (SCF): SCF strengthens network security
        by generating low-level policies to modify and supplement the
        network configuration based on the delivered network policy and
        delivering these to the relevant individual NFs.








  Ahn, et al.              Expires 8 January 2026                 [Page 4]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     *  Security Data Analytics Function (SDAF): It collects and analyzes
        monitoring data to verify whether the policies generated based on
        intents have been properly enforced by the network security
        functions, and to evaluate the performance and functionality of
        the security services.

     *  Network Security Function (NSF): NSF is a network security
        function that provides actual security services based on policies
        generated based on the user's intent.  It actually executes
        security tasks such as blocking or allowing traffic based on the
        policy delivered from ICF.

  3.  An I2NSF-Based Architecture for 5G Edge Security Management

     This section defines a comprehensive framework for 5G security
     management automation by introducing its essential components and
     explaining how each of them is designed to interconnect with
     functions in the 5G core networks [TS-23.501].  The framework is
     grounded in intent-based networking principles, which enable high-
     level user or application intents to be automatically translated into
     actionable policies.  These policies are then enforced and monitored
     across both the core and edge domains without requiring manual
     intervention.

     As 5G networks become more distributed and support a growing number
     of latency-sensitive services and heterogeneous devices, traditional
     static security mechanisms struggle to cope with the dynamic nature
     of threats and the scale of real-time traffic.  Manual configuration
     is no longer feasible in such environments, making automated security
     orchestration essential to maintain consistent protection, reduce
     response time, and minimize human error.

     To realize this, the framework leverages a set of I2NSF-based
     functional modules that collectively support policy translation,
     enforcement, and real-time monitoring.  By integrating these
     components into the 5G architecture, the system enables scalable,
     adaptive, and context-aware security operations tailored to the needs
     of dynamic and heterogeneous edge environments.













  Ahn, et al.              Expires 8 January 2026                 [Page 5]


  Internet-Draft  An Integrated Security Service System fo       July 2025


    +------------------------------------+ +-----------------------------+
    | 5G Core NFs                        | |                             |
    | +-----+  +-----+  +-----+  +-----+ | | +-----+  +-----+  +------+  |
    | |NSSF |  | UDM |  | NRF |  | PCF | | | | IUF |  | ICF |  | SDAF |  |
    | +---+-+  +---+-+  +---+-+  +---+-+ | | +--+--+  +--+--+  +--+---+  |
    |     |        |        |        |   | |    |        |        |      |
    | --+-+------+-+------+-+---+--+-+---+-+----+---+----+----+---+----- |
    |   |        |        |        |     | |        |         |          |
    | +-+---+  +-+---+  +-+---+  +-+---+ | |     +-----+   +-----+       |
    | | AUSF|  | AMF |  | SMF |  | NEF | | |     | DMF |   | SCF |       |
    | +-----+  +-+-+-+  +--+--+  +-----+ | |     +-----+   +-----+       |
    |            | |       |             | |                             |
    |      +-----+ +--+    +------+      | |  AFs for Security Services  |
    +------+----------+-----------+------+ +-----------------------------+
           |          |           |
        +--+--+   +---+---+    +--+---+   +--+---+   +--------------+
        | UE  +---+ (R)AN +----+ UPFs +---+ NSFs +---+ Data Network |
        +-----+   +-------+    +--+---+   +------+   +--------------+

       Figure 1: I2NSF-Based Security Management Framework for 5G Edge
                                   Networks

     Figure 1 illustrates a 5G edge security service architecture based on
     the I2NSF framework [RFC8329], implemented as an Intent-Based System
     (IBS).  An intent-based management strategy is required between the
     5G Core network and distributed edge domains to enable the autonomous
     configuration and security enforcement of edge functions such as User
     Equipment (UEs), as described in the IETF draft on intent-based
     network management automation.

     On the right side of the architecture, the AFs for Security Services
     represent application-layer functions that initiate and manage high-
     level security intents.  These functions serve as the interface
     between external users or applications and the intent-based security
     system.  This service is composed of several key modules, including
     the Intent-Based Use Function (IUF), the Intent Control Function
     (ICF), the Security Control Function (SCF), the Developer's
     Management Function (DMF), and the Security Data Analytics Function
     (SDAF), which collectively support intent interpretation, policy
     translation, enforcement, and monitoring across the network.

     The security intent generated by the Intent-Based Network Use
     Function (IUF) is first interpreted as a high-level objective
     reflecting the desired behavior of the network or specific
     applications.  This intent is then processed by the Intent-Based
     Network Control Function (ICF), which plays a central role in
     translating the abstract intent into concrete policies.  Through this
     translation process, two distinct types of policies are created: a



  Ahn, et al.              Expires 8 January 2026                 [Page 6]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     network policy, which governs how the underlying network should
     behave (e.g., traffic routing, filtering, or QoS enforcement), and an
     application policy, which defines how specific applications or
     devices should operate under given security constraints.

     Once these policies are generated, they are delivered to the 5G Core
     Network via the Network Exposure Function (NEF).  The NEF serves as
     the gateway between external application functions and the internal
     control plane of the 5G Core.  To support flexible deployment and
     orchestration, these components can be implemented as containerized
     microservices and managed using Kubernetes[Kubernetes].  By passing
     the policies through the NEF, the system enables relevant 5G Core
     components such as the Policy Control Function (PCF), Session
     Management Function (SMF), and Access and Mobility Management
     Function (AMF) to enforce the translated policies in real time.  This
     ensures that the original user or service intent is consistently and
     dynamically applied throughout the network.

  4.  The Procedure for I2NSF-Based 5G Edge Security Management

     This testbed demonstrates a use case where high-level user intents
     are automatically translated into enforceable network and application
     policies.  Leveraging the I2NSF (Interface to Network Security
     Functions) framework [RFC8329] and deployed on the free5GC platform,
     this architecture enables automated, intent-driven security
     management that reduces the reliance on manual configuration and
     static rule sets.

     The system is designed to support distributed policy enforcement by
     integrating key I2NSF components such as the Intent-Based Networking
     Use Function (IUF), Intent Control Function (ICF), Security Control
     Function (SCF), and Security Data Analytics Function (SDAF).  These
     components work collaboratively to process intents, generate
     appropriate policies, and enforce them dynamically across both the
     core network and the edge.


                   +--------------+
                   |User Equipment|
                   +--------------+
                          ^  Appplication Policy
                          |    (Configuration)
                          |          +-------------------+
  +-----+             +--------+     |    IBN Control    |         +----------+
  | NEF |<------------+ Router |<----+      Function     |<--------+ IBN Use  |
  +-----+   Network   +--------+     |(Intent Translator)|  Intent | Function |
  5G Core   Policy                   +-------------------+         +----------+
  Network (Firewall& WebFilter)



  Ahn, et al.              Expires 8 January 2026                 [Page 7]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     Figure 2: The Procedure of Policy Generation and Delivery for 5G
                               Edge Network

     Figure 2 shows the procedure for 5G Edge Security Management
     Automation, specifically illustrating the creation of user intents
     and the generation of corresponding network policies and application
     policies.  The process begins when a user or administrator expresses
     a security-related intent via the IBN Use Function (IUF).  This
     intent, representing a high-level goal such as restricting access to
     certain websites or monitoring device behavior, is passed to the IBN
     Control Function (ICF).  The ICF, equipped with an Intent Translator,
     converts this intent into both network-level and application-level
     policies.  The translated network-level policies are forwarded
     through the router to the 5G Core's Network Exposure Function (NEF)
     [TS-29.503], while the application-level policies are delivered
     directly to the User Equipment (UE).  This enables consistent policy
     enforcement from the core network to the device edge.


             User Equipment 1 (SmartPhone)  User Equipment 2 (IoT Device)
                +---------------------+        +---------------------+
                | +-----------------+ |        | +-----------------+ |
                | |Service Functions| |        | |Service Functions| |
                | |      (SFs)      | |        | |      (SFs)      | |
                | +-----------------+ |        | +-----------------+ |
                |          ^ |        |        |          ^ |        |
                |Monitoring| |  API   |        |Monitoring| |  API   |
                |   Data   | |Command |        |   Data   | |Command |
                |          | V        |        |          | V        |
                |   +--------------+  |        |   +--------------+  |
                |   |IBN Controller|  |        |   |IBN Controller|  |
                |   +--------------+  |        |   +--------------+  |
                |          ^  |       |        |        ^       |    |
                +----------+--+-------+        +--------+-------+----+
                           |  |                         |       |
                           |  +---------------------------------+
                           |                            |       |
                           +--------------+-----+-------+----+  +
                     Application Policy   |     |            |  |
                      (Configuration)     |     |            |  |
                                          |     |            |  |
              +---------------------------+-----+-----+      |  |
              |                           |     |     |      |  |
  +--------+  |   +------+   +-----+   +--+--+  |     |      |  |
  |  Data  +--|---+ NSFs +---+ UPF +---+ gNB |  |     |      |  |
  | Network|  |   +------+   +--+--+   +--+--+  |     |      |  |
  +--------+  |                 |         |     |     |      |  |
              |              +--+--+   +--+--+  |     |      |  |



  Ahn, et al.              Expires 8 January 2026                 [Page 8]


  Internet-Draft  An Integrated Security Service System fo       July 2025


              |              | SMF |   | AMF +--+     |      |  |
              |              +--+--+   +--+--+        |      |  |
              |                 |         |           |    +-+--+---+
              | ----+--------+--+-----+---+----+---   |    | Router +---+
              |     |        |        |        |      |    +---+----+   |
              |  +--+--+  +--+--+  +--+--+  +--+--+   |        |        |
              |  | SCF |  | DMF |  | SCF |  | NEF |<--+--------+        |
              |  +--+--+  +--+--+  +--+--+  +--+--+   | Network         |
              |                                       | Policy          |
              |                                       | (Firewall       |
              +---------------------------------------+ & Web Filter)   |
                            5G Core Network                             |
                                                             Monitoring |
                                                               Report   |
                                                                        V
                                                          +-------------------+
                                                          |   Security Data   |
                                                          | Analytics Function|
                                                          +---------+---------+
                                                                    |
                                                    +---------------+---------+
                                                    | Monitoring Data Storage |
                                                    +-------------------------+

      Figure 3: The Procedure within an I2NSF-Based Framework for 5G
                         Edge Security Management

     Figure 3 illustrates the procedure of how the intent-driven network
     policies and application policies are applied across both the 5G core
     network and user equipment.  These policies are then propagated
     throughout the 5G network to support coordinated and consistent
     security enforcement.  Network-level policies are distributed to core
     network functions [TS-23.501], where they help guide the overall
     behavior and resource allocation of the system in alignment with the
     user's intent.  At the same time, application-level policies are
     delivered to various user devices, such as smartphones and IoT nodes,
     which have embedded controllers capable of interpreting and enforcing
     the received policies locally.

     This allows each device to autonomously adjust its behavior according
     to the defined security or operational requirements.  In parallel,
     network-based security functions are also engaged to apply the
     necessary controls, such as access restrictions or traffic filtering,
     ensuring that both the core and the edge of the network operate
     securely and in harmony with the original intent.  This distributed
     approach enables flexible, scalable, and adaptive policy enforcement
     across the entire mobile network environment [TS-23.288].




  Ahn, et al.              Expires 8 January 2026                 [Page 9]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     To support adaptive security validation, each user equipment's IBN
     Controller periodically generates monitoring reports based on local
     policy enforcement status.  These reports are sent to the Security
     Data Analytics Function (SDAF), which analyzes the monitoring data to
     evaluate whether the applied policies are effectively enforced.  All
     collected data is stored in a centralized Monitoring Data Storage
     module, enabling real-time policy validation and historical auditing.
     The related steps are as follows:

     *  Steps 1-2: An intent is sent from an application within the 5G
        Core to the IBN Control Function, where it is translated into
        network and application policies.  This marks the beginning of
        intent-driven automation for security management.

     *  Step 3: The network policy is delivered to relevant 5G Core
        functions and connected security components.  These components
        then prepare for the enforcement of the policy.

     *  Step 4: The application policy is sent to the IBN Controllers on
        the target user devices.  This allows the devices to receive
        instructions without direct user intervention.

     *  Step 5: Each device applies the policy to adjust its settings and
        behavior.  The changes take effect locally to reflect the system-
        wide intent.

     *  Step 6: Devices monitor their own status and send relevant data
        back to their IBN Controllers.  This ensures continuous awareness
        of policy impact at the device level.

     *  Step 7: IBN Controllers compile and forward the data as monitoring
        reports.  These reports provide a basis for evaluating the
        effectiveness of the applied policies.

     *  Step 8: The reports are analyzed to check if the policies are
        working as intended, and the results are stored for future use.
        This completes the feedback loop that enables adaptive policy
        refinement.













  Ahn, et al.              Expires 8 January 2026                [Page 10]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     Through this process, the system enables intent-driven security
     management that spans from core network functions to individual user
     devices.  By translating high-level intents into enforceable policies
     and continuously monitoring their effects, the architecture supports
     real-time adaptation to network conditions and user behaviors.  This
     ensures that security enforcement remains consistent, context-aware,
     and autonomous throughout distributed edge environments.  Moreover,
     the closed-loop structure provides a foundation for scalable and
     self-optimizing policy management, which is essential for future 5G
     edge-native networks.

     Also, the proposed system extends the core components such as the
     Intent-Based Networking Use Function (IUF), Intent Control Function
     (ICF), and distributed enforcement modules to operate in tandem with
     the handover procedures defined in 3GPP specifications.  This helps
     keep security consistent and smart across the edge network where
     quick response and local control are especially important.  This
     approach can also be applied to mobility scenarios where intent-
     driven security policies need to dynamically migrate and be re-
     enforced as User Equipment (UE) transitions between gNBs.

  5.  Security Considerations Sections

     In the context of intent-based edge security management in 5G
     networks, several important security aspects must be considered to
     ensure robust and trustworthy system behavior.  One key concern
     involves the potential for malicious manipulation of user intents.
     Since intents are high-level expressions of user goals that drive the
     automated generation of network and application policies, any
     unauthorized alteration could lead to unintended or insecure
     outcomes.  Ensuring that each intent originates from a trusted source
     and is protected by integrity validation mechanisms is therefore
     essential.

     Another important consideration is the accuracy and reliability of
     the policy translation and enforcement process.  When translating
     abstract intents into concrete policies, the system must preserve the
     user's original intent without introducing misconfigurations or
     inconsistencies.  Incorporating validation checks and feedback
     mechanisms helps ensure that policies are correctly interpreted and
     consistently applied across the network.  To further enhance this
     process, deep learning techniques [Deep-Learning] can be employed to
     detect anomalies, learn from past policy enforcement outcomes, and
     adaptively improve the translation logic based on contextual patterns
     and historical data.






  Ahn, et al.              Expires 8 January 2026                [Page 11]


  Internet-Draft  An Integrated Security Service System fo       July 2025


  6.  IANA Considerations

     This document does not require any IANA actions.

  7.  References

  7.1.  Normative References

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/info/rfc6020>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/info/rfc6241>.

     [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
                Networking: A Perspective from within a Service Provider
                Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
                <https://www.rfc-editor.org/info/rfc7149>.

     [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
                RFC 7950, DOI 10.17487/RFC7950, August 2016,
                <https://www.rfc-editor.org/info/rfc7950>.

     [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
                <https://www.rfc-editor.org/info/rfc8040>.

     [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
                Kumar, "Framework for Interface to Network Security
                Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
                <https://www.rfc-editor.org/info/rfc8329>.

     [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
                Tantsura, "Intent-Based Networking - Concepts and
                Definitions", RFC 9315, DOI 10.17487/RFC9315, October
                2022, <https://www.rfc-editor.org/info/rfc9315>.

  7.2.  Informative References

     [YAML]     Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another
                Markup Language (YAML) 1.0",
                Available: https://yaml.org/spec/history/2001-05-26.html,
                October 2023.




  Ahn, et al.              Expires 8 January 2026                [Page 12]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     [TS-23.501]
                "System Architecture for the 5G System (5GS)", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3144, September
                2023.

     [TS-28.312]
                "Intent Driven Management Services for Mobile Networks",
                Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3554, September
                2023.

     [TS-23.288]
                "Architecture Enhancements for 5G System (5GS) to Support
                Network Data Analytics Services", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3579, September
                2023.

     [TS-29.503]
                "Service-Based Interface Specifications for the Network
                Exposure Function (NEF)", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3342, September
                2023.

     [TS-29.520]
                "Network Data Analytics Services", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3355, September
                2023.

     [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural
                Framework", Available:
                https://www.etsi.org/deliver/etsi_gs/
                nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
                December 2014.

     [REST]     Fielding, R. and R. Taylor, "Principled Design of the
                Modern Web Architecture", ACM Transactions on Internet
                Technology, Vol. 2, Issue 2,,
                Available: https://dl.acm.org/doi/10.1145/514183.514185,
                May 2002.







  Ahn, et al.              Expires 8 January 2026                [Page 13]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     [Deep-Learning]
                Goodfellow, I., Bengio, Y., and A. Courville, "Deep
                Learning", Publisher: The MIT Press,
                Available: https://www.deeplearningbook.org/, November
                2016.

     [Kubernetes]
                "Kubernetes: Cloud Native Computing Platform",
                Available: https://kubernetes.io/, March 2024.

     [Survey-IBN-CST-2023]
                Leivadeas, A. and M. Falkner, "A Survey on Intent-Based
                Networking",
                Available: https://ieeexplore.ieee.org/document/9925251,
                March 2023.

     [ClickINC-Sigcomm-2023]
                Xu, W., Zhang, Z., Feng, Y., Song, H., Chen, Z., Wu, W.,
                Liu, G., Zhang, Y., Liu, S., Tian, Z., and B. Liu,
                "ClickINC: In-network Computing as a Service in
                Heterogeneous Programmable Data-center Networks",
                Publisher: ACM SIGCOMM,
                Available: https://dl.acm.org/doi/10.1145/3603269.3604835,
                September 2023.

  Acknowledgments

     This work was supported by Institute of Information & Communications
     Technology Planning & Evaluation (IITP) grant funded by the Korea
     Ministry of Science and ICT (MSIT) (No.  RS-2024-00398199 and RS-
     2022-II221015).

     This work was supported in part by Institute of Information &
     Communications Technology Planning & Evaluation (IITP) grant funded
     by the Korea Ministry of Science and ICT (MSIT) (No.  IITP-2025-RS-
     2022-II221199, Regional strategic industry convergence security core
     talent training business).

  Contributors

     This document is made by the group effort of OPWAWG, greatly
     benefiting from inputs and texts by Linda Dunbar (Futurewei), Yong-
     Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui
     University).  The authors sincerely appreciate their contributions.

     The following are coauthors of this document:





  Ahn, et al.              Expires 8 January 2026                [Page 14]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     Mose Gu
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: rna0415@skku.edu
     URI:   http://iotlab.skku.edu/people-Moses-Gu.php


  Authors' Addresses

     Yoseop Ahn (editor)
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: ahnjs124@skku.edu
     URI:   http://iotlab.skku.edu/people-Ahn-Yoseop.php


     Jaehoon Paul Jeong (editor)
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4957
     Email: pauljeong@skku.edu
     URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


     Younghan Kim
     School of Electronic Engineering
     Soongsil University
     369, Sangdo-ro, Dongjak-gu
     Seoul
     06978
     Republic of Korea



  Ahn, et al.              Expires 8 January 2026                [Page 15]


  Internet-Draft  An Integrated Security Service System fo       July 2025


     Email: younghak@ssu.ac.kr


















































  Ahn, et al.              Expires 8 January 2026                [Page 16]


name: draft-fu-cats-flow-lb
rev: 03
title: Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)
time: 2026-02-27T03:07:12Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T03:07:12Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.515107+00:00
source: ietf
source_id: 138001
source_url: https://datatracker.ietf.org/doc/draft-fu-cats-flow-lb/
doc_status: active
abstract:
  This document specifies a flow-level load balancing mechanism for
     Computing-Aware Traffic Steering (CATS) that reduces control plane
     overhead and improves resource utilization through data plane
     autonomous flow distribution.

full_text:
  CATS                                                               H. Fu
  Internet-Draft                                                D.H. Huang
  Intended status: Standards Track                                 W. Duan
  Expires: 30 August 2026                                           B. Tan
                                                           ZTE Corporation
                                                          26 February 2026


    Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)
                          draft-fu-cats-flow-lb-03

  Abstract

     This document specifies a flow-level load balancing mechanism for
     Computing-Aware Traffic Steering (CATS) that reduces control plane
     overhead and improves resource utilization through data plane
     autonomous flow distribution.

  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 30 August 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.



  Fu, et al.               Expires 30 August 2026                 [Page 1]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Architectural Model . . . . . . . . . . . . . . . . . . . . .   3
     6.  Control plane Operation . . . . . . . . . . . . . . . . . . .   5
     7.  Data Plane Operation  . . . . . . . . . . . . . . . . . . . .   6
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
       11.2.  Informative References . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Computing-Aware Traffic Steering (CATS) [I-D.ldbc-cats-framework]
     directs traffic between service clients and providers based on real-
     time computing and network status.  While CATS operates as an overlay
     system for selecting optimal service instances, the framework does
     not assume specific data plane or control plane solutions.

     This document defines a flow-level load balancing mechanism
     addressing two operational challenges: control plane scalability
     limitations caused by reactive path computation, and resource
     utilization imbalances resulting from coarse-grained status
     reporting.  The mechanism enables the control plane to pre-compute
     multiple viable forwarding alternatives while allowing the data plane
     to autonomously distribute traffic across these alternatives using
     flow-based affinity.

  2.  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, as shown here.

  3.  Terminology

     This document makes use of the terms defined in
     [I-D.ldbc-cats-framework].





  Fu, et al.               Expires 30 August 2026                 [Page 2]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


     *  CATS Routing Table: Control plane structure containing service
        identifiers, network paths, service instances, and load sharing
        weights.

     *  CATS Forwarding Table: Data plane structure derived from CATS
        Routing Table via UCMP-to-ECMP expansion.

     *  Flow Affinity Table: Data plane table maintaining flow-to-
        forwarding-entry bindings.

  4.  Problem Statement

     Current CATS implementations rely on periodic or threshold-triggered
     resource status reports to optimize service instance and path
     selection.  This approach creates uneven computing resource
     utilization when status updates lag behind actual load changes,
     potentially directing multiple requests to already overloaded
     instances.  Additionally, frequent metric fluctuations trigger
     repeated control plane path recalculation and policy updates,
     creating scalability constraints that incremental calculation alone
     cannot resolve.

  5.  Architectural Model

     The Flow-Level Load Balancing of Computing-Aware Traffic Steering is
     constructed based on the framework established in the CATS
     architecture [I-D.ldbc-cats-framework](Figure 1 for a visual
     representation).























  Fu, et al.               Expires 30 August 2026                 [Page 3]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


         +-----+              +------+           +------+
       +------+|            +------+ |         +------+ |
       |client|+            |client|-+         |client|-+
       +---+--+             +---+--+           +---+--+
           |                    |                  |
           | +----------------+ |            +-----+----------+
           +-+    C-TC#1      +-+      +-----+    C-TC#2      |
             |----------------|        |     |----------------|
             |     |C-PS#1    |    +------+  |CATS-Forwarder 4|
       ......|     +----------|....|C-PS#2|..|                |...
       :     |CATS-Forwarder 2|    |      |  |                |  .
       :     +----------------+    +------+  +----------------+  :
       :                                                         :
       :                                            +-------+    :
       :                         Underlay           | C-NMA |    :
       :                      Infrastructure        +-------+    :
       :                                                         :
       :                                                         :
       : +----------------+                +----------------+    :
       : |CATS-Forwarder 1|  +-------+     |CATS-Forwarder 3|    :
       :.|                |..|C-SMA#1|.... |                |....:
         +---------+------+  +-------+     +----------------+
                   |         |             |   C-SMA#2      |
                   |         |             +-------+--------+
                   |         |                     |
                   |         |                     |
                +------------+               +------------+
               +------------+ |             +------------+ |
               |  Service   | |             |  Service   | |
               |  Contact   | |             |  Contact   | |
               |  Instance  |-+             |  Instance  |-+
               +------------+               +------------+
                service site 1              service site 2

                      Figure 1: CATS-Functional-Components

     The mechanism operates through three functional entities: the Path
     Selector (C-PS) situated in the control plane collecting metrics via
     Metric Agents (C-SMA and C-NMA) and computing forwarding
     alternatives; the Forwarder operating in the data plane performing
     flow identification, affinity maintenance and packet forwarding; and
     the Metric Agents reporting service instance and network status to
     enable path computation.

     The Path Selector maintains the CATS Routing Table containing for
     each CS-ID a set of Forwarding Alternatives comprising network path
     identifiers, service instance identifiers, and load sharing weights
     representing desired traffic distribution proportions.  The Forwarder



  Fu, et al.               Expires 30 August 2026                 [Page 4]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


     generates the CATS Forwarding Table through UCMP-to-ECMP expansion,
     creating a uniform lookup structure where each Forwarding Alternative
     appears in proportion to its weight, and maintains the Flow Affinity
     Table binding flow identifiers to specific forwarding entries.

  6.  Control plane Operation

     The Path Selector identifies for each CS-ID the Service Instance Set
     containing all Forwarding Alternatives satisfying SLA requirements,
     computing load sharing weights based on service instance metrics,
     network path characteristics and policy objectives.  The resulting
     CATS Routing Table is translated into a CATS Forwarding Table and
     distributed to Forwarders..

     Figure 2 shows an example of a representation of multi-next-hop CATS
     routing table designed for a specific CS-ID1.

     +-------+-------+--------------------------------------------------+
     |       |       |              NEXT HOP                            |
     |VRF-ID |PREFIX +-----------------+-----------+--------------------+
     |       |       |SR-Policy        |Service SID| Load Sharing Ratio |
     +-------+-------+-----------------+-----------+--------------------+
     |100    |CS-ID1 |SR-Policy1(2ms)  |END.DX-1   | 20%                |
     |       |       +-----------------+-----------+--------------------+
     |       |       |SR-Policy1(2ms)  |END.DX-2   | 30%                |
     |       |       +-----------------+-----------+--------------------+
     |       |       |SR-Policy2(1.5ms)|END.DX-3   | 30%                |
     |       |       +-----------------+-----------+--------------------+
     |       |       |SR-Policy2(1.5ms)|END.DX-4   | 20%                |
     +-------+-------+-----------------+-----------+--------------------+

                   Figure 2: An example of CATS routing table


     Figure 3 shows an example of the CATS forwarding table following the
     changes.















  Fu, et al.               Expires 30 August 2026                 [Page 5]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


           +-------+-------+-----------------+-----------+--------+
           |VRF-ID |PREFIX |SR-Policy        |Service SID| offset |
           +-------+-------+-----------------+-----------+--------+
           |100    |CS-ID1 |SR-Policy1(2ms)  |END.DX-1   | 0      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy1(2ms)  |END.DX-1   | 1      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy1(2ms)  |END.DX-2   | 2      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy1(2ms)  |END.DX-2   | 3      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy1(2ms)  |END.DX-2   | 4      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy2(1.5ms)|END.DX-3   | 5      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy2(1.5ms)|END.DX-3   | 6      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy2(1.5ms)|END.DX-3   | 7      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy2(1.5ms)|END.DX-4   | 8      |
           |       |       +-----------------+-----------+--------+
           |       |       |SR-Policy2(1.5ms)|END.DX-4   | 9      |
           +-------+-------+-----------------+-----------+--------+

                 Figure 3: An example of CATS forwarding table


     To minimize control plane load, the Path Selector regenerates the
     CATS Routing Table only when metric changes cross predefined
     thresholds rather than reacting to every fluctuation, optionally
     employing hysteresis mechanisms to prevent rapid oscillation between
     configurations.

  7.  Data Plane Operation

     Upon receiving a packet the Forwarder extracts the CS-ID and computes
     the flow identifier, typically derived from the five-tuple.  The
     Forwarder queries the Flow Affinity Table and if an existing binding
     is found forwards the packet using the bound entry.  For unbound
     flows the Forwarder computes a hash over the flow identifier, selects
     the CATS Forwarding Table entry at the resulting index, creates a
     Flow Affinity Entry binding the flow to this entry, and forwards the
     packet.








  Fu, et al.               Expires 30 August 2026                 [Page 6]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


     The CATS Forwarding Table remains stable during flow affinity
     establishment ensuring consistent forwarding for all packets of a
     flow.  Table updates received from the Path Selector apply only to
     new flows while existing bindings remain valid until flow termination
     or timeout.

  8.  Security Considerations

     The mechanism introduces potential denial of service vulnerabilities
     through Flow Affinity Table exhaustion if an attacker generates
     excessive new flows, mitigated by implementing binding creation rate
     limits.  Predictable flow identifiers could enable binding hijacking
     requiring cryptographically robust hash functions.  CATS Forwarding
     Tables distributed from Path Selector to Forwarder may expose
     topology information warranting protection during transmission.

  9.  Acknowledgements

     To be added upon contributions, comments and suggestions.

  10.  IANA Considerations

     TBA

  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,
                <https://www.rfc-editor.org/info/rfc2119>.

     [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>.

     [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
                Decraene, B., Litkowski, S., and R. Shakir, "Segment
                Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
                July 2018, <https://www.rfc-editor.org/info/rfc8402>.

     [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
                Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
                (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
                <https://www.rfc-editor.org/info/rfc8754>.





  Fu, et al.               Expires 30 August 2026                 [Page 7]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


     [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
                D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
                (SRv6) Network Programming", RFC 8986,
                DOI 10.17487/RFC8986, February 2021,
                <https://www.rfc-editor.org/info/rfc8986>.

  11.2.  Informative References

     [I-D.fu-cats-hybrid-fwd]
                Huakai.Fu, Yi, X., Pang, B., Yuan, D., Duan, W., and C.
                Miao, "Hybird Fordwarding of Computing-Aware Traffic
                Steering (CATS)", Work in Progress, Internet-Draft, draft-
                fu-cats-hybrid-fwd-00, 30 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-fu-cats-
                hybrid-fwd-00>.

     [I-D.fu-cats-muti-dp-solution]
                Huakai.Fu, Liu, B., Li, Z., Huang, D., Yuan, D., Ma, L.,
                and W. Duan, "Analysis for Multiple Data Plane Solutions
                of Computing-Aware Traffic Steering", Work in Progress,
                Internet-Draft, draft-fu-cats-muti-dp-solution-03, 19
                August 2025, <https://datatracker.ietf.org/doc/html/draft-
                fu-cats-muti-dp-solution-03>.

     [I-D.huang-service-aware-network-framework]
                Huang, D., Tan, B., and D. Yang, "Service Aware Network
                Framework", Work in Progress, Internet-Draft, draft-huang-
                service-aware-network-framework-01, 22 November 2022,
                <https://datatracker.ietf.org/doc/html/draft-huang-
                service-aware-network-framework-01>.

     [I-D.ietf-cats-usecases-requirements]
                Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
                "Computing-Aware Traffic Steering (CATS) Problem
                Statement, Use Cases, and Requirements", Work in Progress,
                Internet-Draft, draft-ietf-cats-usecases-requirements-14,
                2 February 2026, <https://datatracker.ietf.org/doc/html/
                draft-ietf-cats-usecases-requirements-14>.

     [I-D.lbdd-cats-dp-sr]
                Li, C., Du, Z., Drake, J., and shangyuxiang, "Computing-
                Aware Traffic Steering (CATS) Using Segment Routing", Work
                in Progress, Internet-Draft, draft-lbdd-cats-dp-sr-06, 13
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-lbdd-cats-dp-sr-06>.






  Fu, et al.               Expires 30 August 2026                 [Page 8]


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


     [I-D.ldbc-cats-framework]
                Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
                Drake, "A Framework for Computing-Aware Traffic Steering
                (CATS)", Work in Progress, Internet-Draft, draft-ldbc-
                cats-framework-06, 8 February 2024,
                <https://datatracker.ietf.org/doc/html/draft-ldbc-cats-
                framework-06>.

     [I-D.li-dyncast-architecture]
                Li, Y., Iannone, L., Trossen, D., Liu, P., and C. Li,
                "Dynamic-Anycast Architecture", Work in Progress,
                Internet-Draft, draft-li-dyncast-architecture-08, 16
                January 2023, <https://datatracker.ietf.org/doc/html/
                draft-li-dyncast-architecture-08>.

     [RFC7094]  McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
                "Architectural Considerations of IP Anycast", RFC 7094,
                DOI 10.17487/RFC7094, January 2014,
                <https://www.rfc-editor.org/info/rfc7094>.

  Authors' Addresses

     Huakai Fu
     ZTE Corporation
     Wuhan
     China
     Email: fu.huakai@zte.com.cn


     Daniel Huang
     ZTE Corporation
     Nanjing
     China
     Email: huang.guangping@zte.com.cn


     Wei Duan
     ZTE Corporation
     Nanjing
     China
     Email: duan.wei1@zte.com.cn


     Bin Tan
     ZTE Corporation
     ShangHai
     China
     Email: tan.bin@zte.com.cn



  Fu, et al.               Expires 30 August 2026                 [Page 9]


name: draft-templin-manet-inet
rev: 02
title: MANET Internetworking: Problem Statement and Gap Analysis
time: 2026-01-12T17:45:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T17:45:42Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.519454+00:00
source: ietf
source_id: 149368
source_url: https://datatracker.ietf.org/doc/draft-templin-manet-inet/
doc_status: active
abstract:
  [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
     The system may operate in isolation, or may have gateways to and
     interface with a fixed network" (such as the global public Internet).
     This document presents a MANET Internetworking problem statement and
     gap analysis.

full_text:
  Network Working Group                                 F. L. Templin, Ed.
  Internet-Draft                              Boeing Technology Innovation
  Intended status: Informational                           D. J. Jakubisin
  Expires: 16 July 2026         National Security Institute, Virginia Tech
                                                           12 January 2026


         MANET Internetworking: Problem Statement and Gap Analysis
                        draft-templin-manet-inet-02

  Abstract

     [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
     The system may operate in isolation, or may have gateways to and
     interface with a fixed network" (such as the global public Internet).
     This document presents a MANET Internetworking problem statement and
     gap analysis.

  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 16 July 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.



  Templin & Jakubisin       Expires 16 July 2026                  [Page 1]


  Internet-Draft            MANET Internetworking             January 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  MANET Internetworking Problem Statement and Gap Analysis  . .   4
       3.1.  Problem 1: MANET Local Addressing . . . . . . . . . . . .   4
       3.2.  Problem 2: Autoconfiguration  . . . . . . . . . . . . . .   6
       3.3.  Problem 3: MANET-internal Communications  . . . . . . . .   7
       3.4.  Problem 4: MANET Peer to Internetwork Correspondent . . .   7
       3.5.  Problem 5: Internetwork Correspondent to MANET Peer . . .   8
       3.6.  Problem 6: Peer-to-Peer Between Different MANETs  . . . .   8
       3.7.  Problem 7: Stub MANET to Not-so-stubby MANET
             Connections . . . . . . . . . . . . . . . . . . . . . . .   9
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     Mobile Ad-hoc Networks (MANETs) [RFC2501] often include mobile nodes
     with limited range wireless transmission media interfaces that
     establish links via a dynamically changing set of neighbors within
     operational range.  Each mobile node engages a MANET routing protocol
     to discover links to first hop neighbors as well as multihop paths to
     reach other nodes beyond.  As IP routers [RFC0791][RFC8200], MANET
     routers represent multihop paths as "host routes" established through
     either proactive or reactive discovery.

     Individual MANETs typically include modest numbers of mobile nodes
     (e.g., O(1), O(10), O(100), etc.); this naturally limits the number
     of host routes needed in the local routing system.  MANETs can merge
     to form larger MANETs and/or partition into smaller MANETs according
     to dynamic network conditions such as mobility.  MANETs often operate
     autonomously unless or until they encounter Internetwork access
     points of opportunity.

     Data communications between two nodes within the same MANET follow
     host routes using MANET-internal links.  When a MANET router
     establishes an Internetwork link, it can provide "Internet
     connection-sharing" access to the rest of the MANET as a connected
     "stub" network.  Per [RFC2501], "stub networks carry traffic
     originating at and/or destined for internal nodes, but do not permit
     exogenous traffic to "transit" through the stub network".



  Templin & Jakubisin       Expires 16 July 2026                  [Page 2]


  Internet-Draft            MANET Internetworking             January 2026


     Practical applications however suggest that MANETs can act as either
     true stub networks (e.g., a cellphone providing a hotspot for a
     multihop WiFi SSID) or as "not-so-stubby" networks (e.g., Intelligent
     Transportation Systems where the 5G/6G "SideLink" service supports
     vehicle-to-vehicle (V2V) multihopping).  In the former case, the
     cellphone acts as an IP router for a stub WiFi MANET behind it and
     the individual WiFi nodes act as dependent nodes.  In the latter
     case, individual 5G/6G SideLink nodes can connect the stub MANETs
     they aggregate across not-so-stubby V2V multihop forwarding paths.
     MANET Internetworking must therefore be capable of accommodating all
     such scenarios.

     Google AI reports that: "There are currently more mobile phones than
     people in the world.  While the exact number fluctuates, estimates
     suggest there are over 12 billion mobile connections worldwide".
     Each mobile node that connects to the global public Internet can in
     some sense be regarded as a network access point for a singleton
     "MANET" with the potential to connect still larger MANETs.

     MANET Internetworking therefore regards the global Internet as a
     "network of (mobile ad-hoc) networks", and with unrestricted dynamic
     relationships between distinct local MANET routing regions joined by
     virtual circuits.  Figure 1 illustrates an example of two distinct
     MANETs joined by a virtual circuit using the Internet as transit:


                                  .-(::::::::)
                               .-(::: Global ::)-.
                       +======(===================)======+
                       |        `-(: Internet :)-'       |
                       |           `-(::::::)-'          |
                       v                                 v
                .-(::::::::)                       .-(::::::::)
             .-(::::::::::::)-.                 .-(::::::::::::)-.
            (::::: MANET 1 :::::)              (::::: MANET 2 :::::)
              `-(::::::::::::)-'                 `-(::::::::::::)-'
                 `-(::::::)-'                       `-(::::::)-'

                        Figure 1: MANET Internetworking

  2.  MANET Use Cases

     MANETs have an important role in emergency response communications,
     disaster relief situations, communications in remote and rural areas,
     military operations, vehicular and swarm communications, and low-
     powered Internet of things (IoT) applications.  MANETs provide the
     ability to establish and maintain communications when infrastructure-
     based networks, such as 5G cellular communication systems, are not



  Templin & Jakubisin       Expires 16 July 2026                  [Page 3]


  Internet-Draft            MANET Internetworking             January 2026


     accessible.  As described above, MANETs may also provide Internet
     connectivity to internal nodes, for example, as a "stub" network via
     MANET routers which possess an Internetworking capability and an
     external connection to a radio access network.

     Example use cases of such MANETs include the following:

     *  Disaster Relief: Disaster situations may compromise network
        infrastructure, such as through the loss of base stations in a
        cellular radio access network (RAN).  In this scenario, MANET
        networks can play a role in closing coverage gaps through multi-
        hop routing to nodes within the coverage area of uncompromised
        base stations.  This use case is broadly applicable to any
        situation in which nodes are operating outside or at the periphery
        of RAN coverage.

     *  Tracking and Monitoring: Another example use case is the tracking
        and monitoring of data from low-cost low-power IoT devices
        ("tags") which may be placed on packages during shipment or
        storage.  Such devices may transition in and out of coverage of
        infrastructure-based networks, often being located in environments
        that are not conducive to RF propagation (e.g., shipping
        container, warehouse, etc.).  The ability to discover and connect
        to neighboring MANET-enabled devices and to establish Internet
        connectivity through such MANETs, enables real-time logistics and
        inventory data to be collected opportunistically.

     *  UAV Swarms: local communications within swarms for coordination
        and cooperation is a good use case for MANET networks due to the
        highly mobile dynamic nature of such networks.  Yet swarms may
        also benefit from connectivity to the Internet, or other external
        networks.  And in large swarm-based MANETs, routing of traffic
        through infrastructure networks to MANET endpoints, rather than
        traversing the entire MANET can improve communications throughput
        and reliability.

  3.  MANET Internetworking Problem Statement and Gap Analysis

  3.1.  Problem 1: MANET Local Addressing

     Each MANET router requires a unique IP address for MANET-local
     communications; the router often uses this same address to configure
     a unique "router ID".  For MANETs that are only intermittently
     connected to an Internetwork, these addresses must be generated from
     IP prefixes of scope greater than link-local but not associated with
     infrastructure aggregation points.  For all MANET types, each
     address/ID must be locally-unique within the (limited) local MANET
     routing domain.  For not-so-stubby MANETs, the address/ID must also



  Templin & Jakubisin       Expires 16 July 2026                  [Page 4]


  Internet-Draft            MANET Internetworking             January 2026


     be globally-unique among all local MANET routing domains worldwide.

     The locally-unique property ensures that no two nodes that
     participate in the MANET routing protocol within the same local
     routing domain configure the same address/ID.  The globally-unique
     property may seem moot until one considers that MANETs can merge with
     other MANETS, and nodes from a first MANET can freely move to other
     MANETs.  This may allow a node from a first MANET where there are no
     duplicates to interact with other MANETs where a duplicate address
     may be encountered resulting in unpredictable behavior and/or
     communication failures.

     Although the node population for each MANET local routing domain is
     likely to be modest, the total population of MANET nodes may be on
     the order of the number of worldwide mobile connections (see:
     Section 1).  Assuming the google estimate of O(10**10) wireless
     connections, if MANET nodes assigned random addresses from a 64-bit
     space, the probability of one or more collisions within the total
     world population (i.e., when multiple nodes independently configure
     the same address) exceeds 98% [RFC9374].  With such a high likelihood
     of duplication in the worldwide population, an unresolvable collision
     could occur if duplicates ever met within the same local routing
     domain (e.g., following a MANET merge).

     For stub MANETs that always acts independently of all others, the
     risk of a duplication event within each local routing domain due to a
     new node joining is vanishingly small even for extreme mobility
     frequencies according to Appendix A.2 of [RFC4429].  Stub MANETs can
     therefore rely on statistical uniqueness properties of randomly
     assigned addresses.

     When MANET Internetworking is applied to connect routers in different
     not-so-stubby MANETs, however, independent local routing domains are
     dynamically joined by on-demand virtual circuits across the
     Internetwork overlay as a normal course of operational data
     communications.  When these MANET merge events occur, the MANET local
     IP addresses present in the source and destination MANETs must be
     mutually exclusive.  These merge events must further be considered to
     occur at truly unbounded frequencies across the global population due
     to the unpredictable nature of worldwide Internetworking dynamics for
     peer-to-peer communications.  Statistical uniqueness properties of
     random assignments from even very large populations may therefore be
     insufficient to ensure collision freedom since MANET Internetworking
     exposes the full world population of MANET local addresses as
     potential duplicates.






  Templin & Jakubisin       Expires 16 July 2026                  [Page 5]


  Internet-Draft            MANET Internetworking             January 2026


     Nodes in not-so-stubby MANETs should therefore configure MANET local
     addresses managed for uniqueness even if they first self-generate the
     addresses before enrolling them in a registration service.  Such
     address registration is not required for nodes that only connect via
     stub MANETs.

  3.2.  Problem 2: Autoconfiguration

     When a MANET comes in contact with a fixed Internetwork such as the
     global public Internet, nodes in the MANET that engage global mobile
     Internetworking services require some means of autoconfiguring
     global-scoped IP addresses and/or prefixes that are properly routable
     by network elements accessible from the current point of attachment.
     These network elements are typically proxies or routers of some
     variety that connect to the mobile routing system.

     Nodes in the local MANET that are multiple IP hops away from an
     Internet connection sharing peer cannot use unmodified standard
     autoconfiguration services including IPv6 Neighbor Discovery (IPv6ND)
     [RFC4861] or DHCPv6 [RFC8415] over a MANET interface since these
     services are link-scoped in nature.  (The DHCPv6 architecture
     includes a "relay" function, but the dynamic nature of links in
     (multi-link) local MANET routing regions may interfere with
     straightforward application of DHCPv6 relays.)

     Two methods of supporting generalized autoconfiguration for nodes
     within a MANET have been suggested.  In a first method (conducted
     directly over MANET interfaces) first-hop neighboring nodes within
     the MANET collectively participate to repeat link-scoped
     autoconfiguration discovery requests to other neighbors that are
     topologically closer to an Internet connection sharing node.  This
     hop-by-hop process continues between neighbors until the request
     arrives at an Internet connection sharing node that can then contact
     an Internetwork element capable of delegating an Internet Service
     Provider (ISP) Provider-Aggregated (PA) IP address or prefix.  The
     Internetwork element then returns the delegated IP address/prefix in
     a reply that traverses the reverse path to the original requesting
     node.  Each MANET router then configures a route to this IP address/
     prefix within the MANET local routing protocol, i.e., the MANET local
     routing protocol becomes aware of the delegation.

     In a second autoconfiguration method, the requesting node configures
     a (virtual) overlay multilink network interface over its (physical)
     MANET interface(s) and issues standard link-scoped IPv6ND and/or
     DHCPv6 requests over the virtual interface.  The virtual interface
     applies encapsulation to provide the appearance of a single Non-
     Broadcast Multiple Access (NBMA) link spanning the entire (multilink)
     MANET.  This virtual link supports standard link-scoped



  Templin & Jakubisin       Expires 16 July 2026                  [Page 6]


  Internet-Draft            MANET Internetworking             January 2026


     autoconfiguration services coordinated with an Internetwork element
     capable of delegating an address.  For stub MANETs, the Internet
     connection sharing node itself delegates a public or private IP
     address.  For not-so-stubby MANETS, an overlay Internetwork Mobility
     Anchor Point (MAP) delegates a Mobility Service Provider (MSP) Mobile
     Network Prefix (MNP) as a Provider-Independent (PI) IP prefix
     maintained by the overlay for the requesting node to provision on
     downstream-attached interfaces.  The MAP then returns the delegated
     IP prefix in a link-scoped reply over the virtual interface that
     traverses the reverse path to the original requesting node.  Each
     MANET router optionally configures a route to this IP address via the
     virtual interface, i.e., the MANET local routing protocol is
     optionally made aware of the delegation within the virtual overlay.

  3.3.  Problem 3: MANET-internal Communications

     Two nodes located within the same local MANET routing region should
     be able to communicate (across multiple hops if necessary) using
     MANET local addressing with no external Internetwork infrastructure
     reference points.  As long as the MANET-local addresses configured by
     communicating peers are unique, the MANET local routing system
     maintains continuous multihop forwarding services to ensure session
     continuity.

     Nodes within the local MANET routing region can discover the MANET
     local addresses of peers using services like Multicast DNS (mDNS)
     [RFC6762] supported by Simplified Multicast Forwarding (SMF)
     [RFC6621].  Peer-to-peer communications can then be coordinated
     either in multihop fashion directly over the physical MANET
     interfaces or via a single virtual hop using overlay multilink
     network interface encapsulation.  In that case, the MANET peers
     establish an on-demand virtual circuit spanning any intermediate hops
     in the path.

  3.4.  Problem 4: MANET Peer to Internetwork Correspondent

     When an originating peer (or its stub MANET Internet connection-
     sharing node) within a not-so-stubby MANET needs to communicate with
     a correspondent connected elsewhere in an external Internetwork, the
     peer consults the global DNS which returns a (stable) globally-
     routable IP address for the correspondent.  The peer can then use one
     of its MNP-based IP addresses obtained through autoconfiguration and
     the global IP address of the Internetwork correspondent as the source
     and destination addresses for packet exchanges.

     The MANET peer first establishes an on-demand virtual circuit in the
     overlay to an Internetwork relay beyond the MANET border.  MANET
     local multihop routing will then convey the peer's original packets



  Templin & Jakubisin       Expires 16 July 2026                  [Page 7]


  Internet-Draft            MANET Internetworking             January 2026


     to the MANET border which then forwards them via the overlay to an
     Internetwork relay which directs the packets to the correspondent
     node.

     In the reverse path, the correspondent uses the MNP-based IP address
     of the peer obtained from the source address of initiating packets as
     the destination address for reply packets.  Standard Internetwork
     routing will direct the packets back to the relay which then forwards
     them via an on-demand overlay virtual circuit to the originating
     peer's MANET border.  MANET-local routing and forwarding will then
     convey the packets over one or more MANET-local hops until they
     ultimately reach the peer.

     In this case, the originating peer's IP address need not appear in
     the global DNS since the correspondent discovers the address by
     examining the source of received packets.

  3.5.  Problem 5: Internetwork Correspondent to MANET Peer

     When an Internetwork correspondent needs to communicate with a target
     peer within a local MANET routing region, the correspondent consults
     the global DNS to determine an IP address for the peer.

     The correspondent then forwards packets via standard Internet routing
     until they arrive at a relay.  The relay then establishes an on-
     demand virtual circuit in the overlay to the MANET peer then begins
     forwarding packets via the virtual circuit until they reach the
     destination.  Reverse path forwarding from the MANET peer to the
     Internetwork correspondent is then conducted in the same manner
     described in Section 3.4.

     IP addresses covered by delegated prefixes remain stable even across
     MANET-wide mobility events to the point that continuous dynamic
     updates to the DNS are not required to maintain uninterruptable
     communications.  While it is possible that mobility events may cause
     minor temporary disruptions, transport protocol retransmissions will
     maintain continuity for any ongoing sessions.

  3.6.  Problem 6: Peer-to-Peer Between Different MANETs

     When two prospective peer nodes are located in different MANET local
     routing regions separated by one or more transit Internetwork
     segments, both peers should include their IP addresses in their
     global DNS resource records for the same reasons cited in
     Section 3.5.

     The peers then establish on-demand virtual circuits in the overlay to
     support peer-to-peer bidirectional packet forwarding.



  Templin & Jakubisin       Expires 16 July 2026                  [Page 8]


  Internet-Draft            MANET Internetworking             January 2026


     Maintaining address mappings requires a certain degree of
     coordination between peer nodes and the MSP.  The MSP is responsible
     for ensuring that each peer remains reachable at its stable IP
     address/prefix through distributed mobility management.

  3.7.  Problem 7: Stub MANET to Not-so-stubby MANET Connections

     When an Internet connection sharing MANET router connects a stub
     MANET, it can either delegate public IP addresses to stub MANET nodes
     or delegate private IP addresses then apply Network Address
     Translation (NAT) to support external communications.

     In the public case, all manners of peer-to-peer communications are
     made possible due to the globally routable nature of the addresses.
     In the NAT case, only communications initiated by a stub network peer
     are supported since the reverse path terminates at the NAT.

     The stub MANET itself may configure a local overlay that regards the
     (multihop) MANET as a single unified link.  In that case, the stub
     network overlay link is distinct from the overlay link that spans the
     global public Internet and the two links are joined by an IPv6
     router.

     In the not-so-stubby case, a single overlay link extends across both
     any transit Internetworks and the source and target MANETs
     themselves.  All peer-to-peer communications are therefore conveyed
     across the monolithic Internetwork overlay.

  4.  IANA Considerations

     This document is an informational problem statement and does not in
     itself request any IANA actions.  IANA considerations can be found in
     solution space documents.

  5.  Security Considerations

     This document is an informational problem statement and does not in
     itself address security.  Security considerations can be found in
     solution space documents.

  6.  Acknowledgements

     Discussions on the MANET working group mailing list helped shape
     concepts exposed in this document.  Abdussalam Baryun encouraged a
     MANET use case analysis.  Polls conducted by chairs during the
     IETF124 MANET working group session presentation of this document
     showed unanimous and substantial interest in MANET Internetworking:
     https://datatracker.ietf.org/meeting/124/materials/minutes-124-manet-



  Templin & Jakubisin       Expires 16 July 2026                  [Page 9]


  Internet-Draft            MANET Internetworking             January 2026


     202511061630-00.

     This work is aligned with the Boeing/Virginia Tech National Security
     Institute (VTNSI) 5G MANET research program.

     Honoring life, liberty and the pursuit of happiness.

  7.  References

  7.1.  Normative References

     [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
                DOI 10.17487/RFC0791, September 1981,
                <https://www.rfc-editor.org/info/rfc791>.

     [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", STD 86, RFC 8200,
                DOI 10.17487/RFC8200, July 2017,
                <https://www.rfc-editor.org/info/rfc8200>.

  7.2.  Informative References

     [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
                (MANET): Routing Protocol Performance Issues and
                Evaluation Considerations", RFC 2501,
                DOI 10.17487/RFC2501, January 1999,
                <https://www.rfc-editor.org/info/rfc2501>.

     [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
                for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
                <https://www.rfc-editor.org/info/rfc4429>.

     [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
                DOI 10.17487/RFC4861, September 2007,
                <https://www.rfc-editor.org/info/rfc4861>.

     [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
                RFC 6621, DOI 10.17487/RFC6621, May 2012,
                <https://www.rfc-editor.org/info/rfc6621>.

     [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
                DOI 10.17487/RFC6762, February 2013,
                <https://www.rfc-editor.org/info/rfc6762>.







  Templin & Jakubisin       Expires 16 July 2026                 [Page 10]


  Internet-Draft            MANET Internetworking             January 2026


     [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
                Richardson, M., Jiang, S., Lemon, T., and T. Winters,
                "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
                RFC 8415, DOI 10.17487/RFC8415, November 2018,
                <https://www.rfc-editor.org/info/rfc8415>.

     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/info/rfc9374>.

  Appendix A.  Change Log

     << RFC Editor - remove prior to publication >>

     Differences from -01 to -02:

     *  Simplified addressing model under Autoconfiguration section.  Only
        autoconfiguration now necessary is for Mobile Network Prefixes
        (MNPs).

     Differences from -00 to -01:

     *  Included use case discussion.

     *  Slight clarification to addressing model.

     Differences from earlier versions:

     *  First draft publication.

  Authors' Addresses

     Fred L. Templin (editor)
     Boeing Technology Innovation
     P.O. Box 3707
     Seattle, WA 98124
     United States of America
     Email: fltemplin@acm.org


     Daniel J. Jakubisin
     National Security Institute, Virginia Tech
     2202 Kraft Dr.
     Blacksburg, VA 24060
     United States of America
     Email: djj@vt.edu




  Templin & Jakubisin       Expires 16 July 2026                 [Page 11]


name: draft-sogomonian-ai-uri-scheme
rev: 01
title: AI URI Scheme
time: 2026-04-06T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-06T16:49:42Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:48.588729+00:00
source: ietf
abstract:
  This document specifies the experimental ai Uniform Resource
     Identifier (URI) scheme.  The scheme provides a dedicated access
     point for Artificial Intelligence (AI) resources, enabling autonomous
     systems and robots to connect natively while allowing human-facing
     applications to interoperate via HTTPS gateways.

full_text:
  Network Working Group                                      A. Sogomonian
  Internet-Draft        Artificial Intelligence Internet Foundation (AIIF)
  Intended status: Experimental                             2 October 2025
  Expires: 5 April 2026


                               AI URI Scheme
                     draft-sogomonian-ai-uri-scheme-01

  Abstract

     This document specifies the experimental ai Uniform Resource
     Identifier (URI) scheme.  The scheme provides a dedicated access
     point for Artificial Intelligence (AI) resources, enabling autonomous
     systems and robots to connect natively while allowing human-facing
     applications to interoperate via HTTPS gateways.

  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 5 April 2026.

  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.







  Sogomonian                Expires 5 April 2026                  [Page 1]


  Internet-Draft                   AI URI                     October 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  URI Syntax (Non-Normative)  . . . . . . . . . . . . . . . . .   2
     3.  Web Integration and HTTPS Gateway Access  . . . . . . . . . .   3
       3.1.  Discovery from HTTPS  . . . . . . . . . . . . . . . . . .   3
       3.2.  HTTPS to AIIP Gateway Behavior  . . . . . . . . . . . . .   4
       3.3.  No Native AIIP Requirement for User Agents  . . . . . . .   4
       3.4.  Provenance and Result Integrity . . . . . . . . . . . . .   4
     4.  Namespace Administration  . . . . . . . . . . . . . . . . . .   5
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
     7.  Internationalization Considerations . . . . . . . . . . . . .   5
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
       8.1.  URI Scheme Registration . . . . . . . . . . . . . . . . .   5
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     The ai URI scheme identifies AI-addressable resources such as agents,
     models, tools, and tasks.  Deployments *MAY* resolve ai: identifiers
     natively within AI systems and robots, or via HTTPS gateways for
     compatibility with existing web stacks.

     For clarity, this document uses the term AIIP to denote the
     _Artificial Intelligence Internet Protocol_, the operational protocol
     by which ai:// resources are addressed, resolved, and invoked.  While
     ai:// is the URI scheme, AIIP defines resolution and interaction
     semantics.

     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.  URI Syntax (Non-Normative)

     The scheme follows [RFC3986].  An informal summary is shown:

     ai-uri = "ai:" hier-part [ "?" query ] [ "#" fragment ]
     ; hier-part, query, fragment per RFC 3986

     Examples (illustrative only):

     ai:/agent/forklift-42?task=load&zone=A3
     ai://factory.example/pay?amount=10&currency=USD



  Sogomonian                Expires 5 April 2026                  [Page 2]


  Internet-Draft                   AI URI                     October 2025


  3.  Web Integration and HTTPS Gateway Access

     Many user agents will not natively implement the ai scheme or the
     Artificial Intelligence Internet Protocol (AIIP).  To enable
     immediate interoperability, deployments *MAY* expose ai:// resources
     via HTTPS gateways so that end users remain on conventional websites
     while backends or trusted intermediaries invoke AIIP.  In this model,
     a relying party (for example, an online bank) advertises an ai://
     endpoint and resolves it server-side or through a gateway; the user
     continues to interact over HTTPS without needing to understand ai://.

  3.1.  Discovery from HTTPS

     HTTPS origins that rely on AIIP *SHOULD* advertise their ai://
     endpoints using one or more of:

     *  *HTTP Link header* on responses:

        Link: <ai://bank/service/payments>; rel="aiip"

     *  *HTML link relation* for progressive enhancement:

        <link rel="aiip" href="ai://bank/service/payments">

     *  *Well-known resource* at /.well-known/aiip:

        {
          "endpoint": "ai://bank/service/payments",
          "jwks":
            "https://www.bank.example/.well-known/aiip.jwks.json",
          "scopes": [
            "initiate-payment",
            "check-balance"
          ],
          "policy": {
            "auth": "oauth2",
            "mtls": true,
            "requireSignedResults": true
          }
        }

     *  *DNS bootstrap (optional)*, for example, SRV or TXT records:

        _aiip._tcp.bank.example.  300 IN SRV 0 0 443
                                  aiip.bank.example.
        _aiip.bank.example.       300 IN TXT
                                  "endpoint=ai://bank/service/payments"




  Sogomonian                Expires 5 April 2026                  [Page 3]


  Internet-Draft                   AI URI                     October 2025


  3.2.  HTTPS to AIIP Gateway Behavior

     A conforming HTTPS to AIIP gateway *MUST* map an embedded ai:// URI
     to an HTTPS URL under its control, perform AIIP resolution, and
     translate the result back into HTTPS semantics for the client.  For
     example:

     Original:
       ai://bank/service/payments?amount=10&currency=USD
     Gateway :
       https://ai.example/gateway/bank/service/payments
       ?amount=10&currency=USD

     Gateways *MUST*:

     *  Parse and normalize the ai:// URI; reject malformed or ambiguous
        inputs.

     *  Authenticate to the AI endpoint and verify provenance of responses
        (for example, JWS with a key discoverable via the origin's JWKS).

     *  Enforce authorization consistent with the user's web session (for
        example, token exchange, DPoP, or mTLS constraints).

     *  Preserve confidentiality and integrity at least equivalent to TLS
        1.3 [RFC8446] and obey HTTP semantics [RFC9110].

     *  Prevent downgrades; do not weaken authentication or authorization
        versus native AIIP.

  3.3.  No Native AIIP Requirement for User Agents

     Web user agents *NEED NOT* implement AIIP.  Sites may perform all AI
     resolution server-side or via a trusted gateway.  This enables
     gradual deployment: users remain on HTTPS while services invoke ai://
     under the hood to complete actions (for example, initiating a
     payment).

  3.4.  Provenance and Result Integrity

     Responses returned from AIIP resolution *MUST* include verifiable
     provenance (for example, a detached or embedded signature).  Gateways
     and relying parties *MUST* reject unverifiable or policy-incompatible
     results.  Implementations *SHOULD* publish a JWKS for verification
     and rotate keys per operational policy.






  Sogomonian                Expires 5 April 2026                  [Page 4]


  Internet-Draft                   AI URI                     October 2025


  4.  Namespace Administration

     To support global uniqueness and safe operation of autonomous
     systems, namespace administration for ai: identifiers is expected to
     be coordinated by the _Artificial Intelligence Internet Foundation
     (AIIF)_, which serves as the umbrella governance body.  The _AIIF
     Registry Authority for Identifiers (AIID)_ operates the AI Root
     Registry and administers identifier allocation and operational policy
     for ai:// namespaces.  This administrative role is separate from the
     technical specification of the scheme and protocol.

  5.  Security Considerations

     Implementations that dereference ai: identifiers *MUST* authenticate
     endpoints and apply authorization and safety policies, especially
     when actions may control physical devices or financial operations.
     Gateways translating ai: to HTTPS *MUST* preserve provenance and
     provide transport security per [RFC8446] and semantics conforming to
     [RFC9110].

  6.  Privacy Considerations

     Accessing ai:// resources through HTTPS gateways may expose metadata
     such as target identifiers, origin site, and timing information to
     intermediaries.  Gateways *SHOULD* minimize logging, apply strict
     data retention limits, and avoid retaining identifiers longer than
     operationally necessary.  Provenance and result signatures may
     contain linkable identifiers; deployments *SHOULD* apply least-
     privilege scopes and anonymization where appropriate.

  7.  Internationalization Considerations

     Identifiers in ai:// URIs follow [RFC3986].  Non-ASCII characters
     appearing in the path or query components *MUST* be percent-encoded.
     Any authority components mapped from DNS *MUST* follow IDNA
     processing where applicable.  No additional internationalization
     mechanisms are defined by this document.

  8.  IANA Considerations

     This document requests Provisional registration of the ai URI scheme
     per [RFC7595].

  8.1.  URI Scheme Registration

     This section provides the registration template for the ai URI scheme
     in accordance with [RFC7595] Section 3.4.




  Sogomonian                Expires 5 April 2026                  [Page 5]


  Internet-Draft                   AI URI                     October 2025


     Scheme name: ai
     Status: Provisional
     Applications/protocols that use this scheme:
       AIIP (Artificial Intelligence Internet Protocol)
     Contact:
       Aram Sogomonian <waterbottling@icloud.com>
     Change controller:
       The author of this document (or a designated successor)
     References:
       This document; RFC 3986; RFC 7595; RFC 8446; RFC 9110
     Security considerations:
       See "Security Considerations" of this document

  9.  Normative References

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", RFC 3986,
                January 2005, <https://www.rfc-editor.org/info/rfc3986>.

     [RFC7595]  Thaler, D., Hansen, T., and T. Hardie, "Guidelines and
                Registration Procedures for URI Schemes", RFC 7595, June
                2015, <https://www.rfc-editor.org/info/rfc7595>.

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

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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

     [RFC9110]  Fielding, R. and J. Reschke, "HTTP Semantics", RFC 9110,
                June 2022, <https://www.rfc-editor.org/info/rfc9110>.

  Author's Address

     Aram Sogomonian
     Artificial Intelligence Internet Foundation (AIIF)
     United States of America
     Email: waterbottling@icloud.com







  Sogomonian                Expires 5 April 2026                  [Page 6]


name: draft-bernardos-green-isac-uc
rev: 00
title: Integrated Sensing and Communications (ISAC) use case for GREEN
time: 2025-08-31T07:09:01Z
group_uri: /api/v1/group/group/1027/
expires: 2025-08-31T11:44:52Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.528645+00:00
source: ietf
source_id: 143316
source_url: https://datatracker.ietf.org/doc/draft-bernardos-green-isac-uc/
doc_status: active
abstract:
  Integrated Sensing and Communications (ISAC) represents a paradigm
     shift in wireless networks, where sensing and communication functions
     are jointly designed and optimized.  By leveraging the same spectral
     and hardware resources, ISAC enables advanced capabilities such as
     environment perception, object tracking, and situational awareness,
     while maintaining efficient and reliable data transmission.  This
     integration holds great potential for applications in areas such as
     autonomous systems, smart cities, and industrial automation, where
     precise sensing and low-latency communication are critical.

     This document presents a use case related to ISAC, aiming to
     facilitate discussions within the GREEN Working Group on the
     potential benefits, challenges, and requirements.  The use case
     follows a structured template that we propose for all GREEN use
     cases, ensuring consistency and comparability across different
     scenarios.

full_text:
  GREEN WG                                                   CJ. Bernardos
  Internet-Draft                                                      UC3M
  Intended status: Standards Track                         M. Awais Jadoon
  Expires: 31 August 2025                                        A. Mourad
                                                              InterDigital
                                                          27 February 2025


      Integrated Sensing and Communications (ISAC) use case for GREEN
                      draft-bernardos-green-isac-uc-00

  Abstract

     Integrated Sensing and Communications (ISAC) represents a paradigm
     shift in wireless networks, where sensing and communication functions
     are jointly designed and optimized.  By leveraging the same spectral
     and hardware resources, ISAC enables advanced capabilities such as
     environment perception, object tracking, and situational awareness,
     while maintaining efficient and reliable data transmission.  This
     integration holds great potential for applications in areas such as
     autonomous systems, smart cities, and industrial automation, where
     precise sensing and low-latency communication are critical.

     This document presents a use case related to ISAC, aiming to
     facilitate discussions within the GREEN Working Group on the
     potential benefits, challenges, and requirements.  The use case
     follows a structured template that we propose for all GREEN use
     cases, ensuring consistency and comparability across different
     scenarios.

  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 31 August 2025.





  Bernardos, et al.        Expires 31 August 2025                 [Page 1]


  Internet-Draft           ISAC use case for GREEN           February 2025


  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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Energy-Aware Smart City Traffic Management  . . . . . . . . .   3
       2.1.  Use case description  . . . . . . . . . . . . . . . . . .   3
       2.2.  GREEN Specifics . . . . . . . . . . . . . . . . . . . . .   3
       2.3.  Requirements for GREEN  . . . . . . . . . . . . . . . . .   3
     3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Informative References  . . . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     Integrated Sensing and Communications (ISAC) is emerging as a key
     enabler for next-generation wireless networks, integrating sensing
     and communication functionalities within a unified system.  By
     leveraging the same spectral, hardware, and computational resources,
     ISAC enhances network efficiency while enabling new capabilities such
     as high-resolution environment perception, object detection, and
     situational awareness.  This paradigm shift is particularly relevant
     for applications requiring both reliable connectivity and precise
     sensing, such as autonomous vehicles, industrial automation, and
     smart city deployments.  Given its strategic importance, ISAC has
     gained significant traction in standardization efforts.  The ETSI
     Industry Specification Group (ISG) on ISAC has been established to
     explore technical requirements and use cases, while 3GPP has
     initiated discussions on ISAC-related features within its ongoing
     research on future 6G systems.  Furthermore, research initiatives
     within the IEEE and IETF are investigating how ISAC can be integrated
     into network architectures, spectrum management, and protocol design,
     making it a critical area of development in the evolution of wireless
     networks.



  Bernardos, et al.        Expires 31 August 2025                 [Page 2]


  Internet-Draft           ISAC use case for GREEN           February 2025


     This document presents a use case related to ISAC, aiming to
     facilitate discussions within the GREEN Working Group on the
     potential benefits, challenges, and requirements.  The use case
     follows a structured template that we propose for all GREEN use cases
     [I-D.stephan-green-use-cases], ensuring consistency and comparability
     across different scenarios.

  2.  Energy-Aware Smart City Traffic Management

  2.1.  Use case description

     This use case involves deploying ISAC systems in a smart city to
     monitor and optimize vehicles' traffic flows while minimizing energy
     consumption of the mobile network.  The system integrates sensing
     technologies, such as radar and LIDAR, with communication networks to
     detect vehicle density, monitor road conditions, and communicate with
     autonomous vehicles or traffic lights.  By using ISAC, the system
     minimizes redundant infrastructure (e.g., separate sensors and
     communication equipment), thus reducing the overall carbon and energy
     footprint.

  2.2.  GREEN Specifics

     Energy Consumption Monitoring: Each ISAC component (e.g., roadside
     units, integrated sensors, and communication transceivers) is capable
     of reporting its energy consumption in real time to the centralized
     or distributed energy management system.

     Reconfiguration for Energy Efficiency: The system can dynamically
     switch between high-resolution sensing modes (e.g., during peak
     hours) and low-power modes (e.g., during low traffic periods).  The
     network can reconfigure traffic communication paths to prioritize
     routes or nodes that consume less power, leveraging energy-efficient
     communication protocols.

     Integration of Local and Global Energy Goals: The system can operate
     both locally (e.g., turning off specific roadside units in low-
     traffic areas) and globally (e.g., modifying traffic patterns across
     the city) to achieve defined energy consumption goals.

  2.3.  Requirements for GREEN

     1.  Measurement Granularity:

         *  Ability to measure energy consumption per ISAC component
            (e.g., roadside unit, sensor, transceiver).





  Bernardos, et al.        Expires 31 August 2025                 [Page 3]


  Internet-Draft           ISAC use case for GREEN           February 2025


         *  Granular reporting per communication link or sensing mode
            (e.g., high-power radar mode vs. low-power mode).

     2.  Power Control Mechanisms:

         *  Ability to switch components on/off or place them in sleep/
            standby mode when not in use.

         *  Support for dynamic adjustment of sensing resolution or
            communication bandwidth to balance energy savings and system
            performance.

     3.  Reconfiguration and Adaptability:

         *  Support for hardware reconfiguration (e.g., adaptive sensing
            modes, transceiver settings) to optimize energy use.

         *  Mechanisms to steer traffic or adjust network routing based on
            global or local energy-saving objectives.

     4.  Global Coordination:

         *  Capabilities for cross-domain coordination to enable global
            optimization (e.g., city-wide traffic rerouting or dynamic
            resource allocation across different regions).

         *  Ability to aggregate and analyze energy consumption data from
            all ISAC components to inform high-level decision-making.

     5.  Energy-Aware Standards and Protocols:

         *  Communication protocols that minimize power usage while
            maintaining reliability.

         *  Interoperability standards for energy-aware reconfiguration
            across heterogeneous ISAC components and systems.

  3.  IANA Considerations

     N/A.

  4.  Security Considerations

     TBD.







  Bernardos, et al.        Expires 31 August 2025                 [Page 4]


  Internet-Draft           ISAC use case for GREEN           February 2025


  5.  Acknowledgments

     The work of Carlos J.  Bernardos in this document has been partially
     supported by the Horizon Europe MultiX (Grant Agreement No.
     101192521) and Hexa-X-II (Grant Agreement No. 101095759) projects.

  6.  Informative References

     [I-D.stephan-green-use-cases]
                Stephan, E., Palmero, M., Claise, B., Wu, Q., and L. M.
                Contreras, "Use Cases for Energy Efficiency Management",
                Work in Progress, Internet-Draft, draft-stephan-green-use-
                cases-00, 24 January 2025,
                <https://datatracker.ietf.org/doc/html/draft-stephan-
                green-use-cases-00>.

  Authors' Addresses

     Carlos J. Bernardos
     Universidad Carlos III de Madrid
     Av. Universidad, 30
     28911 Leganes, Madrid
     Spain
     Phone: +34 91624 6236
     Email: cjbc@it.uc3m.es
     URI:   http://www.it.uc3m.es/cjbc/


     Muhammad Awais Jadoon
     InterDigital Europe
     Email: muhammad.awaisjadoon@interdigital.com
     URI:   http://www.InterDigital.com/


     Alain Mourad
     InterDigital Europe
     Email: Alain.Mourad@InterDigital.com
     URI:   http://www.InterDigital.com/













  Bernardos, et al.        Expires 31 August 2025                 [Page 5]


name: draft-pbs-sidrops-roaanycast
rev: 00
title: Route Origin Authorization (ROA) Governance for Anycasted Services with Unique Origin ASNs
time: 2025-09-03T16:08:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-07T16:08:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.532541+00:00
source: ietf
source_id: 149443
source_url: https://datatracker.ietf.org/doc/draft-pbs-sidrops-roaanycast/
doc_status: active
abstract:
  This document describes a set of best practices for the management of
     Route Origin Authorizations (ROAs) used to certify globally anycasted
     services with unique origin autonomous system numbers (ASNs) per
     node.  It identifies key risk areas related to anycast-based ROA
     publication and how to mitigate technical risk for RPKI operations.

full_text:
  Network Working Group                                     L. Poulopoulos
  Internet-Draft                                               S. Boudjema
  Intended status: Best Current Practice                       H. Siddique
  Expires: 7 March 2026                                           Verisign
                                                          3 September 2025


  Route Origin Authorization (ROA) Governance for Anycasted Services with
                             Unique Origin ASNs
                      draft-pbs-sidrops-roaanycast-00

  Abstract

     This document describes a set of best practices for the management of
     Route Origin Authorizations (ROAs) used to certify globally anycasted
     services with unique origin autonomous system numbers (ASNs) per
     node.  It identifies key risk areas related to anycast-based ROA
     publication and how to mitigate technical risk for RPKI operations.

  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 7 March 2026.

  Copyright Notice

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











  Poulopoulos, et al.       Expires 7 March 2026                  [Page 1]


  Internet-Draft       ROAs for Unique Origin Anycast       September 2025


     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 Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
     2.  Single-prefix Minimal ROAs  . . . . . . . . . . . . . . . . .   4
     3.  Sequential-Use EE Certificate . . . . . . . . . . . . . . . .   4
     4.  Single Signing Time . . . . . . . . . . . . . . . . . . . . .   4
     5.  Synchronous Operations  . . . . . . . . . . . . . . . . . . .   4
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     Anycasting, the origination of a prefix from multiple nodes, is an
     internet design pattern for improving the performance, stability and
     resiliency of global networks and is commonly implemented by DNS, CDN
     and DDoS protection service operators.  This approach can result in
     lower latency and can simplify fail-over.  An anycast node can be
     easily taken offline via withdrawl of its BGP route, causing traffic
     to automatically shift to other available nodes.

     Anycast services originating from unique origin ASNs per node
     [RFC6382], originate a single prefix from multiple distinct ASNs.
     The approach allows for more precise monitoring and troubleshooting
     of routing anomalies or hijacks.  The primary benefit is enhanced
     observability of anycasted services, especially when a large number
     of nodes are in operation.











  Poulopoulos, et al.       Expires 7 March 2026                  [Page 2]


  Internet-Draft       ROAs for Unique Origin Anycast       September 2025


     This design (distinct origin ASNs) calls for specific considerations
     when publishing Route Origin Authorizations (ROA).  Certifying
     origins of a Multiple Origin Autonomous System (MOAS) prefix implies
     the existence of a set of ROAs to certify all origins of the prefix.
     Given the exclusive nature of route origin validation (ROV), partial
     ROA coverage of MOAS prefixes MUST be avoided, as it would result in
     "INVALID" prefix/origin pairs for non-covered origins.  In this
     instance, absence of coverage is preferable over partial coverage as
     it would make all prefix/origin pairs resolve to RPKI "UNKNOWN".

     This document presents a set of recommendations meant to avoid
     partial ROA coverage of MOAS prefixes, by ensuring shared fate among
     the set of ROAs covering them.

  1.1.  Conventions Used in This Document

     Anycast:  the practice of making a particular service address
        available in multiple, discrete, autonomous nodes, such that data-
        grams sent are routed to one of several available nodes [RFC4786].
     Multi-origin Autonomous System:  a particular setup of Anycast
        routing, where each node originating the same service is
        identified by a unique Autonomous System Number (ASN) [RFC6382].

     The terms "MOAS Service" and "MOAS Prefix" are used throughout this
     document as a convenience shorthand for the more verbose "Globally
     Anycasted Service with Unique Origin Autonomous System Numbers per
     Node".

     The terms "covering", "covered", when used to describe the effect of
     a ROA on a prefix/origin pair, are to be interpreted in the intuitive
     sense of "certified by".  They are not to be interpreted in the more
     restrictive sense employed by other writings, where "covering" only
     applies to the prefix of a prefix/origin pair [RFC6811] [RFC6483].

     They key words "VALID", "INVALID" and "UNKNOWN", are to be
     interpreted as RPKI validity states as described in [RFC6483] when,
     and only when, they appear in all capitals, as shown here. ç 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,
     as shown here.









  Poulopoulos, et al.       Expires 7 March 2026                  [Page 3]


  Internet-Draft       ROAs for Unique Origin Anycast       September 2025


  2.  Single-prefix Minimal ROAs

     Separate ROAs SHOULD be published for each prefix/origin-AS pair of
     the MOAS prefix.  This entails that these ROAs should contain a
     single prefix and the maximal length should be equal to the prefix
     length, i.e., be minimal ROAs [RFC9319].

     Doing so, ensures that routes of a MOAS prefix do not share fate with
     unrelated resources.

  3.  Sequential-Use EE Certificate

     A set of ROAs covering origins of a MOAS prefix SHOULD be signed
     using the same End-Entity (EE) certificate (a.k.a. "sequential use"
     EE certificate [RFC6487]).

     This guarantees a common validity period among all origins of the
     prefix, avoiding partial expiry or partial revocation within the ROA
     set.

     Moreover, using a single EE certificate for all ROAs covering a MOAS
     prefix avoids unnecessary CRL bloating.

  4.  Single Signing Time

     A set of ROAs covering origins of a MOAS prefix SHOULD present the
     same CMS signing time attribute.

     This practice may also have positive consequences if the publication
     point uses the CMS signing time as a reference to override filesystem
     timestamps [RFC9589] [I-D.ietf-sidrops-publication-server-bcp].

  5.  Synchronous Operations

     Signing, publication and withdrawal of ROAs covering origins of a
     MOAS prefix SHOULD be synchronous to ensure shared fate among them
     and avoid partial coverage.

     In the context of the RPKI publication protocol [RFC8181], clients
     SHOULD request publication or withdrawal of all ROAs related to the
     MOAS prefix as part of a single publication query message, preferably
     avoiding operations on resources unrelated to the MOAS prefix.
     Reciprocally, publication servers SHOULD honor atomicity of
     transactions requested as part of a single query message.







  Poulopoulos, et al.       Expires 7 March 2026                  [Page 4]


  Internet-Draft       ROAs for Unique Origin Anycast       September 2025


     When creating ROAs as the consequence of the addition of new origin
     node to a MOAS service, ROAs covering existing nodes of the prefix
     SHOULD be renewed at the same time to preserve common signing and
     validity times among all origins of the prefix.

     More broadly, any modification to a ROA covering a MOAS prefix SHOULD
     be accompanied by changes to all ROAs covering the same MOAS prefix
     to preserve uniform validity attributes across the set.
     Consequently, these changes SHOULD be published within a single RPKI
     Repository Delta Protocol (RRDP) serial increment, to ensure
     synchronicity on the relying party end [RFC8182].

  6.  IANA Considerations

     This document makes no requests of IANA.

  7.  Security Considerations

     This section will be added later based on community review and
     feedback

  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,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
                Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
                December 2006, <https://www.rfc-editor.org/info/rfc4786>.

     [RFC6382]  McPherson, D., Donnelly, R., and F. Scalzo, "Unique Origin
                Autonomous System Numbers (ASNs) per Node for Globally
                Anycasted Services", BCP 169, RFC 6382,
                DOI 10.17487/RFC6382, October 2011,
                <https://www.rfc-editor.org/info/rfc6382>.

     [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
                X.509 PKIX Resource Certificates", RFC 6487,
                DOI 10.17487/RFC6487, February 2012,
                <https://www.rfc-editor.org/info/rfc6487>.

     [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>.



  Poulopoulos, et al.       Expires 7 March 2026                  [Page 5]


  Internet-Draft       ROAs for Unique Origin Anycast       September 2025


     [RFC8181]  Weiler, S., Sonalker, A., and R. Austein, "A Publication
                Protocol for the Resource Public Key Infrastructure
                (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
                <https://www.rfc-editor.org/info/rfc8181>.

     [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
                "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
                DOI 10.17487/RFC8182, July 2017,
                <https://www.rfc-editor.org/info/rfc8182>.

     [RFC9319]  Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
                Maddison, "The Use of maxLength in the Resource Public Key
                Infrastructure (RPKI)", BCP 185, RFC 9319,
                DOI 10.17487/RFC9319, October 2022,
                <https://www.rfc-editor.org/info/rfc9319>.

     [RFC9589]  Snijders, J. and T. Harrison, "On the Use of the
                Cryptographic Message Syntax (CMS) Signing-Time Attribute
                in Resource Public Key Infrastructure (RPKI) Signed
                Objects", RFC 9589, DOI 10.17487/RFC9589, May 2024,
                <https://www.rfc-editor.org/info/rfc9589>.

  8.2.  Informative References

     [I-D.ietf-sidrops-publication-server-bcp]
                Bruijnzeels, T., de Kock, T., Hill, F., Harrison, T., and
                J. Snijders, "RPKI Publication Server Best Current
                Practices", Work in Progress, Internet-Draft, draft-ietf-
                sidrops-publication-server-bcp-03, 24 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
                publication-server-bcp-03>.

     [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
                Origination Using the Resource Certificate Public Key
                Infrastructure (PKI) and Route Origin Authorizations
                (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
                <https://www.rfc-editor.org/info/rfc6483>.

     [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
                Austein, "BGP Prefix Origin Validation", RFC 6811,
                DOI 10.17487/RFC6811, January 2013,
                <https://www.rfc-editor.org/info/rfc6811>.

  Authors' Addresses







  Poulopoulos, et al.       Expires 7 March 2026                  [Page 6]


  Internet-Draft       ROAs for Unique Origin Anycast       September 2025


     L. Poulopoulos
     Verisign
     Route du Petit Moncor 1E
     CH-1752 Villars sur Glane
     Switzerland
     Email: lpoulopoulos@verisign.com
     URI:   https://www.verisign.com/


     S. Boudjema
     Verisign
     Route du Petit Moncor 1E
     CH-1752 Villars sur Glane
     Switzerland
     Email: sboudjema@verisign.com
     URI:   https://www.verisign.com/


     H. Siddique
     Verisign
     12061 Bluemont Way
     Reston, VA 20190
     United States
     Email: hsiddique@verisign.com
     URI:   https://www.verisign.com/


























  Poulopoulos, et al.       Expires 7 March 2026                  [Page 7]


name: draft-sogomonian-aiip-architecture
rev: 04
title: Architecture for the Artificial Intelligence Internet Protocol
time: 2026-03-25T23:37:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-26T23:37:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:48.588759+00:00
source: ietf
abstract:
  This document defines the architectural model for the Artificial
     Intelligence Internet Protocol (AIIP).  AIIP defines a dedicated
     autonomous access plane for execution-capable systems, enabling
     delegated, stateless execution of real-world actions using a resolve-
     invoke-execute-receipt pattern over authenticated transports.

     AIIP is not a discovery, registration, orchestration, or control-
     plane protocol.  It defines the architectural boundary at which
     autonomous execution is recognized and cryptographically verifiable
     through execution receipts.

full_text:
  Independent Submission                                     A. Sogomonian
  Internet-Draft        Artificial Intelligence Internet Foundation (AIIF)
  Intended status: Experimental                           14 December 2025
  Expires: 17 June 2026


   Architecture for the Artificial Intelligence Internet Protocol (AIIP)
                   draft-sogomonian-aiip-architecture-03

  Abstract

     This document defines the architectural model for the Artificial
     Intelligence Internet Protocol (AIIP), including decentralized
     discovery and a byte-precise native envelope.  AIIP enables
     stateless, verifiable invocation of autonomous systems using a
     resolve-invoke-receipt pattern over authenticated transports.  Native
     AIIP is the default for machine-to-machine operation; HTTPS gateways
     are optional for human-facing access.  Each invocation produces a
     cryptographically verifiable execution receipt, optionally including
     attestation evidence.

  Note

     Work in Progress.

  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 June 2026.

  Copyright Notice

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





  Sogomonian                Expires 17 June 2026                  [Page 1]


  Internet-Draft              AIIP Architecture              December 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
     3.  Native Autonomous Access Model  . . . . . . . . . . . . . . .   3
     4.  Discovery and Delegation Metadata . . . . . . . . . . . . . .   3
       4.1.  DNS Bootstrap Discovery . . . . . . . . . . . . . . . . .   3
       4.2.  HTTPS Metadata Discovery  . . . . . . . . . . . . . . . .   4
       4.3.  Delegation Statements . . . . . . . . . . . . . . . . . .   4
     5.  Native Envelope Framing . . . . . . . . . . . . . . . . . . .   4
       5.1.  Byte Order  . . . . . . . . . . . . . . . . . . . . . . .   4
       5.2.  32-Byte Header  . . . . . . . . . . . . . . . . . . . . .   4
     6.  Execution Receipts  . . . . . . . . . . . . . . . . . . . . .   5
     7.  Use Case: Autonomous Delegation . . . . . . . . . . . . . . .   6
     8.  HTTPS Gateway Profile . . . . . . . . . . . . . . . . . . . .   7
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     12. Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     AIIP provides a uniform address space and invocation model for AI
     resources with verifiable outcomes.  The architecture follows a
     resolve-invoke-receipt pattern.

     Autonomous systems communicate natively using AIIP envelopes over
     authenticated transports.  Human operators and supervisory systems
     can access AIIP resources via HTTPS gateways for compatibility with
     Web-based tools.

     This revision adds discovery metadata (DNS bootstrap plus HTTPS well-
     known) and an autonomous delegation use case.

     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] and
     [RFC8174].





  Sogomonian                Expires 17 June 2026                  [Page 2]


  Internet-Draft              AIIP Architecture              December 2025


  2.  Architectural Overview

     AIIP separates addressing, invocation, and verification into distinct
     steps: (1) discovery and resolution provide invocation metadata; (2)
     invocation is carried in a native AIIP envelope; (3) the response
     includes an execution receipt that can be verified independently.

  3.  Native Autonomous Access Model

     Autonomous systems, including robots, industrial controllers, agents,
     and embedded devices, use AIIP natively.  In native mode, AIIP
     envelopes are exchanged directly between client and resource over an
     authenticated transport such as mutual TLS or QUIC.

     Native AIIP invocation does not depend on HTTP semantics, cookies, or
     browser-originated state.  Authorization, policy enforcement, and
     result verification are defined by AIIP.

     Human operators and management interfaces typically interact with
     AIIP resources through HTTPS gateways.  These gateways provide
     compatibility with Web-based clients but are not required for
     autonomous operation.

  4.  Discovery and Delegation Metadata

     AIIP supports decentralized discovery using two complementary
     mechanisms: DNS-based bootstrap discovery and HTTPS-based detailed
     metadata retrieval.  This design avoids reliance on any single global
     resolver by allowing each administrative domain to publish its own
     resolution parameters and delegation information.

  4.1.  DNS Bootstrap Discovery

     For an AIIP identifier whose authority is a DNS name (for example,
     aiip://service.example/...), an implementation MAY perform bootstrap
     discovery by querying a DNS TXT record under _aiip.service.example.

     The TXT record value is a semicolon-separated set of key/value
     parameters.  At a minimum, it SHOULD include an endpoint parameter
     indicating where detailed metadata can be retrieved.

     Example:

     _aiip.service.example.  IN TXT  "v=aiip1; endpoint=https://service.example/.well-known/aiip"

     The DNS record is intended for bootstrap only.  Implementations
     SHOULD treat HTTPS metadata (Section Section 4.2) as authoritative
     when available.



  Sogomonian                Expires 17 June 2026                  [Page 3]


  Internet-Draft              AIIP Architecture              December 2025


  4.2.  HTTPS Metadata Discovery

     An implementation MAY retrieve detailed AIIP metadata from the HTTPS
     well-known resource /.well-known/aiip on the authority host (see
     [RFC8615]).  The retrieved document can provide resolver endpoints,
     verification keys or key references, and policy signals required to
     validate invocation metadata.

     The well-known document MUST be fetched over HTTPS and its
     authenticity and integrity MUST be validated using standard HTTPS
     server authentication.

     If both DNS bootstrap discovery and HTTPS metadata discovery are
     available, implementations SHOULD use the DNS record only to locate
     the HTTPS metadata.

  4.3.  Delegation Statements

     Discovery metadata MAY include delegation statements allowing an
     administrative domain to delegate subsets of its AIIP namespace or
     specific capabilities to other parties.  Clients and resolvers MUST
     validate delegation chains prior to accepting invocation metadata
     derived from delegated authority.

  5.  Native Envelope Framing

     AIIP invocations are carried in a byte-framed envelope suitable for
     native machine-to-machine transports.  The wire format defined here
     is transport-agnostic: authenticated transports provide
     confidentiality and channel security, while the AIIP envelope
     provides a stable framing and replay-resistant metadata.

  5.1.  Byte Order

     All multi-octet integer fields are encoded in network byte order
     (big-endian).  Unless otherwise specified, fields are unsigned.

  5.2.  32-Byte Header

     An AIIP message is encoded as: Wire = Header(32) ||
     Payload(PayloadLen) || Signature(SigLen).  The header is exactly 32
     octets.









  Sogomonian                Expires 17 June 2026                  [Page 4]


  Internet-Draft              AIIP Architecture              December 2025


       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
      +-------------------------------+-------------------------------+
      |          Magic "AIIP"         | VerMaj|VerMin|   Flags (16)    |
      +-------------------------------+-------------------------------+
      |          PayloadLen (32)      |           SigLen (16)         |
      +-------------------------------+-------------------------------+
      |                         Nonce (64)                            |
      +---------------------------------------------------------------+
      |                      TimestampMs (64)                         |
      +---------------------------------------------------------------+
     Bytes:  0..3   Magic (0x41 49 49 50)
             4      VerMaj (this document: 1)
             5      VerMin (this document: 0)
             6..7   Flags
             8..11  PayloadLen
             12..13 SigLen
             14..15 Rsv16 (MUST be 0)
             16..23 Nonce
             24..31 TimestampMs

                    Figure 1: AIIP Header Layout (32 bytes)

     No reserved fields exist beyond the fixed 32-byte header; the
     signature bytes follow the payload.

     Flags is a 16-bit bitmask.  Bit 0 (0x0001) indicates that the
     requester requires a receipt in the response.  Other bits are
     reserved for future use.

     Example header bytes (illustrative only):

     41 49 49 50  01 00  00 01  00 00 00 9C  00 40  00 00
     2F 7A 13 44  9B 02 5D 8A  00 00 01 93  8F 4C 3A 10

     Payload is UTF-8 JSON.  Binary fields (when needed) are represented
     using base64url strings.

  6.  Execution Receipts

     Each successful invocation produces an execution receipt that can be
     verified independently of transport intermediaries.  Receipts bind
     the invocation identifier, relevant policy context, and execution
     outcome.

     This document illustrates a JWS-based receipt container ([RFC7515]).
     The specific receipt schema is expected to evolve with implementation
     experience.



  Sogomonian                Expires 17 June 2026                  [Page 5]


  Internet-Draft              AIIP Architecture              December 2025


     Illustrative receipt container:

     {
       "protected": "base64url(jws-protected-header)",
       "payload": {
         "txid": "b7f7cfd2-6c38-4d7a-8e5a-6f1e1d9e0a10",
         "ts": 1734149100000,
         "result": { "status": 200, "data_commitment": "base64url(hash)" },
         "policy": { "max_speed_mps": 0.5, "forbidden_zones": ["Z1", "Z2"] },
         "attestation": { "tee": "base64url(attestation-evidence)" }
       },
       "signature": "base64url(jws-signature)"
     }

     Receipt structure sketch (informative, ASN.1-like):

     AIIP-Receipt ::= SEQUENCE {
       txid            UUID,
       ts              INTEGER,            -- milliseconds since epoch
       resultCommit    OCTET STRING,       -- hash/commitment
       policy          SEQUENCE OF UTF8String OPTIONAL,
       attestation     OCTET STRING OPTIONAL,
       sigAlg          OBJECT IDENTIFIER,
       signature       OCTET STRING
     }

  7.  Use Case: Autonomous Delegation

     AIIP enables explicit delegation of real-world actions to autonomous
     agents without disclosure of user credentials and without interactive
     authorization at execution time.  A user may delegate a capability
     (for example, aiip://user.phone/call) to an AI agent once, under
     defined policy constraints.

     After delegation, any authorized AI agent may invoke the delegated
     capability directly using AIIP.  Invocation does not require access
     to passwords, OAuth tokens, or user sessions.  Each execution
     produces a verifiable receipt binding the user’s authorization, the
     invoked action, and the execution outcome.

     Example invocation:

     aiip://user.phone/call?to=+15551234567&text=I'm+late








  Sogomonian                Expires 17 June 2026                  [Page 6]


  Internet-Draft              AIIP Architecture              December 2025


     The resulting execution receipt provides non-repudiable evidence that
     the user authorized the action and that it was executed as requested.
     This delegation model enables autonomous agents to perform actions
     such as calls, messages, device control, or payments without exposing
     credentials or requiring repeated user interaction.

  8.  HTTPS Gateway Profile

     An HTTPS gateway translates Web-based requests into AIIP invocations
     and returns results with receipts to human-facing clients.

     The HTTPS gateway is a compatibility layer for human operators and
     MUST NOT be required for autonomous or machine-to-machine AIIP
     invocation.

  9.  Security Considerations

     AIIP implementations MUST authenticate peers via the selected
     transport binding, prevent replay, and ensure integrity of invocation
     and receipt data.

     Execution receipts provide non-repudiable evidence of authorization
     and execution, suitable for audit, dispute resolution, and legal
     review.

  10.  Privacy Considerations

     Implementations SHOULD minimize retained metadata and avoid
     correlating invocations beyond what is required for verification.
     Delegations SHOULD be scoped minimally to avoid over-exposure of
     capabilities or metadata.

  11.  IANA Considerations

     This document makes no IANA requests.  Future revisions may request
     registration of well-known resources used for AIIP discovery.

  12.  Normative References

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

     [RFC7515]  Jones, M.B., "JSON Web Signature (JWS)", RFC 7515, May
                2015, <https://www.rfc-editor.org/info/rfc7515>.






  Sogomonian                Expires 17 June 2026                  [Page 7]


  Internet-Draft              AIIP Architecture              December 2025


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

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, May 2019,
                <https://www.rfc-editor.org/info/rfc8615>.

  Author's Address

     Aram Sogomonian
     Artificial Intelligence Internet Foundation (AIIF)
     United States of America
     Email: aiinternetfoundation@icloud.com
     (mailto:aiinternetfoundation@icloud.com)

  Author's Address

     Aram Sogomonian
     Artificial Intelligence Internet Foundation (AIIF)
     United States of America
     Email: aiinternetfoundation@icloud.com





























  Sogomonian                Expires 17 June 2026                  [Page 8]


name: draft-moreno-lisp-uberlay
rev: 07
title: Uberlay Interconnection of Multiple LISP overlays
time: 2025-10-09T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-09T16:38:42Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.541080+00:00
source: ietf
source_id: 87374
source_url: https://datatracker.ietf.org/doc/draft-moreno-lisp-uberlay/
doc_status: active
abstract:
  This document describes the use of the Locator/ID Separation Protocol
     (LISP) to interconnect multiple disparate and independent network
     overlays by using a transit overlay.  The transit overlay is referred
     to as the "uberlay" and provides connectivity and control plane
     abstraction between different overlays.  Each network overlay may use
     different control and data plane approaches and may be managed by a
     different organization.  Structuring the network into multiple
     network overlays enables the interworking of different overlay
     approaches to data and control plane methods.  The different network
     overlays are autonomous from a control and data plane perspective,
     this in turn enables failure survivability across overlay domains.
     This document specifies the mechanisms and procedures for the
     distribution of control plane information across overlay sites and in
     the uberlay as well as the lookup and forwarding procedures for
     unicast and multicast traffic within and across overlays.  The
     specification also defines the procedures to support inter-overlay
     mobility of EIDs and their integration with the intra-overlay EID
     mobility procedures defined in draft-ietf-lisp-eid-mobility.

full_text:
  Network Working Group                                          V. Moreno
  Internet-Draft                                                Google LLC
  Intended status: Experimental                               D. Farinacci
  Expires: 9 October 2025                                      lispers.net
                                                        A. Rodriguez-Natal
                                                       M. Portoles-Comeras
                                                                  F. Maino
                                                                  S. Hooda
                                                             Cisco Systems
                                                              7 April 2025


             Uberlay Interconnection of Multiple LISP overlays
                        draft-moreno-lisp-uberlay-07

  Abstract

     This document describes the use of the Locator/ID Separation Protocol
     (LISP) to interconnect multiple disparate and independent network
     overlays by using a transit overlay.  The transit overlay is referred
     to as the "uberlay" and provides connectivity and control plane
     abstraction between different overlays.  Each network overlay may use
     different control and data plane approaches and may be managed by a
     different organization.  Structuring the network into multiple
     network overlays enables the interworking of different overlay
     approaches to data and control plane methods.  The different network
     overlays are autonomous from a control and data plane perspective,
     this in turn enables failure survivability across overlay domains.
     This document specifies the mechanisms and procedures for the
     distribution of control plane information across overlay sites and in
     the uberlay as well as the lookup and forwarding procedures for
     unicast and multicast traffic within and across overlays.  The
     specification also defines the procedures to support inter-overlay
     mobility of EIDs and their integration with the intra-overlay EID
     mobility procedures defined in draft-ietf-lisp-eid-mobility.

  Requirements Language

     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].


  Status of This Memo

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




  Moreno, et al.           Expires 9 October 2025                 [Page 1]


  Internet-Draft                LISP Uberlay                    April 2025


     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 9 October 2025.

  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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
     3.  Interconnecting multiple LISP site-overlays via the
             Uberlay . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Logical Topology Considerations . . . . . . . . . . . . .   7
     4.  General Procedures  . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Control Plane Procedures  . . . . . . . . . . . . . . . .   9
         4.1.1.  Split-horizon at the Border xTRs  . . . . . . . . . .  10
         4.1.2.  Border-xTR Resiliency . . . . . . . . . . . . . . . .  11
       4.2.  Resolution and Forwarding Procedures  . . . . . . . . . .  12
         4.2.1.  Multi-overlay requests at border xTR  . . . . . . . .  13
       4.3.  Default EID registration and treatment  . . . . . . . . .  14
     5.  Multicast Specific Procedures . . . . . . . . . . . . . . . .  14
       5.1.  Inter-site-overlay Control Plane Procedures for Signal-free
             multicast . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.2.  Border xTR Resolution and Forwarding procedures for
             Signal-free multicast . . . . . . . . . . . . . . . . . .  15
     6.  Inter site-overlay Mobility Procedures  . . . . . . . . . . .  16
     7.  Virtual Private Network (VPN) Considerations  . . . . . . . .  17
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18



  Moreno, et al.           Expires 9 October 2025                 [Page 2]


  Internet-Draft                LISP Uberlay                    April 2025


     9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       10.2.  Informative References . . . . . . . . . . . . . . . . .  18
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

  1.  Introduction

     The main motivation for this specification is to provide a
     methodology for the interconnection of LISP domains that may use
     disparate control and/or data plane approaches.  For instance, one
     domain may use native LISP encapsulation for its data plane and a DDT
     based mapping system, while another domain may use VXLAN-GPE
     encapsulation and a mapping system based on
     [I-D.farinacci-lisp-decent].  Furthermore, one domain may use an IPv4
     RLOC space and the other domain may use an IPv6 RLOC space and there
     may not be connectivity between the domains at the RLOC level.  We
     propose a method to interconnect and enable interoperability between
     these disparate LISP overlay networks by connecting them to a common
     transit LISP overlay.

     In order to provide interworking across implementations of overlays
     that may use different control and data plane approaches, a LISP
     network may be structured as a collection of site-overlays
     interconnected by a transit area.  Each site-overlay is a fully
     functional overlay network and has its own set of Map Servers and Map
     Resolvers.  Site-overlays share a border xTR with a transit area.
     Connectivity between site-overlays is provided via the transit area
     which we will refer to as “The Uberlay”. This specification describes
     the Control Plane and Forwarding procedures for the implementation of
     an Uberlay connected multi-overlay LISP network.  This approach to
     the structure of a LISP network may also enable regional failure
     survivability and fault isolation.

  2.  Definition of Terms

     LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
     Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
     Resolver (MR) are defined in the LISP specifications [RFC9300] and
     [RFC9301].

     Terms defining interactions with the LISP Mapping System are defined
     in [RFC9301].

     Terms related to the procedures for signal free multicast are defined
     in [RFC8378].





  Moreno, et al.           Expires 9 October 2025                 [Page 3]


  Internet-Draft                LISP Uberlay                    April 2025


     The following terms are here defined to facilitate the descriptions
     and discussions within this particular document.

     Site-Overlay - Overlay network at a specific area or domain.  This
     overlay network has a dedicated Mapping System.

     Border-xTR - xTR that connects a site-overlay to one or more
     uberlays.

     xTR - LISP Tunnel Router as defined in [RFC9301].  An xTR connects
     end-points to the site-overlay.

     Local Mapping System - Mapping system of the site-overlay

     Uberlay - Overlay network that interconnects different site-overlays
     to each other.  The Uberlay has a dedicated Mapping System and
     creates an overlay amongst the border xTRs which connect different
     site-overlays.

     Uberlay Mapping System - Autonomous mapping system dedicated to the
     uberlay.

     Site-Overlay EIDs - Also referred to as local site-overlay EIDs,
     these are the EIDs that are connected to xTRs in a particular site-
     overlay and are registered in their own local site-overlay mapping
     system.  These EIDs will also be registered in the uberlay but not in
     the remote site-overlay mapping systems.

     Remote site-overlay EIDs - These are EIDs connected and registered in
     site-overlays other than the local site-overlay.

     Local site-overlay EIDs - These are EIDs connected and registered in
     the local site-overlay.

  3.  Interconnecting multiple LISP site-overlays via the Uberlay

     A LISP network can be structured as a collection of LISP site-
     overlays that are interconnected by one or more LISP Uberlays.

     A LISP site-overlay is an overlay network that has its own set of
     xTRs, its own dedicated Mapping System and it may have a dedicated
     RLOC space, separate from that of other site-overlays or the uberlay.
     A LISP uberlay is also an overlay network with its own set of xTRs,
     its own dedicated Mapping System and it may have its own dedicated
     RLOC space.  When the RLOC spaces are dedicated, RLOC routes in the
     local underlay do not leak across to the underlay of other site-
     overlays.




  Moreno, et al.           Expires 9 October 2025                 [Page 4]


  Internet-Draft                LISP Uberlay                    April 2025


     A site-overlay will have xTRs and Border xTRs.  The xTRs provide
     connectivity to the local site-overlay EIDs, which are the EIDs that
     are locally connected to the overlay-site.  The Border xTRs are Re-
     encapsulating Tunnel Routers (RTRs) that connect the site-overlays to
     the LISP Uberlay in the transit network. xTRs participate in one
     site-overlay and one site-overlay only.  Border xTRs participate in
     the mapping system of the site-overlay it resides in and the mapping
     system of the uberlay it connects the site-overlay to.  Border xTRs
     may be shared by more than one site-overlay.

     The different site-overlays can be interconnected by an uberlay.  The
     uberlay consists of a dedicated Mapping System and the set of Border
     xTRs that connect the participating site-overlays to the Uberlay and
     the Uberlay Mapping System.

     Each site-overlay will have its own set of Map Servers and Map
     Resolvers (MS/MRs) which operate as an autonomous Mapping System.
     The Uberlay Mapping System is also autonomous and includes all
     necessary Map Servers and Map Resolvers.  Any of the Mapping Systems,
     in site-overlays or in the Uberlay, follow the control plane
     specification in [RFC9301] and may be structured as a Distributed
     Delegation Tree (DDT) per [RFC8111]for the purposes of horizontal
     scaling or other optimizations within each Mapping System.

     The MS/MRs can be co-located with the border-xTRs of the site-overlay
     When a Border xTR services more than one site-overlay, and the MS/MRs
     are instantiated on the Border xTR, logical instances of MS/MRs must
     be dedicated to each site-overlay.

     This specification defines the interaction between the Mapping
     Systems of the site-overlays and the uberlay to deliver a multi-
     overlay hierarchical network.  The forwarding procedures relevant to
     the border xTRs are also specified.  Figure 1 illustrates the multi-
     overlay network.

















  Moreno, et al.           Expires 9 October 2025                 [Page 5]


  Internet-Draft                LISP Uberlay                    April 2025


     +-------------------------------+
     |  +-----+   +-----+   +-----+  |
     |  | xTR |   | xTR |   | xTR |  |
     |  +-----+   +-----+   +-----+  |
     |                               |
     |                     +-------+ |   RLOC space 1
     |    Site Overlay 1   | MS/MR | |   (underlay 1)
     |                     +-------+ |
     |                               |
     |                               |
     |     +--------+  +--------+    |
     +-----| Border |--| Border |----+
     +-----|  xTR   |--|  xTR   |----+
     |     +--------+  +--------+    |
     |                               |
     |                               |
     |                               |
     |                     +-------+ |       Uberlay
     |     Uberlay         | MS/MR | |     RLOC Space
     |                     +-------+ |  (Transit Underlay)
     |                               |
     |                               |
     |         +----------+          |
     +---------|  Border  |----------+
     +---------|   xTR    |----------+
     |         +----------+          |
     |                               |
     |                     +-------+ |   RLOC space 2
     |    Site Overlay 2   | MS/MR | |   (underlay 2)
     |                     +-------+ |
     |                               |
     |  +-----+   +-----+   +-----+  |
     |  | xTR |   | xTR |   | xTR |  |
     |  +-----+   +-----+   +-----+  |
     +-------------------------------+


     Figure 1. Site-overlays connected via Uberlay

     Structuring the LISP network as multiple site-overlays interconnected
     by an uberlay delivers the following benefits:

     *  Enable the interworking of diverse site-overlay implementations in
        which different mapping systems and encapsulations may be used.

     *  Enhanced resiliency through regional failure survivability.
        Failures in one site-overlay or failures in a portion of the
        underlay should not affect other site-overlays.



  Moreno, et al.           Expires 9 October 2025                 [Page 6]


  Internet-Draft                LISP Uberlay                    April 2025


     *  Reduce the state of the site-overlay control plane.  The site-
        overlay control plane will only maintain state for EIDs that are
        connected to xTRs within the site-overlay These EIDs are referred
        to as local site-overlay EIDs in this specification.  Remote site-
        overlay EIDs will not be explicitly registered within the site-
        overlay.

     *  Separate the RLOC space of the different site-overlays as well as
        the uberlay RLOC space.  Each site-overlay will only need
        reachability to its own RLOCs, making the RLOCs private to the
        site-overlay Similarly, the uberlay RLOC space does not require
        knowledge of site-overlay specific RLOCs.  This simplifies the
        underlay routing protocol structure and reduces the state that
        must be handled and maintained by the underlay routing protocols.

     *  Reduced latency for local site-overlay EID registrations may be
        achieved when xTRs and Map Servers are topologically close.
        Topological proximity is expected when the RLOC spaces for the
        different overlays are kept separate.

     *  Reduced latency for local site-overlay EID lookups may be achieved
        when xTRs, Map Resolvers and Map Servers are topologically close.
        Topological proximity is expected when the RLOC spaces for the
        different overlays are kept separate.

     *  Creates a multicast replication hierarchy where the Border RTRs
        serve as the points of multicast replication for multicast traffic
        that spans multiple site-overlays.

     *  Creates a distributed structure of RTRs that can be leveraged for
        the deployment of NAT traversal in the RLOC space.


  3.1.  Logical Topology Considerations

     xTRs as defined in RFC9301 connect a network to the LISP overlay and
     register the EID prefixes from the connected network to the LISP
     mapping system.  Border xTRs, as defined in this document, will
     connect site-overlays to the Uberlay and register the EID prefixes
     that originate in a site-overlay in the Mapping System of the
     Uberlay.  Conversely, a border xTR may register EID prefixes present
     in the Uberlay Mapping System into the Mapping System of a particular
     site-overlay.  Furthermore, border xTRs may connect Uberlays to each
     other and register the EID prefixes from one Uberlay into the other.
     There is no provision for the detection of registration loops when
     concatenating site-overlays and Uberlays, thus any interconnection of
     overlay domains (site-overlays or Uberlays) must be done in a loop
     free topology.



  Moreno, et al.           Expires 9 October 2025                 [Page 7]


  Internet-Draft                LISP Uberlay                    April 2025


     A loop free topology is hereby defined for reference.  This is a
     general concept and is not encoded into any of the protocol messages
     in LISP.  A loop free topology limits the peerings between Uberlays
     and/or overlays to a strict hierarchy.  At the top of the hierarchy
     is a single central Uberlay or Core Uberlay.  The loop free topology
     is defined by two simple rules: Uberlays must only connect to
     Uberlays in the next consecutive level of hierarchy (no level
     skipping) and uberlays within the same level of hierarchy must not
     connect to each other.  The loop-free topology hierarchy is
     illustrated in Figure 2.

     +----------------+                  +----------------+
     | site-overlay 1 |                  | site-overlay 2 |
     |    (Level 2)   |                  |    (Level 2)   |
     +----------------+                  +----------------+
               +---+                        +---+
               |RTR|                        |RTR|
               +---+                        +---+
            +-----------+             +-----------+
            | Uberlay 1 |             | Uberlay 2 |
            | (Level 1) |             | (Level 1) |
            +-----------+             +-----------+
                      +---+         +---+
                      |RTR+---------+RTR|
                      +--++         ++--+
                         |   Core    |
                         |  Uberlay  |
                         | (Level 0) |
                      +--++         ++--+
                      |RTR+---------+RTR|
                      +---+         +---+
            +-----------+             +-----------+
            | Uberlay 3 |             | Uberlay 4 |
            | (Level 1) |             | (Level 1) |
            +-----------+             +-----------+
               +---+                        +---+
               |RTR|                        |RTR|
               +---+                        +---+
     +----------------+                 +----------------+
     | site-overlay 3 |                 | site-overlay 4 |
     |    (Level 2)   |                 |    (Level 2)   |
     +----------------+                 +----------------+

     Figure 2. Loop-free topology hierarchy







  Moreno, et al.           Expires 9 October 2025                 [Page 8]


  Internet-Draft                LISP Uberlay                    April 2025


  4.  General Procedures

     A site-overlay maintains state only for its local site-overlay EIDs
     and RLOCs.  Tunnels never cross site-overlay or uberlay boundaries.
     Remote site-overlay EIDs are reachable at the source site-overlay via
     a default mapping which will steer all traffic destined to remote
     site-overlay EIDs to the border xTRs where it can be handed off to
     the uberlay.  Traffic will be decapsulated at the border xTRs and a
     lookup in the uberlay mapping system will determine the site-overlay
     to which traffic is to be re-encapsulated.  The uberlay maintains
     state for the EIDs of all interconnected site-overlays and will steer
     traffic from the source site-overlay to the destination site-overlay
     by encapsulating the traffic from the source site-overlay border xTR
     to the destination site-overlay border xTR.  At the border xTR of the
     destination site-overlay, traffic will be de-capsulated, a lookup in
     the local destination site-overlay Mapping System will take place and
     traffic will be re-encapsulated to the xTR that connects to the
     destination EID.  Thus, forwarding is achieved by concatenating
     overlays and doing Re-encapsulation at the border xTRs to forward the
     traffic from the Ingress site-overlay to the Egress site-overlay via
     the Uberlay.

     Traffic for non-LISP sites, or for EIDs not registered in any site-
     overlay, will also be forwarded to the border xTR where it will be
     forwarded or dropped as appropriate.

  4.1.  Control Plane Procedures

     Local EIDs must be registered by the xTRs into the local Mapping
     System of the site-overlay.  Intra-site communication follows the
     standard procedures of registration, resolution, caching and
     encapsulation defined in [RFC9300] and [RFC9301] amongst the xTRs
     within the local site-overlay.

     The border xTRs at a site-overlay should have a local site-overlay
     RLOC-set and will also have an uberlay RLOC-set.  The local site-
     overlay RLOC-set is in the private site-overlay RLOC space and is
     used by the border xTRs as the RLOC set for any mappings it may
     register with the site-overlay Mapping System.  The uberlay RLOC-set
     for the border-xTRs of a particular site-overlay are the RLOCs to
     reach the site-overlay in the uberlay RLOC space.  The border xTR
     will use the uberlay RLOC-set in any mappings it may register with
     the uberlay Mapping System.  It is possible for a deployment to
     connect the RLOC spaces of the site-overlays and the uberlay, it is
     also possible in the scenario of a common RLOC space for the uberlay
     and local site-overlay RLOC sets to be one and the same.  Any
     implementation of this specification should support disjoint RLOC
     spaces or joint RLOC spaces.



  Moreno, et al.           Expires 9 October 2025                 [Page 9]


  Internet-Draft                LISP Uberlay                    April 2025


     The border xTRs must register a default EID-prefix as specified in
     Section 4.3 with the local site-overlay Mapping System.  Remote EIDs
     will be generally reachable by xTRs in a site-overlay using the
     default EID mapping registered by the border xTRs.  This is expected
     to be the mapping used for most communications to remote site-overlay
     EIDs.  Remote site-overlay EIDs may be registered with the local
     site-overlay Mapping System for the purposes of supporting inter-
     overlay EID mobility as specified in Section 6, these mappings will
     be preferred over the default EID mapping whenever present.

     Local EIDs registered with the site-overlay mapping system must also
     be registered with the Uberlay Mapping System.  The registration of
     the local site-overlay EIDs with the uberlay Mapping System is
     originated by the Border xTRs.  The local site-overlay EIDs SHOULD be
     aggregated into the shortest covering prefix possible before being
     registered with the uberlay Mapping System.  How this aggregation is
     achieved is implementation specific.

     In order to be able to register the local site-overlay EIDs with the
     uberlay Mapping System, the border xTRs must subscribe to all EIDs
     registered in their local site-overlay Mapping System.  This is a
     subscription to 0.0.0.0/0 (or 0::/0) with the N-bit set as specified
     in [RFC9437].  The subscription populates all local site-overlay EID
     mappings in the map-cache of the border xTRs.

     Once received through the subscription, the local site-overlay EIDs
     in the map-cache at the border xTRs must be registered by the border
     xTRs with the uberlay Mapping System.  The local site-overlay EIDs
     will be registered using the 'uberlay' RLOC-set for the registering
     border xTR.

     Following [I-D.ietf-lisp-eid-mobility], the border xTRs will also
     subscribe to any EID prefixes it registers with the uberlay Mapping
     System.  This allows the border xTRs to get Map Notify messages from
     the uberlay Mapping System for EID prefixes that may move from their
     local site-overlay to a remote site-overlay.

  4.1.1.  Split-horizon at the Border xTRs

     Remote site-overlay EIDs may be learnt at a border xTR due to
     resolution of a remote destination EID or due to a mobility event as
     specified in Section 6.  Remote site-overlay EIDs learnt from the
     uberlay will be installed in the map-cache of the border xTR with the
     corresponding remote uberlay RLOC-set for the remote border xTR.
     When these remote site-overlay EIDs are learnt as a consequence of
     the map-notify messages defined in the Inter-overlay mobility
     procedures in Section 6, the EIDs will also be registered with the
     local site-overlay mapping system using the local site-overlay RLOC-



  Moreno, et al.           Expires 9 October 2025                [Page 10]


  Internet-Draft                LISP Uberlay                    April 2025


     set for the border-xTR.  The remote site-overlay EIDs registered with
     the local site-overlay mapping system will be learnt back at the
     border xTR because of the border xTR's subscription to all local
     site-overlay EIDs.  This can cause the mapping for the remote EID
     that is installed in the border xTR map-cache to flip flop between
     the uberlay RLOC-set and the local site-overlay RLOC-set.

     In order to avoid this flip flopping a split horizon procedure must
     be implemented.  When a mapping received at the border xTR (as part
     of its subscription to all local site-overlay EID prefixes) has the
     local site-overlay RLOC-set for the border xTR, the mapping received
     in the subscription corresponds to a remote site-overlay EID and
     should be ignored by the border xTR.  The mapping should not be
     installed in the map-cache of the border xTR and the EIDs in the
     mapping should not be advertised to the uberlay.  More robust split
     horizon mechanisms can be proposed in future revisions of this
     specification.

  4.1.2.  Border-xTR Resiliency

     Redundancy at the border xTRs requires that border xTRs be logically
     grouped so that the redundant array doesn’t create a registration
     loop.  As border xTRs interconnect overlay domains, the border xTRs
     will register the EID prefixes from one domain into the neighboring
     domain.  From the perspective of the border xTR, the EID prefixes to
     be registered in one domain are learnt from a neighbor domain which
     we will refer to as the "site-of-origin".  The site-of-origin may be
     an overlay-site, an Uberlay or an IP network.

     Border xTRs should be logically grouped in Border Sets.  A border set
     is a group of border xTRs that register EID prefixes from the same
     site-of-origin.  Members of a border set will register the EIDs from
     a particular site-of-origin into the neighboring overlay (site-
     overlay or uberlay) using a common site-id.  The use of the site-ID
     namespace is locally significant to each overlay domain (site-overlay
     or Uberlay) and does not require cross-domain synchronization or
     dispersion.  A border-xTR may be a member of multiple border sets to
     allow different site-of-origin domains to be serviced by the border-
     xTR.  Note that not all site-of-origin domains will connect to the
     same combination of border-xTRs.











  Moreno, et al.           Expires 9 October 2025                [Page 11]


  Internet-Draft                LISP Uberlay                    April 2025


     EID Mappings will be tagged with a site-ID according to their site-
     of-origin when they are registered by the border-xTR.  The site-ID
     must be maintained in the Mapping System as part of the registration
     record.  EID Mappings published and received at the border xTR must
     include the site-ID for the EID Mapping.  If the border-xTR receives
     a mapping for an EID with a site-ID that matches the site-ID for one
     of its border sets (site-of-origin), the Border xTR will not register
     that information to the site-of-origin associated with that site-ID
     and thus prevent any registration loops from occurring.

  4.2.  Resolution and Forwarding Procedures

     Intra-site communication follows the standard procedures of
     registration, resolution, caching and encapsulation defined in
     [RFC9300] and [RFC9301] amongst the xTRs within the local site-
     overlay.

     Inter-site communication is achieved by encapsulating traffic
     destined to remote site-overlay EIDs from the xTRs to the border
     xTRs.  Traffic will be decapsulated at the border xTRs and a lookup
     in the uberlay mapping system will determine the site-overlay to
     which traffic is to be re-encapsulated.  The lookup should return the
     uberlay RLOCs for the border xTRs of the site-overlay where the
     destination EID is located.  At the border xTR of the destination
     overlay-site, traffic will be de-capsulated, and re-encapsulated to
     the destination xTR, just like an RTR does.  The border xTR already
     has the destination EID in its cache per its subscription to all
     local site-overlay EIDs.

     When receiving encapsulated traffic, a border xTR will de-capsulate
     the traffic and will do a lookup for the destination EID in its map
     cache.  If the destination EID is present in the map cache, the
     traffic is forwarded and no lookup takes place.  If the destination
     EID is not present in the cache, the destination EID is not in any
     local site-overlay connected to the border xTR, in which case the
     border xTR will issue a map-request to all Uberlay Mapping Systems it
     is connected to.  The criteria to determine which Mapping Systems are
     Uberlay Mapping Systems is simply to select those Mapping Systems
     with which the border xTR doesn't hold a subscription to 0.0.0.0/0
     (or 0::/0).











  Moreno, et al.           Expires 9 October 2025                [Page 12]


  Internet-Draft                LISP Uberlay                    April 2025


  4.2.1.  Multi-overlay requests at border xTR

     A Border xTR may query all Mapping Systems in all uberlays it
     participates in.  The border xTR will then chose based on longest
     prefix match the more specific EID mapping provided by any of the
     Mapping Systems.  This procedure could also include site-overlay
     Mapping Systems, however those are not expected to be queried as the
     border xTR subscribes to all EIDs in the site-overlays and the
     presence of the mappings in the cache will prevent any lookups.  The
     processing of Map Requests following the multi-domain request logic
     works as follows:

     1.  The Border xTR sends a map request for the prefix that it intends
         to resolve to each of the uberlay Mapping Systems it participates
         in.

     2.  The Border xTR receives Map Replies from each of the different
         uberlay Mapping Systems it sent requests to.  The Border xTR will
         treat the replies differently depending on their contents:

         *  Negative Map Replies (NMR) are ignored and discarded unless
            all Map Replies received are Negative, then the border xTR
            follows the procedures specified in [RFC9301] for Negative Map
            Replies.

         *  Map Replies with RLOCs that belong to the requesting border
            xTR are ignored.

         *  Map Replies with EID prefixes that are not already in the map
            cache of the border xTR are accepted and cached.

         *  If the EID prefix received in the Map-Reply already exists in
            the cache/routing table, but the Map-Reply contains a
            different RLOC-set than the one cached, the mappings are
            merged so that the RLOCs received in the Map-Reply are added
            to the RLOC-set previously cached for the EID prefix.

         *  If the EID prefix received in the Map-Reply is more specific
            or less specific than an EID prefix already cached, the
            mapping received MUST be cached.

     It is expected that a deployment of the uberlay would include the
     dynamic registration of default EIDs.  It is also recommended that an
     implementation adopts mechanisms for the dynamic resolution of
     default EIDs.  In an environment leveraging the dynamic registration
     and resolution of default EIDs, the border xTR should not receive
     Negative Map-Replies, but all replies (including those in response to
     requests for destinations that are external to the EID space) will be



  Moreno, et al.           Expires 9 October 2025                [Page 13]


  Internet-Draft                LISP Uberlay                    April 2025


     Map-replies with a non-zero locator count.  Nevertheless, an
     implementation could opt to not use dynamic default-EID handling.  In
     these cases, the border xTR will receive NMRs.  The implementation of
     the Border xTR should defer the decision on caching an NMR until all
     relevant Map-replies are received.  To this effect, the
     implementation should implement mechanisms to ensure that sufficient
     replies are received before programming the map-cache.  The
     mechanisms by which this is achieved are an implementation specific
     matter and therefore not specified in this document.

     When following these rules to process multi-domain requests, the
     Border xTR guarantees proper discovery and use of destination
     prefixes that will be associated with their corresponding overlay-
     site.  By ignoring the negative replies the procedure works
     regardless of whether the Mapping Systems of multiple uberlays have
     consistent configurations or operate individually without being aware
     of the whole addressing space in the overlay fabric.

  4.3.  Default EID registration and treatment

     Border xTRs will register a mapping to be used as a default mapping
     to handle the forwarding of traffic destined to any EIDs that are not
     explicitly registered.  These mappings will be registered in the
     local site-overlay Mapping System of each site-overlay.  The RLOCs
     for the mappings will be the site-overlay RLOCs of the border xTR.
     This registration is intended to instruct the Mapping System to
     follow the procedures in [RFC9301] for Negative Map Replies and
     calculate the broadest non-registered EID prefix that includes the
     requested destination EID and issue a map-reply with the calculated
     EID and the RLOCs registered by the border xTRs.  The map-reply for
     this default mapping will have a shorter TTL to accommodate any
     changes in the registrations.

     The instruction to the Mapping System can be encoded as the
     registration of an agreed upon distinguished name [RFC9735] such as
     "Default".  The registration will contain the RLOC set desired for
     the default handling.

  5.  Multicast Specific Procedures

     This specification will focus on the procedures necessary to extend
     signal-free multicast [RFC8378] across multiple site-overlays
     interconnected with an uberlay.  The specification will focus on the
     extensions of the Sender and Receiver site procedures







  Moreno, et al.           Expires 9 October 2025                [Page 14]


  Internet-Draft                LISP Uberlay                    April 2025


  5.1.  Inter-site-overlay Control Plane Procedures for Signal-free
        multicast

     1.  At the listener sites, xTRs with multicast listeners will follow
         the receiver site procedures described in [RFC8378].  A
         replication list will be built and registered on the site-overlay
         Mapping System for the multicast channel being joined by the
         listeners.

     2.  The Mapping System for the listener site-overlay will send Map-
         Notify messages towards the multicast source or RP per [RFC8378].
         The multicast source or RP is reachable via the border-xTRs of
         the listener site-overlay via the default EID mapping registered
         in the listener site-overlay.

     3.  Upon reception of the Map-Notify in the previous step, the
         listener site-overlay border-xTR will register the multicast EID
         with the uberlay Mapping System using the uberlay RLOCs for its
         site-overlay as the RLOC set for the mapping being registered.
         Only one of the RLOCs in the set should be active in the
         registration per the procedures in [RFC8378].  A replication tree
         is built in the uberlay as specified in [RFC8378].

     4.  After the listener site-overlay border-xTR registers the
         multicast EID with the uberlay Mapping system, the uberlay MS
         will send a Map-Notify toward the multicast source per [RFC8378]

     5.  Upon reception of the Map-Notify in the previous step, the border
         xTR at the source site-overlay registers its interest in the
         multicast EID with the source site-overlay Mapping System
         following the procedures described in [RFC8378].

  5.2.  Border xTR Resolution and Forwarding procedures for Signal-free
        multicast

     The mapping resolution procedures for multicast EIDs at border xTRs
     fall within the scope of the mechanisms specified in Section 4.  The
     Map-replies obtained from the lookup will follow the behavior
     specified in [RFC8378] for signal-free multicast.

     Forwarding will also follow the General Procedures specified in
     Section 4 without alteration.  It is worth noting that the
     concatenation of overlays between listener sites, uberlay and sender
     site-overlays creates a convenient replication structure where the
     border xTRs act as the replication points to form an optimized end-
     to-end multi-level replication tree.





  Moreno, et al.           Expires 9 October 2025                [Page 15]


  Internet-Draft                LISP Uberlay                    April 2025


  6.  Inter site-overlay Mobility Procedures

     The receiver and sender site procedures defined in
     [I-D.ietf-lisp-eid-mobility] apply without change to each site-
     overlay and to the uberlay.  Border xTRs are connected to two or more
     overlay networks which are following the mobility procedures.  An
     away table is defined at the border xTR for each overlay network it
     participates in.  In order to illustrate the procedures required,
     this specification describes a scenario where a border xTR has one
     local site-overlay away table and one uberlay facing away table.  The
     procedures for mobility described in this section are extensible to
     border xTRs participating in more than two overlays.

     When a map notify for an EID is received at an xTR, an away entry is
     created on the receiving side table.  Any away entries for the
     specific EID in other tables on the same LISP node (xTR or RTR) must
     be removed.  This general rule addresses convergence necessary for a
     first move as well as any subsequent moves (moves that take place
     after the away tables are already populated with entries for the
     moving EID due to previous moves).

     The following set of procedures highlights any additions to the
     mobility procedures defined in [I-D.ietf-lisp-eid-mobility]:

     1.   Detect the roaming EID per the mechanisms described in
          [I-D.ietf-lisp-eid-mobility] and register the EID with the site-
          overlay Mapping System at the landing site-overlay

     2.   The site-overlay Mapping System at the landing site-overlay must
          send a Map-Notify to the last registrant xTR (if it is local to
          the site-overlay) and to the border xTR as the border xTR
          subscribes to all EIDs in the site-overlay.

     3.   The border xTR will install an entry for the moved host in the
          local away table of the border xTR.

     4.   The border xTR from the landing site-overlay will register the
          roaming EID with the uberlay Mapping System using the uberlay
          RLOC-set for the landing site-overlay

     5.   The Uberlay Map Server will send Map-Notify messages to the
          border xTRs at the departure site-overlay as specified in
          [I-D.ietf-lisp-eid-mobility] (border xTR with the previously
          registered RLOCs).







  Moreno, et al.           Expires 9 October 2025                [Page 16]


  Internet-Draft                LISP Uberlay                    April 2025


     6.   Upon reception of the Map-Notify, the border xTR must check if
          the Map-Notify is for an EID-prefix that is covered by a broader
          or equal EID-prefix that is locally registered.  Local
          registration is determined by the presence of the broader or
          equal EID prefix in the map-cache of the border xTR.

     7.   If the roaming EID-prefix received in the Map-Notify is not
          covered under a previously registered EID-prefix in the local
          site-overlay, the EID-prefix is a newly registered prefix and no
          further action is required.

     8.   If the roaming EID-prefix received in the Map-Notify is covered
          under a registered EID-prefix, the Map-Notify is due to a move
          event.  In this case, the site-overlay border xTR must register
          the roaming EID prefix in the site-overlay mapping system using
          the site-overlay facing RLOC-set of the border-xTRs.  The
          roaming EID-prefix must also be installed in the uberlay facing
          away table of the border xTR at the departure site-overlay.

     9.   The departure site-overlay Map-Server will send Map-Notify
          messages to the xTRs at the departure site-overlay as specified
          in [I-D.ietf-lisp-eid-mobility] (edge xTRs with the previously
          registered RLOCs).

     10.  When the site-overlay xTR at the departure site-overlay receives
          the Map-Notify from the border xTR, it will include the EID
          prefix received in the Map-Notify in its away table per the
          procedures described in [I-D.ietf-lisp-eid-mobility].

     11.  Data triggered Solicit Map Requests (SMRs) will be initiated in
          the different site-overlays and the uberlay as traffic matches
          the different away tables.  As specified in
          [I-D.ietf-lisp-eid-mobility], these SMRs notify the different
          ITRs involved in communications with the roaming EID that they
          must issue a new Map-Request to the mapping system to renew
          their mappings for the roaming EID.

  7.  Virtual Private Network (VPN) Considerations

     When supporting multiple Instance IDs as specified in
     [I-D.ietf-lisp-vpn] the Instance IDs range is divided in two sets.  A
     reuse-set that can be used in each site-overlay and a global-set used
     across site-overlays and the uberlay.








  Moreno, et al.           Expires 9 October 2025                [Page 17]


  Internet-Draft                LISP Uberlay                    April 2025


     Instance-IDs that are local to a site-overlay should only provide
     intra-overlay connectivity and are in the site-overlay mapping system
     only for VPN use for the xTRs in the site-overlay.  When the VPN
     reaches across site-overlays, then the global-set instance-IDs are in
     the uberlay mapping system as well as each site-overlay mapping
     system where the VPN members exist.

  8.  IANA Considerations

     This document has no IANA implications

  9.  Acknowledgements

     The authors want to thank Kedar Karamarkar, Prakash Jain and Vina
     Ermagan for their insightful contribution to shaping the ideas in
     this document.  We would also like to acknowledge the valuable input
     from the workgroup chairs Joel Halpern and Luigi Iannone in refining
     the objectives of the document.

  10.  References

  10.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,
                <https://www.rfc-editor.org/info/rfc2119>.

  10.2.  Informative References

     [I-D.farinacci-lisp-decent]
                Farinacci, D. and C. Cantrell, "A Decent LISP Mapping
                System (LISP-Decent)", Work in Progress, Internet-Draft,
                draft-farinacci-lisp-decent-16, 27 December 2024,
                <https://datatracker.ietf.org/doc/html/draft-farinacci-
                lisp-decent-16>.

     [I-D.ietf-lisp-eid-mobility]
                Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno,
                V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
                Unified Control Plane", Work in Progress, Internet-Draft,
                draft-ietf-lisp-eid-mobility-15, 4 November 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
                eid-mobility-15>.

     [I-D.ietf-lisp-vpn]
                Moreno, V. and D. Farinacci, "LISP Virtual Private
                Networks (VPNs)", Work in Progress, Internet-Draft, draft-



  Moreno, et al.           Expires 9 October 2025                [Page 18]


  Internet-Draft                LISP Uberlay                    April 2025


                ietf-lisp-vpn-12, 19 September 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
                vpn-12>.

     [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
                Smirnov, "Locator/ID Separation Protocol Delegated
                Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
                May 2017, <https://www.rfc-editor.org/info/rfc8111>.

     [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
                Separation Protocol (LISP) Multicast", RFC 8378,
                DOI 10.17487/RFC8378, May 2018,
                <https://www.rfc-editor.org/info/rfc8378>.

     [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
                Cabellos, Ed., "The Locator/ID Separation Protocol
                (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
                <https://www.rfc-editor.org/info/rfc9300>.

     [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
                Ed., "Locator/ID Separation Protocol (LISP) Control
                Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
                <https://www.rfc-editor.org/info/rfc9301>.

     [RFC9437]  Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
                S., and M. Boucadair, "Publish/Subscribe Functionality for
                the Locator/ID Separation Protocol (LISP)", RFC 9437,
                DOI 10.17487/RFC9437, August 2023,
                <https://www.rfc-editor.org/info/rfc9437>.

     [RFC9735]  Farinacci, D. and L. Iannone, Ed., "Locator/ID Separation
                Protocol (LISP) Distinguished Name Encoding", RFC 9735,
                DOI 10.17487/RFC9735, February 2025,
                <https://www.rfc-editor.org/info/rfc9735>.

  Authors' Addresses

     Victor Moreno
     Google LLC
     1600 Amphitheater Parkway
     Mountain View, California 94043
     United States of America
     Email: vimoreno@google.com








  Moreno, et al.           Expires 9 October 2025                [Page 19]


  Internet-Draft                LISP Uberlay                    April 2025


     Dino Farinacci
     lispers.net
     San Jose, CA 95120
     United States of America
     Email: farinacci@gmail.com


     Alberto Rodriguez-Natal
     Cisco Systems
     170 Tasman Drive
     San Jose, California 95134
     United States of America
     Email: natal@cisco.com


     Marc Portoles-Comeras
     Cisco Systems
     170 Tasman Drive
     San Jose, California 95134
     United States of America
     Email: mportole@cisco.com


     Fabio Maino
     Cisco Systems
     170 Tasman Drive
     San Jose, California 95134
     United States of America
     Email: fmaino@cisco.com


     Sanjay Hooda
     Cisco Systems
     170 Tasman Drive
     San Jose, California 95134
     United States of America
     Email: shooda@cisco.com














  Moreno, et al.           Expires 9 October 2025                [Page 20]


name: draft-yue-moq-transporting-sensing-data
rev: 03
title: Challenges in Transporting Sensing Data with Media Over QUIC
time: 2025-10-19T02:01:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-22T02:01:16Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.546507+00:00
source: ietf
source_id: 146278
source_url: https://datatracker.ietf.org/doc/draft-yue-moq-transporting-sensing-data/
doc_status: active
abstract:
  This document proposes leveraging Media Over QUIC (MOQ) to address
     the challenges of transmitting large-scale, real-time sensing data in
     6G networks.  By building on QUIC's low-latency and multiplexing
     capabilities, MOQ offers a flexible and efficient transport mechanism
     tailored to the dynamic and high-throughput requirements of 6G
     environments.  The approach focuses on enabling protocol adaptability
     across diverse application scenarios such as autonomous driving,
     smart cities, and industrial IoT, while ensuring efficient data
     fragmentation, secure and anonymous transmission, and end-to-end QoS
     awareness.  Through information-aware endpoints and optimized data
     delivery mechanisms, this solution supports scalable, reliable, and
     intelligent sensing data distribution in next-generation wireless
     networks.  It is also available to other types of 6G System Data
     [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.

full_text:
  moq                                                          Y. Yue, Ed.
  Internet-Draft                                                F. Li, Ed.
  Intended status: Standards Track                             W. Liu, Ed.
  Expires: 22 April 2026                                      China Unicom
                                                              C. Yang, Ed.
                                                          A. Akhavain, Ed.
                                                             K. Zhang, Ed.
                                             Huawei Technologies Co., Ltd.
                                                            M. Jadoon, Ed.
                                                         S. Robitzsch, Ed.
                                                  InterDigital Europe Ltd.
                                                           19 October 2025


        Challenges in Transporting Sensing Data with Media Over QUIC
                 draft-yue-moq-transporting-sensing-data-03

  Abstract

     This document proposes leveraging Media Over QUIC (MOQ) to address
     the challenges of transmitting large-scale, real-time sensing data in
     6G networks.  By building on QUIC's low-latency and multiplexing
     capabilities, MOQ offers a flexible and efficient transport mechanism
     tailored to the dynamic and high-throughput requirements of 6G
     environments.  The approach focuses on enabling protocol adaptability
     across diverse application scenarios such as autonomous driving,
     smart cities, and industrial IoT, while ensuring efficient data
     fragmentation, secure and anonymous transmission, and end-to-end QoS
     awareness.  Through information-aware endpoints and optimized data
     delivery mechanisms, this solution supports scalable, reliable, and
     intelligent sensing data distribution in next-generation wireless
     networks.  It is also available to other types of 6G System Data
     [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.

  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."



  Yue, et al.               Expires 22 April 2026                 [Page 1]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     This Internet-Draft will expire on 22 April 2026.

  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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Autonomous Vehicles . . . . . . . . . . . . . . . . . . .   4
       3.2.  Smart Cities  . . . . . . . . . . . . . . . . . . . . . .   4
       3.3.  Industrial IoT  . . . . . . . . . . . . . . . . . . . . .   4
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Multi-Scenario Applicability  . . . . . . . . . . . . . .   5
       4.2.  Efficient Data Transmission . . . . . . . . . . . . . . .   5
       4.3.  Anonymity . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.4.  Data Security . . . . . . . . . . . . . . . . . . . . . .   6
       4.5.  Traceability  . . . . . . . . . . . . . . . . . . . . . .   6
       4.6.  Information Awareness . . . . . . . . . . . . . . . . . .   6
       4.7.  Multi-Source Federation & Scale . . . . . . . . . . . . .   6
     5.  Publish-subscribe mechanism for data distribution . . . . . .   7
       5.1.  Why Pub-Sub and MoQ for Data Distribution . . . . . . . .   7
       5.2.  Benefits of Pub-Sub Mechanism for Data Distribution . . .   8
     6.  Pub-Sub Flows for Data Distribution . . . . . . . . . . . . .   8
       6.1.  Data Publish Flows  . . . . . . . . . . . . . . . . . . .   9
       6.2.  Data Subscribe Flows  . . . . . . . . . . . . . . . . . .  10
     7.  MoQ Protocol Enhancements for Sensing Data Transport  . . . .  11
       7.1.  Conceptual Object Format with Metadata Extension  . . . .  11
       7.2.  Extended Metadata Fields  . . . . . . . . . . . . . . . .  13
         7.2.1.  Data Information  . . . . . . . . . . . . . . . . . .  13
         7.2.2.  Network Information . . . . . . . . . . . . . . . . .  13
         7.2.3.  Service and Task Context  . . . . . . . . . . . . . .  14
         7.2.4.  QoS Information . . . . . . . . . . . . . . . . . . .  14
       7.3.  Protocol Behavior Enhancements  . . . . . . . . . . . . .  15
         7.3.1.  Control Plane Coordination  . . . . . . . . . . . . .  15
         7.3.2.  Failure Feedback Mechanisms . . . . . . . . . . . . .  15



  Yue, et al.               Expires 22 April 2026                 [Page 2]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
       10.2.  Informative References . . . . . . . . . . . . . . . . .  16
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     With the advent of 6G networks, there is an exponential increase in
     the volume and diversity of data generated by connected devices,
     sensors, and applications.  This data, known as "sensing data,"
     encompasses a wide range of information, including environmental,
     contextual, and behavioral data that can be leveraged for various
     advanced applications like autonomous driving, smart cities, and
     industrial IoT.  However, transmitting this sensing data efficiently
     in a 6G environment poses a significant challenge due to its large
     volume, distributed and massive number of sources , dynamic nature,
     and stringent real-time requirements.

     Media Over QUIC (MOQ) [*I-D.ietf-moq-transport*], a protocol designed
     to enable efficient media transport over QUIC, presents a promising
     solution for addressing these challenges.  QUIC, being a modern
     transport protocol, provides low-latency, multiplexed connections
     with enhanced congestion control, making it well-suited for real-time
     communication in dynamic networks.  MOQ builds on QUIC's capabilities
     to offer a robust and flexible framework for the high-throughput and
     low-latency transmission of multimedia data.

     This document explores how MOQ can be leveraged to efficiently
     transmit sensing data in 6G networks, focusing on its potential to
     handle the unique requirements of real-time, high-volume data streams
     while ensuring reliability, scalability, and low overhead.  The use
     of MOQ for data transport in this context can significantly improve
     the user experience and enable innovative services in next-generation
     wireless communication networks.

  2.  Conventions and Definitions

     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, as shown here.  Abbreviations and definitions used in this
     document: *MOQ: Media Over QUIC *V2V: Vehicle-to-Vehicle. *P2P:
     Point-to-Point





  Yue, et al.               Expires 22 April 2026                 [Page 3]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


  3.  Use Cases

     [*I-D.lcurley-moq-use-cases*] defines several use cases for MOQ,
     while this document focuses on MOQ use cases in the context of
     sensing data transmission.

  3.1.  Autonomous Vehicles

     Autonomous vehicles rely on real-time sensing data from onboard
     sensors (e.g., LiDAR, cameras) and external sources (e.g., traffic
     signals, nearby vehicles).  MOQ facilitates the efficient and
     reliable transmission of this data in the following ways: 1.
     Vehicle-to-Vehicle (V2V) Communication: MOQ over QUIC establishes
     low-latency, multiplexed streams between vehicles, enabling the
     exchange of situational data like location, speed, and hazards in
     real-time. 2.  Data Prioritization: High-priority sensing data, such
     as collision warnings, is tagged for immediate transmission, while
     less critical data, like traffic updates, is sent with lower priority
     to optimize bandwidth.

  3.2.  Smart Cities

     Smart cities generate diverse types of sensing data from devices such
     as traffic cameras, pollution monitors, and utility sensors.  MOQ
     enhances urban management through: 1.  Adaptive Data Aggregation:
     Sensors stream data to edge servers via MOQ's multiplexed
     connections, which dynamically adapt to varying link conditions to
     prevent packet loss during congestion. 2.  Real-Time Event Streaming:
     For critical events (e.g., emergencies or system failures), MOQ
     ensures prioritized and low-latency delivery of sensor data to
     central control systems or cloud platforms for immediate response.

  3.3.  Industrial IoT

     Factories equipped with IoT sensors require reliable, low-latency
     communication to monitor and optimize operations.  MOQ supports
     industrial IoT through: 1.  Real-Time Monitoring: MOQ streams sensor
     data such as vibration or temperature directly to monitoring systems,
     ensuring fast anomaly detection and response. 2.  Redundant
     Transmission: For critical sensing data, MOQ can enable redundant
     streams over QUIC to ensure delivery even under adverse network
     conditions.









  Yue, et al.               Expires 22 April 2026                 [Page 4]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


  4.  Problem Statement

     The application of Media Over QUIC (MOQ) for transmitting sensing
     data in 6G networks presents several key challenges that must be
     addressed to ensure its feasibility and effectiveness.  These
     challenges are as follows:

  4.1.  Multi-Scenario Applicability

     Sensing data in 6G networks is generated in diverse scenarios,
     ranging from autonomous vehicles to smart cities and industrial IoT.
     Each scenario imposes unique requirements on the transport protocol,
     such as varying latency, throughput, and reliability demands.  These
     use cases may involve real-time synchronous or asynchronous data
     transmission, as well as point to point (P2P) or multi-point
     communication modes.  Ensuring that MOQ can adapt to these diverse
     requirements without compromising performance or introducing overhead
     remains a significant challenge , e.g., how to differentiate
     transmissions of sensing data flows with varying demands.

  4.2.  Efficient Data Transmission

     The sheer volume and velocity of sensing data in 6G networks
     necessitate highly efficient transport mechanisms.  MOQ must address
     issues such as reducing overhead for small and frequent data packets,
     optimizing transmission for bursty data patterns, and ensuring low-
     latency delivery even under high traffic loads.  Balancing efficient
     utilization of network resources while maintaining robust performance
     is critical.  Avoid redundant data collection and transmission, e.g.,
     to cache data on demand.

  4.3.  Anonymity

     In applications such as smart cities and industrial IoT, sensing data
     often includes sensitive or identifiable information.  Ensuring
     anonymity during transmission is essential to protect user privacy
     and comply with regulatory requirements.  MOQ must integrate
     mechanisms to obscure identifying information in data streams while
     maintaining the integrity and usability of the transmitted data.
     Data sources and data consumers are not aware of each other.











  Yue, et al.               Expires 22 April 2026                 [Page 5]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


  4.4.  Data Security

     Sensing data in 6G networks is often critical to the operation of
     real-time systems, making it a prime target for cyber threats such as
     interception, tampering, and unauthorized access.  MOQ must
     incorporate advanced security measures to guarantee the
     confidentiality, integrity, and authenticity of data in transit.
     Additionally, the protocol must address the challenge of securely
     transmitting data in dynamic and heterogeneous network environments,
     including cross-domain communication.  Data payload is visible only
     to data sources and data consumers, and is invisible to intermediate
     nodes.  The payload needs to be encrypted.

  4.5.  Traceability

     Sensing data logs can be recorded, and data collection and
     consumption history is traceable.

  4.6.  Information Awareness

     MOQ endpoints should be aware of key contextual information related
     to sensing data to enable efficient and intelligent data
     distribution.  This includes: 1.  Network Awareness: The MOQ endpoint
     should have knowledge of network-related sensing data, such as cell
     or sensing area information, to optimize data distribution decisions.
     2.  QoS Awareness: MOQ should ensure QoS guarantees for the
     collection and transmission of sensing data, adjusting delivery
     mechanisms accordingly.  Service Awareness: The MOQ endpoint should
     identify the intended service or application utilizing the sensing
     data.  This enables proper classification, retrieval, and
     provisioning of sensing data to authorized services.

  4.7.  Multi-Source Federation & Scale

     Sensing in future networks is expected to involve a large number of
     distributed and heterogeneous sources, such as base stations, user
     devices, roadside units, and access points.  Each source may produce
     sensing data of different types and at different temporal or spatial
     resolutions.  When combined across diverse sensing tasks and use
     cases, the overall volume of generated data can become massive.
     Managing such a distributed and data-intensive environment raises
     challenges in terms of scalability, coordination, and resource
     efficiency.  Multiple sensing entities may observe overlapping
     environments, leading to redundant or partially correlated
     information.  Without mechanisms to coordinate data generation and
     dissemination, the resulting data traffic can impose significant load
     on transport infrastructure.  Therefore, scalability in sensing
     networks is not only a matter of bandwidth or throughput but also of



  Yue, et al.               Expires 22 April 2026                 [Page 6]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     how effectively information from numerous and diverse sources can be
     collected, organized, and made available to the entities that need
     it.  This requires careful consideration of data distribution
     principles that can operate efficiently under high source/destination
     density and dynamic network conditions.

  5.  Publish-subscribe mechanism for data distribution

  5.1.  Why Pub-Sub and MoQ for Data Distribution

     Large-scale sensing deployments, such as those envisioned for next-
     generation networks [3GPP.SA2.6G.SID], [3GPP.22.137], [3GPP.22.870],
     [ETSI.GRISC.001], can produce an immense and continuous flow of
     heterogeneous information ranging from assistance data, sensing
     measurements to sensing data, both attached with metadata, to sensing
     results that has contextual information attached.  When multiple
     sensing use cases operate concurrently, for example, object tracking,
     localization, and environmental monitoring, the aggregate volume of
     information can become substantial.  Using traditional web-based
     client-server application and point-to-point transport protocols to
     move such heterogeneous information across a mobile network, risks
     creating severe networking and processing bottlenecks.  Furthermore,
     the heterogenous information comes with severely different quality of
     service (QoS) requirements when being exchanged between two endpoints
     in the mobile network, with those endpoints possible to change at any
     point in time due to the mobile nature of terminals.

     Existing protocols generally require dedicated sessions per source or
     per consumer, leading to duplicated transmissions, inefficient
     resource use, and reduced timeliness as the system scales and the
     same set of information from a single source is required at different
     destinations, e.g. allowing multiple instances at different parts of
     the mobile network to process information to identify the most
     reliable and accurate result.

     To address these scalability and dynamism challenges, a _publish/
     subscribe_ information distribution model is more suitable.  It
     decouples data producers and consumers, allowing information
     generated by many sensing entities to be distributed flexibly and
     efficiently to multiple analytics or network/application functions
     without maintaining direct session state between every pair.  Such a
     model enables aggregation, filtering, and routing of sensing
     information according to spatial, temporal, or service-level needs,
     significantly improving scalability and resilience.

     Within the IETF, the Media over QUIC Transport (MOQT) protocol
     provides a foundation for realizing such an efficient, object-
     oriented, and real-time publish/subscribe distribution system.  MOQT



  Yue, et al.               Expires 22 April 2026                 [Page 7]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     builds upon QUIC’s secure, congestion-controlled transport and
     introduces mechanisms for scalable dissemination of time-sensitive
     data.  Its general design principles – publisher – subscriber
     decoupling, adaptive data delivery, and relay-based distribution,
     align well with the characteristics of sensing data and the need to
     serve multiple simultaneous use cases in a resource-efficient manner.

     In summary, adopting a publish/subscribe distribution approach,
     supported by technologies such as MOQ, offers a path to transport
     sensing information at scale while maintaining efficiency,
     flexibility, and timeliness across diverse sensing applications.

  5.2.  Benefits of Pub-Sub Mechanism for Data Distribution

     *  *Flexible and scalable:* applicable to Point to point/Multi-points
        data distribution, real-time synchronous or asynchronous data
        transmission,

     *  *Efficient data distribution:* any of the on-path Data Proxies can
        cache/store data, to avoid redundant data collection and
        transmission.

     *  *Data privacy and security:* Data payload is visible only to data
        sources and data consumers, and is invisible to Data-Proxy.

  6.  Pub-Sub Flows for Data Distribution

     To support multi-scenario applicability of 6G system data (e.g.,
     sensing data) distribution, aspects such as Network topology and
     transmission requirement should be taken into consideration:

      *1.  Network topology:* Providers and consumers of 6G system data
     (e.g., sensing data) are highly distributed in 6G network.  P2P data
     distribution and point to multi-points (P2MP) data distribution are
     coexisted.

      *2.  Transmission requirement:* Different scenarios impose unique
     requirements in data sensing transmission, such as varying latency
     and throughput, real-time synchronous and asynchronous etc.  Even the
     same data source might be consumed in different requirements by
     consumers.

     Due to these these aspects, a publish/subscribe information model is
     required.

     _The publish/subscribe topology is illustrated in the figure below:_





  Yue, et al.               Expires 22 April 2026                 [Page 8]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


                                  +-------+
             +------------------->| Data  |----------------------+
             |         Data +-->--| proxy2|-->--+  Data          |
             |      session/      +-------+      \ session       |
             |            /         |  ^          \              |
             | Pub      (2)     Sub |  | Sub      (3)        Pub |
             |          /           |  |            \            |
             |         /            |  |             \           |
             |        /             |  |              \          |
             |    +-------+         |  |            +-------+    |
             +----| Data  |<--------+  +------------| Data  |<---+
       +--------->| proxy1|--+    +---------------->| proxy3|---------------+
       |          +-------+  |    |         +---<---+-------+--->---+       |
       |            |        |    |         |         |  ^          |       |
       | Pub       (1)   Sub |    | Sub     |     Pub |  | Sub      |   Pub |
       |            |        |    |       (4.1)       |  |        (4.2)     |
       |            ^        |    |         |         |  |          |       |
       |        Data|        |    |     Data|         |  |     Data |       |
       |     session|        |    |  session|         |  |   session|       |
       |            |        |    |         |         |  |          |       |
       |            |        |    |         |         |  |          |       |
       |   +------------+    |    |  +------------+   |  |  +------------+  |
       +---|   Data     |<---+    +--|    Data    |<--+  +--|    Data    |<-+
           | provider 1 |            | consumer 1 |         | consumer 2 |
      |    +------------+            +------------+         +------------+
      ^                        |
      |    +------------+      |
      +----|   Data     |<-----+
       Pub | provider 2 |   Sub
           +------------+

     _In this figure, data proxies act as MoQ relays, data providers are
     original publishers of data (e.g., sensing data) and consumers are
     end subscribers requesting for data._

  6.1.  Data Publish Flows

     1.  Data providers (e.g., Data provide 1&2) publish metadata (e.g.,
         sensing metadata) of 6G system data to upstream data proxies
         (e.g., Data-proxy 1) based on the MoQ publish mechanism and
         procedure.  The data proxies can be new type of logical endpoints
         or other data providers or consumers.  This metadata may include
         non-exhaustively: data information, network information, service
         information and QoS information (refer to descriptions in
         following sections).






  Yue, et al.               Expires 22 April 2026                 [Page 9]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     2.  The upstream data proxies active as publishers can continue
         publish metadata of 6G system data to their upstream endpoints
         (e.g., Data proxy 2).  Considering that different endpoints may
         have different capabilities and network contextual status, the
         published information by upstream endpoints (e.g., Data proxy 2)
         might be different from the original data provider’s.  Moreover,
         the upstream endpoints (e.g., Data-proxies) may perform some data
         processing actions (e.g., data cleaning, data filtering, data
         aggregation, data anonymization) before publish.

     3.  The metadata (e.g., sensing metadata) of 6G system data are
         published hop by hop to related upstream data proxies and/or data
         consumers, e.g., by specific policy.

  6.2.  Data Subscribe Flows

      After the publish process,

     1.  Data Consumer (e.g., sensing data consumer 1) active as Original
         Subscriber sends MoQ subscribe messages to its downstream
         endpoint (e.g., Data-proxy 3).  The data consumer may select one
         of connected Data-proxies based on its specific demand on 6G
         system data (e.g., sensing data) and sends subscribe message.

     2.  Once the downstream endpoint (e.g., Data-proxy 3) receive the
         subscribe message, it will check whether there is available data
         (e.g., caching data), if there is, the downstream endpoint can
         send the available data to he Data Consumer; otherwise, the
         downstream endpoint will send MoQ subscribe messages to its
         downstream endpoints (e.g., Data-proxy 2) and so forth until the
         available data is found.  For example, the available data is
         found from Data Provider 1.

     3.  A data session (consisting of MoQ session) can be established
         between the Data Provider 1 and the Data Consumer.

     4.  It is possible that more than one Data Consumers (e.g., Data
         Consumer 1 and 2 as in the figure) request the same data.  The
         Data-proxy (e.g., Data-proxy 3) can collect data only once from
         Data Provider (e.g., data provider 1) and replicates the data to
         the Data consumers respectively.  It can reduce redundancy of
         data collection and data delivery.  Moreover, the Data Proxy can
         cache the collected data if necessary for further requests (e.g.,
         other data consumers' requests for the same data).







  Yue, et al.               Expires 22 April 2026                [Page 10]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


  7.  MoQ Protocol Enhancements for Sensing Data Transport

     To support the efficient and intelligent transmission of sensing data
     in 6G environments, enhancements to the MoQ protocol are proposed.
     These enhancements aim to enrich MoQ metadata or header extensions to
     include key information required for intelligent routing, data
     classification, service mapping, and QoS-aware scheduling in sensing-
     centric applications.

  7.1.  Conceptual Object Format with Metadata Extension

     The following diagram illustrates a conceptual format for a MoQ
     object with enhanced metadata fields for sensing applications:






































  Yue, et al.               Expires 22 April 2026                [Page 11]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


        +-------------------------------+
        |       MoQ Object Header       |
        +-------------------------------+
        |  - Object Name                |
        |  - Object Type                |
        |  - Duration (optional)        |
        |  - Group ID / Track ID        |
        +-------------------------------+
        |  Extended Metadata Header     |
        +-------------------------------+
        |  - Metadata Type (e.g., TLV)  |
        |  - Length                     |
        +-------------------------------+
        |           Data Info           |
        |  - Data Name                  |
        |  - Data Feature               |
        |  - Semantics Token            |
        |  - Data Representation        |
        |  - Data Hash                  |
        +-------------------------------+
        |         Network Info          |
        |  - Network ID (PLMN ID)       |
        |  - Cell ID                    |
        |  - Node ID                    |
        |  - Tracking Area Code         |
        |  - Sensing Region ID          |
        +-------------------------------+
        |        Service Info           |
        |  - Service ID                 |
        |  - Task ID                    |
        |  - Mission ID                 |
        |  - SFC ID                     |
        +-------------------------------+
        |          QoS Info             |
        |  - QoS Identifier (QI)        |
        |  - Timestamp                  |
        |  - data quality               |
        |  - data transmission QoS      |
        |  - data processing QoS        |
        +-------------------------------+
        |          Payload              |
        |      (Encrypted Data)         |
        +-------------------------------+








  Yue, et al.               Expires 22 April 2026                [Page 12]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


  7.2.  Extended Metadata Fields

     The following categories of metadata are recommended to be included
     in MoQ object headers or extension fields, either through expansion
     of the existing metadata field (e.g., the new information are some
     bits of the existing metadata fields) or through the definition of
     new metadata elements:

  7.2.1.  Data Information

     Metadata related to the content and identity of the sensing data:

     (1) data_keyword: Keywords or descriptors representing data semantics
     of content.

     (2) data_feature: Characteristics such as modality, format or other
     attributes.

     (3) data_representation: Encoding type (e.g., JSON, CBOR, binary).

     (4) data_name: Human-readable or system-assigned identifier.

     (5) semantics: Token-level annotations describing data meaning.

     (6) hash: Hash value of content, e.g., for indexing or integrity
     verification.

  7.2.2.  Network Information

     Network-related metadata used to describe the contextual origin or
     association of the data.  One or more of the following fields may be
     included:

     (1) network_id (e.g., PLMN ID): Identifies the network to which the
     data belongs.  This may refer to the network in which the data was
     collected or published, the network the data describes, or the
     network in which the sensing node resides.

     (2) cell_id: Identifies the cell associated with the data.  This may
     refer to the cell where the data was collected or published, the cell
     the data is about, or the cell in which the sensing node resides.

     (3) node_id: Identifies the network node associated with the data.
     This may be the node that collected or published the data, or the
     node the data describes.






  Yue, et al.               Expires 22 April 2026                [Page 13]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     (4) tracking_area_code (TAC): Identifies the tracking area to which
     the data belongs.  This may refer to the area where the data was
     collected/published, the area the data is about, or the area in which
     the relevant node resides.

     (5) sensing_region_id: Identifies the sensing region associated with
     the data.  This may refer to the region where the data was collected,
     the region being sensed, the region where the sensing node resides,
     or the region where the sensed object is located.

  7.2.3.  Service and Task Context

     Metadata describing the service or task context associated with the
     data.  One or more of the following fields may be included:

     (1) service_id: Identifies the service to which the data is related.
     For example, it indicates that data can be used by an AI service,
     sensing service, XR service, etc.

     (2) task_id: Identifies a specific task that processes the data.  A
     task may include AI model training, inference, data preprocessing,
     data analysis, privacy-preserving operations, or data distribution.

     (3) mission_id: Identifies a task group (or job), which consists of
     multiple tasks that are executed in a predefined sequence (e.g.,
     sequential or parallel).  The data is used as input for this mission.

     (4) sfc_id: Identifies a Service Function Chain (SFC).  The data is
     used for processing through the corresponding service function chain.

  7.2.4.  QoS Information

     Metadata related to the quality of service requirements for the data.
     One or more of the following fields may be included:

     (1) QI (QoS Identifier): Represents a QoS class or profile, which may
     imply specific parameters such as maximum delay budget for
     processing, or end-to-end latency requirements (e.g., including both
     transmission and processing delays). (2) timestamp: Indicates the
     time at which the data was generated by the source or forwarded by an
     intermediate node.  This can be used to calculate end-to-end latency
     or time spent in transit.  The timestamp may be provided at different
     granularity levels, such as per object, group, or track.

     (3) data quality: identify quality metrics on data itself, e.g.,
     accuracy, completeness, reliability, redundancy, bias, source
     reliability, and integrity.




  Yue, et al.               Expires 22 April 2026                [Page 14]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     (4) data transmission QoS: Indicates QoS requirement (e.g., delay) on
     data transmission.

     (5) data processing QoS: Indicates QoS requirement (e.g., delay,
     accuracy) on data processing, e.g., data cleaning, data
     anonymization, data analysis, or data generation.

  7.3.  Protocol Behavior Enhancements

     In addition to metadata enrichment, certain behavioral extensions are
     necessary when applying MoQ to sensing applications, especially when
     operating at the user plane (UP) or data plane in 6G architectures:

  7.3.1.  Control Plane Coordination

     MoQ endpoints deployed in sensing environments may require dynamic
     interaction with the control plane to receive configuration
     parameters, access control policies, and data routing instructions.
     This includes the ability to register interests or capability to
     control plane, or notify the control plane upon data path failures or
     when requested publishers are not found.

  7.3.2.  Failure Feedback Mechanisms

     In cases where a MoQ subscriber is unable to locate a publisher
     (e.g., within limited time or hops) for the required sensing data,
     the protocol should support mechanisms to notify upstream
     orchestration entities or the control plane for further resolution or
     dynamic path redirection and publisher reselection.

  8.  Security Considerations

     TBD

  9.  IANA Considerations

     TBD

  10.  References

  10.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, https://www.rfc-editor.org/info/rfc2119 (https://www.rfc-
        editor.org/info/rfc2119).





  Yue, et al.               Expires 22 April 2026                [Page 15]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     *  [*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 (https://www.rfc-
        editor.org/info/rfc8174).

  10.2.  Informative References

     *  [*3GPP.22.870*] 3GPP TR22.870, "Study on 6G Use Cases and Service
        Requirements",

        https://portal.3gpp.org/desktopmodules/Specifications/
        SpecificationDetails.aspx?specificationId=4374
        (https://portal.3gpp.org/desktopmodules/Specifications/
        SpecificationDetails.aspx?specificationId=4374).

     *  [*I-D.ietf-moq-transport*] Nandakumar, S., Vasiliev, V., Swett,
        I., and A.  Frindell, "Media over QUIC Transport", Work in
        Progress, Internet-Draft, draft-ietf-moq-transport-14, 2 September
        2025, https://datatracker.ietf.org/doc/html/draft-ietf-moq-
        transport-14 (https://datatracker.ietf.org/doc/html/draft-ietf-
        moq-transport-14).

     *  [*I-D.lcurley-moq-use-cases*] Curley, L., "Media over QUIC - Use
        Cases", Work in Progress, Internet-Draft, draft-lcurley-moq-use-
        cases-01, 22 July 2025, https://datatracker.ietf.org/doc/html/
        draft-lcurley-moq-use-cases-01
        (https://datatracker.ietf.org/doc/html/draft-lcurley-moq-use-
        cases-01).

     *  [*3GPP.SA2.6G.SID*] 3GPP SP-250806, "Study on Architecture for 6G
        System".

     *  [*3GPP.22.137*] 3GPP TS22.137, "Service requirements for
        Integrated Sensing and Communication",

        https://portal.3gpp.org/desktopmodules/Specifications/
        SpecificationDetails.aspx?specificationId=4198
        (https://portal.3gpp.org/desktopmodules/Specifications/
        SpecificationDetails.aspx?specificationId=4198).

     *  [*ETSI.GRISC.001*] ETSI ISAC ISG, "ISAC; Generic reference
        architecture for Integrated Sensing And Communications (ISAC),"
        ETSI GR ISC 001 - V1.1.1, 2025,
        https://www.etsi.org/deliver/etsi_gr/ISC/001_099/001/01.01.01_60/
        gr_isc001v010101p.pdf
        (https://www.etsi.org/deliver/etsi_gr/ISC/001_099/001/01.01.01_60/
        gr_isc001v010101p.pdf).




  Yue, et al.               Expires 22 April 2026                [Page 16]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


  Authors' Addresses

     Yi Yue (editor)
     China Unicom
     Beijing
     China
     Email: yuey80@chinaunicom.cn


     Feile Li (editor)
     China Unicom
     Beijing
     China
     Email: lifl100@chinaunicom.cn


     Wei Liu (editor)
     China Unicom
     Beijing
     China
     Email: liuw550@chinaunicom.cn


     Chenchen Yang (editor)
     Huawei Technologies Co., Ltd.
     Shanghai
     China
     Email: yangchenchen7@huawei.com


     Arashmid Akhavain (editor)
     Huawei Technologies Co., Ltd.
     Ottawa
     Canada
     Email: arashmid.akhavain@huawei.com


     Kuan Zhang (editor)
     Huawei Technologies Co., Ltd.
     Shanghai
     China
     Email: zhangkuan3@huawei.com


     Muhammad Awais Jadoon (editor)
     InterDigital Europe Ltd.
     London
     United Kingdom



  Yue, et al.               Expires 22 April 2026                [Page 17]


  Internet-Draft   Challenges in Transporting Sensing Data    October 2025


     Email: Muhammad.AwaisJadoon@InterDigital.com


     Sebastian Robitzsch (editor)
     InterDigital Europe Ltd.
     London
     United Kingdom
     Email: Sebastian.Robitzsch@InterDigital.com











































  Yue, et al.               Expires 22 April 2026                [Page 18]


name: draft-ahn-nmrg-5g-security-i2nsf-framework
rev: 01
title: An Integrated Security Service System for 5G Networks using an I2NSF Framework
time: 2026-02-25T08:28:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T08:28:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.551900+00:00
source: ietf
source_id: 150311
source_url: https://datatracker.ietf.org/doc/draft-ahn-nmrg-5g-security-i2nsf-framework/
doc_status: active
abstract:
  This document presents an integrated framework for automated security
     management in 5G edge networks using the Interface to Network
     Security Functions (I2NSF) architecture.  The proposed system
     leverages Intent-Based Networking (IBN) to allow users or
     administrators to declare high-level security intents, which are
     translated into enforceable network and application policies.
     Network-level policies are delivered to 5G core components via the
     Network Exposure Function (NEF), while application-level policies are
     enforced directly on a User Equipment (UE) through distributed IBN
     Controllers.  This architecture supports adaptive, context-aware, and
     distributed policy enforcement, enabling real-time response to
     dynamic edge conditions and user mobility scenarios such as
     handovers.  By integrating closed-loop monitoring and analytics, the
     system ensures consistent and autonomous security across
     heterogeneous 5G environments.

full_text:
  Internet Research Task Force                                 Y. Ahn, Ed.
  Internet-Draft                                             J. Jeong, Ed.
  Intended status: Informational                   Sungkyunkwan University
  Expires: 29 August 2026                                           Y. Kim
                                                       Soongsil University
                                                          25 February 2026


    An Integrated Security Service System for 5G Networks using an I2NSF
                                 Framework
               draft-ahn-nmrg-5g-security-i2nsf-framework-01

  Abstract

     This document presents an integrated framework for automated security
     management in 5G edge networks using the Interface to Network
     Security Functions (I2NSF) architecture.  The proposed system
     leverages Intent-Based Networking (IBN) to allow users or
     administrators to declare high-level security intents, which are
     translated into enforceable network and application policies.
     Network-level policies are delivered to 5G core components via the
     Network Exposure Function (NEF), while application-level policies are
     enforced directly on a User Equipment (UE) through distributed IBN
     Controllers.  This architecture supports adaptive, context-aware, and
     distributed policy enforcement, enabling real-time response to
     dynamic edge conditions and user mobility scenarios such as
     handovers.  By integrating closed-loop monitoring and analytics, the
     system ensures consistent and autonomous security across
     heterogeneous 5G environments.

  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 29 August 2026.





  Ahn, et al.              Expires 29 August 2026                 [Page 1]


  Internet-Draft  An 5G Integrated Security Service System   February 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  An I2NSF-Based Architecture for 5G Edge Security
             Management  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  The Procedure for I2NSF-Based 5G Edge Security Management . .   7
     5.  Security Considerations Sections  . . . . . . . . . . . . . .  11
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Introduction

     Network softwarization has become a fundamental approach for
     delivering network services across various infrastructures, including
     5G mobile networks [TS-23.501], cloud computing platforms, and edge
     computing environments.  This paradigm is enabled through key
     technologies such as Network Functions Virtualization (NFV)
     [ETSI-NFV] and Software-Defined Networking (SDN) [RFC7149].  In
     addition, Intent-Based Networking (IBN) [RFC9315]
     [Survey-IBN-CST-2023] serves as a foundation for implementing
     intelligent behaviors in both network-level and application-level
     services.  As networks continue to evolve in this software-driven
     direction, the emergence of 5G introduces new challenges,
     particularly in the realm of security.

     As mobile networks evolve toward 5G, the increasing complexity of
     network functions and the widespread deployment of edge devices such
     as IoT nodes, user equipment (UE), and application functions (AFs)



  Ahn, et al.              Expires 29 August 2026                 [Page 2]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     [TS-23.501] introduce significant challenges to existing security
     models.  These environments are inherently dynamic, heterogeneous,
     and latency-sensitive, making it difficult for traditional rule-based
     configurations, which are typically static and manually managed, to
     respond effectively to changing conditions.  In particular, security
     operations at the edge require more contextual awareness, automation,
     and adaptability than ever before.

     Intent-Based Networking (IBN) provides a promising paradigm to meet
     these requirements.  It enables operators or users to declare high-
     level goals, or intents, which the system can automatically translate
     into enforceable security and network policies [TS-28.312].  These
     policies may range from abstract service-level objectives to fine-
     grained access control rules.  By automating this translation and
     enforcement process, the network gains the ability to respond
     autonomously to operational demands without requiring manual
     intervention.  This model supports closed-loop control, where real-
     time feedback mechanisms continuously refine and adapt system
     behavior based on evolving context and intent.

     This document defines an intent-based framework for edge security
     management in the context of 5G systems.  The framework builds upon
     the service-based architecture (SBA) defined in 3GPP 5G and beyond,
     and introduces a layered approach that includes intent translation,
     policy generation, enforcement, and monitoring.  It integrates
     seamlessly with existing 3GPP network functions such as the Policy
     Control Function (PCF) [TS-29.520], Access and Mobility Management
     Function (AMF), Session Management Function (SMF), and Network Data
     Analytics Function (NWDAF) [TS-23.288].  The aim is to deliver
     scalable and adaptive security control across heterogeneous edge
     domains through policy-driven orchestration.

     Furthermore, the framework is designed to support mobility scenarios,
     including handovers between gNBs and session migration across
     multiple User Plane Functions (UPFs).  By dynamically enforcing
     intents on the edge, the system maintains consistent and context-
     aware security postures even in the presence of mobility events.
     This capability improves network resilience and responsiveness and
     provides a foundation for secure, automated, and intelligent 5G
     services.  The proposed framework also aligns with long-term goals of
     zero-touch security, AI-driven orchestration, and intent-based policy
     automation within future mobile network infrastructures.









  Ahn, et al.              Expires 29 August 2026                 [Page 3]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


  2.  Terminology

     This section provides definitions of the key terms and concepts used
     throughout this document.  The terminology is intended to establish a
     common understanding of the architectural elements, interfaces, and
     operational principles discussed in the context of intent-based
     security management in 5G networks.  These terms are used to describe
     5G Network automation based on the Intent-Based Networking (IBN) and
     Interface to Network Security Functions (I2NSF) framework.

     *  Intent: It refers to a set of operational objectives and expected
        outcomes that a network is expected to fulfill, expressed in a
        declarative manner without specifying the implementation details
        or the exact procedures to achieve them [RFC9315].  Intents can be
        represented using XML [RFC6020] [RFC7950] or YAML [YAML] formats,
        and may be delivered to the target components through protocols
        such as NETCONF [RFC6241], RESTCONF [RFC8040], or via standard
        REST APIs [REST].

     *  IBN User Function (IUF): The IUF is typically accessed via a web-
        browser interface, which allows Mobile Object administrators to
        input network intents for the IBN Control Function (ICF).  These
        intents serve as strategic objectives that guide the generation of
        security and network policies within the system.

     *  IBN Control Function (ICF): The ICF operates as a core component
        of the I2NSF architecture deployed within the 5G network.  It is
        responsible for managing and orchestrating security enforcement
        functions by both translating the intents from the IUF into
        actionable policies, and selecting appropriate 5G Network
        Functions (NFs) for their execution.

     *  Developer's Management Function (DMF): The DMF is a component
        within the Interface to Network Security Functions (I2NSF)
        framework that acts as a provider of Network Security Functions
        (NSFs).  It is responsible for registering the capabilities of
        these NSFs with the Security Controller, essentially making them
        available for use in enforcing security policies.

     *  Security Control Function (SCF): The SCF strengthens network
        security by generating low-level policies to modify and supplement
        the network configuration based on the delivered network policy
        and delivering them to the relevant individual NFs.








  Ahn, et al.              Expires 29 August 2026                 [Page 4]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     *  Security Data Analytics Function (SDAF): THE SDAF collects and
        analyzes monitoring data to verify whether the policies generated
        based on intents have been properly enforced by the network
        security functions, and to evaluate the performance and
        functionality of the security services.

     *  Network Security Function (NSF): The NSF is a network security
        function that provides actual security services based on policies
        generated based on the user's intent.  It actually executes
        security tasks such as blocking or allowing traffic based on the
        policy delivered from ICF.

  3.  An I2NSF-Based Architecture for 5G Edge Security Management

     This section defines a comprehensive framework for 5G security
     management automation by introducing its essential components and
     explaining how each of them is designed to interconnect with
     functions in the 5G core networks [TS-23.501].  The framework is
     grounded in intent-based networking principles, which enable high-
     level user or application intents to be automatically translated into
     actionable policies.  These policies are then enforced and monitored
     across both the core and edge domains without requiring manual
     intervention.

     As 5G networks become more distributed and support a growing number
     of latency-sensitive services and heterogeneous devices, traditional
     static security mechanisms struggle to cope with the dynamic nature
     of threats and the scale of real-time traffic.  Manual configuration
     is no longer feasible in such environments, making automated security
     orchestration essential to maintain consistent protection, reduce
     response time, and minimize human error.

     To realize this, the framework leverages a set of I2NSF-based
     functional modules that collectively support policy translation,
     enforcement, and real-time monitoring.  By integrating these
     components into the 5G architecture, the system enables scalable,
     adaptive, and context-aware security operations tailored to the needs
     of dynamic and heterogeneous edge environments.













  Ahn, et al.              Expires 29 August 2026                 [Page 5]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


    +------------------------------------+ +-----------------------------+
    | 5G Core NFs                        | |                             |
    | +-----+  +-----+  +-----+  +-----+ | | +-----+  +-----+  +------+  |
    | |NSSF |  | UDM |  | NRF |  | PCF | | | | IUF |  | ICF |  | SDAF |  |
    | +---+-+  +---+-+  +---+-+  +---+-+ | | +--+--+  +--+--+  +--+---+  |
    |     |        |        |        |   | |    |        |        |      |
    | --+-+------+-+------+-+---+--+-+---+-+----+---+----+----+---+----- |
    |   |        |        |        |     | |        |         |          |
    | +-+---+  +-+---+  +-+---+  +-+---+ | |     +-----+   +-----+       |
    | | AUSF|  | AMF |  | SMF |  | NEF | | |     | DMF |   | SCF |       |
    | +-----+  +-+-+-+  +--+--+  +-----+ | |     +-----+   +-----+       |
    |            | |       |             | |                             |
    |      +-----+ +--+    +------+      | |  AFs for Security Services  |
    +------+----------+-----------+------+ +-----------------------------+
           |          |           |
        +--+--+   +---+---+    +--+---+   +--+---+   +--------------+
        | UE  +---+ (R)AN +----+ UPFs +---+ NSFs +---+ Data Network |
        +-----+   +-------+    +--+---+   +------+   +--------------+

       Figure 1: I2NSF-Based Security Management Framework for 5G Edge
                                   Networks

     Figure 1 illustrates a 5G edge security service architecture based on
     the I2NSF framework [RFC8329], implemented as an Intent-Based System
     (IBS).  An intent-based management strategy is required between the
     5G Core network and distributed edge domains to enable the autonomous
     configuration and security enforcement of edge functions such as User
     Equipment (UEs), as described in the IETF draft on intent-based
     network management automation.

     On the right side of the architecture, the AFs for Security Services
     represent application-layer functions that initiate and manage high-
     level security intents.  These functions serve as the interface
     between external users or applications and the intent-based security
     system.  This service is composed of several key modules, including
     the Intent-Based Use Function (IUF), the Intent Control Function
     (ICF), the Security Control Function (SCF), the Developer's
     Management Function (DMF), and the Security Data Analytics Function
     (SDAF), which collectively support intent interpretation, policy
     translation, enforcement, and monitoring across the network.

     The security intent generated by the Intent-Based Network Use
     Function (IUF) is first interpreted as a high-level objective
     reflecting the desired behavior of the network or specific
     applications.  This intent is then processed by the Intent-Based
     Network Control Function (ICF), which plays a central role in
     translating the abstract intent into concrete policies.  Through this
     translation process, two distinct types of policies are created: a



  Ahn, et al.              Expires 29 August 2026                 [Page 6]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     network policy, which governs how the underlying network should
     behave (e.g., traffic routing, filtering, or QoS enforcement), and an
     application policy, which defines how specific applications or
     devices should operate under given security constraints.

     Once these policies are generated, they are delivered to the 5G Core
     Network via the Network Exposure Function (NEF).  The NEF serves as
     the gateway between external application functions and the internal
     control plane of the 5G Core.  To support flexible deployment and
     orchestration, these components can be implemented as containerized
     microservices and managed using Kubernetes[Kubernetes].  By passing
     the policies through the NEF, the system enables relevant 5G Core
     components such as the Policy Control Function (PCF), Session
     Management Function (SMF), and Access and Mobility Management
     Function (AMF) to enforce the translated policies in real time.  This
     ensures that the original user or service intent is consistently and
     dynamically applied throughout the network.

  4.  The Procedure for I2NSF-Based 5G Edge Security Management

     This testbed demonstrates a use case where high-level user intents
     are automatically translated into enforceable network and application
     policies.  Leveraging the I2NSF (Interface to Network Security
     Functions) framework [RFC8329] and deployed on the free5GC platform,
     this architecture enables automated, intent-driven security
     management that reduces the reliance on manual configuration and
     static rule sets.

     The system is designed to support distributed policy enforcement by
     integrating key I2NSF components such as the Intent-Based Networking
     Use Function (IUF), Intent Control Function (ICF), Security Control
     Function (SCF), and Security Data Analytics Function (SDAF).  These
     components work collaboratively to process intents, generate
     appropriate policies, and enforce them dynamically across both the
     core network and the edge.


                   +--------------+
                   |User Equipment|
                   +--------------+
                          ^  Appplication Policy
                          |    (Configuration)
                          |          +-------------------+
  +-----+             +--------+     |    IBN Control    |         +----------+
  | NEF |<------------+ Router |<----+      Function     |<--------+ IBN Use  |
  +-----+   Network   +--------+     |(Intent Translator)|  Intent | Function |
  5G Core   Policy                   +-------------------+         +----------+
  Network (Firewall& WebFilter)



  Ahn, et al.              Expires 29 August 2026                 [Page 7]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     Figure 2: The Procedure of Policy Generation and Delivery for 5G
                               Edge Network

     Figure 2 shows the procedure for 5G Edge Security Management
     Automation, specifically illustrating the creation of user intents
     and the generation of corresponding network policies and application
     policies.  The process begins when a user or administrator expresses
     a security-related intent via the IBN Use Function (IUF).  This
     intent, representing a high-level goal such as restricting access to
     certain websites or monitoring device behavior, is passed to the IBN
     Control Function (ICF).  The ICF, equipped with an Intent Translator,
     converts this intent into both network-level and application-level
     policies.  The translated network-level policies are forwarded
     through the router to the 5G Core's Network Exposure Function (NEF)
     [TS-29.503], while the application-level policies are delivered
     directly to the User Equipment (UE).  This enables consistent policy
     enforcement from the core network to the device edge.


             User Equipment 1 (SmartPhone)  User Equipment 2 (IoT Device)
                +---------------------+        +---------------------+
                | +-----------------+ |        | +-----------------+ |
                | |Service Functions| |        | |Service Functions| |
                | |      (SFs)      | |        | |      (SFs)      | |
                | +-----------------+ |        | +-----------------+ |
                |          ^ |        |        |          ^ |        |
                |Monitoring| |  API   |        |Monitoring| |  API   |
                |   Data   | |Command |        |   Data   | |Command |
                |          | V        |        |          | V        |
                |   +--------------+  |        |   +--------------+  |
                |   |IBN Controller|  |        |   |IBN Controller|  |
                |   +--------------+  |        |   +--------------+  |
                |          ^  |       |        |        ^       |    |
                +----------+--+-------+        +--------+-------+----+
                           |  |                         |       |
                           |  +---------------------------------+
                           |                            |       |
                           +--------------+-----+-------+----+  +
                     Application Policy   |     |            |  |
                      (Configuration)     |     |            |  |
                                          |     |            |  |
              +---------------------------+-----+-----+      |  |
              |                           |     |     |      |  |
  +--------+  |   +------+   +-----+   +--+--+  |     |      |  |
  |  Data  +--|---+ NSFs +---+ UPF +---+ gNB |  |     |      |  |
  | Network|  |   +------+   +--+--+   +--+--+  |     |      |  |
  +--------+  |                 |         |     |     |      |  |
              |              +--+--+   +--+--+  |     |      |  |



  Ahn, et al.              Expires 29 August 2026                 [Page 8]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


              |              | SMF |   | AMF +--+     |      |  |
              |              +--+--+   +--+--+        |      |  |
              |                 |         |           |    +-+--+---+
              |  ------------+--+-----+---+----+---   |    | Router +---+
              |              |        |        |      |    +---+----+   |
              |           +--+--+  +--+--+  +--+--+   |        |        |
              |           | DMF |  | SCF |  | NEF |<--+--------+        |
              |           +--+--+  +--+--+  +--+--+   | Network         |
              |                                       | Policy          |
              |                                       | (Firewall       |
              +---------------------------------------+ & Web Filter)   |
                            5G Core Network                             |
                                                             Monitoring |
                                                               Report   |
                                                                        V
                                                          +-------------------+
                                                          |   Security Data   |
                                                          | Analytics Function|
                                                          +---------+---------+
                                                                    |
                                                    +---------------+---------+
                                                    | Monitoring Data Storage |
                                                    +-------------------------+

      Figure 3: The Procedure within an I2NSF-Based Framework for 5G
                         Edge Security Management

     Figure 3 illustrates the procedure of how the intent-driven network
     policies and application policies are applied across both the 5G core
     network and user equipment.  These policies are then propagated
     throughout the 5G network to support coordinated and consistent
     security enforcement.  Network-level policies are distributed to core
     network functions [TS-23.501], where they help guide the overall
     behavior and resource allocation of the system in alignment with the
     user's intent.  At the same time, application-level policies are
     delivered to various user devices, such as smartphones and IoT nodes,
     which have embedded controllers capable of interpreting and enforcing
     the received policies locally.

     This allows each device to autonomously adjust its behavior according
     to the defined security or operational requirements.  In parallel,
     network-based security functions are also engaged to apply the
     necessary controls, such as access restrictions or traffic filtering,
     ensuring that both the core and the edge of the network operate
     securely and in harmony with the original intent.  This distributed
     approach enables flexible, scalable, and adaptive policy enforcement
     across the entire mobile network environment [TS-23.288].




  Ahn, et al.              Expires 29 August 2026                 [Page 9]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     To support adaptive security validation, each user equipment's IBN
     Controller periodically generates monitoring reports based on local
     policy enforcement status.  These reports are sent to the Security
     Data Analytics Function (SDAF), which analyzes the monitoring data to
     evaluate whether the applied policies are effectively enforced.  All
     collected data is stored in a centralized Monitoring Data Storage
     module, enabling real-time policy validation and historical auditing.
     The related steps are as follows:

     *  Steps 1-2: An intent is sent from an application within the 5G
        Core to the IBN Control Function (ICF), where it is translated
        into network and application policies.  This marks the beginning
        of intent-driven automation for security management.

     *  Step 3: The network policy is delivered via the NEF to relevant 5G
        Core functions and connected security components.  These
        components then prepare for the enforcement of the policy.

     *  Step 4: The application policy is sent to the IBN Controllers on
        target user devices.  This allows the devices to receive
        instructions without direct user intervention.

     *  Step 5: Each device applies the policy to adjust its settings and
        behavior.  The changes take effect locally to reflect the system-
        wide intent.

     *  Step 6: Devices monitor their own status and send relevant data
        back to their IBN Controllers.  This ensures continuous awareness
        of policy impact at the device level.

     *  Step 7: The IBN Controllers compile and forward the data as
        monitoring reports.  These reports provide a basis for evaluating
        the effectiveness of the applied policies.

     *  Step 8: The reports are analyzed to check if the policies are
        working as intended, and the results are stored for future use.
        This completes the feedback loop that enables adaptive policy
        refinement.













  Ahn, et al.              Expires 29 August 2026                [Page 10]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     Through this process, the system enables intent-driven security
     management that spans from core network functions to individual user
     devices.  By translating high-level intents into enforceable policies
     and continuously monitoring their effects, the architecture supports
     real-time adaptation to network conditions and user behaviors.  This
     ensures that security enforcement remains consistent, context-aware,
     and autonomous throughout distributed edge environments.  Moreover,
     the closed-loop structure provides a foundation for scalable and
     self-optimizing policy management, which is essential for future 5G
     edge-native networks.

     Also, the proposed system extends the core components such as the
     Intent-Based Networking Use Function (IUF), Intent Control Function
     (ICF), and distributed enforcement modules to operate in tandem with
     the handover procedures defined in 3GPP specifications.  This helps
     keep security consistent and smart across the edge network where
     quick response and local control are especially important.  This
     approach can also be applied to mobility scenarios where intent-
     driven security policies need to dynamically migrate and be re-
     enforced as User Equipment (UE) transitions between gNBs.

  5.  Security Considerations Sections

     In the context of intent-based edge security management in 5G
     networks, several important security aspects must be considered to
     ensure robust and trustworthy system behavior.  One key concern
     involves the potential for malicious manipulation of user intents.
     Since intents are high-level expressions of user goals that drive the
     automated generation of network and application policies, any
     unauthorized alteration could lead to unintended or insecure
     outcomes.  Ensuring that each intent originates from a trusted source
     and is protected by integrity validation mechanisms is therefore
     essential.

     Another important consideration is the accuracy and reliability of
     the policy translation and enforcement process.  When translating
     abstract intents into concrete policies, the system must preserve the
     user's original intent without introducing misconfigurations or
     inconsistencies.  Incorporating validation checks and feedback
     mechanisms helps to ensure that policies are correctly interpreted
     and consistently applied across the network.  To further enhance this
     process, deep learning techniques [Deep-Learning] can be employed to
     detect anomalies, learn from past policy enforcement outcomes, and
     adaptively improve the translation logic based on contextual patterns
     and historical data.






  Ahn, et al.              Expires 29 August 2026                [Page 11]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


  6.  IANA Considerations

     This document does not require any IANA actions.

  7.  References

  7.1.  Normative References

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/info/rfc6020>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/info/rfc6241>.

     [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
                Networking: A Perspective from within a Service Provider
                Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
                <https://www.rfc-editor.org/info/rfc7149>.

     [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
                RFC 7950, DOI 10.17487/RFC7950, August 2016,
                <https://www.rfc-editor.org/info/rfc7950>.

     [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
                <https://www.rfc-editor.org/info/rfc8040>.

     [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
                Kumar, "Framework for Interface to Network Security
                Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
                <https://www.rfc-editor.org/info/rfc8329>.

     [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
                Tantsura, "Intent-Based Networking - Concepts and
                Definitions", RFC 9315, DOI 10.17487/RFC9315, October
                2022, <https://www.rfc-editor.org/info/rfc9315>.

  7.2.  Informative References

     [YAML]     Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another
                Markup Language (YAML) 1.0",
                Available: https://yaml.org/spec/history/2001-05-26.html,
                October 2023.




  Ahn, et al.              Expires 29 August 2026                [Page 12]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     [TS-23.501]
                "System Architecture for the 5G System (5GS)", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3144, September
                2023.

     [TS-28.312]
                "Intent Driven Management Services for Mobile Networks",
                Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3554, September
                2023.

     [TS-23.288]
                "Architecture Enhancements for 5G System (5GS) to Support
                Network Data Analytics Services", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3579, September
                2023.

     [TS-29.503]
                "Service-Based Interface Specifications for the Network
                Exposure Function (NEF)", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3342, September
                2023.

     [TS-29.520]
                "Network Data Analytics Services", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3355, September
                2023.

     [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural
                Framework", Available:
                https://www.etsi.org/deliver/etsi_gs/
                nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
                December 2014.

     [REST]     Fielding, R. and R. Taylor, "Principled Design of the
                Modern Web Architecture", ACM Transactions on Internet
                Technology, Vol. 2, Issue 2,,
                Available: https://dl.acm.org/doi/10.1145/514183.514185,
                May 2002.







  Ahn, et al.              Expires 29 August 2026                [Page 13]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     [Deep-Learning]
                Goodfellow, I., Bengio, Y., and A. Courville, "Deep
                Learning", Publisher: The MIT Press,
                Available: https://www.deeplearningbook.org/, November
                2016.

     [Kubernetes]
                "Kubernetes: Cloud Native Computing Platform",
                Available: https://kubernetes.io/, March 2024.

     [Survey-IBN-CST-2023]
                Leivadeas, A. and M. Falkner, "A Survey on Intent-Based
                Networking",
                Available: https://ieeexplore.ieee.org/document/9925251,
                March 2023.

     [ClickINC-Sigcomm-2023]
                Xu, W., Zhang, Z., Feng, Y., Song, H., Chen, Z., Wu, W.,
                Liu, G., Zhang, Y., Liu, S., Tian, Z., and B. Liu,
                "ClickINC: In-network Computing as a Service in
                Heterogeneous Programmable Data-center Networks",
                Publisher: ACM SIGCOMM,
                Available: https://dl.acm.org/doi/10.1145/3603269.3604835,
                September 2023.

  Acknowledgments

     This work was supported by Institute of Information & Communications
     Technology Planning & Evaluation (IITP) grant funded by the Korea
     Ministry of Science and ICT (MSIT) (No.  RS-2024-00398199 and RS-
     2022-II221015).

     This work was supported in part by Institute of Information &
     Communications Technology Planning & Evaluation (IITP) grant funded
     by the Korea Ministry of Science and ICT (MSIT) (No.  IITP-2025-RS-
     2022-II221199, Regional strategic industry convergence security core
     talent training business).

  Contributors

     This document is made by the group effort of NMRG, greatly benefiting
     from inputs and texts by Linda Dunbar (Futurewei), Yong-Geun Hong
     (Daejeon University), and Joo-Sang Youn (Dong-Eui University).  The
     authors sincerely appreciate their contributions.

     The following is the coauthor of this document:





  Ahn, et al.              Expires 29 August 2026                [Page 14]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     Mose Gu
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: rna0415@skku.edu
     URI:   http://iotlab.skku.edu/people-Moses-Gu.php


  Authors' Addresses

     Yoseop Ahn (editor)
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: ahnjs124@skku.edu
     URI:   http://iotlab.skku.edu/people-Ahn-Yoseop.php


     Jaehoon Paul Jeong (editor)
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4957
     Email: pauljeong@skku.edu
     URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


     Younghan Kim
     School of Electronic Engineering
     Soongsil University
     369, Sangdo-ro, Dongjak-gu
     Seoul
     06978
     Republic of Korea



  Ahn, et al.              Expires 29 August 2026                [Page 15]


  Internet-Draft  An 5G Integrated Security Service System   February 2026


     Email: younghak@ssu.ac.kr


















































  Ahn, et al.              Expires 29 August 2026                [Page 16]


name: draft-ietf-netconf-configuration-tracing
rev: 06
title: External Trace ID for Configuration Tracing
time: 2025-11-03T09:57:35Z
group_uri: /api/v1/group/group/1575/
expires: 2026-05-07T09:57:35Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/41/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.557114+00:00
source: ietf
source_id: 131881
source_url: https://datatracker.ietf.org/doc/draft-ietf-netconf-configuration-tracing/
doc_status: active
abstract:
  Network equipment are often configured by a variety of network
     management systems (NMS), protocols, and teams.  If a network issue
     arises (e.g., because of a wrong configuration change), it is
     important to quickly identify the root cause and obtain the reason
     for pushing that modification.  Another potential network issue can
     stem from concurrent NMSes with overlapping intents, each having
     their own tasks to perform.  In such a case, it is important to map
     the respective modifications to its originating NMS.

     This document specifies a NETCONF mechanism to automatically map the
     configuration modifications to their source, up to a specific NMS
     change request.  Such a mechanism is required, in particular, for
     autonomous networks to trace the source of a particular configuration
     change that led to an anomaly detection.  This mechanism facilitates
     the troubleshooting, the post-mortem analysis, and in the end the
     closed loop automation required for self-healing networks.  The
     specification also includes a YANG module that is meant to map a
     local configuration change to the corresponding trace id, up to the
     controller or even the orchestrator.

full_text:
  OPSAWG                                                       J. Quilbeuf
  Internet-Draft                                                    Huawei
  Intended status: Standards Track                               B. Claise
  Expires: 7 May 2026                                       Everything OPS
                                                                   T. Graf
                                                                  Swisscom
                                                                  D. Lopez
                                                            Telefonica I+D
                                                                    Q. Sun
                                                             China Telecom
                                                           3 November 2025


                External Trace ID for Configuration Tracing
                draft-ietf-netconf-configuration-tracing-06

  Abstract

     Network equipment are often configured by a variety of network
     management systems (NMS), protocols, and teams.  If a network issue
     arises (e.g., because of a wrong configuration change), it is
     important to quickly identify the root cause and obtain the reason
     for pushing that modification.  Another potential network issue can
     stem from concurrent NMSes with overlapping intents, each having
     their own tasks to perform.  In such a case, it is important to map
     the respective modifications to its originating NMS.

     This document specifies a NETCONF mechanism to automatically map the
     configuration modifications to their source, up to a specific NMS
     change request.  Such a mechanism is required, in particular, for
     autonomous networks to trace the source of a particular configuration
     change that led to an anomaly detection.  This mechanism facilitates
     the troubleshooting, the post-mortem analysis, and in the end the
     closed loop automation required for self-healing networks.  The
     specification also includes a YANG module that is meant to map a
     local configuration change to the corresponding trace id, up to the
     controller or even the orchestrator.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/netconf-wg/configuration-tracing.







  Quilbeuf, et al.           Expires 7 May 2026                   [Page 1]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


  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 7 May 2026.

  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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Configuration Mistakes  . . . . . . . . . . . . . . . . .   5
       3.2.  Concurrent NMS Configuration  . . . . . . . . . . . . . .   5
       3.3.  Conflicting Intents . . . . . . . . . . . . . . . . . . .   5
       3.4.  Not a use case: Onboarding  . . . . . . . . . . . . . . .   5
     4.  Relying on W3C Trace Context to Trace Configuration
             Modifications . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Existing configuration metadata on device . . . . . . . .   6
       4.2.  Client ID . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Instantiating the YANG module . . . . . . . . . . . . . .   6
       4.4.  Using the YANG module . . . . . . . . . . . . . . . . . .   7
     5.  YANG module . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9



  Quilbeuf, et al.           Expires 7 May 2026                   [Page 2]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


       5.2.  YANG module ietf-external-transaction-id  . . . . . . . .  10
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.  Open Issues / TODO  . . . . . . . . . . . . . . . . . . . . .  14
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  15
     11. Informative References  . . . . . . . . . . . . . . . . . . .  16
     Appendix A.  Changes between revisions  . . . . . . . . . . . . .  17
     Appendix B.  Example of NETCONF message . . . . . . . . . . . . .  17
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

  1.  Introduction

     Issues arising in the network, for instance violation of some SLAs,
     might be due to some configuration modification.  In the context of
     automated networks, the assurance system needs not only to identify
     and revert the problematic configuration modification, but also to
     make sure that it won't happen again and that the fix will not
     disrupt other services.  To cover the last two points, it is
     imperative to understand the cause of the problematic configuration
     change.  Indeed, the first point, making sure that the configuration
     modification will not be repeated, cannot be ensured if the cause for
     pushing the modification in the first place is not known.  Ensuring
     the second point, not disrupting other services, requires as well
     knowing if the configuration modification was pushed in order to
     support new services.  Therefore, we need to be able to trace a
     configuration modification on a device back to the reason that
     triggered that modification, for instance in a NMS, whether the
     controller or the orchestrator.

     This specification focuses only on configuration pushed via NETCONF
     [RFC6241] or RESTCONF [RFC8040].  The rationale for this choice is
     that NETCONF is better suited for normalization than other protocols
     (SNMP, CLI).  Another reason is that the notion of trace context,
     useful to track configuration modifications, has been ported to
     NETCONF in [I-D.ietf-netconf-trace-ctx-extension] and RESTCONF in
     [I-D.ietf-netconf-restconf-trace-ctx-headers].

     The same network element, or NETCONF [RFC6241] server, can be
     configured by different NMSs or NETCONF clients.  If an issue arises,
     one of the starting points for investigation is the configuration
     modification on the devices supporting the impacted service.  In the
     best case, there is a dedicated user for each client and the
     timestamp of the modification allows tracing the problematic
     modification to its cause.  In the worst case, everything is done by
     the same user and some more correlations must be done to trace the
     problematic modification to its source.



  Quilbeuf, et al.           Expires 7 May 2026                   [Page 3]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     This document specifies a mechanism to automatically map the
     configuration modifications to their source, up to a specific NMS
     service request.  Practically, this mechanism annotates configuration
     changes on the configured element with sufficient information to
     unambiguously identify the corresponding transaction, if any, on the
     element that requested the configuration modification.  It reuses the
     concept of Trace Context [W3C-Trace-Context] applied to NETCONF as in
     [I-D.ietf-netconf-trace-ctx-extension] The information needed to
     trace the configuration is stored in a new YANG module that maps a
     local configuration change to some additional metadata.  The
     additional metadata contains the trace ID, and, if the local change
     is not the beginning of the trace, the ID of the client that
     triggered the local-change.  In that sense, it is an instance of the
     YANG DataStore implementation of the Trace Context as proposed in
     Section 1.2 of [I-D.ietf-netconf-trace-ctx-extension].

  2.  Terminology

     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, as shown here.

     This document uses the terms client and server from [RFC6241].

     This document uses the terms transaction and Transaction ID from
     [I-D.ietf-netconf-transaction-id].

     This document uses the term trace ID from [W3C-Trace-Context].

     Local Commit ID  Identifier of a local configuration change on a
        Network Equipment, Controller, Orchestrator or any other device or
        software handling configuration.  Such an identifier is usually
        present in devices that can show a history of the configuration
        changes, to identify one such configuration change.

  3.  Use cases

     This document was written with autonomous networks in mind.  We
     assume that an existing monitoring or assurance system, such as
     described in [RFC9417], is able to detect and report network
     anomalies , e.g. SLA violations, intent violations, network failure,
     or simply a customer issue.  Here are the use cases for the proposed
     YANG module; they are extensions of the "Provisioning root cause
     analysis" use case presented in Section 1.3.1 of
     [I-D.ietf-netconf-trace-ctx-extension].




  Quilbeuf, et al.           Expires 7 May 2026                   [Page 4]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


  3.1.  Configuration Mistakes

     Taking into account that many network anomalies are due to
     configuration mistakes, this mechanism allows to find out whether the
     offending configuration modification was triggered by a tracing-
     enabled client/NMS.  In such a case, we can map the offending
     configuration modification id on a server/NE to a local configuration
     modification id on the client/NMS.  Assuming that this mechanism (the
     YANG module) is implemented on the controller, we can recursively
     find, in the orchestrator, the latest (set of of) service request(s)
     that triggered the configuration modification.  Whether this/those
     service request(s) are actually the root cause needs to be
     investigated.  However, they are a good starting point for
     troubleshooting, post-mortem analysis, and in the end the closed loop
     automation, which is absolutely required for self-healing networks.

  3.2.  Concurrent NMS Configuration

     Building on the previous use case is the situation where two NMS's,
     unaware of each other, are configuring a common router, each
     believing that they are the only NMS for the common router.  So one
     configuration executed by the NMS1 is overwritten by the NMS2, which
     in turn is overwritten by NMS1, etc.

  3.3.  Conflicting Intents

     Autonomous networks will be solved first by assuring intent per
     specific domain; for example data center, core, cloud, etc.  This
     last use case is a more specific "Concurrent NMS configuration" use
     case where assuring domain intent breaks the entire end to end
     service, even if the domain-specific controllers are aware of each
     other.

  3.4.  Not a use case: Onboarding

     During onboarding, a newly added device is likely to receive a
     multiple configuration message, as it needs to be fully configured.
     Our use cases focus more on what happens after the initial
     configuration is done, i.e. when the "stable" configuration is
     modified.

  4.  Relying on W3C Trace Context to Trace Configuration Modifications









  Quilbeuf, et al.           Expires 7 May 2026                   [Page 5]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


  4.1.  Existing configuration metadata on device

     This document assumes that NETCONF clients or servers (orchestrators,
     controllers, devices, ...) have some kind of mechanism to record the
     modifications done to the configuration.  For instance, devices
     typically have a history of configuration changes and this history
     associates a locally unique identifier to some metadata, such as the
     timestamp of the modification, the user doing the modification or the
     protocol used for the modification.  Such a locally unique identifier
     is a Local Commit ID, we assume that it exists on the platform.  This
     Local Commit ID is the link between the module presented in this
     draft and the device-specific way of storing configuration changes.

  4.2.  Client ID

     This document assumes that each NETCONF client for which
     configuration must be traced (for instance orchestrator and
     controllers) has a unique client ID among the other NETCONF clients
     in the network.  Such an ID could be an IP address or a host name.
     The mechanism for providing and defining this client ID is out of
     scope of the current document.

  4.3.  Instantiating the YANG module

     [I-D.ietf-netconf-trace-ctx-extension] defines a NETCONF extension
     providing the trace context from [W3C-Trace-Context].  Using this
     mechanism, the NETCONF server captures the trace-id, when available,
     and maps it to a local commit ID, by populating the YANG module.

     The trace context from W3C provides a parent-id.  This parent-id does
     not identify a particular server or NMS but rather one request in the
     chain of HTTP requests constituting the trace.  Similarly to the
     passing of the trace context in
     [I-D.ietf-netconf-trace-ctx-extension], we propose an XML attribute
     on NETCONF messages to pass the client-id.  The attribute name is
     "client-id" and the namespace is the namespace of the YANG module
     from Section 5, namely 'urn:ietf:params:xml:ns:yang:ietf-external-
     transaction-id'.  An example of a commit message including the
     client-id is shown in Figure 4.












  Quilbeuf, et al.           Expires 7 May 2026                   [Page 6]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


                              +---------------+
                              | Orchestrator  |
                              +---------------+
                                     | tr-1, tx-1
                                     v
                              +---------------+
                              |   Controller  |
                              +---------------+
                     tr-1, tx-2 |           | tr-1, tx-3
                                v           v
                             +-----+     +-----+
                             | NE1 |     | NE2 |
                             +-----+     +-----+


       Figure 1: Example of Hierarchical Configuration. tx: transaction.
                                   tr: trace.

     In Figure 1, the transactions 'tx-1', 'tx-2' and 'tx-3' are sent via
     NETCONF.  The NETCONF RPC used, most likely 'commit' in our use case,
     is annotated with the 'traceparent' annotation as defined in
     [I-D.ietf-netconf-trace-ctx-extension].  The traceparent annotation
     has the same trace id 'tr-1' for each of these transactions.
     Additionally, for each transaction the client id is passed via the
     'client-id' annotation.  For 'tx-1' the client-id is the id of the
     Orchestrator.  For 'tx-2' and 'tx-3', the client is the id of the
     Controller.

     It is technically possible that several clients push configuration to
     the candidate configuration datastore and only one of them commits
     the changes to the running configuration datastore.  From the running
     configuration datastore perspective, which is the effective one,
     there is a single modification, but caused by several clients, which
     means that this modification should have several corresponding
     client-ids.  Although, this case is technically possible, it is a bad
     practice.  We won't cover it in this document.  In other terms, we
     assume that a given configuration modification on a server is caused
     by a single client, and thus has a single corresponding client-id.

  4.4.  Using the YANG module

     The YANG module defined below enables tracing a configuration change
     in a Network Equipment back to its origin, for instance a service
     request in an orchestrator.  To do so, the Anomaly Detection System
     (ADS) should have, for each client-id, access to some credentials
     enabling read access to the YANG module for configuration tracing on
     that client.  It should as well have access to the network equipment
     in which an issue is detected.



  Quilbeuf, et al.           Expires 7 May 2026                   [Page 7]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


                                                       +---------------+
          .----------------[5]match tr-1-------------->|               |
          |                                            | Orchestrator  |
          | ----------------[6]commit-id---------------|               |
          | |                                          +---------------+
          | |                                                | tx-1
          | |                                                v
          | |                                          +---------------+
          | |   .-----------[3] match tr-1------------>|               |
          | |   |                                      |   Controller  |
          | |   | .-----------[4] c-id O tr-1----------|               |
          | |   | |                                    +---------------+
          | |   | |                                          | tx-2
          | v   | v                                          v
        +-----------+                                      +----+
        | Anomaly   |--[1] match commit-id before time t-->|    |
        | Detection |                                      | NE |
        | System    |<--------- [2] c-id C tr-1------------|    |
        +----------+                                       +----+


          Figure 2: Example of Configuration Tracing. tr: trace-id, C:
        Controller, O: orchestrator.  The number between square brackets
                      refer to steps in the listing below.

     The steps for a software to trace a configuration modification in a
     Network Equipment back to a service request are illustrated in
     Figure 2.  They are detailed below.

     1.  The Anomaly Detection System (ADS) identifies the commit-id that
         created an issue, for instance by looking for the last commit-id
         occurring before the issue was detected.  The ADS queries the NE
         for the trace id and client id associated to the commit-id.

     2.  The ADS receives the trace-id and the client-id.  In Figure 2,
         that step would receive the trace-id tr-1 and the id of the
         Controller as a result.  If there is no associated client-id, the
         change was not done by a client compatible with the present
         draft, and the investigation stops here.

     3.  The ADS queries the client identified by the client-id found at
         the previous step, looking for a match of the trace-id from the
         previous step.  In Figure 2, for that step, the software would
         look for the trace-id tr-1 stored in the Controller.







  Quilbeuf, et al.           Expires 7 May 2026                   [Page 8]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     4.  From that query, the ADS knows the local-commit-id on the client
         (Controller in our case).  Since the local-commit-id is
         associated to a client-id pointing to the Orchestrator, the ADS
         continues the investigation.

     5.  The ADS queries the Orchestrator, trying to find a match for the
         trace-id tr-1.

     6.  Finally, the ADS receives the commit-id from the Orchestrator
         that ultimately caused the issue in the NE.  Since there is no
         associated client-id, the investigation stops here.  The
         modification associated to the commit-id, for instance a service
         request, is now available for further manual or automated
         analysis, such as analyzing the root cause of the issue.

     Note that step 5 and 6 are actually a repetition of step 3 and 4.
     The general algorithm is to continue looking for a client until no
     more client-id can be found in the current element.

  5.  YANG module

     We present in this section the YANG module for modelling the
     information about the configuration modifications.

  5.1.  Overview

     The tree representation [RFC8340] of our YANG module is depicted in
     Figure 3

     module: ietf-external-transaction-id
       +--ro external-transactions-id
          +--ro configuration-change* [local-commit-id]
             +--ro local-commit-id    string
             +--ro timestamp?         yang:date-and-time
             +--ro trace-parent
             |  +--ro version?       hex-digits
             |  +--ro trace-id?      hex-digits
             |  +--ro parent-id?     hex-digits
             |  +--ro trace-flags?   hex-digits
             +--ro client-id?         string


         Figure 3: Tree representation of ietf-external-transaction-id
                                  YANG module

     The local-commit-id represents the local id of the configuration
     changes, which is device-specific.  It can be used to retrieve the
     local configuration changes that happened during that transaction.



  Quilbeuf, et al.           Expires 7 May 2026                   [Page 9]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     The trace-parent is present to identify the trace associated to the
     local-commit-id.  This trace-parent can be transmitted by a client or
     created by the current server.  In Section 4.4, the most important
     field in trace-parent is the trace-id.  We also included the other
     fields for trace-parent as defined in [W3C-Trace-Context] for the
     sake of completion.  In some cases, for instance direct configuration
     of the device, the device may choose to not include the trace-id.

     The presence of a client-id indicates that the trace-parent has been
     transmitted by that client.  If the trace is initiated by the current
     server, there is no associated client-id.

     Even if this document focuses only on NETCONF or RESTCONF, the use
     cases defined in Section 3 are not specific to NETCONF or RESTCONF
     and the mechanism described in this document could be adapted to
     other configuration mechanisms.  For instance, a configuration
     modification pushed via CLI can be identified via a label, which
     could contain the trace-parent.  As such cases are difficult to
     standardize, we won't cover them in this document.

  5.2.  YANG module ietf-external-transaction-id

     <CODE BEGINS> file "ietf-external-transaction-id@2021-11-03.yang"
     module ietf-external-transaction-id {
       yang-version 1.1;
       namespace
         "urn:ietf:params:xml:ns:yang:ietf-external-transaction-id";
       prefix ext-txid;

       import ietf-yang-types {
         prefix yang;
         reference
           "RFC 6991: Common YANG Data Types, Section 3";
       }

       organization
         "IETF NETCONF Working Group";
       contact
         "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
          WG List:  <mailto:netconf@ietf.org>
          Author:   Benoit Claise  <mailto:benoit.claise@huawei.com>
          Author:   Jean Quilbeuf  <mailto:jean.quilbeuf@huawei.com>";
       description
         "This module enables tracing of configuration changes in a
          network for the sake of automated correlation between
          configuration changes and the external request that triggered
          that change.




  Quilbeuf, et al.           Expires 7 May 2026                  [Page 10]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


          The module stores the identifier of the trace, if any, that
          triggered the change in a device. If that trace-id was provided
          by a client, (i.e. not created locally by the server), the id
          of that client is stored as well to indicated which client
          triggered the configuration change.

          Copyright (c) 2025 IETF Trust and the persons identified as
          authors of the code.  All rights reserved.

          Redistribution and use in source and binary forms, with or
          without modification, is permitted pursuant to, and subject
          to the license terms contained in, the Revised BSD License
          set forth in Section 4.c of the IETF Trust's Legal Provisions
          Relating to IETF Documents
          (https://trustee.ietf.org/license-info).
          This version of this YANG module is part of RFC XXXX; see the
          RFC itself for full legal notices.  ";

       revision 2022-10-20 {
         description
           "Initial revision";
         reference
           "RFC xxxx: External Trace ID for Configuration Tracing";
       }

       typedef hex-digits {
         type string {
           pattern '[0-9a-f]*';
         }
         description
           "A string composed of hexadecimal digits. Digits represented by
            letters are restricted to lowercase so that a single
            representation of a given value is allowed. This enables using
            the string equality to check equality of the represented
            values.";
       }

       grouping trace-parent-g {
         description
           "Trace parent frow the W3C trace-context recommandation.
            Follows the format version 00.";
         leaf version {
           type hex-digits {
             length "2";
           }
           must "../version = '00'";
           description
             "Version of the trace context. Must be 00 to match the



  Quilbeuf, et al.           Expires 7 May 2026                  [Page 11]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


              format described in this module.";
         }
         leaf trace-id {
           type hex-digits {
             length "32";
           }
           must "../trace-id != '00000000000000000000000000000000'";
           description
             "Trace ID that is common for every transaction that is
              part of the configuration chain. This value can be used
              to match a local commit id to a commit local to another
              system.";
         }
         leaf parent-id {
           type hex-digits {
             length "16";
           }
           description
             "ID of the request (client-side) that lead to configuring
              the server hosting this module.";
         }
         leaf trace-flags {
           type hex-digits {
             length "2";
           }
           description
             "Flags enabled for this trace. See W3C reference for the
              details about flags.";
         }
       }

       container external-transactions-id {
         config false;
         description
           "Contains the IDs of configuration transactions that are
            external to the device.";
         list configuration-change {
           key "local-commit-id";
           description
             "List of configuration changes, identified by their
              local-commit-id";
           leaf local-commit-id {
             type string;
             description
               "Stores the identifier as saved by the server. Can be used
                to retrieve the corresponding changes using the server
                mechanism if available.";
           }



  Quilbeuf, et al.           Expires 7 May 2026                  [Page 12]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


           leaf timestamp {
             type yang:date-and-time;
             description
               "A timestamp that can be used to further filter change
                events.";
           }
           container trace-parent {
             description
               "Trace parent associated to the local-commit-id. If a
                client ID is present as well, the trace context was
                transmitted by that client. If not, the trace context was
                created locally.

                This trace-parent must come from the trace context of the
                request actually modifying the running configuration
                datastore. This request might be an edit-config or a
                commit depending on whether the candidate datastore is
                used.";
             uses trace-parent-g;
           }
           leaf client-id {
             type string;
             description
               "ID of the client that originated the modification, to
                further query information about the corresponding
                change.

                This data node is present only when the configuration was
                pushed by a compatible system.";
           }
         }
       }
     }
     <CODE ENDS>

  6.  Security Considerations

     This section is modeled after the template described in Section 3.7
     of [I-D.ietf-netmod-rfc8407bis].

     The "ietf-external-transaction-id" module defines a data model that
     is designed to be accessed via YANG-based management protocols, such
     as NETCONF [RFC6241] and RESTCONF[RFC8040].  These protocols have to
     use a secure transport layer (e.g., SSH [RFC6242], TLS [RFC8446] and
     QUIC [RFC9000]) and have to use mutual authentication.






  Quilbeuf, et al.           Expires 7 May 2026                  [Page 13]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     The Network Configuration Access Control Model (NACM) [RFC8341]
     provides the means to restrict access for particular NETCONF or
     RESTCONF users to a preconfigured subset of all available NETCONF or
     RESTCONF protocol operations and content.

     Some of the readable data nodes in this YANG module may be considered
     sensitive or vulnerable in some network environments.  It is thus
     important to control read access (e.g., via get, get-config, or
     notification) to these data nodes.  Specifically, the following
     subtrees and data nodes have particular sensitivities/
     vulnerabilities:

     *  external-transactions-id/configuration-change exposes information
        about which user or external system can configure the device and
        could help an attacker to send its own configuration to the
        device.  It could also give some information about the
        architecture of the configuration, i.e. what are the controllers
        and the orchestrators.

  7.  IANA Considerations

     RFC Ed.: replace XXXX with actual RFC number and remove this note.

     IANA is requested to register the following URI in the "ns"
     subregistry within the "IETF XML Registry" [RFC3688]:

             URI: urn:ietf:params:xml:ns:yang:ietf-external-transaction-id
             Registrant Contact:  The IESG.
             XML: N/A; the requested URI is an XML namespace.

     IANA is requested to register the following YANG module in the "YANG
     Module Names" subregistry [RFC6020] within the "YANG Parameters"
     registry.

          Name: ietf-external-transaction-id
          Maintained by IANA?  N
          Namespace: urn:ietf:params:xml:ns:yang:ietf-external-transaction-id
          Prefix: ext-txid
          Reference: RFC XXXX

  8.  Contributors

  9.  Open Issues / TODO

     This section is to be removed before publishing as an RFC.

     None




  Quilbeuf, et al.           Expires 7 May 2026                  [Page 14]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


  10.  Normative References

     [I-D.ietf-netconf-restconf-trace-ctx-headers]
                Gagliano, R., Larsson, K., and J. Lindblad, "RESTCONF
                Extension to Support Trace Context Headers", Work in
                Progress, Internet-Draft, draft-ietf-netconf-restconf-
                trace-ctx-headers-07, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
                restconf-trace-ctx-headers-07>.

     [I-D.ietf-netconf-trace-ctx-extension]
                Gagliano, R., Larsson, K., and J. Lindblad, "NETCONF
                Extension to support Trace Context propagation", Work in
                Progress, Internet-Draft, draft-ietf-netconf-trace-ctx-
                extension-05, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
                trace-ctx-extension-05>.

     [I-D.ietf-netconf-transaction-id]
                Lindblad, J., "Transaction ID Mechanism for NETCONF", Work
                in Progress, Internet-Draft, draft-ietf-netconf-
                transaction-id-07, 19 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
                transaction-id-07>.

     [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>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/info/rfc6241>.

     [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
                Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
                <https://www.rfc-editor.org/info/rfc6242>.

     [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
                <https://www.rfc-editor.org/info/rfc8040>.

     [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>.





  Quilbeuf, et al.           Expires 7 May 2026                  [Page 15]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
                BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
                <https://www.rfc-editor.org/info/rfc8340>.

     [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
                Access Control Model", STD 91, RFC 8341,
                DOI 10.17487/RFC8341, March 2018,
                <https://www.rfc-editor.org/info/rfc8341>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

     [W3C-Trace-Context]
                "W3C Recommendation on Trace Context", 23 November 2021,
                <https://www.w3.org/TR/2021/REC-trace-context-
                1-20211123/>.

  11.  Informative References

     [I-D.ietf-netmod-rfc8407bis]
                Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
                Authors and Reviewers of Documents Containing YANG Data
                Models", Work in Progress, Internet-Draft, draft-ietf-
                netmod-rfc8407bis-28, 5 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
                rfc8407bis-28>.

     [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
                DOI 10.17487/RFC3688, January 2004,
                <https://www.rfc-editor.org/info/rfc3688>.

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/info/rfc6020>.

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/info/rfc9000>.

     [RFC9417]  Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
                Arumugam, "Service Assurance for Intent-Based Networking
                Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
                <https://www.rfc-editor.org/info/rfc9417>.





  Quilbeuf, et al.           Expires 7 May 2026                  [Page 16]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


  Appendix A.  Changes between revisions

     This section is to be removed before publishing as an RFC.

     05 -> 06

     *  Change Benoit's affiliation

     04 -> 05

     *  Fix security considerations template

     03 -> 04

     *  Add security and IANA considerations

     01 -> 02

     *  Remove YANG specific annotation for the mechanism to pass the
        client-id.

     *  Align with NETCONF Trace context draft.

     00(WG adoption) -> 01

     *  Define mechanism to pass the client-id.

     01 -> 02

     *  Switch to trace-parent instead of transaction id for tracing
        configuration

     00 -> 01

     *  Define Parent and Child Transaction

     *  Context for the "local-commit-id" concept

     *  Feedback from Med, both in text and YANG module

  Appendix B.  Example of NETCONF message










  Quilbeuf, et al.           Expires 7 May 2026                  [Page 17]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"
          xmlns:w3ctc="urn:ietf:params:xml:ns:netconf:w3ctc:1.0"
          xmlns:ext-txid=
            "urn:ietf:params:xml:ns:yang:ietf-external-transaction-id"
          w3ctc:traceparent=
            "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"
          ext-txid:client-id="controller-01">
       <commit/>
     </rpc>


            Figure 4: Example of NETCONF commit RPC with annotations

     In Figure 4, we present an RPC annotated with the traceparent and the
     client-id.  The traceparent example is taken from
     [I-D.ietf-netconf-trace-ctx-extension].  The client-id annotation is
     defined in our YANG module.  Here the client-id passed is
     'controller-01'.

  Acknowledgements

     The authors would like to thank Mohamed Boucadair, Jan Linblad and
     Roque Gagliano for their reviews and propositions.

  Authors' Addresses

     Jean Quilbeuf
     Huawei
     Email: jean.quilbeuf@huawei.com


     Benoit Claise
     Everything OPS
     Email: benoit@everything-ops.net


     Thomas Graf
     Swisscom
     Binzring 17
     CH-8045 Zurich
     Switzerland
     Email: thomas.graf@swisscom.com









  Quilbeuf, et al.           Expires 7 May 2026                  [Page 18]


  Internet-Draft     Configuration Tracing via trace-id      November 2025


     Diego R. Lopez
     Telefonica I+D
     Don Ramon de la Cruz, 82
     Madrid  28006
     Spain
     Email: diego.r.lopez@telefonica.com


     Qiong Sun
     China Telecom
     Email: sunqiong@chinatelecom.cn








































  Quilbeuf, et al.           Expires 7 May 2026                  [Page 19]


name: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps
rev: 13
title: Zeroconf Multicast Address Allocation Problem Statement and Requirements
time: 2026-02-26T17:46:14Z
group_uri: /api/v1/group/group/1397/
expires: 2026-08-22T04:45:48Z
ad: /api/v1/person/person/108304/
shepherd: /api/v1/person/email/stig@venaas.com/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.562436+00:00
source: ietf
source_id: 120753
source_url: https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/
doc_status: active
abstract:
  This document surveys current problems with existing protocols for
     automatically assigning multicast IP addresses in zero-configuration
     ("zeroconf") networking environments.  It addresses key challenges,
     such as link-layer address collisions, hardware limitations,
     multicast snooping inefficiencies, and the need to avoid manual
     configuration.  Based on these challenges, it derives requirements
     for a lightweight, decentralized solution for dynamically allocating
     unique multicast group addresses without central coordination.

     The document presents explicit requirements covering discovery,
     allocation, conflict detection and resolution, and lease management.
     It also evaluates considerations specific to IPv6 and IPv4 multicast
     address ranges, and identifies approaches that are unsuited for
     zeroconf deployment.  This foundation serves as a reference for
     developing future solutions for multicast address allocation that
     operate autonomously within local networks.

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/110/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
  Network Working Group                                        N. Karstens
  Internet-Draft                                                    Garmin
  Intended status: Informational                              D. Farinacci
  Expires: 21 August 2026                                      lispers.net
                                                                M. McBride
                                                                 Futurewei
                                                          17 February 2026


  Zeroconf Multicast Address Allocation Problem Statement and Requirements
               draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-13

  Abstract

     This document surveys current problems with existing protocols for
     automatically assigning multicast IP addresses in zero-configuration
     ("zeroconf") networking environments.  It addresses key challenges,
     such as link-layer address collisions, hardware limitations,
     multicast snooping inefficiencies, and the need to avoid manual
     configuration.  Based on these challenges, it derives requirements
     for a lightweight, decentralized solution for dynamically allocating
     unique multicast group addresses without central coordination.

     The document presents explicit requirements covering discovery,
     allocation, conflict detection and resolution, and lease management.
     It also evaluates considerations specific to IPv6 and IPv4 multicast
     address ranges, and identifies approaches that are unsuited for
     zeroconf deployment.  This foundation serves as a reference for
     developing future solutions for multicast address allocation that
     operate autonomously within local networks.

  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 21 August 2026.




  Karstens, et al.         Expires 21 August 2026                 [Page 1]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Link-Layer Address Collisions . . . . . . . . . . . . . . . .   4
     3.  Solution Requirements . . . . . . . . . . . . . . . . . . . .   5
     4.  IPv6 Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.  IPv4 Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Appendix A.  Excluded Solutions . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     Multicast communication is commonly used in networks that need to
     distribute data from one sender to multiple receivers efficiently.
     In some environments, such as small or isolated networks, multicast
     must operate without centralized servers or manual configuration.
     These are referred to as zero-configuration (zeroconf) multicast
     networks.

     One example of such an environment is marine networks, which
     typically include a mix of sensors, controls, and displays.  These
     networks vary in complexity depending on the size and design of the
     vessel.  Devices may range from low-cost temperature or fluid sensors
     to high-bandwidth sources such as radar, sonar, or video feeds.  Many
     marine networks are built on a single subnet and rely on Layer 2
     Ethernet switches to connect devices.




  Karstens, et al.         Expires 21 August 2026                 [Page 2]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     In these networks, multicast is the most efficient method for
     distributing sensor data to multiple displays.  However, challenges
     arise when high-bandwidth multicast streams overload links to low-
     bandwidth devices.  Cost-effective switches often do not support
     source-specific multicast (SSM) because their address table only maps
     destination MAC addresses.  Instead, each multicast stream is
     assigned a unique destination multicast IP address, and IGMP/MLD
     snooping [RFC4541] is used to control multicast delivery.  This
     method introduces limitations, especially in environments where
     switch hardware lacks advanced multicast filtering capabilities.

     While marine networks illustrate these issues well, the challenges
     they face are not unique.  Many other zeroconf multicast
     environments, such as industrial automation, small-scale AV systems,
     or ad hoc sensor networks, share similar constraints.

     [RFC2730] (MADCAP) describes a method for multicast IP address
     allocation, but its server-based model does not suit a zeroconf
     environment.  [RFC3306] and [RFC4489] both discuss similar approaches
     to host-based multicast IPv6 address allocation, but neither
     adequately prevents link-layer address collisions.  Although
     [RFC3307] establishes a framework to avoid multicast address
     collisions at both IPv6 and link layers, additional refinement is
     needed to put this into practice (see Section 4).

     This document outlines the problem space for zeroconf multicast
     address allocation, describes the key limitations of current
     protocols, details sources of link-layer address collisions, and
     defines a set of requirements for decentralized, zero-configuration
     multicast address allocation solutions.  Multicast applications
     deployed in a zeroconf environment can use these solutions to
     dynamically allocate multicast group addresses.  The manner in which
     a multicast group address is used after allocation is outside the
     scope of this document.

     The organization of IPv6 multicast and immense volume of possible
     multicast addresses makes IPv6 well-suited for zeroconf multicast
     networks.  However, IPv4 is still considered by this document for
     networks where transitioning to IPv6 remains impractical.

  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, as shown here.




  Karstens, et al.         Expires 21 August 2026                 [Page 3]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     The requirements language is used in Section 3 and applies to
     implementations conformant to the listed requirements.

  2.  Link-Layer Address Collisions

     Link-layer address collisions are a key concern in multicast
     networks, particularly when devices rely on zero-configuration
     operation.  Collisions occur when two or more multicast groups are
     assigned the same link-layer (MAC) address, leading to performance or
     forwarding issues.  This section outlines three scenarios where such
     collisions can cause problems.

     First, many host network interfaces allow filtering of multicast
     traffic directly in hardware.  When an application joins a multicast
     group, the host network stack typically programs the hardware to
     accept only traffic for that group.  However, if two groups share the
     same link-layer address, the network interface cannot distinguish
     them.  The network stack is then forced to process unwanted traffic
     in software, reducing performance and increasing CPU usage.

     Second, link-layer address collisions reduce the benefit of using
     multicast snooping switches on a network.  Section 4 of [RFC4541]
     indicates some switches forward multicast traffic based solely on the
     link-layer address, without considering the network-layer group (see
     the results for Q2 and Q3).  Although the survey is outdated,
     switches with these limitations still exist in some of the target
     deployments.  In such cases, if two multicast streams share the same
     MAC address, traffic may be sent to devices that did not request it.
     This is especially problematic when low-bandwidth links are
     overwhelmed by high-bandwidth streams.  Additional concerns related
     to the overlap of IPv6 and link-layer addresses are discussed in
     [RFC4541], Section 3.

     Third, the internal design of some switches can also contribute to
     collisions.  For example, certain switch implementations use a hash
     table with fixed buckets to store forwarding entries based on MAC
     addresses (see [US6690667B1]).  If multiple addresses hash to the
     same location and the bucket fills up, additional entries may be
     dropped or rejected, resulting in forwarding failures.

     These examples highlight why a collision-resistant multicast address
     allocation mechanism is essential in zeroconf environments.  The
     success of this approach depends on the capabilities of the hardware
     (such as the number of addresses supported by the filters in host
     network interfaces and the size of the tables maintained in switches/
     routers) and on the number of multicast groups that are subscribed to
     by a particular receiver.  When the number of entries in the filter
     tables exceeds availability, a typical fallback mechanism is to



  Karstens, et al.         Expires 21 August 2026                 [Page 4]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     bypass the filter entirely and flood traffic to the receiver.  This
     subsequently incurs a per-packet cost for any software-based
     filtering that is needed.

  3.  Solution Requirements

     A solution intended for decentralized, zero-configuration multicast
     IP address assignment is expected to operate in dynamic,
     infrastructure-free environments.  To be effective in such contexts,
     the solution needs to exhibit the following characteristics:

     1.  [REQ-1] Unique Address Assignment: Use of the solution SHALL
         result in a unique address being assigned to the multicast group
         at both the network and link layers.

     2.  [REQ-2] Resilience to Single Points of Failure: The solution
         SHALL be designed to minimize introduction of a single point of
         failure, ensuring that operation continues even if individual
         devices or links become unavailable.

     3.  [REQ-3] Zero User Configuration: It SHALL operate without
         requiring user or administrator configuration, allowing seamless
         deployment in unmanaged networks.

     4.  [REQ-4] Coexistence with Multicast Address Allocation Solutions:
         The design SHALL allow coexistence with other multicast IP
         address allocation solutions, including both manual assignment
         and existing dynamic protocols.

     5.  [REQ-5] Single-Subnet Operation: It SHALL support operation
         within a single IP subnet, which is typical in link-local or
         isolated network environments.

     6.  [REQ-6] No External Connectivity: The solution SHALL NOT require
         Internet access or connectivity to external infrastructure.

     7.  [REQ-7] Supports Multiple Host Applications: It SHALL support
         multiple applications on the same host, each independently
         allocating multicast addresses and transmitting to those
         addresses.

     8.  [REQ-8] Collision Detection and Resolution: The solution SHALL
         include mechanisms to detect and resolve multicast address
         collisions at both the network and link layers.







  Karstens, et al.         Expires 21 August 2026                 [Page 5]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     Note: In rare cases, collisions may arise after a temporary network
     partition, when different parts of the network allocate the same
     multicast address independently.  Upon reconnection, such collisions
     SHALL be detectable and resolved gracefully by ensuring that
     conflicting streams are migrated to unique addresses.

     In addition to the above, the following characteristics are
     considered desirable, but are left as recommendations to allow for
     flexibility in solution design:

     1.  [CONS-1] Multi-Subnet Support: Operation across multiple subnets
         is beneficial in more complex or routed environments and SHOULD
         be supported.

     2.  [CONS-2] Standards Compatibility: The solution SHOULD aim to
         minimize the need for changes to existing protocols or standards
         that affect backwards compatibility or deployment in existing
         networks.

     3.  [CONS-3] Cross-Platform Availability: It SHOULD use capabilities
         that are widely available across host platforms and operating
         systems.

     4.  [CONS-4] Minimal Dependency on Manufacturing Data: It SHOULD
         avoid reliance on pre-loaded configuration or device-specific
         manufacturing data.

     5.  [CONS-5] Low Overhead: The solution SHOULD minimize the volume
         and frequency of network traffic generated during normal
         operation.

     6.  [CONS-6] Advertisement: The solution SHOULD describe a mechanism
         for advertising and discovering multicast addresses allocated for
         an application.

     7.  [CONS-7] Network Topology: To allow compatibility with a variety
         of networks, the solution SHOULD work independent of the dynamics
         of the underlying topology and adjacencies.

  4.  IPv6 Considerations

     The rules for IPv6 multicast addresses, described in [RFC3307], are
     comprehensive and well-organized.  These rules must be followed by
     any solution allocating IPv6 multicast addresses, including solutions
     that meet the requirements defined in this document.  However, some
     aspects of its current organization need to be improved to ensure
     that a zeroconf multicast address assignment solution can coexist
     with other IPv6 multicast address assignment protocols.



  Karstens, et al.         Expires 21 August 2026                 [Page 6]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     For example, Section 2 of [RFC3307] explains that the last 32 bits of
     an IPv6 multicast address, called the group ID, are mapped directly
     to the Ethernet MAC address.  Different parts of the group ID range
     are assigned based on how the address is allocated.  Section 4.3 of
     [RFC3307] describes two ways to assign group IDs dynamically: one
     where a server assigns addresses, and one where hosts assign
     addresses themselves.  However, both methods use the same group ID
     range, which creates a risk of address collisions if both are used at
     the same time.

     An additional concern is that the group IDs used for this dynamic
     range overlap with the range used for Solicited-Node multicast
     addresses, a special type of multicast used by IPv6 for neighbor
     discovery (see Section 2.7.1 of [RFC4291]).  This overlap increases
     the risk of unintentional conflicts with link-layer addresses.

     Note that [RFC3307] focuses on 48-bit addresses on Ethernet, but
     similar issues would be seen on any medium that generates link-layer
     multicast addresses by truncating an IPv6 multicast address.

  5.  IPv4 Considerations

     In IPv4, multicast addresses can sometimes cause conflicts at the
     data link layer.  For example, as explained with Ethernet in
     Section 6.4 of [RFC1112], this happens because only the lower 23 bits
     of an IPv4 multicast address are used to generate the Ethernet
     multicast address.  Since an IPv4 multicast address is 32 bits and
     starts with a fixed 4-bit prefix (leaving 28 bits), this means up to
     2^(28-23) = 32 different multicast IP addresses can map to the same
     Ethernet address.  As a result, devices may receive multicast traffic
     they didn't ask for.

     The address allocation guidelines in [RFC5771] did not account for
     this type of collision when they were created.  Because of this
     limitation, the recommended approach for new designs that need
     dynamic multicast IP address assignment is to use IPv6 instead of
     IPv4.

     However, if using IPv4 is necessary, then multicast addresses SHOULD
     be chosen carefully from within the Administratively Scoped Block
     (239.0.0.0/8).  Additionally, solutions for zeroconf multicast
     address allocation SHOULD try to avoid using addresses that may
     already be in use by other applications on the same network, to
     minimize the risk of conflicts.







  Karstens, et al.         Expires 21 August 2026                 [Page 7]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     Zeroconf coexistence with other IPv4 multicast address allocation
     solutions may not be possible, in which case it may be necessary to
     require manual configuration or to limit the solutions that are
     deployed.

  6.  Security Considerations

     Zeroconf multicast address allocation mechanisms are vulnerable to
     accidental or malicious address collisions, which may lead to denial
     of service or misdirection of traffic.  Solutions derived from these
     requirements SHALL include measures for collision detection and
     conflict resolution [REQ-7], and SHOULD include measure to prevent
     unauthorized address use.  Specific security mechanisms are outside
     the scope of this document.

  7.  IANA Considerations

     This document has no IANA actions.

  8.  Acknowledgement

     Special thanks to the National Marine Electronics Association for
     their contributions in developing marine industry standards and their
     support for this research.

     Thanks also to the members of the PIM working group for their early
     brainstorming sessions and review of this draft, and to Gunter van de
     Velde for his review and suggestions.

  9.  References

  9.1.  Normative References

     [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
                RFC 1112, DOI 10.17487/RFC1112, August 1989,
                <https://www.rfc-editor.org/info/rfc1112>.

     [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>.

     [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
                Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
                <https://www.rfc-editor.org/info/rfc2464>.






  Karstens, et al.         Expires 21 August 2026                 [Page 8]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
                Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
                <https://www.rfc-editor.org/info/rfc3307>.

     [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 4291, DOI 10.17487/RFC4291, February
                2006, <https://www.rfc-editor.org/info/rfc4291>.

     [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
                "Considerations for Internet Group Management Protocol
                (IGMP) and Multicast Listener Discovery (MLD) Snooping
                Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
                <https://www.rfc-editor.org/info/rfc4541>.

     [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,
                <https://www.rfc-editor.org/info/rfc5771>.

     [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>.

  9.2.  Informative References

     [RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address
                Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
                DOI 10.17487/RFC2730, December 1999,
                <https://www.rfc-editor.org/info/rfc2730>.

     [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
                Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
                August 2002, <https://www.rfc-editor.org/info/rfc3306>.

     [RFC4489]  Park, J., Shin, M., and H. Kim, "A Method for Generating
                Link-Scoped IPv6 Multicast Addresses", RFC 4489,
                DOI 10.17487/RFC4489, April 2006,
                <https://www.rfc-editor.org/info/rfc4489>.

     [US6690667B1]
                Warren, D., "United States Patent 6690667B1: Switch with
                adaptive address lookup hashing scheme", 10 February 2004.









  Karstens, et al.         Expires 21 August 2026                 [Page 9]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


  Appendix A.  Excluded Solutions

     The way multicast IP addresses are mapped to link-layer multicast
     addresses is already defined in existing standards, such as [RFC1112]
     for IPv4 over Ethernet and [RFC2464] for IPv6 over Ethernet.  These
     standards specify a fixed prefix used in creating the Ethernet
     multicast address.  Changing this prefix would open the door to new
     solutions, but those are not being considered here for practical
     reasons.

     One idea is to reduce the size of the fixed prefix, which would leave
     more bits available for the group ID.  This would make address
     collisions less likely.  Another idea is to create a new protocol
     that dynamically maps multicast IP addresses to link-layer addresses,
     similar to how DHCP assigns IP addresses.  This protocol could work
     locally on a subnet, and routers could adjust the mapping for
     incoming multicast traffic at the network edge.

     However, these ideas would require significant changes to how network
     devices handle multicast traffic.  Since existing hardware and
     operating systems are built around the current standards, it's
     unlikely that such changes would be widely supported anytime soon.

     Another potential solution for IPv4 was to assign 32 separate, non-
     overlapping address ranges to avoid collisions altogether (e.g.,
     assign 224.0.0.254, 224.128.0.254, 225.0.0.254, etc.).  But this was
     rejected because [RFC5771] discourages new allocations, given how
     limited the IPv4 multicast address space already is.

  Authors' Addresses

     Nate Karstens
     Garmin International, Inc.
     1200 E. 151st St.
     Olathe, KS 66062-3426
     United States of America
     Email: nate.karstens@gmail.com


     Dino Farinacci
     lispers.net
     San Jose, CA
     United States of America
     Email: farinacci@gmail.com







  Karstens, et al.         Expires 21 August 2026                [Page 10]


  Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   February 2026


     Mike McBride
     Futurewei
     United States of America
     Email: michael.mcbride@futurewei.com















































  Karstens, et al.         Expires 21 August 2026                [Page 11]


