0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (=137)  |  Code (=0/1)  |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Destination Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

Figure 5: AERO Redirect/Predirect Message Format

3.15.4. Sending Predirects

When a Client forwards a packet with a source address from one of its ACPs toward a destination address covered by an ASP (i.e., toward another AERO Client connected to the same AERO link), the source Client MAY send a Predirect message forward toward the destination Client via the Server.

In the reference operational scenario, when Client ('C1') forwards a packet toward Client ('C2'), it MAY also send a Predirect message forward toward Client ('C2'), subject to rate limiting (see Section 8.2 of [RFC4861]). Client ('C1') prepares the Predirect message as follows:

• the link-layer source address is set to 'L2(C1)' (i.e., the link-layer address of Client ('C1')).
• the link-layer destination address is set to 'L2(S1)' (i.e., the link-layer address of Server ('S1')).
• the network-layer source address is set to fe80::2001:db8:0:0 (i.e., the base AERO address of Client ('C1')).
• the network-layer destination address is set to the AERO address corresponding to the destination address of Client ('C2').
• the Type is set to 137.
• the Code is set to 1 to indicate "Predirect".
• the Target Address is set to fe80::2001:db8:0:0 (i.e., the base AERO address of Client ('C1')).
• the Destination Address is set to the source address of the originating packet that triggered the Predirection event. (If the originating packet is an IPv4 packet, the address is constructed in IPv4-mapped IPv6 address format).
• the message includes one or more TLLAOs set to appropriate values for Client ('C1')'s underlying interfaces.
• the message includes one or more Route Information Options (RIOs) [RFC4191] that include Client ('C1')'s ACPs.
• the message SHOULD include a Timestamp option and a Nonce option.
• the message includes a Redirected Header Option (RHO) that contains the originating packet truncated if necessary to ensure that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.

Note that the act of sending Predirect messages is cited as "MAY", since Client ('C1') may have advanced knowledge that the direct path to Client ('C2') would be unusable or otherwise undesirable. If the direct path later becomes unusable after the initial route optimization, Client ('C1') simply allows packets to again flow through Server ('S1').

3.15.5. Re-encapsulating and Relaying Predirects

When Server ('S1') receives a Predirect message from Client ('C1'), it first verifies that the TLLAOs in the Predirect are a proper subset of the Interface IDs in Client ('C1')'s neighbor cache entry. If the Client's TLLAOs are not acceptable, Server ('S1') discards the message. Otherwise, Server ('S1') validates the message according to the Redirect message validation rules in Section 8.1 of [RFC4861], except that the Predirect has Code=1. Server ('S1') also verifies that Client ('C1') is authorized to use the ACPs encoded in the RIOs of the Predirect. If validation fails, Server ('S1') discards the Predirect; otherwise, it copies the correct UDP Port number and IP Address for Client ('C1')'s underlying link into the first TLLAO in case the addresses have been subject to NAT.

Server ('S1') then examines the network-layer destination address of the Predirect to determine the next hop toward Client ('C2') by searching for the AERO address in the neighbor cache. Since Client ('C2') is not one of its neighbors, Server ('S1') re-encapsulates the Predirect and relays it via Relay ('R1') by changing the link-layer source address of the message to 'L2(S1)' and changing the link-layer destination address to 'L2(R1)'. Server ('S1') finally forwards the re-encapsulated message to Relay ('R1') without decrementing the network-layer TTL/Hop Limit field.

When Relay ('R1') receives the Predirect message from Server ('S1') it determines that Server ('S2') is the next hop toward Client ('C2') by consulting its forwarding table. Relay ('R1') then re-encapsulates the Predirect while changing the link-layer source address to 'L2(R1)' and changing the link-layer destination address to 'L2(S2)'. Relay ('R1') then relays the Predirect via Server ('S2').

When Server ('S2') receives the Predirect message from Relay ('R1') it determines that Client ('C2') is a neighbor by consulting its neighbor cache. Server ('S2') then re-encapsulates the Predirect while changing the link-layer source address to 'L2(S2)' and changing the link-layer destination address to 'L2(C2)'. Server ('S2') then forwards the message to Client ('C2').

