



Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                                        The Boeing Company
Intended status: Standards Track                              1 May 2026
Expires: 2 November 2026


           AERO/OMNI Base Specification Amendments (Volume 1)
                  draft-templin-6man-aero-omni-amen-08

Abstract

   The Automatic Extended Route Optimization (AERO) and Overlay
   Multilink Network (OMNI) Interface functional specifications have
   reached a level of maturity ready for advancement in the RFC
   publication process.  Updates to the base specifications are
   documented in this first amendment and any additional future
   amendments as necessary.

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 2 November 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                  Expires 2 November 2026                [Page 1]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  AERO/OMNI: First Amendment  . . . . . . . . . . . . . . . . .   2
     2.1.  Amendment 1.1: Prefix Delegation Administration . . . . .   3
     2.2.  Amendment 1.2: AERO/OMNI MLA Addressing . . . . . . . . .   4
     2.3.  Amendment 1.3: Address Resolution for Non-MLAs  . . . . .   5
     2.4.  Amendment 1.4: OMNI Interface Virtual Router  . . . . . .   6
     2.5.  Amendment 1.5: OMNI Interface Neighbor Cache  . . . . . .   6
     2.6.  Amendment 1.6: Scalable Mapping . . . . . . . . . . . . .   7
     2.7.  Amendment 1.7: Address Duplication Implications . . . . .   9
     2.8.  Amendment 1.8: Setting Auth Offset  . . . . . . . . . . .   9
     2.9.  Amendment 1.9: Surrogate Multilink Pilots (MPs) . . . . .   9
     2.10. Amendment 1.10: Extended AFVI TLVs  . . . . . . . . . . .  10
     2.11. Amendment 1.11: Path Change Mitigations . . . . . . . . .  11
     2.12. Amendment 1.12: MAP Proxy/Servers . . . . . . . . . . . .  12
   3.  Implementation Status . . . . . . . . . . . . . . . . . . . .  13
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The Automatic Extended Route Optimization (AERO)
   [I-D.templin-6man-aero3] and Overlay Multilink Network (OMNI)
   Interface [I-D.templin-6man-omni3] functional specifications have
   reached a level of maturity ready for advancement in the RFC
   publication process, while this and any other future amendments
   provide normative updates.

   These amendments assume consistency with IPv4 [RFC0791], IPv6
   [RFC8200] and the IPv6 neighbor discovery and autoconfiguration
   services [RFC4861][RFC4862][RFC9915].  The term "IP" refers
   universally to either the IPv4 or IPv6 protocol version.

2.  AERO/OMNI: First Amendment

   Amendments to the AERO/OMNI specifications appear in the following
   sections in the chronological order in which they were identified,
   formalized and recorded.  Additional amendments may appear in future
   volumes.





Templin                  Expires 2 November 2026                [Page 2]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


