Automatic Extended Route Optimization (AERO)
draft-templin-intarea-6706bis-98
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Fred Templin | ||
| Last updated | 2021-03-23 (Latest revision 2021-03-22) | ||
| Replaces | draft-templin-aerolink | ||
| Replaced by | draft-templin-6man-aero, draft-templin-6man-aero | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-templin-intarea-6706bis-98
quot; address that is configured by all Bridges on the link. Correspondent nodes can then perform Segment Routing to select the correct SRT, which will then direct the original IP packet over multiple hops to the target. 3.19. DNS Considerations AERO Client MNs and INET correspondent nodes consult the Domain Name System (DNS) the same as for any Internetworking node. When correspondent nodes and Client MNs use different IP protocol versions (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain A records for IPv4 address mappings to MNs which must then be populated in Relay NAT64 mapping caches. In that way, an IPv4 correspondent node can send original IPv4 packets to the IPv4 address mapping of the target MN, and the Relay will translate the IPv4 header and destination address into an IPv6 header and IPv6 destination address of the MN. When an AERO Client registers with an AERO Proxy/Server, the Proxy/ Server can return the address(es) of DNS servers in RDNSS options [RFC6106]. The DNS server provides the IP addresses of other MNs and correspondent nodes in AAAA records for IPv6 or A records for IPv4. 3.20. Transition/Coexistence Considerations OAL encapsulation ensures that dissimilar INET partitions can be joined into a single unified OMNI link, even though the partitions themselves may have differing protocol versions and/or incompatible addressing plans. However, a commonality can be achieved by incrementally distributing globally routable (i.e., native) IP prefixes to eventually reach all nodes (both mobile and fixed) in all Templin Expires September 24, 2021 [Page 65] Internet-Draft AERO March 2021 OMNI link segments. This can be accomplished by incrementally deploying AERO Bridges on each INET partition, with each Bridge distributing its MNPs and/or discovering non-MNP IP GUA prefixes on its INET links. This gives rise to the opportunity to eventually distribute native IP addresses to all nodes, and to present a unified OMNI link view even if the INET partitions remain in their current protocol and addressing plans. In that way, the OMNI link can serve the dual purpose of providing a mobility/multilink service and a transition/ coexistence service. Or, if an INET partition is transitioned to a native IP protocol version and addressing scheme that is compatible with the OMNI link MNP-based addressing scheme, the partition and OMNI link can be joined by Bridges. Relays that connect INETs/EUNs with dissimilar IP protocol versions may need to employ a network address and protocol translation function such as NAT64 [RFC6146]. 3.21. Detecting and Reacting to Server and Bridge Failures In environments where rapid failure recovery is required, Proxy/ Servers and Bridges SHOULD use Bidirectional Forwarding Detection (BFD) [RFC5880]. Nodes that use BFD can quickly detect and react to failures so that cached information is re-established through alternate nodes. BFD control messaging is carried only over well- connected ground domain networks (i.e., and not low-end radio links) and can therefore be tuned for rapid response. Proxy/Servers and Bridges maintain BFD sessions in parallel with their BGP peerings. If a Proxy/Server or Bridge fails, BGP peers will quickly re-establish routes through alternate paths the same as for common BGP deployments. Similarly, Proxys maintain BFD sessions with their associated Bridges even though they do not establish BGP peerings with them. Proxys SHOULD use proactive NUD for Proxy/Servers for which there are currently active ANET Clients in a manner that parallels BFD, i.e., by sending unicast NS messages in rapid succession to receive solicited NA messages. When the Proxy is also sending RS messages on behalf of ANET Clients, the RS/RA messaging can be considered as equivalent hints of forward progress. This means that the Proxy need not also send a periodic NS if it has already sent an RS within the same period. If a Proxy/Server fails, the Proxy will cease to receive advertisements and can quickly inform Clients of the outage by sending multicast RA messages on the ANET interface. Templin Expires September 24, 2021 [Page 66] Internet-Draft AERO March 2021 The Proxy sends multicast RA messages with source address set to the Proxy/Server's address, destination address set to (link-local) All- Nodes multicast, and Router Lifetime set to 0. The Proxy SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated by small delays [RFC4861]. Any Clients on the ANET interface that have been using the (now defunct) Proxy/Server will receive the RA messages and associate with a new Proxy/Server. 3.22. AERO Clients on the Open Internet AERO Clients that connect to the open Internet via INET interfaces can establish a VPN or direct link to securely connect to a Proxy/ Server in a "tethered" arrangement with all of the Client's traffic transiting the Proxy/Server. Alternatively, the Client can associate with an INET Proxy/Server using UDP/IP encapsulation and control message securing services as discussed in the following sections. When a Client's OMNI interface enables an INET underlying interface, it first determines whether the interface is likely to be behind a NAT. For IPv4, the Client assumes it is on the open Internet if the INET address is not a special-use IPv4 address per [RFC3330]. Similarly for IPv6, the Client assumes it is on the open Internet if the INET address is a Global Unicast Address (GUA) [RFC4291]. Otherwise, the Client assumes it may be behind one or several NATs. The Client then prepares an RS message with IPv6 source address set to its MNP-LLA, with IPv6 destination set to (link-local) All-Routers multicast and with an OMNI option with underlying interface attributes. If the Client believes that it is on the open Internet, it SHOULD include an L2ADDR in the Interface Attributes sub-option corresponding to the underlying interface; otherwise, it MAY omit L2ADDR. If the underlying address is IPv4, the Client includes the Port Number and IPv4 address written in obfuscated form [RFC4380] as discussed in Section 3.3. If the underlying interface address is IPv6, the Client instead includes the Port Number and IPv6 address in obfuscated form. The Client finally includes a HIP "Initiator" message sub-option in the OMNI option [I-D.templin-6man-omni-interface] to provide message authentication and submits the RS for OAL encapsulation as an OAL atomic fragment using an unpredictable Identification value to establish the start of the "send" window for this Proxy/Server. The Client then encapsulates the OAL fragment in UDP/IP headers to form a carrier packet, sets the UDP/IP source to its INET address and UDP port, sets the UDP/IP destination to the Proxy/Server's INET address and the AERO service port number (8060), then sends the carrier packet to the Proxy/Server. Templin Expires September 24, 2021 [Page 67] Internet-Draft AERO March 2021 When the Proxy/Server receives the RS, it discards the OAL encapsulation, authenticates the RS message, creates a neighbor cache entry and registers the Client's MNP, Identification and INET interface information according to the OMNI option parameters. If the RS message OMNI option includes Interface Attributes with an L2ADDR, the Proxy/Server compares the encapsulation IP address and UDP port number with the (unobfuscated) values. If the values are the same, the Proxy/Server caches the Client's information as "INET" addresses meaning that the Client is likely to accept direct messages without requiring NAT traversal exchanges. If the values are different (or, if the OMNI option did not include an L2ADDR) the Proxy/Server instead caches the Client's information as "mapped" addresses meaning that NAT traversal exchanges may be necessary. The Proxy/Server then prepares an RA message with IPv6 source and destination set corresponding to the addresses in the RS, and with an OMNI option with an Origin Indication sub-option per [I-D.templin-6man-omni-interface] with the mapped and obfuscated Port Number and IP address observed in the encapsulation headers. The Proxy/Server also includes a HIP "Responder" message sub-option per [I-D.templin-6man-omni-interface] that contains an acknowledgement of the update sent by the Client. The Proxy/Server then performs OAL encapsulation and fragmentation if necessary using the same Identification value that appeared in the RS, and encapsulates each fragment in UDP/IP headers with addresses set per the L2ADDR information in the neighbor cache entry for the Client. When the Client receives the RA message, it verifies the OAL Identification value, performs OAL reassembly if necessary, authenticates the HIP "Responder" message, then compares the mapped Port Number and IP address from the Origin Indication sub-option with its own address. If the addresses are the same, the Client assumes the open Internet / Cone NAT principle; if the addresses are different, the Client instead assumes that further qualification procedures are necessary to detect the type of NAT and proceeds according to standard procedures [RFC6081][RFC4380]. After the Client has registered its INET interfaces in such RS/RA exchanges it sends periodic RS messages to receive fresh RA messages before the Router Lifetime received on each INET interface expires. The Client also maintains default routes via its Proxy/Servers, i.e., the same as described in earlier sections. When the Client sends messages to target IP addresses, it also invokes route optimization per Section 3.14 using IPv6 ND address resolution messaging. The Client first creates a neighbor cache entry for the target in the INCOMPLETE state, then sends the NS(AR) message to the Proxy/Server with an OMNI option with a HIP "Update/ Templin Expires September 24, 2021 [Page 68] Internet-Draft AERO March 2021 Sequence" message sub-option. The Client sets the NS source address to the Client's MNP-LLA, destination address to the target solicited node multicast address and target address to the LLA of the target. The Client then wraps the NS message in OAL headers (i.e., as an atomic OAL fragment) with an unpredictable Identification value to establish the "send" window for this target, with source address set to its own MNP-ULA and destination address set to the target's MNP- ULA. The Client then wraps the atomic OAL fragment in a UDP/IP header and sends the resulting carrier packet to the Proxy/Server. When the Client's Proxy/Server receives the OAL-encapsulated NS, it authenticates the message by processing the HIP message sub-option and forwards the message over the spanning tree on behalf of the Client while changing the OAL source address to its own ULA and the OAL destination address to the MNP-ULA for the target but retains the Client's supplied Identification. When the ROR receives the NS(AR), it creates a neighbor cache entry for the ROS in the STALE state and caches the Identification value as the start of the "accept" window for packets originating from this ROS (if the ROR is a Proxy/Server, it also creates a Report List entry for this ROS in the target Client's neighbor cache entry). The ROR then returns an NA(AR) with OMNI option information for the target including all of the target's Interface Attributes. The ROR sets the NA(AR) source address to its own LLA, sets the destination address to the ROS LLA and sets the target address to the LLA of the target. The ROR then performs OAL encapsulation using the same Identification value that appeared in the NS(AR), then sets the OAL source address to the ROR's ULA and destination address to ULA source of the NS(AR). When the ROS Client receives the NA(AR) message contained in one or more carrier packets, it verifies the OAL Identification matches the same value that was used in the NS(AR) then reassembles if necessary. When reassembly is complete, the Proxy/Server changes the ROS sets the neighbor cache entry state for this target to REACHABLE. Following route optimization for targets in the same OMNI link segment, if the target's L2ADDR is on the open INET, the Client forwards carrier packets directly to the target INET address. If the target is behind a NAT, the Client first establishes NAT state for the L2ADDR using the "direct bubble" and NUD mechanisms discussed in Section 3.10.1. The Client continues to send carrier packets via its Proxy/Server until NAT state is populated, then begins forwarding carrier packets via the direct path through the NAT to the target. For targets in different OMNI link segments, the Client uses OAL/ORH encapsulation and forwards carrier packets to the Bridge that returned the NA message. Templin Expires September 24, 2021 [Page 69] Internet-Draft AERO March 2021 The ROR may return uNAs via the ROS Proxy/Server if the target moves, and the Proxy/Server will send corresponding uNAs to the Client with a HIP "Notify" authentication message. The Client can also send NUD messages to test forward path reachability even though there is no security association between the Client and the target. The Client can send original IP packets to route-optimized neighbors in the same OMNI link segment no larger than the path MPS in one piece and with OAL encapsulation but without fragmentation. For larger original IP packets, the Client applies OAL encapsulation and fragmentation if necessary according to Section 3.9, with OAL header with source set to its own MNP-ULA and destination set to the MNP-ULA of the target. The Client then encapsulates each original IP packet or OAL fragment in UDP/IP *NET headers and sends them to the next hop. Note: The NAT traversal procedures specified in this document are applicable for Cone, Address-Restricted and Port-Restricted NATs only. While future updates to this document may specify procedures for other NAT variations (e.g., hairpinning and various forms of Symmetric NATs), it should be noted that continuous communications are always possible through forwarding via a Proxy/Server even if NAT traversal is not employed. Note: Following the initial HIP Initiator/Responder exchange, AERO Clients with OMNI interfaces configured over the open Internet maintain HIP associations through the transmission of IPv6 ND messages that include OMNI options with HIP "Update" and "Notify" messages. OMNI interfaces use the HIP "Update" message when an acknowledgement is required, and use the "Notify" message in unacknowledged isolated IPv6 ND messages (e.g., unsolicited NAs). Note: Proxy/Servers on the open Internet that act as Proxys authenticate and remove OMNI option HIP message sub-options from RSes they forward from the MN to another Proxy/Server, and insert and sign HIP message and Origin Indication sub-options in RAs they forward from another Proxy/Server to the MN. Conversely, Proxy/Servers that act as Proxys forward without processing any MNP registration/ delegation information in RS/RA message exchanges between MNs and other Proxy/Servers. The Proxy/Server acting as a Proxy is therefore responsible for MN authentication, while the other Proxy/Servers are responsible for registering/delegating MNPs (noting that the same node can act as both Proxy and Proxy/Server). Templin Expires September 24, 2021 [Page 70] Internet-Draft AERO March 2021 3.23. Time-Varying MNPs In some use cases, it is desirable, beneficial and efficient for the Client to receive a constant MNP that travels with the Client wherever it moves. For example, this would allow air traffic controllers to easily track aircraft, etc. In other cases, however (e.g., intelligent transportation systems), the MN may be willing to sacrifice a modicum of efficiency in order to have time-varying MNPs that can be changed every so often to defeat adversarial tracking. The DHCPv6 service offers a way for Clients that desire time-varying MNPs to obtain short-lived prefixes (e.g., on the order of a small number of minutes). In that case, the identity of the Client would not be bound to the MNP but rather to a Node Identification value (see: [I-D.templin-6man-omni-interface]) to be used as the Client ID seed for MNP prefix delegation. The Client would then be obligated to renumber its internal networks whenever its MNP (and therefore also its MNP-LLA) changes. This should not present a challenge for Clients with automated network renumbering services, however presents limits for the durations of ongoing sessions that would prefer to use a constant address. 4. Implementation Status An early AERO implementation based on OpenVPN (https://openvpn.net/) was announced on the v6ops mailing list on January 10, 2018 and an initial public release of the AERO proof-of-concept source code was announced on the intarea mailing list on August 21, 2015. AERO Release-3.0.2 was tagged on October 15, 2020, and is undergoing internal testing. Additional internal releases expected within the coming months, with first public release expected end of 1H2021. 5. IANA Considerations The IANA is instructed to assign a new type value TBD1 in the IPv6 Routing Types registry. The IANA has assigned the UDP port number "8060" for an earlier experimental first version of AERO [RFC6706]. This document obsoletes [RFC6706], and together with [I-D.templin-6man-omni-interface] reclaims the UDP port number "8060" for 'aero' as the service port for UDP/IP encapsulation. (Note that, although [RFC6706] was not widely implemented or deployed, any messages coded to that specification can be easily distinguished and ignored since they use the invalid ICMPv6 message type number '0'.) This document makes no request of IANA, since [I-D.templin-6man-omni-interface] already provides instructions. Templin Expires September 24, 2021 [Page 71] Internet-Draft AERO March 2021 No further IANA actions are required. 6. Security Considerations AERO Bridges configure secured tunnels with AERO Proxy/Servers, Relays and Proxys within their local OMNI link segments. Applicable secured tunnel alternatives include IPsec [RFC4301], TLS/SSL [RFC8446], DTLS [RFC6347], WireGuard [WG], etc. The AERO Bridges of all OMNI link segments in turn configure secured tunnels for their neighboring AERO Bridges in a spanning tree topology. Therefore, control messages exchanged between any pair of OMNI link neighbors on the spanning tree are already secured. AERO nodes acting as Route Optimization Responders (RORs) may also receive packets directly from arbitrary nodes in INET partitions instead of via the spanning tree. For INET partitions that apply effective ingress filtering to defeat source address spoofing, the simple data origin authentication procedures in Section 3.8 can be applied. For INET partitions that require strong security in the data plane, two options for securing communications include 1) disable route optimization so that all traffic is conveyed over secured tunnels, or 2) enable on-demand secure tunnel creation between INET partition neighbors. Option 1) would result in longer routes than necessary and traffic concentration on critical infrastructure elements. Option 2) could be coordinated by establishing a secured tunnel on- demand instead of performing an NS/NA exchange in the route optimization procedures. Procedures for establishing on-demand secured tunnels are out of scope. AERO Clients that connect to secured ANETs need not apply security to their ND messages, since the messages will be intercepted by a perimeter Proxy that applies security on its INET-facing interface as part of the spanning tree (see above). AERO Clients connected to the open INET can use network and/or transport layer security services such as VPNs or can by some other means establish a direct link. When a VPN or direct link may be impractical, however, the authentication services specified in [RFC7401] and/or [RFC4380] should be applied. Application endpoints SHOULD use application-layer security services such as TLS/SSL, DTLS or SSH [RFC4251] to assure the same level of protection as for critical secured Internet services. AERO Clients that require host-based VPN services SHOULD use network and/or transport layer security services such as IPsec, TLS/SSL, DTLS, etc. AERO Proxys and Proxy/Servers can also provide a network-based VPN service on behalf of the Client, e.g., if the Client is located Templin Expires September 24, 2021 [Page 72] Internet-Draft AERO March 2021 within a secured enclave and cannot establish a VPN on its own behalf. AERO Proxy/Servers and Bridges present targets for traffic amplification Denial of Service (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 Proxy/ Servers and Bridges 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 secured enclaves. AERO Proxy/Servers and Proxys can institute rate limits that protect Clients from receiving packet floods that could DoS low data rate links. AERO Relays must implement ingress filtering to avoid a spoofing attack in which spurious messages with ULA addresses are injected into an OMNI link from an outside attacker. 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 such as tethering.) The MAP list MUST be well-managed and secured from unauthorized tampering, even though the list contains only public information. The MAP list can be conveyed to the Client in a similar fashion as in [RFC5214] (e.g., through layer 2 data link login messaging, secure upload of a static file, DNS lookups, etc.). SRH authentication facilities are specified in [RFC8754]. Security considerations for accepting link-layer ICMP messages and reflected packets are discussed throughout the document. Security considerations for IPv6 fragmentation and reassembly are discussed in [I-D.templin-6man-omni-interface]. 7. Acknowledgements Discussions in the IETF, aviation standards communities and 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, Templin Expires September 24, 2021 [Page 73] Internet-Draft AERO March 2021 Wojciech Dec, Pavel Drasil, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha Hlusiak, Lee Howard, Zdenek Jaron, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members of the IESG also provided valuable input during their review process that greatly improved the document. 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 Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam Brodie, John Bush, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu Danilov, Don Dillenburg, Joe Dudkowski, Wen Fang, Samad Farooqui, Anthony Gregory, Jeff Holland, Seth Jahne, Brian Jaury, Greg Kimberly, Ed King, Madhuri Madhava Badgandi, Laurel Matthew, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Vijay Rajagopalan, Greg Saccone, Rod Santiago, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Katie Tran, Brendan Williams, Amelia Wilson, Julie Wulff, Yueli Yang, Eric Yeh and other members of the Boeing mobility, networking and autonomy teams. Kyle Bae, Wayne Benson, Katie Tran and Eric Yeh are especially acknowledged for implementing the AERO functions as extensions to the public domain OpenVPN distribution. 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: o The Internet Routing Overlay Network (IRON) [RFC6179][I-D.templin-ironbis] o Virtual Enterprise Traversal (VET) [RFC5558][I-D.templin-intarea-vet] o The Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320][I-D.templin-intarea-seal] o 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. Templin Expires September 24, 2021 [Page 74] Internet-Draft AERO March 2021 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 Commercial Airplanes (BCA) Internet of Things (IoT) and autonomy programs. This work is aligned with the Boeing Information Technology (BIT) MobileNet program. 8. References 8.1. Normative References [I-D.templin-6man-omni-interface] Templin, F. and T. Whyman, "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", draft- templin-6man-omni-interface-69 (work in progress), January 2021. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>. Templin Expires September 24, 2021 [Page 75] Internet-Draft AERO March 2021 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>. [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/RFC6081, January 2011, <https://www.rfc-editor.org/info/rfc6081>. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>. [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, <https://www.rfc-editor.org/info/rfc7739>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. Templin Expires September 24, 2021 [Page 76] Internet-Draft AERO March 2021 [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, November 2018, <https://www.rfc-editor.org/info/rfc8415>. 8.2. Informative References [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2016. [I-D.bonica-6man-comp-rtg-hdr] Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. Jalil, "The IPv6 Compact Routing Header (CRH)", draft- bonica-6man-comp-rtg-hdr-24 (work in progress), January 2021. [I-D.bonica-6man-crh-helper-opt] Li, X., Bao, C., Ruan, E., and R. Bonica, "Compressed Routing Header (CRH) Helper Option", draft-bonica-6man- crh-helper-opt-02 (work in progress), October 2020. [I-D.ietf-intarea-frag-fragile] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", draft- ietf-intarea-frag-fragile-17 (work in progress), September 2019. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", draft-ietf-intarea-tunnels-10 (work in progress), September 2019. [I-D.ietf-ipwave-vehicular-networking] Jeong, J., "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", draft-ietf- ipwave-vehicular-networking-19 (work in progress), July 2020. [I-D.ietf-rtgwg-atn-bgp] Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. Moreno, "A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network", draft-ietf- rtgwg-atn-bgp-10 (work in progress), January 2021. Templin Expires September 24, 2021 [Page 77] Internet-Draft AERO March 2021 [I-D.templin-6man-dhcpv6-ndopt] Templin, F., "A Unified Stateful/Stateless Configuration Service for IPv6", draft-templin-6man-dhcpv6-ndopt-11 (work in progress), January 2021. [I-D.templin-intarea-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", draft-templin-intarea-seal-68 (work in progress), January 2014. [I-D.templin-intarea-vet] Templin, F., "Virtual Enterprise Traversal (VET)", draft- templin-intarea-vet-40 (work in progress), May 2013. [I-D.templin-ipwave-uam-its] Templin, F., "Urban Air Mobility Implications for Intelligent Transportation Systems", draft-templin-ipwave- uam-its-04 (work in progress), January 2021. [I-D.templin-ironbis] Templin, F., "The Interior Routing Overlay Network (IRON)", draft-templin-ironbis-16 (work in progress), March 2014. [I-D.templin-v6ops-pdhost] Templin, F., "IPv6 Prefix Delegation and Multi-Addressing Models", draft-templin-v6ops-pdhost-27 (work in progress), January 2021. [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>. [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, <https://www.rfc-editor.org/info/rfc2003>. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, DOI 10.17487/RFC2004, October 1996, <https://www.rfc-editor.org/info/rfc2004>. Templin Expires September 24, 2021 [Page 78] Internet-Draft AERO March 2021 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, DOI 10.17487/RFC2529, March 1999, <https://www.rfc-editor.org/info/rfc2529>. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <https://www.rfc-editor.org/info/rfc2983>. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, DOI 10.17487/RFC3330, September 2002, <https://www.rfc-editor.org/info/rfc3330>. [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>. [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>. Templin Expires September 24, 2021 [Page 79] Internet-Draft AERO March 2021 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>. [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <https://www.rfc-editor.org/info/rfc4389>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>. [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006, <https://www.rfc-editor.org/info/rfc4511>. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, August 2006, <https://www.rfc-editor.org/info/rfc4605>. [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, <https://www.rfc-editor.org/info/rfc4982>. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <https://www.rfc-editor.org/info/rfc5015>. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, <https://www.rfc-editor.org/info/rfc5214>. Templin Expires September 24, 2021 [Page 80] Internet-Draft AERO March 2021 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, February 2010, <https://www.rfc-editor.org/info/rfc5320>. [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", RFC 5522, DOI 10.17487/RFC5522, October 2009, <https://www.rfc-editor.org/info/rfc5522>. [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, DOI 10.17487/RFC5558, February 2010, <https://www.rfc-editor.org/info/rfc5558>. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, January 2010, <https://www.rfc-editor.org/info/rfc5569>. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010, <https://www.rfc-editor.org/info/rfc6106>. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>. [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, <https://www.rfc-editor.org/info/rfc6179>. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <https://www.rfc-editor.org/info/rfc6221>. [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, DOI 10.17487/RFC6273, June 2011, <https://www.rfc-editor.org/info/rfc6273>. Templin Expires September 24, 2021 [Page 81] Internet-Draft AERO March 2021 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, DOI 10.17487/RFC6355, August 2011, <https://www.rfc-editor.org/info/rfc6355>. [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>. [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, <https://www.rfc-editor.org/info/rfc6706>. [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, <https://www.rfc-editor.org/info/rfc7333>. [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. Templin Expires September 24, 2021 [Page 82] Internet-Draft AERO March 2021 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>. [WG] Wireguard, "Wireguard, https://www.wireguard.com", August 2020. Appendix A. Non-Normative Considerations AERO can be applied to a multitude of Internetworking scenarios, with each having its own adaptations. The following considerations are provided as non-normative guidance: A.1. Implementation Strategies for Route Optimization Route optimization as discussed in Section 3.14 results in the route optimization source (ROS) creating a neighbor cache entry for the target neighbor. The neighbor cache entry is maintained for at most ReachableTime seconds and then deleted unless updated. In order to refresh the neighbor cache entry lifetime before the ReachableTime timer expires, the specification requires implementations to issue a new NS/NA exchange to reset ReachableTime while data packets are still flowing. However, the decision of when to initiate a new NS/NA exchange and to perpetuate the process is left as an implementation detail. One possible strategy may be to monitor the neighbor cache entry watching for data packets for (ReachableTime - 5) seconds. If any data packets have been sent to the neighbor within this timeframe, then send an NS to receive a new NA. If no data packets have been sent, wait for 5 additional seconds and send an immediate NS if any data packets are sent within this "expiration pending" 5 second window. If no additional data packets are sent within the 5 second window, delete the neighbor cache entry. The monitoring of the neighbor data packet traffic therefore becomes an asymmetric ongoing process during the neighbor cache entry lifetime. If the neighbor cache entry expires, future data packets will trigger a new NS/NA exchange while the packets themselves are delivered over a longer path until route optimization state is re- established. A.2. Implicit Mobility Management OMNI interface neighbors MAY provide a configuration option that allows them to perform implicit mobility management in which no ND messaging is used. In that case, the Client only transmits packets Templin Expires September 24, 2021 [Page 83] Internet-Draft AERO March 2021 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 according to the Client's new 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. A.3. Direct Underlying Interfaces When a Client's OMNI interface is configured over a Direct interface, the neighbor at the other end of the Direct link can receive packets without any encapsulation. In that case, the Client sends packets over the Direct link according to QoS preferences. If the Direct interface has the highest QoS preference, then the Client's IP packets are transmitted directly to the peer without going through an ANET/INET. If other interfaces have higher QoS preferences, then the Client's IP packets are transmitted via a different interface, which may result in the inclusion of Proxys, Proxy/Servers and Bridges in the communications path. Direct interfaces must be tested periodically for reachability, e.g., via NUD. A.4. AERO Critical Infrastructure Considerations AERO Bridges can be either Commercial off-the Shelf (COTS) standard IP routers or virtual machines in the cloud. Bridges must be provisioned, supported and managed by the INET administrative authority, and connected to the Bridges of other INETs via inter- domain peerings. Cost for purchasing, configuring and managing Bridges is nominal even for very large OMNI links. AERO Proxy/Servers can be standard dedicated server platforms, but most often will be deployed as virtual machines in the cloud. The only requirements for Proxy/Servers are that they can run the AERO user-level code and have at least one network interface connection to the INET. As with Bridges, Proxy/Servers must be provisioned, supported and managed by the INET administrative authority. Cost for purchasing, configuring and managing Proxy/Servers is nominal especially for virtual Proxy/Servers hosted in the cloud. AERO Proxys are most often standard dedicated server platforms with one network interface connected to the ANET and a second interface Templin Expires September 24, 2021 [Page 84] Internet-Draft AERO March 2021 connected to an INET. As with Proxy/Servers, the only requirements are that they can run the AERO user-level code and have at least one interface connection to the INET. Proxys must be provisioned, supported and managed by the ANET administrative authority. Cost for purchasing, configuring and managing Proxys is nominal, and borne by the ANET administrative authority. AERO Relays can be any dedicated server or COTS router platform connected to INETs and/or EUNs. The Relay connects to the OMNI link and engages in eBGP peering with one or more Bridges as a stub AS. The Relay then injects its MNPs and/or non-MNP prefixes into the BGP routing system, and provisions the prefixes to its downstream- attached networks. The Relay can perform ROS/ROR services the same as for any Proxy/Server, and can route between the MNP and non-MNP address spaces. A.5. AERO Server Failure Implications AERO Proxy/Servers may appear as a single point of failure in the architecture, but such is not the case since all Proxy/Servers on the link provide identical services and loss of a Proxy/Server does not imply immediate and/or comprehensive communication failures. Although Clients typically associate with a single Proxy/Server at a time, Proxy/Server failure is quickly detected and conveyed by Bidirectional Forward Detection (BFD) and/or proactive NUD allowing Clients to migrate to new Proxy/Servers. If a Proxy/Server fails, ongoing packet forwarding to Clients will continue by virtue of the neighbor cache entries that have already been established in route optimization sources (ROSs). If a Client also experiences mobility events at roughly the same time the Proxy/ Server fails, unsolicited NA messages may be lost but proxy neighbor cache entries in the DEPARTED state will ensure that packet forwarding to the Client's new locations will continue for up to DepartTime seconds. If a Client is left without a Proxy/Server for an extended timeframe (e.g., greater than ReachableTime seconds) then existing neighbor cache entries will eventually expire and both ongoing and new communications will fail. The original source will continue to retransmit until the Client has established a new Proxy/Server relationship, after which time continuous communications will resume. Therefore, providing many Proxy/Servers on the link with high availability profiles provides resilience against loss of individual Proxy/Servers and assurance that Clients can establish new Proxy/ Server relationships quickly in event of a Proxy/Server failure. Templin Expires September 24, 2021 [Page 85] Internet-Draft AERO March 2021 A.6. AERO Client / Server Architecture The AERO architectural model is client / server in the control plane, with route optimization in the data plane. The same as for common Internet services, the AERO Client discovers the addresses of AERO Proxy/Servers and selects one Proxy/Server to connect to. The AERO service is analogous to common Internet services such as google.com, yahoo.com, cnn.com, etc. However, there is only one AERO service for the link and all Proxy/Servers provide identical services. Common Internet services provide differing strategies for advertising server addresses to clients. The strategy is conveyed through the DNS resource records returned in response to name resolution queries. As of January 2020 Internet-based 'nslookup' services were used to determine the following: o When a client resolves the domainname "google.com", the DNS always returns one A record (i.e., an IPv4 address) and one AAAA record (i.e., an IPv6 address). The client receives the same addresses each time it resolves the domainname via the same DNS resolver, but may receive different addresses when it resolves the domainname via different DNS resolvers. But, in each case, exactly one A and one AAAA record are returned. o When a client resolves the domainname "ietf.org", the DNS always returns one A record and one AAAA record with the same addresses regardless of which DNS resolver is used. o When a client resolves the domainname "yahoo.com", the DNS always returns a list of 4 A records and 4 AAAA records. Each time the client resolves the domainname via the same DNS resolver, the same list of addresses are returned but in randomized order (i.e., consistent with a DNS round-robin strategy). But, interestingly, the same addresses are returned (albeit in randomized order) when the domainname is resolved via different DNS resolvers. o When a client resolves the domainname "amazon.com", the DNS always returns a list of 3 A records and no AAAA records. As with "yahoo.com", the same three A records are returned from any worldwide Internet connection point in randomized order. The above example strategies show differing approaches to Internet resilience and service distribution offered by major Internet services. The Google approach exposes only a single IPv4 and a single IPv6 address to clients. Clients can then select whichever IP protocol version offers the best response, but will always use the same IP address according to the current Internet connection point. This means that the IP address offered by the network must lead to a Templin Expires September 24, 2021 [Page 86] Internet-Draft AERO March 2021 highly-available server and/or service distribution point. In other words, resilience is predicated on high availability within the network and with no client-initiated failovers expected (i.e., it is all-or-nothing from the client's perspective). However, Google does provide for worldwide distributed service distribution by virtue of the fact that each Internet connection point responds with a different IPv6 and IPv4 address. The IETF approach is like google (all-or-nothing from the client's perspective), but provides only a single IPv4 or IPv6 address on a worldwide basis. This means that the addresses must be made highly-available at the network level with no client failover possibility, and if there is any worldwide service distribution it would need to be conducted by a network element that is reached via the IP address acting as a service distribution point. In contrast to the Google and IETF philosophies, Yahoo and Amazon both provide clients with a (short) list of IP addresses with Yahoo providing both IP protocol versions and Amazon as IPv4-only. The order of the list is randomized with each name service query response, with the effect of round-robin load balancing for service distribution. With a short list of addresses, there is still expectation that the network will implement high availability for each address but in case any single address fails the client can switch over to using a different address. The balance then becomes one of function in the network vs function in the end system. The same implications observed for common highly-available services in the Internet apply also to the AERO client/server architecture. When an AERO Client connects to one or more ANETs, it discovers one or more AERO Proxy/Server addresses through the mechanisms discussed in earlier sections. Each Proxy/Server address presumably leads to a fault-tolerant clustering arrangement such as supported by Linux-HA, Extended Virtual Synchrony or Paxos. Such an arrangement has precedence in common Internet service deployments in lightweight virtual machines without requiring expensive hardware deployment. Similarly, common Internet service deployments set service IP addresses on service distribution points that may relay requests to many different servers. For AERO, the expectation is that a combination of the Google/IETF and Yahoo/Amazon philosophies would be employed. The AERO Client connects to different ANET access points and can receive 1-2 Proxy/ Server ADM-LLAs at each point. It then selects one AERO Proxy/Server address, and engages in RS/RA exchanges with the same Proxy/Server from all ANET connections. The Client remains with this Proxy/Server unless or until the Proxy/Server fails, in which case it can switch over to an alternate Proxy/Server. The Client can likewise switch over to a different Proxy/Server at any time if there is some reason for it to do so. So, the AERO expectation is for a balance of Templin Expires September 24, 2021 [Page 87] Internet-Draft AERO March 2021 function in the network and end system, with fault tolerance and resilience at both levels. Appendix B. Change Log << RFC Editor - remove prior to publication >> Changes from draft-templin-intarea-6706bis-61 to draft-templin- intrea-6706bis-62: o New sub-section on OMNI Neighbor Interface Attributes Changes from draft-templin-intarea-6706bis-59 to draft-templin- intrea-6706bis-60: o Removed all references to S/TLLAO - all Interface Attributes are now maintained completely in the OMNI option. Changes from draft-templin-intarea-6706bis-58 to draft-templin- intrea-6706bis-59: o The term "Relay" used in older draft versions is now "Bridge". "Relay" now refers to what was formally called: "Gateway". o Fine-grained cleanup of Forwarding Algorithm; IPv6 ND message addressing; OMNI Prefix Lengths, etc. Changes from draft-templin-intarea-6706bis-54 to draft-templin- intrea-6706bis-55: o Updates on Segment Routing and S/TLLAO contents. o Various editorials and addressing cleanups. Changes from draft-templin-intarea-6706bis-52 to draft-templin- intrea-6706bis-53: o Normative reference to the OMNI spec, and remove portions that are already specified in OMNI. o Renamed "AERO interface/link" to "OMIN interface/link" throughout the document. o Truncated obsolete back section matter. Templin Expires September 24, 2021 [Page 88] Internet-Draft AERO March 2021 Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires September 24, 2021 [Page 89]