3.15.6. Processing Predirects and Sending Redirects

When Client ('C2') receives the Predirect message, it accepts the Predirect only if the message has a link-layer source address of one of its Servers (e.g., L2(S2)). Client ('C2') further accepts the message only if it is willing to serve as a redirection target. Next, Client ('C2') validates the message according to the Redirect message validation rules in Section 8.1 of [RFC4861], except that it accepts the message even though Code=1 and even though the network-layer source address is not that of it's current first-hop router.

In the reference operational scenario, when Client ('C2') receives a valid Predirect message, it either creates or updates a dynamic neighbor cache entry that stores the Target Address of the message as the network-layer address of Client ('C1') , stores the link-layer addresses found in the TLLAOs as the link-layer addresses of Client ('C1'), and stores the ACPs encoded in the RIOs of the Predirect as the ACPs for Client ('C1'). Client ('C2') then sets AcceptTime for the neighbor cache entry to ACCEPT_TIME.

After processing the message, Client ('C2') prepares a Redirect message response as follows:

• the link-layer source address is set to 'L2(C2)' (i.e., the link-layer address of Client ('C2')).
• the link-layer destination address is set to 'L2(S2)' (i.e., the link-layer address of Server ('S2')).
• the network-layer source address is set to fe80::2001:db8:1:0 (i.e., the base AERO address of Client ('C2')).
• the network-layer destination address is set to fe80::2001:db8:0:0 (i.e., the base AERO address of Client ('C1')).
• the Type is set to 137.
• the Code is set to 0 to indicate "Redirect".
• the Target Address is set to fe80::2001:db8:1:0 (i.e., the base AERO address of Client ('C2')).
• the Destination Address is set to the destination address of the originating packet that triggered the Redirection event. (If the originating packet is an IPv4 packet, the address is constructed in IPv4-mapped IPv6 address format).
• the message includes one or more TLLAOs set to appropriate values for Client ('C2')'s underlying interfaces.
• the message includes one or more Route Information Options (RIOs) that include Client ('C2')'s ACPs.
• the message SHOULD include a Timestamp option and MUST echo the Nonce option received in the Predirect (i.e., if a Nonce option is included).
• the message includes as much of the RHO copied from the corresponding Predirect message as possible such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.

After Client ('C2') prepares the Redirect message, it sends the message to Server ('S2').

3.15.7. Re-encapsulating and Relaying Redirects

When Server ('S2') receives a Redirect message from Client ('C2'), it first verifies that the TLLAOs in the Redirect are a proper subset of the Interface IDs in Client ('C2')'s neighbor cache entry. If the Client's TLLAOs are not acceptable, Server ('S2') discards the message. Otherwise, Server ('S2') validates the message according to the Redirect message validation rules in Section 8.1 of [RFC4861]. Server ('S2') also verifies that Client ('C2') is authorized to use the ACPs encoded in the RIOs of the Redirect message. If validation fails, Server ('S2') discards the Redirect; otherwise, it copies the correct UDP Port number and IP Address for Client ('C2')'s underlying link into the first TLLAO in case the addresses have been subject to NAT.

Server ('S2') then examines the network-layer destination address of the Redirect to determine the next hop toward Client ('C1') by searching for the AERO address in the neighbor cache. Since Client ('C1') is not a neighbor, Server ('S2') re-encapsulates the Redirect and relays it via Relay ('R1') by changing the link-layer source address of the message to 'L2(S2)' and changing the link-layer destination address to 'L2(R1)'. Server ('S2') finally forwards the re-encapsulated message to Relay ('R1') without decrementing the network-layer TTL/Hop Limit field.

When Relay ('R1') receives the Redirect message from Server ('S2') it determines that Server ('S1') is the next hop toward Client ('C1') by consulting its forwarding table. Relay ('R1') then re-encapsulates the Redirect while changing the link-layer source address to 'L2(R1)' and changing the link-layer destination address to 'L2(S1)'. Relay ('R1') then relays the Redirect via Server ('S1').