2.1.  Amendment 1.1: Prefix Delegation Administration

   The AERO/OMNI base specifications include comprehensive instructions
   for Clients to request and receive Mobile Network Prefix (MNP) IP
   Prefix Delegations (PDs) from the mobility service.  The
   specifications suggest that the Client should apply these MNP PDs on
   downstream-attached (or, "tethered") End User Network (EUN)
   interfaces but do not discuss specific MNP administrative procedures.

   Per this amendment, when a Client receives an MNP PD it should
   provision the MNP over EUNs in a manner consistent with [RFC9663] and
   [RFC9762].  More specifically, the Client assigns some portions of
   the MNP to its EUN interfaces and optionally also sub-delegates other
   portions of the MNP to requesting EUN nodes.  The Client can also use
   a virtual interface such as a loopback as an EUN interface.  The
   Client should then assign an IP address taken from each EUN prefix to
   a corresponding EUN interface using standard IP address
   (auto)configuration procedures.

   The Client then associates the IPv6 Subnet Router Anycast (SRA)
   address [RFC4291] corresponding to the MNP with the OMNI interface
   but does not assign it to the interface.  For example, if the Client
   receives the IPv6 MNP PD 2001:db8:1::/48, it can either accept
   packets with an SRA address 2001:db8:1:*::/64 as the destination and
   respond with packets that use one of the Client's EUN addresses as
   the source or forward the packet to an EUN router that configures a
   more-specific sub-prefix of the ::/48.  In the first case, the
   wildcard response would represent all sub-prefixes as reachable when
   in fact some may not be assigned to any EUN links; in the latter
   case, an adversary may be able to map the EUN internal subnets.

   After the Client configures the SRA address and assigns EUN addresses
   it can operate as an IP host over the OMNI interface according to the
   weak end system model [RFC1122] while also serving as an IP router
   for its EUNs.  The Client then engages host and router operations the
   same as per [RFC4861] and [RFC8200] except that the Client engages
   the OMNI interface as a combined host/router interface.

   When the Client acts as a host over the OMNI interface, it can send
   Router Solicitations (RSs) to elicit Router Advertisements (RAs) from
   OMNI link Proxy/Servers.  The Client can then use its EUN addresses
   for packets exchanged between its local applications and
   correspondents reached via OMNI link neighbors.  (When the Client has
   no EUN addresses, it can instead use its OMNI interface Multilink
   Local Address (MLA) [I-D.templin-6man-mla] with the understanding
   that the packets may be routable only within the OMNI link limited
   domain.)




Templin                  Expires 2 November 2026                [Page 3]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   When the Client acts as a router over the OMNI interface, it forwards
   IP packets between EUN peers and correspondents reached via OMNI link
   neighbors but never sends RA messages over the OMNI interface.  This
   may require the Client to enable IP forwarding on the OMNI interface
   but without representing itself as an router in OMNI link IPv6
   Neighbor Discovery (IPv6 ND) messages.  The Client instead sends RAs
   over its EUN interfaces that include EUN portions of the MNP in
   Prefix Information Options (PIOs) and also represents itself as a
   router in other EUN interface IPv6 ND messages.

   Note that the Client could also optionally assign each EUN address it
   configures to the OMNI interface.  This would give the outward
   appearance of strong end system support [RFC1122], albeit with added
   complexity and ambiguity for the Client to coordinate the same IP
   unicast address assigned to multiple interfaces.

   Further details on MNP PD administrative options are beyond the scope
   of this amendment.

2.2.  Amendment 1.2: AERO/OMNI MLA Addressing

   In the addressing model supported under the current specifications,
   the MLAs of all nodes within the OMNI link limited domain (including
   Clients, Proxy/Servers and others) should be reachable by all other
   nodes on the link.  MLAs of nodes beyond the extent of the OMNI link
   will appear as unreachable destinations though they may be reachable
   within other OMNI links.  This is due to the limited domain nature of
   OMNI link routing for MLAs and highlights why MLAs must appear as a
   lower preference than other GUAs in address selection policies.

   In this addressing model, an MLA prefix (e.g., 2001:30::/28
   [RFC9374]) is configured on-link on the OMNI interface and any MLA
   routes discovered by Mobile Ad-hoc NETworking (MANET) routing
   protocols are maintained in an alternate routing table instead of the
   main kernel routing table.  The MANET routing protocol can then
   manage its multihop routes dynamically as necessary while the network
   layer forwards all packets with MLA destinations into the OMNI
   interface.  The on-link nature of the MLA prefix will cause the
   network layer to invoke address resolution for destination MLAs
   within the limited domain.  This will cause the OMNI Address
   Resolution Source (ARS) to either return an NA(AR) message locally
   for locally-known MLAs or propagate the NS(AR) message over the OMNI
   link to elicit an NA(AR) response from an Address Resolution Target
   (ART).

   The ARS's NS(AR) uses the invoking packet's address or its local MLA
   as the Source, uses the MLA of the target as the Target and uses the
   solicited-node multicast address as the Destination.  If the original



