Internet-Draft AERO/OMNI Amendments (Vol. 1) February 2026
Templin Expires 30 August 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-templin-6man-aero-omni-amen-00
Published:
Intended Status:
Standards Track
Expires:
Author:
F. L. Templin, Ed.
Boeing Technology Innovation

AERO/OMNI Base Specification Amendments (Volume 1)

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

Table of Contents

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. Updates to the base specifications are documented in this first amendment and any additional future amendments as necessary. This document assumes consistency with IPv4 [RFC0791], IPv6 [RFC8200] and the IPv6 neighbor discovery and autoconfiguration services [RFC4861][RFC4862][RFC8415].

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 reported. As new amendments are reported and/or discovered, they will be added below in the order they are received which may not necessarily align with specification chapter orders and/or resolution priority.

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) Prefix Delegations (PD) 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 /64 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 virtual interfaces such as a loopback as EUN interfaces.) The Client should then assign an IPv6 address taken from each EUN /64 prefix to the corresponding EUN interface using standard IPv6 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 MNP PD 2001:db8:1::/48, it should accept packets with the SRA address 2001:db8:1:: as the destination and respond with packets that use one of the Client's EUN addresses as the source.

After the Client configures the SRA address and assigns EUN addresses it can operate as an IPv6 host over the OMNI interface according to the weak end system model while also serving as an IPv6 router for its EUNs. The Client then engages IPv6 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 an IPv6 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) with the understanding that the packets may be routable only within the OMNI link limited domain.)

When the Client acts as an IPv6 router over the OMNI interface, it forwards IPv6 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 "IPv6 forwarding" on the OMNI interface but without representing itself as an IPv6 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 an IPv6 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 support for the strong end system model, albeit with added complexity for coordinating the same IP unicast address assigned to multiple Client interfaces.

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

3. IANA Considerations

This document includes no actions for IANA.

4. Security Considerations

The security considerations in the normative references apply.

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

6. References

6.1. Normative References

[I-D.templin-6man-aero3]
Templin, F., "Automatic Extended Route Optimization (AERO)", Work in Progress, Internet-Draft, draft-templin-6man-aero3-52, , <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, , <https://datatracker.ietf.org/doc/html/draft-templin-6man-omni3-73>.
[RFC0791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <https://www.rfc-editor.org/info/rfc791>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8200>.
[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, , <https://www.rfc-editor.org/info/rfc8415>.

6.2. Informative References

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

Appendix A. Change Log

<< RFC Editor - remove prior to publication >>

Differences from earlier versions:

Author's Address

Fred L. Templin (editor)
Boeing Technology Innovation
P.O. Box 3707
Seattle, WA 98124
United States of America