When Server ('S1') receives the Redirect message from Relay ('R1') it determines that Client ('C1') is a neighbor by consulting its neighbor cache. Server ('S1') then re-encapsulates the Redirect while changing the link-layer source address to 'L2(S1)' and changing the link-layer destination address to 'L2(C1)'. Server ('S1') then forwards the message to Client ('C1').

3.15.8. Processing Redirects

When Client ('C1') receives the Redirect message, it accepts the message only if it has a link-layer source address of one of its Servers (e.g., 'L2(S1)'). Next, Client ('C1') validates the message according to the Redirect message validation rules in Section 8.1 of [RFC4861], except that it accepts the message even though the network-layer source address is not that of it's current first-hop router. Following validation, Client ('C1') then processes the message as follows.

In the reference operational scenario, when Client ('C1') receives the Redirect message, it either creates or updates a dynamic neighbor cache entry that stores the Target Address of the message as the network-layer address of Client ('C2'), stores the link-layer addresses found in the TLLAOs as the link-layer addresses of Client ('C2') and stores the ACPs encoded in the RIOs of the Redirect as the ACPs for Client ('C2').. Client ('C1') then sets ForwardTime for the neighbor cache entry to FORWARD_TIME.

Now, Client ('C1') has a neighbor cache entry with a valid ForwardTime value, while Client ('C2') has a neighbor cache entry with a valid AcceptTime value. Thereafter, Client ('C1') may forward ordinary network-layer data packets directly to Client ('C2') without involving any intermediate nodes, and Client ('C2') can verify that the packets came from an acceptable source. (In order for Client ('C2') to forward packets to Client ('C1'), a corresponding Predirect/Redirect message exchange is required in the reverse direction; hence, the mechanism is asymmetric.)

3.15.9. Server-to-Client and Client-to-Server Redirection

In some environments, the Server nearest the target Client may need to serve as a proxy redirection target, e.g., if direct Client-to-Client communications are not possible. In that case, when the source Client sends a Predirect message the target Server prepares a corresponding Redirect the same as if it were the target Client (see: Section 3.15.6), except that it writes its own link-layer address in the TLLAO option. The Server must then maintain a dynamic neighbor cache entry for the redirected source Client.

Similarly, when the source Client must send all packets via its own Server and cannot act on a route optimization request, the source Server can send a Predirect message toward the target Client. The target Client then prepares a corresponding Redirect message the same as for Client-to-Client route optimization and sends the Redirect message back to the source Server.

Thereafter, if a Client moves to a new Server, the old Server sends ICMP "Destination Unreachable" messages subject to rate limiting in response to data packets received from a correspondent node to report that the route optimization ForwardTime should be set to 0. The correspondent Client (or Server) then allows future packets destined to the departed Client to again flow through its own Server (or Relay). Note however that the old Server retains the neighbor cache entry and does not set AcceptTime to 0 since there may be many packets in flight. When the old Server receives these packets, it forwards them to a Relay which will forward them to the departed Client's new Server. AcceptTime will then eventually decrement to 0 once the correspondent node processes and acts on the Destination Unreachables.

In any case, a Server MUST NOT send a BGP update to its Relays for Clients discovered through dynamic route optimization redirection. BGP updates are only to be sent for the Server's working set of statically-associated Clients.

3.15.10. Server-to-Server Redirection

If neither the source nor target Clients are capable of sending packets other than via their own Servers, a Server-to-Server route optimization can still be employed. In that case, the source Client's Server can send a Predirect message via a Relay to the AERO address of the target Client, and the Relay will forward the message to the target Client's Server. The target Server prepares the Redirect message the same as if it were the target Client, except that it writes its own link-layer address in the TLLAO option then sends a Redirect message back to the source Server. (The target Server can send the Redirect message back to the source Server either directly or via the Relay according to the security model.) Both Servers must then maintain a dynamic neighbor cache entry for the redirected Clients.