Templin                  Expires 2 November 2026                [Page 4]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   packet's source address is not on-link on the OMNI link, the OMNI
   interface also includes a Route Information Option (RIO) with a
   prefix that covers the source address as an OMNI sub-option.  The
   ART's NA(AR) uses the NS(AR) target as both the Source and Target and
   uses the NS(AR) source as the Destination.  AERO routing will cause
   these messages to traverse the OMNI link as OAL-encapsulated packets
   and return fresh reachability information.

2.3.  Amendment 1.3: Address Resolution for Non-MLAs

   Non-MLAs include MNP/FNP addresses and other GUA addresses matched
   only by "default".  These prefixes must be configured as reachable
   (but not on-link) via the OMNI link.  Clients therefore configure
   routes in the IPv6 routing system that cover MNPs and/or FNPs and
   with next hop set to the Link-Local Address (LLA) of the OMNI
   interface internal virtual router.  This will cause all packets with
   destinations within these off-link prefixes to be delivered to the
   virtual router.  The route(s) may include specific MNP/FNP prefixes
   or even the full Mobility Service Prefix and/or ::/0 (i.e., default).

   The OMNI link virtual router then acts as an ARS to resolve
   adaptation layer addressing information for the packet's destination
   prefix internally within the adaptation layer and without disturbing
   the network layer.  While address resolution is in progress, the
   virtual router maintains a short queue (possibly only a single entry)
   of packets destined to the ART prefix in the spirit of [RFC4861]
   (noting that many distinct destinations may match the same ART
   prefix).  The virtual router may alternately forward packets destined
   to the ART prefix while bypassing the queue with the understanding
   that they may be dropped in the network while address resolution is
   still in progress.  The virtual router should not attach subject
   packets awaiting address resolution to NS(AR) messages, as they may
   be produced by high-volume applications (e.g., "flood-pings") that
   send many unacknowledged packets without waiting for a response.

   In this off-link model, the ARS's NS(AR) message uses the MLA
   assigned to the OMNI interface as the Source, a /64 Subnet Router
   Anycast address that covers the subject packet's destination address
   as the Target and the target's solicited-node multicast address as
   the Destination.  If the original packet's source is not on-link on
   the OMNI interface, the NS(AR) also includes an OMNI RIO sub-option
   with a prefix that covers the source.  The ART's responsive NA(AR)
   message uses its own MLA as the Source, the NS(AR) target as the
   Target and the NS(AR) source as the Destination.  The NA(AR) also
   includes an RIO with a prefix that covers the NS(AR) target.  The
   target and source OMNI interfaces then cache the RIO information as
   address resolution results.




Templin                  Expires 2 November 2026                [Page 5]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   This enhanced address resolution allows the ARS and ART to discover
   information for entire IPv6 prefix ranges without necessarily
   conveying reachability information for specific destinations (or even
   sub-prefixes) within the prefix.  The system therefore depends on the
   target network returning ICMPv6 Destination Unreachable messages for
   unreachable destinations within (reachable) prefixes the same as for
   any router.

2.4.  Amendment 1.4: OMNI Interface Virtual Router

   The virtual router entity within the OMNI interface must present
   itself to the network layer as a minimally qualified IPv6 router
   according to IPv6 node requirements [RFC8504].  This includes using
   its internal LLA to send solicited and unsolicited Router
   Advertisements as well as respond to Neighbor Solicitations by
   returning solicited Neighbor Advertisements.

   The virtual router entity uses its internal LLA as the Source or
   Destination Address for message exchanges with the network layer.
   The virtual router entity should also provide a configuration option
   allowing it to either respond to or ignore ICMPv6 Echo Request
   messages addressed to its internal LLA or the subnet router anycast
   address for its MLA prefix(es).

   The virtual router can announce itself to the network layer
   proactively when an OMNI interface is first enabled, or it may
   instead wait for the network layer to generate a Router Solicitation
   (RS).  In both cases, the virtual router is responsible for
   coordinating with its selected Proxy/Servers.

