Asymmetric Extended Route Optimization (AERO)
draft-templin-intarea-6706bis-78

Templin                   Expires June 19, 2021                [Page 70]
Internet-Draft                    AERO                     December 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-06 (work in progress), June 2020.

   [I-D.templin-6man-dhcpv6-ndopt]
              Templin, F., "A Unified Stateful/Stateless Configuration
              Service for IPv6", draft-templin-6man-dhcpv6-ndopt-10
              (work in progress), June 2020.

   [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-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-26 (work in progress),
              June 2020.

   [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 June 19, 2021                [Page 71]
Internet-Draft                    AERO                     December 2020

   [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 June 19, 2021                [Page 72]
Internet-Draft                    AERO                     December 2020

   [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 June 19, 2021                [Page 73]
Internet-Draft                    AERO                     December 2020

   [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 June 19, 2021                [Page 74]
Internet-Draft                    AERO                     December 2020

   [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 June 19, 2021                [Page 75]
Internet-Draft                    AERO                     December 2020

   [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 an asymmetric 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 June 19, 2021                [Page 76]
Internet-Draft                    AERO                     December 2020

   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, 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 Servers can be standard dedicated server platforms, but most
   often will be deployed as virtual machines in the cloud.  The only
   requirements for 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, Servers must be provisioned, supported and managed
   by the INET administrative authority.  Cost for purchasing,
   configuring and managing Servers is nominal especially for virtual
   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 June 19, 2021                [Page 77]
Internet-Draft                    AERO                     December 2020

   connected to an INET.  As with 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 Server, and can route between the MNP and non-MNP address
   spaces.

A.5.  AERO Server Failure Implications

   AERO Servers may appear as a single point of failure in the
   architecture, but such is not the case since all Servers on the link
   provide identical services and loss of a Server does not imply
   immediate and/or comprehensive communication failures.  Although
   Clients typically associate with a single Server at a time, Server
   failure is quickly detected and conveyed by Bidirectional Forward
   Detection (BFD) and/or proactive NUD allowing Clients to migrate to
   new Servers.

   If a Server fails, ongoing packet forwarding to Clients will continue
   by virtue of the asymmetric 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 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 Server for an extended timeframe (e.g.,
   greater than ReachableTime seconds) then existing asymmetric 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 Server
   relationship, after which time continuous communications will resume.

   Therefore, providing many Servers on the link with high availability
   profiles provides resilience against loss of individual Servers and
   assurance that Clients can establish new Server relationships quickly
   in event of a Server failure.

Templin                   Expires June 19, 2021                [Page 78]
Internet-Draft                    AERO                     December 2020

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
   Servers and selects one 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 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 June 19, 2021                [Page 79]
Internet-Draft                    AERO                     December 2020

   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 Server addresses through the mechanisms discussed in
   earlier sections.  Each 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 Server
   LLAs at each point.  It then selects one AERO Server address, and
   engages in RS/RA exchanges with the same Server from all ANET
   connections.  The Client remains with this Server unless or until the
   Server fails, in which case it can switch over to an alternate
   Server.  The Client can likewise switch over to a different Server at
   any time if there is some reason for it to do so.  So, the AERO

Templin                   Expires June 19, 2021                [Page 80]
Internet-Draft                    AERO                     December 2020

   expectation is for a balance of 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 June 19, 2021                [Page 81]
Internet-Draft                    AERO                     December 2020

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

Templin                   Expires June 19, 2021                [Page 82]