Thereafter, if a Client moves to a new Server, the old Server sends ICMP "Destination Unreachable" messages subject to rate limiting in response to data packets forwarded by the correspondent Server to report that the route optimization ForwardTime should be set to 0. The correspondent Server then allows future packets destined to the departed Client to again flow through its own Relay. Note however that the old Server retains the neighbor cache entry and does not set AcceptTime to 0 since there may be many packets in flight. When the old Server receives these packets, it forwards them to a Relay which will forward them to the departed Client's new Server. AcceptTime will then eventually decrement to 0 once the correspondent node processes and acts on the Destination Unreachables.

In any case, a Server MUST NOT send a BGP update to its Relays for Clients discovered through dynamic route optimization redirection. BGP updates are only to be sent for the Server's working set of statically-associated Clients..

3.16. Neighbor Unreachability Detection (NUD)

AERO nodes perform Neighbor Unreachability Detection (NUD) by sending unicast NS messages with SLLAOs to elicit solicited NA messages from neighbors the same as described in [RFC4861]. NUD is performed either reactively in response to persistent L2 errors (see Section 3.13) or proactively to update neighbor cache entry timers and/or link-layer address information.

When an AERO node sends an NS/NA message, it MUST use one of its link-local addresses as the IPv6 source address and a link-local address of the neighbor as the IPv6 destination address. When an AERO node receives an NS message or a solicited NA message, it accepts the message if it has a neighbor cache entry for the neighbor; otherwise, it ignores the message.

When a source AERO node is redirected to a target AERO node it SHOULD proactively test the direct path by sending an initial NS message to elicit a solicited NA response. While testing the path, the source node can optionally continue sending packets via its Server (or Relay), maintain a small queue of packets until target reachability is confirmed, or (optimistically) allow packets to flow directly to the target.