2.5.  Amendment 1.5: OMNI Interface Neighbor Cache

   Each OMNI interface maintains a standard IPv6 network layer neighbor
   cache the same as for any IPv6 interface and also maintains an
   internal adaptation layer neighbor cache.  The network layer neighbor
   cache maintains entries (NCEs) for the adaptation layer as a virtual
   router as well as for active on-link destinations only, while the
   adaptation layer neighbor cache maintains NCEs for both on-link
   destinations and off-link prefixes reached via the OMNI interface.












Templin                  Expires 2 November 2026                [Page 6]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   Each network layer NCE resolves to a singular OMNI interface internal
   link-layer address; this means that all NCE destinations would appear
   to belong to the same (singular) neighbor.  The adaptation layer
   virtual router entity will then map the network layer NCE to the
   corresponding adaptation layer NCE by examining the IP source or
   destination address rather than the link-layer address.  This
   relationship establishes a 1x1 mapping between the network layer as a
   virtual host and the adaptation layer as a virtual peer host/router
   on a shared link.

   The network and adaptation layer neighbor caches are affected by the
   transmission and reception of IPv6 Neighbor Discovery (IPv6 ND)
   messages according to the base specifications.  IPv6 ND messages
   affect both the network layer and adaptation layer caches for on-link
   addresses, while only the adaptation layer cache is affected for off-
   link addresses.

   When the OMNI interface forwards an IPv6 ND message from the network
   layer to the adaptation layer, the adaptation layer removes the
   Source/Target Link Layer Address Option (S/TLLAO) and resets the IPv6
   source address from the network layer Link-Local Address (LLA) to the
   node's MLA if necessary.  The adaptation layer does not reset the
   ICMPv6 checksum before performing OAL encapsulation and transmission
   over an underlay interface since the OMNI option checksum protects
   integrity as an adaptation layer service.  The ICMPv6 checksum will
   then appear simply as a random bit string over the wire to be ignored
   by the OAL destination as well as all OAL intermediate nodes.

   When the underlay forwards an OAL-encapsulated IPv6 ND message to the
   adaptation layer, the OAL first verifies the OMNI checksum then
   processes any OMNI sub-options and performs decapsulation.  The OAL
   then inserts a S/TLLAO that includes the MAC address assigned to the
   OMNI-internal virtual Ethernet interface and for RA messages only
   resets the IPv6 source address to the virtual router entity's LLA.
   The OAL then re-calculates/resets the ICMPv6 checksum and forwards
   the IPv6 ND message to the network layer via the OMNI interface.  The
   network layer will then accept the message under the assumption that
   it originated from an on-link neighbor.

2.6.  Amendment 1.6: Scalable Mapping

   Scaling properties for the worldwide civil aviation airplane
   population are likely to remain within reasonable bounds for the pure
   BGP routing system discussed in [I-D.templin-6man-aero3] for the
   foreseeable future.  (A single BGP system can presumably support
   O(10*6) routes when considering the scaling properties of the global
   public Internet BGP service.)  However, the advent of unmanned air
   systems and all other manners of mobile nodes will soon present



