AERO/OMNI Base Specification Amendments (Volume 1)

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.

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 and . 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 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 while also serving as an IP router for its EUNs. The Client then engages host and router operations the same as per and 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 IPv6 Router Solicitations (RSs) to elicit IPv6 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 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 , 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.

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:*::/N ) 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 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.

Non-MLAs include Mobile Network Prefix (MNP) and Foreign Network Prefix (FNP) addresses as well as other 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 (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. 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.

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

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

Scaling properties for the worldwide civil aviation airplane population are likely to remain within reasonable bounds for the pure BGP routing system discussed in 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 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 without carrying the entire population of mobile node MNP/FNP/MLA information. Each Mobility Anchor Point (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 to maintain a searchable database of MLAs with the node's public key and MAP Proxy/Server MLA maintained in HIP DNS Resource Records (RRs) per . (Note that the RR contains the public key of the target but the MLA of the MAP, since the MLA of the target is already encoded in the ip6.arpa reverse zone.) Address resolution is then based on a two-phase operation where the OMNI link ingress node first performs a reverse-DNS lookup for the target node MLA to discover the MLA of the target's current MAP Proxy/Server. The ingress node next forwards an address resolution request in the form of an IPv6 Neighbor Solicitation (NS) message using the MAP Proxy/Server MLA as the destination and the MLA of the target as the Target Address into the OMNI link which uses standard BGP routing to direct the request to the MAP. The MAP then returns a fully qualified address resolution response in the form of an IPv6 Neighbor Advertisement (NA) message. 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. This is likely to remain within acceptable scaling limits even for extremely large mobile node populations for the foreseeable future. Note 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.

When a source node resolves a domain name corresponding to an MNP/FNP destination, the DNS returns the IP address of the destination and the source forwards packets destined for the IP address to an OMNI link ingress node. The OMNI link ingress then performs reverse-DNS lookup for the IP address to match the longest MNP/FNP prefix in the DNS in order to receive HIP RR's per that contain the MLA and public key of the target node on the path to the MNP/FNP prefix. The OMNI link ingress then caches the MNP/FNP prefix and prefix length association with the target node MLA, then performs address resolution for the MLA as above.

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.

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.

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

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:

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.

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: ) and then forward packets with uncompressed headers only if the underlay network is secured against DoS spoofing.

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 IPv6 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 :

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 an IPv6 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.

MANET routing for nodes operating in a common local routing region can be configured to operate as either a layer-3 (L3-MANET) or layer-2 (L2-MANET) service. The AERO/OMNI base specifications assume L3-MANET, but this amendment extends them to also support L2-MANET. In L3-MANET, routing and addressing occurs at the IP layer and each MANET forwarding hop decrements the IP TTL/Hop-Limit. IP address uniqueness assurance is essential to avoid conflicts, while MAC address uniqueness assurance is desirable but optional. The MANET interface observes a partially-connected multi-access link with some nodes as single-hop IP neighbors and others reachable only over multi-hop paths. IP multicast transmissions only reach single-hop neighbors which must engage an IP layer service such as Simplified Multicast Forwarding (SMF) to flood multicast messages to all nodes in the local MANET routing region. IP header compression state must be maintained at each MANET forwarding hop and may become invalidated due to path changes. In L2-MANET, routing and addressing occurs at the MAC layer and the IP TTL/Hop-Limit is not decremented. Both IP address and MAC address uniqueness assurance are essential to avoid conflicts. The MANET interface observes a fully-connected multi-access link with all nodes appearing as single-hop IP neighbors even though some may be separated by multiple L2 hops. IP multicast transmissions are propagated to all MANET nodes even though the L2 service may be required to forward at the layer below IP. IP header compression state is only maintained at the MANET ingress and egress nodes and is therefore not invalidated due to interior MANET path changes. Instead, the L2 header must carry additional overhead (including a TTL, packet identification and ancillary addresses) to support forwarding at a layer below IP. Since L3-MANETs propagate IP host routes, address resolution services based on MANET-wide multicast can often be avoided. By default, L2-MANETs require multicast-based address resolution services which can be minimized through proactive distribution of IP-to-MAC layer address resolution information. In both cases, sub link-scoped multicast addressing is used since only a (small) subset of all MANET nodes appear in the local MANET routing region, while others appear elsewhere in the MANET-of-MANETs. In both the L2- and L3-MANET models, MANETs can partition into smaller separate MANETs or merge to form larger MANETs; a singleton MANET router is also regarded as a MANET unto itself. These MANET characteristics present a challenge to the classical IP subnet model where all nodes within the subnet are presumed to be reachable as single-hop neighbors connected to the same (shared) link. All MANET routers should therefore only configure the MLA and MSP prefixes as on-link prefixes on the OMNI interface. This causes the node to invoke address resolution for both MANET-local nodes and target peers in other networks reached via the overlay while avoiding multilink subnet issues since the overlay appears as a connected NBMA link even for peers located in different MANET local routing regions. The AERO/OMNI technologies apply equally to both the L3-MANET and L2-MANET models. In addition to MLAs, MANET routers must also configure L2 MAC addresses on their MANET interfaces that are assured unique at least within the MANET local routing region. MAC addresses can be configured either through random generation with universal/local (U/L) bit set to "local" or administratively assigned according to an organizationally unique identifier (OUI) with U/L set to "universal". The MANET router then assigns the corresponding IPv6 Link-Local Address (LLA) with Modified EUI-64 Interface Identifier to the MANET interface per Section 2.5.1 of and tests the address for uniqueness in the MANET local routing region according to Duplicate Address Detection (DAD) procedures . If multiple routers within the same MANET local routing region somehow configure the same MAC address the MANET router must detect and deconflict the duplication (e.g., by assigning a new randomly-generated MAC address) to ensure routing system integrity. For further discussion on MANET Architectural Layering and addressing, see: . For further discussion on sub-link-scoped multicast addressing, see: .

The AERO/OMNI base specifications use the common virtual Ethernet construct as basis for the OMNI interface, but that construct often requires root access on the device which may not be permitted on standard cellphones. Cellphone implementations can instead use the TUN/TAP interface (operating in TUN mode) in the same way as done for common VPN solutions (e.g., OpenVPN). Using the TUN function of the TUN/TAP interface, the OMNI interface will receive raw IP packets from the host operating system with no L2 headers and can then apply OMNI encapsulation before forwarding via an underlay interface. In the reverse direction, the OMNI interface receives encapsulated packets from underlay interfaces, then decapsulates and delivers them as raw IP packets to the host operating system. It is also possible for a single end system to configure multiple TUN/TAP interfaces, with each corresponding to a different OMNI link domain. The different MLA prefixes assigned to the TUN/TAP interfaces will differentiate the OMNI links, e.g., by the Registered Assigning Authority (RAA).