While data packets are still flowing, the source node thereafter periodically tests the direct path to the target node (see Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache entries alive. When the target node receives a valid NS message, it resets AcceptTime to ACCEPT_TIME and updates its cached link-layer addresses (if necessary). When the source node receives a solicited NA message, it resets ForwardTime to FORWARD_TIME and updates its cached link-layer addresses (if necessary). If the source node is unable to elicit a solicited NA response from the target node after MaxRetry attempts, it SHOULD set ForwardTime to 0. Otherwise, the source node considers the path usable and SHOULD thereafter process any link-layer errors as a hint that the direct path to the target node has either failed or has become intermittent.

When ForwardTime for a dynamic neighbor cache entry expires, the source node resumes sending any subsequent packets via a Server (or Relay) and may (eventually) attempt to re-initiate the AERO redirection process. When AcceptTime for a dynamic neighbor cache entry expires, the target node discards any subsequent packets received directly from the source node. When both ForwardTime and AcceptTime for a dynamic neighbor cache entry expire, the node deletes the neighbor cache entry.

3.17. Mobility Management

3.17.1. Announcing Link-Layer Address Changes

When a Client needs to change its link-layer addresses, e.g., due to a mobility event, it sends unsolicited NAs to its neighbors using the new link-layer address as the source address and with TLLAOs that include the updated Client link-layer information.

The Client MAY send up to MaxRetry unsolicited NA messages in parallel with sending actual data packets in case one or more NAs are lost. If all NAs are lost, the Client will eventually invoke NUD by sending NS messages that include SLLAOs.

3.17.2. Bringing New Links Into Service

When a Client needs to bring new underlying interfaces into service (e.g., when it activates a new data link), it sends unsolicited NAs to its neighbors using the new link-layer address as the source address and with TLLAOs that include the new Client link-layer information.

3.17.3. Removing Existing Links from Service

When a Client needs to remove existing underlying interfaces from service (e.g., when it de-activates an existing data link), it sends unsolicited NAs to its neighbors with TLLAOs that include P(i) values set to "disabled".

If the Client needs to send the unsolicited NAs over a link other than the one being removed from service, it MUST include a TLLAO for the sending link as the first TLLAO and include the TLLAO for the link being removed from service as an additional TLLAO.

3.17.4. Implicit Mobility Management

AERO interface neighbors MAY include a configuration knob that allows them to perform implicit mobility management in which no IPv6 ND messaging is used. In that case, the Client only transmits packets over a single interface at a time, and the neighbor always observes packets arriving from the Client from the same link-layer source address.

If the Client's underlying interface address changes (either due to a readdressing of the original interface or switching to a new interface) the neighbor immediately updates the neighbor cache entry for the Client and begins accepting and sending packets to the Client's new link-layer address. This implicit mobility method applies to use cases such as cellphones with both WiFi and Cellular interfaces where only one of the interfaces is active at a given time, and the Client automatically switches over to the backup interface if the primary interface fails.

3.17.5. Moving to a New Server

When a Client associates with a new Server, it performs the Client procedures specified in Section 3.14.2.

When a Client disassociates with an existing Server, it sends a DHCPv6 Release message via a new Server with its base AERO address as the network-layer source address and the unicast link-local address of the old Server as the network-layer destination address. The new Server then encapsulates the Release message in a DHCPv6 Relay-Forward message header, writes the Client's source address in the 'peer-address' field, and writes its own link-local address in the IP source address (i.e., the new Server acts as a DHCPv6 relay agent). The new Server then forwards the message to an Relay, which forwards the message to the old Server based on the network-layer destination address.

When the old Server receives the Release, it first authenticates the message then releases the DHCPv6 PDs and deletes the Client's ACP routes. The old Server then deletes the Client's neighbor cache entry so that any in-flight packets will be forwarded via a Relay to the new Server, which will forward them to the Client. The old Server finally returns a DHCPv6 Relay-Reply message via an Relay to the new Server, which will decapsulate the DHCPv6 Reply message and forward it to the Client.

When the new Server forwards the Reply message, the Client can delete both the default route and the neighbor cache entry for the old Server. (Note that since Release/Reply messages may be lost in the network the Client SHOULD retry until it gets a Reply indicating that the Release was successful. If the Client does not receive a Reply after MaxRetry attempts, the old Server may have failed and the Client should discontinue its Release attempts.)

Note that this DHCPv6 relay-chaining approach is necessary to avoid failures, e.g., due to temporary routing fluctuations. In particular, the Client should always be able to forward messages via its new Server but may not always be able to send messages directly to an old Server. But, the new Server and Old Server should always be able to exchange messages with one another.

Finally, Clients SHOULD NOT move rapidly between Servers in order to avoid causing excessive oscillations in the AERO routing system. Such oscillations could result in intermittent reachability for the Client itself, while causing little harm to the network. Examples of when a Client might wish to change to a different Server include a Server that has gone unreachable, topological movements of significant distance, etc.

3.17.6. Packet Queueing for Mobility

AERO Clients and Servers should maintain a small queue of packets they have recently sent to an AERO neighbor, e.g., a 1 second window. If the AERO neighbor moves, the AERO node MAY retransmit the queued packets to ensure that they are delivered to the AERO neighbor's new location.

Note that this may have performance implications for asymmetric paths. For example, if the AERO neighbor moves from a 50Mbps link to a 128Kbps link, retransmitting a 1 second window could cause significant congestion. However, any retransmission bursts will subside after the 1 second window.

3.17.7. Alternate Mobility Security Model

In some environments, an AERO node may have no way of authenticating any unsolicited NA messages it receives. In that case, the target AERO node SHOULD ignore any unsolicited NA messages it receives, and the source AERO node SHOULD inform the target of its new link-layer addresses by sending a fresh Predirect message via its Server (or Relay). The target AERO node can then accept the Predirect message and update its link-layer addresses based on the Predirect TLLAOs.

3.18. Multicast Considerations

When the underlying network does not support multicast, AERO Clients map link-scoped multicast addresses to the link-layer address of a Server, which acts as a multicast forwarding agent. The AERO Client also serves as an IGMP/MLD Proxy for its EUNs and/or hosted applications per [RFC4605] while using the link-layer address of the Server as the link-layer address for all multicast packets.

When the underlying network supports multicast, AERO nodes use the multicast address mapping specification found in [RFC2529] for IPv4 underlying networks and use a TBD site-scoped multicast mapping for IPv6 underlying networks. In that case, border routers must ensure that the encapsulated site-scoped multicast packets do not leak outside of the site spanned by the AERO link.

4. AERO Variations

AERO can be used in many different variations based on the specific use case. The following sections discuss variations that adhere to the AERO principles while allowing selective application of AERO components.

4.1. Operation on Host-Only IPv6 AERO Links

IPv6 AERO links typically have ASPs that cover many candidate ACPs of length /64 or shorter. However, in some cases it may be desirable to use AERO over links that have only a /64 ASP. This can be accommodated by treating all Clients on the AERO link as simple hosts that receive /128 prefix delegations.

In that case, each Client configures an administratively-provisioned link-local address instead of an AERO address, i.e., the same as for Servers and Relays. The Client discovers its link-local address by including an IA_NA option in its DHCPv6 Solicit message to the Server. The Server responds by returning the Client's administratively-provisioned link-local address in the IA_NA option plus any IPv6 addresses for the Client in IA_PD options with prefix length /128.

For example, if the ASP for the host-only IPv6 AERO link is 2001:db8:1000:2000::/64, each Client will receive one or more /128 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2001:db8:1000:2000::2/128, etc. The Client then assigns the /128s to the AERO interface as IPv6 addresses, and the Client's applications treat the AERO interface as an ordinary host interface.

In this arrangement, the Client conducts route optimization in the same sense as discussed in Section 3.15, except that the Predirect message network-layer source address is the Client's administratively-assigned link-local address and the network-layer destination address is the same as the destination address of the packet that triggered the redirection. All other aspects of AERO operation are the same as described in earlier sections.

This has applicability for nodes that act as a Client on an "upstream" AERO link, but also act as a Server on "downstream" AERO links. More specifically, if the node acts as a Client to receive a /64 prefix from the upstream AERO link it can then act as a Server to provision /128s to Clients on downstream AERO links.

Note that, due to the nature of the AERO address format, valid IPv6 ACP lengths are either /64 or shorter, or exactly /128 (i.e., prefix lengths between /65 and /127 cannot be accommodated).

4.2. Operation on AERO Links Without DHCPv6 Services

When Servers on the AERO link do not provide DHCPv6 services, operation can still be accommodated through administrative configuration of ACPs on AERO Clients. In that case, administrative configurations of AERO interface neighbor cache entries on both the Server and Client are also necessary. However, this may interfere with the ability for Clients to dynamically change to new Servers, and can expose the AERO link to misconfigurations unless the administrative configurations are carefully coordinated.

4.3. Operation on Server-less AERO Links

In some AERO link scenarios, there may be no Servers on the link and/or no need for Clients to use a Server as an intermediary trust anchor. In that case, each Client acts as a Server unto itself to establish neighbor cache entries by performing direct Client-to-Client IPv6 ND message exchanges, and some other form of trust basis must be applied so that each Client can verify that the prospective neighbor is authorized to use its claimed ACP.

When there is no Server on the link, Clients must arrange to receive ACPs and publish them via a secure alternate PD authority through some means outside the scope of this document.

4.4. Operation on Client-less AERO Links

In some environments, the AERO service may be useful for mobile nodes that do not implement the AERO Client function and do not perform encapsulation. For example, if the mobile node has a way of injecting its ACP into the access subnetwork routing system an AERO Server connected to the same access network can accept the ACP prefix injection as an indication that a new mobile node has come onto the subnetwork. The Server can then inject the ACP into the BGP routing system the same as if an AERO Client/Server DHCPv6 PD exchange had occurred. If the mobile node subsequently withdraws the ACP from the access network routing system, the Server can then withdraw the ACP from the BGP routing system.

In this arrangement, AERO Servers and Relays are used in exactly the same ways as for environments where DHCPv6 Client/Server exchanges are supported. However, the access subnetwork routing systems must be capable of accommodating rapid ACP injections and withdrawals from mobile nodes with the understanding that the information must be propagated to all routers in the system. Operational experience has shown that this kind of routing system "churn" can lead to overall instability and routing system inconsistency.

4.5. Manually-Configured AERO Tunnels

In addition to the dynamic neighbor discovery procedures for AERO link neighbors described above, AERO encapsulation can be applied to manually-configured tunnels. In that case, the tunnel endpoints use an administratively-provisioned link-local address and exchange NS/NA messages the same as for dynamically-established tunnels.

4.6. Encapsulation Avoidance on Relay-Server Dedicated Links

In some environments, AERO Servers and Relays may be connected by dedicated point-to-point links, e.g., high speed fiberoptic leased lines. In that case, the Servers and Relays can participate in the AERO link the same as specified above but can avoid encapsulation over the dedicated links. In that case, however, the links would be dedicated for AERO and could not be multiplexed for both AERO and non-AERO communications.

4.7. Encapsulation Protocol Version Considerations

A source Client may connect only to an IPvX underlying network, while the target Client connects only to an IPvY underlying network. In that case, the target and source Clients have no means for reaching each other directly (since they connect to underlying networks of different IP protocol versions) and so must ignore any redirection messages and continue to send packets via their Servers.

5. Implementation Status

Production user-level and kernel-level AERO implementations have been developed and are undergoing internal testing within Boeing.

An initial public release of the AERO proof-of-concept source code was announced on the intarea mailing list on August 21, 2015, and a pointer to the code is available in the list archives.

6. IANA Considerations

The IANA has assigned a 4-octet Private Enterprise Number "45282" for AERO in the "enterprise-numbers" registry.

The IANA has assigned the UDP port number "8060" for an earlier experimental version of AERO [RFC6706]. This document obsoletes [RFC6706] and claims the UDP port number "8060" for all future use.

No further IANA actions are required.

7. Security Considerations

AERO link security considerations are the same as for standard IPv6 Neighbor Discovery [RFC4861] except that AERO improves on some aspects. In particular, AERO uses a trust basis between Clients and Servers, where the Clients only engage in the AERO mechanism when it is facilitated by a trust anchor.

Redirect, Predirect and unsolicited NA messages SHOULD include a Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes can use to verify the message time of origin. Predirect, NS and RS messages SHOULD include a Nonce option (see Section 5.3 of [RFC3971]) that recipients echo back in corresponding responses. In cases where spoofing cannot be mitigated through other means, however, all AERO IPv6 ND messages should employ Secure Neighbor Discovery (SeND) [RFC3971].

AERO links must be protected against link-layer address spoofing attacks in which an attacker on the link pretends to be a trusted neighbor. Links that provide link-layer securing mechanisms (e.g., IEEE 802.1X WLANs) and links that provide physical security (e.g., enterprise network wired LANs) provide a first line of defense, however AERO nodes SHOULD also use DHCPv6 securing services (e.g., Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6], etc.) for Client authentication and network admission control. Following authenticated DHCPv6 PD procedures, AERO nodes MUST ensure that the source of data packets corresponds to the node to which the prefixes were delegated.