Templin                  Expires 2 November 2026                [Page 7]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   multiple orders of magnitude more mobility targets which may exceed
   the carrying capacity of a BGP-only service.

   In order to support unbounded scaling, the BGP routing system can be
   limited to carry only the MLAs of all Proxy/Servers on the OMNI link
   (and possibly also the MNPs/FNPs/MLAs of a limited number of mobile
   nodes) without carrying the entire population of mobile node MNP/FNP/
   MLA information.  Each MAP Proxy/Server then registers the MNP/FNP
   routes and MLA addresses of its dependent mobile nodes with a
   scalable mapping system that can be used to resolve a target address
   based on longest prefix match into a MAP Proxy/Server MLA address.
   The Domain Name System (DNS) ip6.arpa reverse zone can be used for
   this purpose as suggested in [RFC9374].

   Address resolution is then based on a two-phase operation where the
   address resolution request is first forwarded (e.g., via a default or
   more-specific route) to a Gateway which consults the DNS to determine
   the MLA of the current MAP Proxy/Server for the address resolution
   target.  The mapping system agent then changes the OAL destination to
   the discovered MLA and forwards the address resolution request to the
   MAP which returns a fully qualified address resolution response.

   By maintaining mobile node to MAP mappings in a scalable ancillary
   lookup directory database, the BGP routing system only needs to scale
   to the total population of Proxy/Servers and Gateways that make up
   the OMNI link (plus possibly also a limited number of mobile nodes).
   This is likely to remain within acceptable scaling limits even for
   extremely large mobile node populations for the foreseeable future.

   Note that the Gateway performs these mapping system lookups only for
   subject prefixes associated with the OMNI link, e.g., those covered
   by MSPs or any well-known FNPs.  For other subject prefixes that
   match only "default" the Gateway returns an address resolution
   response with a Route Information Option (RIO) that includes a /64
   prefix covering the target address while including its own MLA as the
   address resolution result.

   Note also that MAP Proxy/Servers need only add or replace DNS
   resource records with the IP prefix mappings as they receive
   registration requests from new Clients.  If the Client moves to a new
   MAP Proxy/Server, the new MAP simply replaces the old resource
   records with fresh information.  If the resource records expire
   before a new MAP Proxy/Server supplies fresh information, the records
   are removed.

   Global propagation delays for DNS resource record updates and the
   location privacy considerations for mobile node affiliations with MAP
   Proxy/Servers suggest that the OMNI link should configure a "two-



Templin                  Expires 2 November 2026                [Page 8]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   faced" DNS service infrastructure maintained separately from the
   global public DNS.  Such a service should be optimized for fast
   updates so that Gateways always receive fresh address resolution
   information.

2.7.  Amendment 1.7: Address Duplication Implications

   An implicit assumption in AERO/OMNI is that IP address duplication
   within the same OMNI link domain could result in an unresolvable and
   harmful interaction for any nodes affected.  The AERO/OMNI routing
   system and neighbor discovery services are founded on an expectation
   of uniqueness of the MNPs/FNPs/MLAs claimed by nodes.  The MLA in
   particular is carefully coordinated with a registration authority and
   bound to a public key identity to ensure uniqueness.  MNP/FNP
   delegations are similarly bound to an MLA when delegated by AERO/OMNI
   infrastructure supporting nodes to prevent duplication.

   On the other hand, link-layer address duplication (while presumably
   rare) would result in simply minor performance congestion since the
   IP stacks of the nodes with duplicate link-layer addresses would
   reject any mis-directed packets while the stacks of routers would be
   able to discern control messages based on their IPv6 MLA addresses as
   a unique node identifier.  While link-layer address duplication is
   not desirable, it should have no harmful operational effects.

2.8.  Amendment 1.8: Setting Auth Offset

   The OMNI option trailer includes a 1-octet Auth Offset field that
   encodes the offset from the beginning of the OMNI sub-options to the
   first authentication (or "authentication helper") sub-option.  This
   allows for more efficient authentication verification at OAL
   destinations since they need not wade through potentially long
   concatenations of leading non-authentication sub-options.

   When an OMNI option does not assert an authentication/helper sub-
   option offset, the OAL source can set Auth Offset to any value no
   smaller than OMNI Length.  For example, the OAL source can simply set
   the value 'ff' as an unambiguous indication that no offset is
   asserted.

2.9.  Amendment 1.9: Surrogate Multilink Pilots (MPs)

   The AERO/OMNI base specifications require that control messages
   (including IPv6 ND and Multilink Pilot (MP) messages) must be
   transmitted as whole packets not subject to OAL fragmentation.  Very
   large original IP packets may therefore be unsuited to serve as MP
   messages.




Templin                  Expires 2 November 2026                [Page 9]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   In that case, the OAL source can continue to hold large packets in a
   queue (or release them to follow a sub-optimal path) while sending
   unsolicited Neighbor Advertisement (uNA) messages that include
   Source, Destination and Flow Label information copied from the large
   packet as surrogate MPs.

   Transmission of surrogate MPs will cause OAL intermediate systems to
   securely establish AFVI state, after which the OAL source can release
   any large packets (while applying fragmentation if necessary followed
   by header compression) to follow the newly-established AFVI path in
   the data plane.

