AERO/OMNI Base Specification Amendments (Volume 1)

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 virtual interfaces (such as a loopback) as EUN interfaces. The Client should then assign an IP address taken from each EUN prefix to the 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.)¶

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 (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 propagate NS(AR) messages over the OMNI link to generate 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. 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 encapsulated OAL packets and return fresh address resolution information.¶

2.3. Amendment 1.3: Off-link Nature of 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 could even be ::/0 (i.e., default) and/or the full Mobility Service Prefix.¶

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 the same as for [RFC4861]. 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.¶

The ARS's NS(AR) message uses the subject packet's source address as the Source, the subject packet's destination address as the Target and the solicited-node multicast address as the Destination. The ART's responsive NA(AR) message uses its own MLA as the Source, the Subnet Router Anycast (SRA) address that matches the NS(AR) target as the Target and the NS(AR) source as the Destination.¶

The ART therefore responds to all addresses within the IPv6 prefix that covers the NS(AR) Target Address while including a Route Information Option (RIO) which asserts reachability for an entire IPv6 prefix whereas the target itself (or even the target's more-specific prefix) may be unreachable.¶

This non-MLA address resolution allows the ARS 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.¶

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 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 entity uses its internal LLA as the Source or Destination Address for message exchanges with the network layer. The virtual router entity need not respond to messages addressed to fe80::/128 as this represents an ambiguous LLA form not widely acknowledged as a valid IPv6 unicast/anycast address.¶

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 adaptation layer neighbor cache internally. 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- and off-link destinations reached via the OMNI interface.¶

Each network layer NCE resolves to the 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 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.¶

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. However, the advent of unmanned air systems and all other manners of mobile nodes will soon present 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 then becomes 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-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.¶

In that case, the OAL source can continue to hold the large packet in a queue 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 the large packet (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)              -+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

• 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 "Path change" (TBD) and then forward packets with uncompressed headers only if the underlay network is secured against DoS spoofing. In open Internetworks, the OAL intermediate node should instead simply drop the packets.¶