AERO Clients MUST ensure that their connectivity is not used by unauthorized nodes on their EUNs to gain access to a protected network, i.e., AERO Clients that act as routers MUST NOT provide routing services for unauthorized nodes. (This concern is no different than for ordinary hosts that receive an IP address delegation but then "share" the address with other nodes via some form of Internet connection sharing.)

AERO Clients, Servers and Relays on the open Internet are susceptible to the same attack profiles as for any Internet nodes. For this reason, IP security SHOULD be used when AERO is employed over unmanaged/unsecured links using securing mechanisms such as IPsec [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, however, the use of end-to-end security from Clients to correspondent nodes (i.e., other Clients and/or Internet nodes) could obviate the need for IP security between AERO Clients, Servers and Relays.

AERO Servers and Relays present targets for traffic amplification DoS attacks. This concern is no different than for widely-deployed VPN security gateways in the Internet, where attackers could send spoofed packets to the gateways at high data rates. This can be mitigated by connecting Relays and Servers over dedicated links with no connections to the Internet and/or when connections to the Internet are only permitted through well-managed firewalls.

Traffic amplification DoS attacks can also target an AERO Client's low data rate links. This is a concern not only for Clients located on the open Internet but also for Clients in protected enclaves. AERO Servers can institute rate limits that protect Clients from receiving packet floods that could DoS low data rate links.

8. Acknowledgements

Discussions both on IETF lists and in private exchanges helped shape some of the concepts in this work. Individuals who contributed insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, Adrian Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom Herbert, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. Members of the IESG also provided valuable input during their review process that greatly improved the document. Discussions on the v6ops list in the December 2015 through January 2016 timeframe further helped clarify AERO multi-addressing capabilities. Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman for their shepherding guidance during the publication of the AERO first edition.

This work has further been encouraged and supported by Boeing colleagues including M. Wayne Benson, Dave Bernhardt, Cam Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie Wulff, Yueli Yang, and other members of the BR&T and BIT mobile networking teams. Wayne Benson is especially acknowledged for his outstanding work in converting the AERO proof-of-concept implementation into production-ready code.

Earlier works on NBMA tunneling approaches are found in [RFC2529][RFC5214][RFC5569].

Many of the constructs presented in this second edition of AERO are based on the author's earlier works, including:

• The Internet Routing Overlay Network (IRON) [RFC6179][I-D.templin-ironbis]
• Virtual Enterprise Traversal (VET) [RFC5558][I-D.templin-intarea-vet]
• The Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320][I-D.templin-intarea-seal]
• AERO, First Edition [RFC6706]