2.10.  Amendment 1.10: Extended AFVI TLVs

   The OMNI specification defines a segment Routing Header (SRH) TLV
   termed the AERO Flow Vector Index (AFVI) TLV.  This amendment defines
   an extended form of the AFVI TLV to include a Sequence Number and
   Window size as shown below:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |I|           Window            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 AERO Flow Vector Index (AFVI)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-             Sequence Number (8 octets)              -+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 1: Extended AFVI TLV

   In this extended form:

   *  Type is set the same as in the OMNI specification.

   *  Length is set to 14.

   *  I is an "Initialize" flag used for the same purpose as in the OMNI
      specification.

   *  Window is a 15-bit integer that encodes the size of the current
      send window in units of 512 Sequence Numbers.  For example, if
      Window encodes the value 128 the current send window is (128 *
      512) = 65536 Sequence Numbers.

   *  AERO Flow Vector Index (AFVI) is a 32-bit field used for the same
      purpose as in the OMNI specification.




Templin                  Expires 2 November 2026               [Page 10]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   *  Sequence Number is an 8-octet field that encodes the same value
      that would appear in the Extended Fragment Header (EFH).  For
      unfragmented control messages, this value can therefore include a
      Sequence Number used to establish AFV state.

   When the OAL source includes this extended form of the SRH AFVI TLV
   in unfragmented control messages, it should not also include an
   Extended Fragment Header (EFH) as it would only include redundant or
   conflicting information that could confuse OAL intermediate systems.
   The SRH AFVI TLV also has the distinct advantage that it is covered
   by the authentication signature included in the SRH HMAC TLV.

   This amendment therefore deprecates inclusion of the EFH in
   unfragmented control messages and mandates inclusion of the SRH
   extended AFVI TLV in its place.

   This amendment further deprecates inclusion of the OMNI Neighbor
   Synchronization sub-option, as all window synchronization will be
   unidirectional based on the SRH AFVI TLV and therefore no TCP-like
   bidirectional handshaking is necessary.

2.11.  Amendment 1.11: Path Change Mitigations

   The AERO specification includes path change mitigations that permit
   an OAL intermediate node to revert to sending packets with
   uncompressed headers when the next hop in the AFV path has changed.
   The OAL destination is then responsible for returning ICMPv6
   Parameter Problem messages with code "Compressed header expected".

   In open Internetworks not protected by lower layer security, however,
   this arrangement could open a Denial of Service (DoS) vector in which
   an unauthorized source produces a flood of packets with uncompressed
   headers causing an OAL destination to return false path change
   reports.

   The OAL intermediate node should therefore return an ICMP Parameter
   Problem message (subject to rate limiting) with code "Compressed
   header expected" (see: [I-D.templin-6man-aero3]) and then forward
   packets with uncompressed headers only if the underlay network is
   secured against DoS spoofing.











Templin                  Expires 2 November 2026               [Page 11]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


2.12.  Amendment 1.12: MAP Proxy/Servers

   The OMNI specification implies that all First Hop Segment (FHS)
   Proxy/Servers should be eligible to also act as distributed Mobility
   Anchor Points (MAPs).  For FHS Proxy/Servers positioned in highly
   dynamic environments, however, this might lead to undesirable
   interactions with the OMNI link routing system.  These dynamic FHS
   Proxy/Servers should therefore not accept the MAP role themselves,
   but should instead act as transparent proxies to forward Client
   registration requests to MAPs located in more stable environments.

   The Client discovers the list of eligible MAPs for the OMNI link by
   querying the Domain Name System (DNS) for the OMNI link Potential
   Router List (PRL).  The PRL query returns a list of MAP Proxy/Server
   resource records that include the MLA, underlay IP address(es) and
   geographic positioning information for each MAP.  Clients can then
   select specific MAPs by placing the MLA in an OMNI Router
   Solicitation (RS) Destination Address; the FHS Proxy/Server for the
   Client's link will in turn transparently proxy and forward the RS to
   the MAP.

   Clients may selectively test connectivity to candidate MAPs before
   selecting one with the desired performance profile.  The MAP should
   in turn defer its interactions with the OMNI link routing system
   until the Client indicates its intention to commit.  This amendment
   therefore adds a new (C)ommit flag to the OMNI Proxy/Server Control
   sub-option as shown in Figure 2:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Sub-Type=15  |   Sub-Length  |M|P|N|A|R|C|    Reserved       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~

            Figure 2: Proxy/Server Control With (C)ommit Flag

   When the Client sends an RS to test a candidate MAP Proxy/Server's
   reachability and performance, it includes a Proxy/Server Control sub-
   option with the (C)ommit flag set to 0.  The MAP Proxy/Server then
   returns a Router Advertisement (RA) message without committing to
   serve the Client.  When the Client instead sets the (C)ommit flag to
   1, the MAP Proxy/Server returns an RA with zero lifetimes if it is
   unable to commit.  Otherwise, the MAP Proxy/Server creates a Neighbor
   Cache entry, delegates the Client's requested MNP(s) and injects the
   Client's MNP(s) and MLA into the OMNI link routing system.  The MAP
   Proxy/Server then returns an RA with valid lifetimes.






Templin                  Expires 2 November 2026               [Page 12]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


3.  Implementation Status

   A write-from-scratch reference implementation is under active
   internal development, with release version v0.8 tagged on March 4,
   2026.  Future versions will be made available for public release.

4.  IANA Considerations

   This document includes no actions for IANA.

5.  Security Considerations

   The security considerations in the normative references apply.

6.  Acknowledgements

   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

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

   [I-D.templin-6man-mla]
              Templin, F., "IPv6 Addresses for Ad Hoc Networks", Work in
              Progress, Internet-Draft, draft-templin-6man-mla-32, 16
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-templin-6man-mla-32>.

   [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-80, 28 February
              2026, <https://datatracker.ietf.org/doc/html/draft-
              templin-6man-omni3-80>.

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



Templin                  Expires 2 November 2026               [Page 13]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


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

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

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

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

   [RFC9915]  Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
              Winters, "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
              January 2026, <https://www.rfc-editor.org/info/rfc9915>.

7.2.  Informative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
              January 2019, <https://www.rfc-editor.org/info/rfc8504>.

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

   [RFC9663]  Colitti, L., Linkova, J., Ed., and X. Ma, Ed., "Using
              DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
              IPv6 Prefixes per Client in Large Broadcast Networks",
              RFC 9663, DOI 10.17487/RFC9663, October 2024,
              <https://www.rfc-editor.org/info/rfc9663>.






Templin                  Expires 2 November 2026               [Page 14]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


   [RFC9762]  Colitti, L., Linkova, J., Ma, X., Ed., and D. Lamparter,
              "Using Router Advertisements to Signal the Availability of
              DHCPv6 Prefix Delegation to Clients", RFC 9762,
              DOI 10.17487/RFC9762, June 2025,
              <https://www.rfc-editor.org/info/rfc9762>.

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from -07 to -08:

   *  Added implementation status section.

   *  Permit packet forwarding while address resolution is in progress.

   Differences from -06 to -07:

   *  Clarified IPv6 ND message exchange requirements between network
      and adaptation layers.

   Differences from -05 to -06:

   *  Subnet Router Anycast address for non-MLA NS/NA.

   Differences from -04 to -05:

   *  Reverted to off-link model for non-MLAs.

   Differences from -01 to -04:

   *  Further clarifications on on/off-link models.

   *  Added amendment 1.12 on MAP Proxy/Servers.

   Differences from -00 to -01:

   *  Added amendments 1.2 through 1.11.

   Differences from earlier versions:

   *  First draft publication.

Author's Address







Templin                  Expires 2 November 2026               [Page 15]

Internet-Draft        AERO/OMNI Amendments (Vol. 1)             May 2026


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













































Templin                  Expires 2 November 2026               [Page 16]