Note that these works cite numerous earlier efforts that are not also cited here due to space limitations. The authors of those earlier works are acknowledged for their insights.

This work is aligned with the NASA Safe Autonomous Systems Operation (SASO) program under NASA contract number NNA16BD84C.

This work is aligned with the FAA as per the SE2025 contract number DTFAWA-15-D-00030.

This work is aligned with the Boeing Information Technology (BIT) MobileNet program.

This work is aligned with the Boeing Research and Technology (BR&T) autonomous systems networking program.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. AERO Alternate Encapsulations

When GUE encapsulation is not needed, AERO can use common encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The encapsulation is therefore only differentiated from non-AERO tunnels through the application of AERO control messaging and not through, e.g., a well-known UDP port number.

As for GUE encapsulation, alternate AERO encapsulation formats may require encapsulation layer fragmentation. For simple IP-in-IP encapsulation, an IPv6 fragment header is inserted directly between the inner and outer IP headers when needed, i.e., even if the outer header is IPv4. The IPv6 Fragment Header is identified to the outer IP layer by its IP protocol number, and the Next Header field in the IPv6 Fragment Header identifies the inner IP header version. For GRE encapsulation, a GRE fragment header is inserted within the GRE header [I-D.templin-intarea-grefrag].

Figure 6 shows the AERO IP-in-IP encapsulation format before any fragmentation is applied:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Outer IPv4 Header     |      |    Outer IPv6 Header      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |IPv6 Frag Header (optional)|      |IPv6 Frag Header (optional)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Inner IP Header      |      |       Inner IP Header     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           |      |                           |
     ~                           ~      ~                           ~
     ~    Inner Packet Body      ~      ~     Inner Packet Body     ~
     ~                           ~      ~                           ~
     |                           |      |                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Minimal Encapsulation in IPv4      Minimal Encapsulation in IPv6

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Outer IP Header        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          GRE Header           |
     | (with checksum, key, etc..)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | GRE Fragment Header (optional)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Inner IP Header        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     ~                               ~
     ~      Inner Packet Body        ~
     ~                               ~
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+