idnits 2.17.1 draft-templin-6man-aero-55.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 June 2022) is 666 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3971' is defined on line 4579, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 4584, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 4588, but no explicit reference was found in the text == Unused Reference: 'RFC7739' is defined on line 4620, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 4641, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-crh-helper-opt' is defined on line 4657, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-frag-fragile' is defined on line 4664, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-dhcpv6-ndopt' is defined on line 4695, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-v6ops-pdhost' is defined on line 4729, but no explicit reference was found in the text == Unused Reference: 'OVPN' is defined on line 4743, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 4762, but no explicit reference was found in the text == Unused Reference: 'RFC2004' is defined on line 4766, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 4783, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 4787, but no explicit reference was found in the text == Unused Reference: 'RFC3330' is defined on line 4792, but no explicit reference was found in the text == Unused Reference: 'RFC4122' is defined on line 4801, but no explicit reference was found in the text == Unused Reference: 'RFC4982' is defined on line 4850, but no explicit reference was found in the text == Unused Reference: 'RFC6139' is defined on line 4892, but no explicit reference was found in the text == Unused Reference: 'RFC6273' is defined on line 4912, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 4921, but no explicit reference was found in the text == Unused Reference: 'RFC6438' is defined on line 4926, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 4935, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 4940, but no explicit reference was found in the text == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-63 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-28 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-29 == Outdated reference: A later version (-26) exists of draft-ietf-rtgwg-atn-bgp-18 -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 29 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. L. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational 28 June 2022 5 Expires: 30 December 2022 7 Automatic Extended Route Optimization (AERO) 8 draft-templin-6man-aero-55 10 Abstract 12 This document specifies an Automatic Extended Route Optimization 13 (AERO) service for IP internetworking over Overlay Multilink Network 14 (OMNI) interfaces. AERO/OMNI use an IPv6 unique-local address format 15 for IPv6 Neighbor Discovery (IPv6 ND) messaging over the OMNI virtual 16 link. Router discovery and neighbor coordination are employed for 17 network admission and to manage the OMNI link forwarding and routing 18 systems. Secure multilink operation, mobility management, multicast, 19 traffic path selection and route optimization are naturally supported 20 through dynamic neighbor cache updates. AERO is a widely-applicable 21 mobile internetworking service especially well-suited to aviation, 22 intelligent transportation systems, mobile end user devices and many 23 other applications. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 30 December 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Automatic Extended Route Optimization (AERO) . . . . . . . . 16 61 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 16 62 3.2. The AERO Service over OMNI Links . . . . . . . . . . . . 17 63 3.2.1. AERO/OMNI Reference Model . . . . . . . . . . . . . . 17 64 3.2.2. Addressing and Node Identification . . . . . . . . . 21 65 3.2.3. AERO Routing System . . . . . . . . . . . . . . . . . 22 66 3.2.4. Segment Routing Topologies (SRTs) . . . . . . . . . . 24 67 3.2.5. Segment Routing For OMNI Link Selection . . . . . . . 25 68 3.3. OMNI Interface Characteristics . . . . . . . . . . . . . 25 69 3.4. OMNI Interface Initialization . . . . . . . . . . . . . . 28 70 3.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 28 71 3.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 29 72 3.4.3. AERO Host Behavior . . . . . . . . . . . . . . . . . 29 73 3.4.4. AERO Gateway Behavior . . . . . . . . . . . . . . . . 30 74 3.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 30 75 3.5.1. OMNI ND Messages . . . . . . . . . . . . . . . . . . 32 76 3.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 34 77 3.5.3. OMNI Neighbor Window Synchronization . . . . . . . . 35 78 3.6. OMNI Interface Encapsulation and Fragmentation . . . . . 35 79 3.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 37 80 3.8. OMNI Interface Data Origin Authentication . . . . . . . . 38 81 3.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 39 82 3.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 39 83 3.10.1. Host Forwarding Algorithm . . . . . . . . . . . . . 41 84 3.10.2. Client Forwarding Algorithm . . . . . . . . . . . . 41 85 3.10.3. Proxy/Server and Relay Forwarding Algorithm . . . . 43 86 3.10.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 45 87 3.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 47 88 3.12. AERO Mobility Service Coordination . . . . . . . . . . . 50 89 3.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 50 90 3.12.2. AERO Host and Client Behavior . . . . . . . . . . . 51 91 3.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 52 92 3.13. AERO Address Resolution, Multilink Forwarding and Route 93 Optimization . . . . . . . . . . . . . . . . . . . . . . 59 94 3.13.1. Multilink Address Resolution . . . . . . . . . . . . 60 95 3.13.2. Multilink Forwarding . . . . . . . . . . . . . . . . 65 96 3.13.3. Client/Gateway Route Optimization . . . . . . . . . 79 97 3.13.4. Client/Client Route Optimization . . . . . . . . . . 81 98 3.13.5. Client-to-Client OMNI Link Extension . . . . . . . . 83 99 3.13.6. Intra-ANET/ENET Route Optimization for AERO Peers . 83 100 3.14. Neighbor Unreachability Detection (NUD) . . . . . . . . . 84 101 3.15. Mobility Management and Quality of Service (QoS) . . . . 85 102 3.15.1. Mobility Update Messaging . . . . . . . . . . . . . 86 103 3.15.2. Announcing Link-Layer Information Changes . . . . . 87 104 3.15.3. Bringing New Links Into Service . . . . . . . . . . 87 105 3.15.4. Deactivating Existing Links . . . . . . . . . . . . 88 106 3.15.5. Moving Between Proxy/Servers . . . . . . . . . . . . 88 107 3.16. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 89 108 3.16.1. Source-Specific Multicast (SSM) . . . . . . . . . . 90 109 3.16.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 91 110 3.16.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 92 111 3.17. Operation over Multiple OMNI Links . . . . . . . . . . . 92 112 3.18. DNS Considerations . . . . . . . . . . . . . . . . . . . 93 113 3.19. Transition/Coexistence Considerations . . . . . . . . . . 93 114 3.20. Proxy/Server-Gateway Bidirectional Forwarding 115 Detection . . . . . . . . . . . . . . . . . . . . . . . 94 116 3.21. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 94 117 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 94 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 119 6. Security Considerations . . . . . . . . . . . . . . . . . . . 95 120 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 122 8.1. Normative References . . . . . . . . . . . . . . . . . . 99 123 8.2. Informative References . . . . . . . . . . . . . . . . . 101 124 Appendix A. Non-Normative Considerations . . . . . . . . . . . . 108 125 A.1. Implementation Strategies for Route Optimization . . . . 109 126 A.2. Implicit Mobility Management . . . . . . . . . . . . . . 109 127 A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 110 128 A.4. AERO Critical Infrastructure Considerations . . . . . . . 110 129 A.5. AERO Server Failure Implications . . . . . . . . . . . . 111 130 A.6. AERO Client / Server Architecture . . . . . . . . . . . . 111 131 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 113 132 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 114 134 1. Introduction 136 Automatic Extended Route Optimization (AERO) fulfills the 137 requirements of Distributed Mobility Management (DMM) [RFC7333] and 138 route optimization [RFC5522] for aeronautical networking and other 139 network mobility use cases including intelligent transportation 140 systems and enterprise mobile device users. AERO is a secure 141 internetworking and mobility management service that employs the 142 Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] 143 Non-Broadcast, Multiple Access (NBMA) virtual link model. The OMNI 144 link is a virtual overlay manifested by IPv6 encapsulation and 145 configured over a network-of-networks concatenation of underlay 146 Internetworks. Nodes on the link can exchange original IP packets as 147 single-hop neighbors on the link - both IP protocol versions (IPv4 148 and IPv6) are supported. The OMNI Adaptation Layer (OAL) supports 149 multilink operation for increased reliability and path optimization 150 while providing fragmentation and reassembly services to support 151 improved performance and Maximum Transmission Unit (MTU) diversity. 152 This specification provides a mobility service architecture companion 153 to the OMNI specification. 155 The AERO service connects Hosts and Clients as OMNI link neighbors 156 via Proxy/Servers and Relays as intermediate nodes as necessary; AERO 157 further provides Gateways that interconnect diverse Internetworks as 158 OMNI link segments through OAL forwarding at a layer below IP. Each 159 node's OMNI interface uses an IPv6 unique-local address format that 160 supports operation of the IPv6 Neighbor Discovery (IPv6 ND) protocol 161 [RFC4861]. A Client's OMNI interface can be configured over multiple 162 underlay interfaces, and therefore appears as a single interface with 163 multiple link-layer addresses. Each link-layer address is subject to 164 change due to mobility and/or multilink fluctuations, and link-layer 165 address changes are signaled by ND messaging the same as for any IPv6 166 link. 168 AERO provides a secure cloud-based service where mobile node Clients 169 may use Proxy/Servers acting as proxys and/or designated routers 170 while fixed nodes may use any Relay on the link for efficient 171 communications. Fixed nodes forward original IP packets destined to 172 other AERO nodes via the nearest Relay, which forwards them through 173 the cloud. Mobile node Clients discover shortest paths to OMNI link 174 neighbors through AERO route optimization. Both unicast and 175 multicast communications are supported, and Clients may efficiently 176 move between locations while maintaining continuous communications 177 with correspondents using stable IP Addresses not subject to dynamic 178 fluctuations. 180 AERO Gateways peer with Proxy/Servers in a secured private BGP 181 overlay routing instance to establish a Segment Routing Topology 182 (SRT) spanning tree over the underlay Internetworks of one or more 183 disjoint administrative domains concatenated as a single unified OMNI 184 link. Each OMNI link instance is characterized by the set of 185 Mobility Service Prefixes (MSPs) common to all mobile nodes. Relays 186 provide an optimal route from (fixed) correspondent nodes on underlay 187 Internetworks to (mobile or fixed) nodes on the OMNI link. From the 188 perspective of underlay Internetworks, each Relay appears as the 189 source of a route to the MSP; hence uplink traffic to mobile nodes is 190 naturally routed to the nearest Relay. 192 AERO can be used with OMNI links that span private-use Internetworks 193 and/or public Internetworks such as the global Internet. In both 194 cases, Clients may be located behind Network Address Translators 195 (NATs) on the path to their associated Proxy/Servers. A means for 196 robust traversal of NATs while avoiding "triangle routing" and 197 critical infrastructure traffic concentration through a service known 198 as "route optimization" is therefore provided. 200 AERO assumes the use of PIM Sparse Mode in support of multicast 201 communication. In support of Source Specific Multicast (SSM) when a 202 Mobile Node is the source, AERO route optimization ensures that a 203 shortest-path multicast tree is established with provisions for 204 mobility and multilink operation. In all other multicast scenarios 205 there are no AERO dependencies. 207 AERO provides a secure aeronautical internetworking service for both 208 manned and unmanned aircraft, where the aircraft is treated as a 209 mobile node that can connect an Internet of Things (IoT). AERO is 210 also applicable to a wide variety of other use cases. For example, 211 it can be used to coordinate the links of mobile nodes (e.g., 212 cellphones, tablets, laptop computers, etc.) that connect into a home 213 enterprise network via public access networks with VPN or non-VPN 214 services enabled according to the appropriate security model. AERO 215 can also be used to facilitate terrestrial vehicular and urban air 216 mobility (as well as pedestrian communication services) for future 217 intelligent transportation systems 218 [I-D.ietf-ipwave-vehicular-networking][I-D.templin-ipwave-uam-its]. 219 Other applicable use cases are also in scope. 221 Along with OMNI, AERO provides secured optimal routing support for 222 the "6 M's" of modern Internetworking, including: 224 1. Multilink - a mobile node's ability to coordinate multiple 225 diverse underlay data links as a single logical unit (i.e., the 226 OMNI interface) to achieve the required communications 227 performance and reliability objectives. 229 2. Multinet - the ability to span the OMNI link over a segment 230 routing topology with multiple diverse administrative domain 231 network segments while maintaining seamless end-to-end 232 communications between mobile Clients and correspondents such as 233 air traffic controllers, fleet administrators, other mobile 234 Clients, etc. 236 3. Mobility - a mobile node's ability to change network points of 237 attachment (e.g., moving between wireless base stations) which 238 may result in an underlay interface address change, but without 239 disruptions to ongoing communication sessions with peers over the 240 OMNI link. 242 4. Multicast - the ability to send a single network transmission 243 that reaches multiple nodes belonging to the same interest group, 244 but without disturbing other nodes not subscribed to the interest 245 group. 247 5. Multihop - a mobile node vehicle-to-vehicle relaying capability 248 useful when multiple forwarding hops between vehicles may be 249 necessary to "reach back" to an infrastructure access point 250 connection to the OMNI link. 252 6. MTU assurance - the ability to deliver packets of various robust 253 sizes between peers without loss due to a link size restriction, 254 and to dynamically adjust packets sizes to achieve the optimal 255 performance for each independent traffic flow. 257 The following numbered sections present the AERO specification. The 258 appendices at the end of the document are non-normative. 260 2. Terminology 262 The terminology in the normative references applies; especially, the 263 terminology in the OMNI specification [I-D.templin-6man-omni] is used 264 extensively throughout. The following terms are defined within the 265 scope of this document: 267 IPv6 Neighbor Discovery (IPv6 ND) 268 a control message service for coordinating neighbor relationships 269 between nodes connected to a common link. AERO uses the IPv6 ND 270 messaging service specified in [RFC4861] in conjunction with the 271 OMNI extensions specified in [I-D.templin-6man-omni]. 273 IPv6 Prefix Delegation 274 a networking service for delegating IPv6 prefixes to nodes on the 275 link. The nominal service is DHCPv6 [RFC8415], however alternate 276 services (e.g., based on IPv6 ND messaging) are also in scope. A 277 minimal form of prefix delegation known as "prefix registration" 278 can be used if the Client knows its prefix in advance and can 279 represent it in the source address of an IPv6 ND message. 281 L2 282 The Data Link layer in the OSI network model. Also known as 283 "layer-2", "link-layer", "sub-IP layer", etc. 285 L3 286 The Network layer in the OSI network model. Also known as "layer- 287 3", "IP layer", etc. 289 Adaptation layer 290 A mid-layer that adapts L3 to a diverse collection of L2 underlay 291 interfaces and their encapsulations. (No layer number is 292 assigned, since numbering was an artifact of the legacy reference 293 model that need not carry forward in the modern architecture.) 294 The adaptation layer sees the upper layer as "L3" and sees all 295 lower layer encapsulations as "L2 encapsulations", which may 296 include UDP, IP and true link-layer (e.g., Ethernet, etc.) 297 headers. 299 Access Network (ANET) 300 a connected network region (e.g., an aviation radio access 301 network, satellite service provider network, cellular operator 302 network, WiFi network, etc.) that joins Clients to the Mobility 303 Service. Physical and/or data link level security is assumed, and 304 sometimes referred to as "protected spectrum". Private enterprise 305 networks and ground domain aviation service networks may provide 306 multiple secured IP hops between the Client's point of connection 307 and the nearest Proxy/Server. 309 Internetwork (INET) 310 a connected network region with a coherent IP addressing plan that 311 provides transit forwarding services between ANETs and AERO/OMNI 312 nodes that coordinate with the Mobility Service over unprotected 313 media. No physical and/or data link level security is assumed, 314 therefore security must be applied by upper layers. The global 315 public Internet itself is an example. 317 End-user Network (ENET) 318 a simple or complex "downstream" network that travels with the 319 Client as a single logical unit. The ENET could be as simple as a 320 single link connecting a single Host, or as complex as a large 321 network with many links, routers, bridges and Hosts. The ENET 322 could also provide an "upstream" link in a recursively-descending 323 chain of additional Clients and ENETs. In this way, an ENET of an 324 upstream Client is seen as the ANET of a downstream Client. 326 {A,I,E}NET interface 327 a node's attachment to a link in an {A,I,E}NET. 329 underlay network/interface 330 an ANET/INET/ENET network/interface over which an OMNI interface 331 is configured. The OMNI interface is seen as a network layer (L3) 332 interface by the IP layer, and the OMNI adaptation layer sees the 333 underlay interface as a data link layer (L2) interface. The 334 underlay interface either connects directly to the physical 335 communications media or coordinates with another node where the 336 physical media is hosted. 338 OMNI link 339 the same as defined in [I-D.templin-6man-omni]. The OMNI link 340 employs IPv6 encapsulation [RFC2473] to traverse intermediate 341 nodes in a spanning tree over underlay network segments the same 342 as a bridged campus LAN. AERO nodes on the OMNI link appear as 343 single-hop neighbors at the network layer even though they may be 344 separated by many underlay network hops; AERO nodes can employ 345 Segment Routing [RFC8402] to navigate between different OMNI 346 links, and/or to cause packets to visit selected waypoints within 347 the same OMNI link. 349 OMNI Adaptation Layer (OAL) 350 an OMNI interface sublayer service that encapsulates original IP 351 packets admitted into the interface in an IPv6 header and/or 352 subjects them to fragmentation and reassembly. The OAL is also 353 responsible for generating MTU-related control messages as 354 necessary, and for providing addressing context for spanning 355 multiple segments of an extended OMNI link. 357 OMNI Interface 358 a node's attachment to an OMNI link (i.e., the same as defined in 359 [I-D.templin-6man-omni]). Since OMNI interface addresses are 360 managed for uniqueness, OMNI interfaces do not require Duplicate 361 Address Detection (DAD) and therefore set the administrative 362 variable 'DupAddrDetectTransmits' to zero [RFC4862]. 364 (network) partition 365 frequently, underlay networks such as large corporate enterprise 366 networks are sub-divided internally into separate isolated 367 partitions (a technique also known as "network segmentation"). 368 Each partition is fully connected internally but disconnected from 369 other partitions, and there is no requirement that separate 370 partitions maintain consistent Internet Protocol and/or addressing 371 plans. (Each partition is seen as a separate OMNI link segment as 372 discussed throughout this document.) 374 L2 encapsulation 375 the OAL encapsulation of a packet in an outer header or headers 376 that can be routed within the scope of the local {A,I,E}NET 377 underlay network partition. Common L2 encapsulation combinations 378 include UDP/IP/Ethernet, etc. 380 L2 address (L2ADDR) 381 an address that appears in the OAL L2 encapsulation for an 382 underlay interface and also in IPv6 ND message OMNI options. 383 L2ADDR can be either an IP address for IP encapsulations or an 384 IEEE EUI address [EUI] for direct data link encapsulation. (When 385 UDP/IP encapsulation is used, the UDP port number is considered an 386 ancillary extension of the IP L2ADDR.) 388 original IP packet 389 a whole IP packet or fragment admitted into the OMNI interface by 390 the network layer prior to OAL encapsulation and fragmentation, or 391 an IP packet delivered to the network layer by the OMNI interface 392 following OAL decapsulation and reassembly. 394 OAL packet 395 an original IP packet encapsulated in an OAL IPv6 header before 396 OAL fragmentation, or following OAL reassembly. 398 OAL fragment 399 a portion of an OAL packet following fragmentation but prior to L2 400 encapsulation, or following L2 decapsulation but prior to OAL 401 reassembly. 403 (OAL) atomic fragment 404 an OAL packet that can be forwarded without fragmentation, but 405 still includes a Fragment Header with a valid Identification value 406 and with Fragment Offset and More Fragments both set to 0. 408 (OAL) carrier packet 409 an encapsulated OAL fragment following L2 encapsulation or prior 410 to L2 decapsulation. OAL sources and destinations exchange 411 carrier packets over underlay interfaces, and may be separated by 412 one or more OAL intermediate nodes. OAL intermediate nodes re- 413 encapsulate carrier packets during forwarding by removing the L2 414 headers of the previous hop underlay network and replacing them 415 with new L2 headers for the next hop underlay network. 417 OAL source 418 an OMNI interface acts as an OAL source when it encapsulates 419 original IP packets to form OAL packets, then performs OAL 420 fragmentation and L2 encapsulation to create carrier packets. 422 OAL destination 423 an OMNI interface acts as an OAL destination when it decapsulates 424 carrier packets, then performs OAL reassembly and decapsulation to 425 derive the original IP packet. 427 OAL intermediate node 428 an OMNI interface acts as an OAL intermediate node when it removes 429 the L2 headers of carrier packets received from a previous hop, 430 then re-encapsulates the carrier packets in new L2 headers and 431 forwards them to the next hop. OAL intermediate nodes decrement 432 the OAL Hop Limit during forwarding, and discard the packet if the 433 Hop Limit reaches 0. OAL intermediate nodes do not decrement the 434 TTL/Hop Limit of the original IP packet. 436 Mobility Service Prefix (MSP) 437 an aggregated IP Global Unicast Address (GUA) prefix (e.g., 438 2001:db8::/32, 192.0.2.0/24, etc.) assigned to the OMNI link and 439 from which more-specific Mobile Network Prefixes (MNPs) are 440 delegated. OMNI link administrators typically obtain MSPs from an 441 Internet address registry, however private-use prefixes can 442 alternatively be used subject to certain limitations (see: 443 [I-D.templin-6man-omni]). OMNI links that connect to the global 444 Internet advertise their MSPs to their interdomain routing peers. 446 Mobile Network Prefix (MNP) 447 a longer IP prefix delegated from an MSP (e.g., 448 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and delegated to an 449 AERO Client or Relay. 451 Interface Identifier (IID) 452 the least significant 64 bits of an IPv6 address, as specified in 453 the IPv6 addressing architecture [RFC4291]. 455 Link Local Address (LLA) 456 an IPv6 address beginning with fe80::/64 per the IPv6 addressing 457 architecture [RFC4291] and with either a 64-bit MNP (LLA-MNP) or a 458 56-bit random value (LLA-RND) encoded in the IID as specified in 459 [I-D.templin-6man-omni]. 461 Unique Local Address (ULA) 462 an IPv6 address beginning with fd00::/8 followed by a 40-bit 463 Global ID followed by a 16-bit Subnet ID per [RFC4193] and with 464 either a 64-bit MNP (ULA-MNP) or a 56-bit random value (ULA-RND) 465 encoded in the IID as specified in [I-D.templin-6man-omni]. (Note 466 that [RFC4193] specifies a second form of ULAs based on the prefix 467 fc00::/8, which are referred to as "ULA-C" throughout this 468 document to distinguish them from the ULAs defined here.) 470 Temporary Local Address (TLA) 471 a ULA beginning with fd00::/16 followed by a 48-bit randomly- 472 initialized value followed by an MNP-based (TLA-MNP) or random 473 (TLA-RND) IID as specified in [I-D.templin-6man-omni]. Clients 474 use TLAs to bootstrap autoconfiguration in the presence of OMNI 475 link infrastructure or for sustained communications in the absence 476 of infrastructure. (Note that in some environments Clients can 477 instead use a (Hierarchical) Host Identity Tag ((H)HIT) instead of 478 a TLA - see: [I-D.templin-6man-omni].) 480 eXtended Local Address (XLA) 481 a ULA beginning with fd00::/64 followed by an MNP-based (XLA-MNP) 482 or random (XLA-RND) IID as specified in [I-D.templin-6man-omni]. 483 An XLA can be used to supply a stable address for IPv6 ND 484 messaging, a routing table entry for the OMNI link routing system, 485 etc. (Note that XLAs can also be statelessly formed from LLAs 486 (and vice-versa) simply by inverting prefix bits 7 and 8.) 488 AERO node 489 a node that is connected to an OMNI link and participates in the 490 AERO internetworking and mobility service. 492 AERO Host ("Host") 493 an AERO node that configures an OMNI interface over an ENET 494 underlying interface serviced by an upstream Client. The Host 495 does not assign an LLA or ULA to the OMNI interface, but instead 496 assigns the address taken from the ENET underlying interface. (As 497 an implementation matter, the Host may instead configure the "OMNI 498 interface" as a virtual sublayer of the underlay interface 499 itself.) When an AERO host forwards an original IP packet to 500 another AERO node on the same ENET, it uses simple IP-in-IP 501 encapsulation without including an OAL encapsulation header. The 502 Host is therefore an OMNI link termination endpoint. 504 AERO Client ("Client") 505 an AERO node that configures an OMNI interface over one or more 506 underlay interfaces and requests MNP delegation/registration 507 service from AERO Proxy/Servers. The Client assigns an XLA-MNP 508 (as well as Proxy/Server-specific ULA-MNPs) to the OMNI interface 509 for use in IPv6 ND exchanges with other AERO nodes and forwards 510 original IP packets to correspondents according to OMNI interface 511 neighbor cache state. The Client coordinates with Proxy/Servers 512 and/or other Clients over upstream ANET/INET interfaces and may 513 also provide Proxy/Server services for Hosts and/or other Clients 514 over downstream ENET interfaces. 516 AERO Proxy/Server ("Proxy/Server") 517 a node that provides a proxying service between AERO Clients and 518 external peers on its Client-facing ANET interfaces (i.e., in the 519 same fashion as for an enterprise network proxy) as well as 520 designated router services for coordination with correspondents on 521 its INET-facing interfaces. (Proxy/Servers in the open INET 522 instead configure only a single INET interface and no ANET 523 interfaces.) The Proxy/Server configures an OMNI interface and 524 assigns a ULA-RND to support the operation of IPv6 ND services, 525 while advertising any associated MNPs for which it is acting as a 526 hub via BGP peerings with AERO Gateways. 528 AERO Relay ("Relay") 529 a Proxy/Server that provides forwarding services between nodes 530 reached via the OMNI link and correspondents on other links/ 531 networks. AERO Relays assign a ULA-RND to an OMNI interface and 532 maintain BGP peerings with Gateways the same as Proxy/Servers. 533 Relays also run a dynamic routing protocol to discover any non-MNP 534 IP GUA routes in service on other links/networks, advertise OMNI 535 link MSP(s) to other links/networks, and redistribute routes 536 discovered on other links/networks into the OMNI link BGP routing 537 system. (Relays that connect to major Internetworks such as the 538 global IPv6 or IPv4 Internet can also be configured to advertise 539 "default" routes into the OMNI link BGP routing system.) 541 AERO Gateway ("Gateway") 542 a BGP hub autonomous system node that also provides OAL forwarding 543 services for nodes on an OMNI link. Gateways forward carrier 544 packets between OMNI link segments as OAL intermediate nodes while 545 decrementing the OAL IPv6 header Hop Limit but without 546 decrementing the network layer IP TTL/Hop Limit. Gateways peer 547 with Proxy/Servers and other Gateways to form an IPv6-based OAL 548 spanning tree over all OMNI link segments and to discover the set 549 of all MNP and non-MNP prefixes in service. Gateways process 550 carrier packets received over the secured spanning tree that are 551 addressed to themselves, while forwarding all other carrier 552 packets to the next hop also via the secured spanning tree. 553 Gateways forward carrier packets received over the unsecured 554 spanning tree to the next hop either via the unsecured spanning 555 tree or via direct encapsulation if the next hop is on the same 556 OMNI link segment. 558 First-Hop Segment (FHS) Client 559 a Client that initiates communications with a target peer by 560 sending an NS message to establish reverse-path multilink 561 forwarding state in OMNI link intermediate nodes on the path to 562 the target. Note that in some arrangements the Client's (FHS) 563 Proxy/Server (and not the Client itself) initiates the NS. 565 Last-Hop Segment (LHS) Client 566 a Client that responds to a communications request from a source 567 peer's NS by returning an NA response to establish forward-path 568 multilink forwarding state in OMNI link intermediate nodes on the 569 path to the source. Note that in some arrangements the Client's 570 (LHS) Proxy/Server (and not the Client itself) returns the NA. 572 First-Hop Segment (FHS) Proxy/Server 573 a Proxy/Server for an FHS Client's underlay interface that 574 forwards the Client's packets into the segment routing topology. 575 FHS Proxy/Servers also act as intermediate forwarding nodes to 576 facilitate RS/RA exchanges between a Client and its Hub Proxy/ 577 Server. 579 Last-Hop Segment (LHS) Proxy/Server 580 a Proxy/Server for an underlay interface of an LHS Client that 581 forwards packets received from the segment routing topology to the 582 Client over that interface. 584 Hub Proxy/Server 585 a single Proxy/Server selected by a Client that injects the 586 Client's XLA-MNP into the BGP routing system and provides a 587 designated router service for all of the Client's underlay 588 interfaces. Clients often select the first FHS Proxy/Server they 589 coordinate with to serve in the Hub role (as all FHS Proxy/Servers 590 are equally capable candidates to serve as a Hub), however the 591 Client can also select any available Proxy/Server for the OMNI 592 link (as there is no requirement that the Hub must also be one of 593 the Client's FHS Proxy/Servers). 595 Segment Routing Topology (SRT) 596 a Multinet OMNI link forwarding region between FHS and LHS Proxy/ 597 Servers. FHS/LHS Proxy/Servers and SRT Gateways span the OMNI 598 link on behalf of FHS/LHS Client pairs. The SRT maintains a 599 spanning tree established through BGP peerings between Gateways 600 and Proxy/Servers. Each SRT segment includes Gateways in a "hub" 601 and Proxy/Servers in "spokes", while adjacent segments are 602 interconnected by Gateway-Gateway peerings. The BGP peerings are 603 configured over both secured and unsecured underlay network paths 604 such that a secured spanning tree is available for critical 605 control messages while other messages can use the unsecured 606 spanning tree. 608 Mobile Node (MN) 609 an AERO Client and all of its downstream-attached networks that 610 move together as a single unit, i.e., an end system that connects 611 an Internet of Things. 613 Mobile Router (MR) 614 a MN's on-board router that forwards original IP packets between 615 any downstream-attached networks and the OMNI link. The MR is the 616 MN entity that hosts the AERO Client. 618 Address Resolution Source (ARS) 619 the node nearest the original source that initiates OMNI link 620 address resolution. The ARS may be a Proxy/Server or Relay for 621 the source, or may be the source Client itself. The ARS is often 622 (but not always) also the same node that becomes the FHS source 623 during route optimization. 625 Address Resolution Target (ART) 626 the node toward which address resolution is directed. The ART may 627 be a Relay or the target Client itself. The ART is often (but not 628 always) also the same node that becomes the LHS target during 629 route optimization. 631 Address Resolution Responder (ARR) 632 the node that responds to address resolution requests on behalf of 633 the ART. The ARR may be a Relay, the ART itself, or the ART's 634 current Hub Proxy/Server. Note that a Hub Proxy/Server can assume 635 the ARR role even if it is located on a different SRT segment than 636 the ART. The Hub Proxy/Server assumes the ARR role only when it 637 receives an RS message from the ART that has the Neighbor 638 Coordination sub-option 'A' flag set (see: 639 [I-D.templin-6man-omni]). 641 Potential Router List (PRL) 642 a geographically and/or topologically referenced list of addresses 643 of all Proxy/Servers within the same OMNI link. Each OMNI link 644 has its own PRL. 646 Distributed Mobility Management (DMM) 647 a BGP-based overlay routing service coordinated by Proxy/Servers 648 and Gateways that tracks all Proxy/Server-to-Client associations. 650 Mobility Service (MS) 651 the collective set of all Proxy/Servers, Gateways and Relays that 652 provide the AERO Service to Clients. 654 AERO Forwarding Information Base (AFIB) 655 A forwarding table on each OAL source, destination and 656 intermediate node that includes AERO Forwarding Vectors (AFV) with 657 both multilink forwarding instructions and context for 658 reconstructing compressed headers for specific communicating peer 659 underlay interface pairs. The AFIB also supports route 660 optimization where one or more OAL intermediate nodes in the path 661 can be "skipped" to reduce path stretch and decrease load on 662 critical infrastructure elements. 664 AERO Forwarding Vector (AFV) 665 An AFIB entry that includes soft state for each underlay interface 666 pairwise communication session between peer OAL nodes. AFVs are 667 identified by both a forward and reverse path AFV Index (AFVI). 668 OAL nodes establish reverse path AFVIs when they forward an IPv6 669 ND unicast Neighbor Solicitation (NS) message and establish 670 forward path AFVIs when they forward the solicited IPv6 ND unicast 671 Neighbor Advertisement (NA) response. 673 AERO Forwarding Vector Index (AFVI) 674 A locally-unique 4 octet value automatically generated by an OAL 675 node when it creates an AFV. OAL intermediate nodes assign two 676 distinct AFVIs (called "A" and "B") to each AFV, with "A" 677 representing the forward path and "B" representing the reverse 678 path. Meanwhile, the OAL source assigns a single "B" AFVI, and 679 the OAL destination assigns a single "A" AFVI. Each OAL node 680 advertises its "A" AFVI to previous hop nodes on the reverse path 681 toward the source and advertises its "B" AFVI to next hop nodes on 682 the forward path toward the destination. 684 AERO Forwarding Parameters (AFP) 685 An OMNI option sub-option that appears in IPv6 ND NS/NA messages 686 and includes all parameters necessary for establishing AFV state 687 in OAL nodes in the path (see: [I-D.templin-6man-omni]). 689 Throughout the document, the simple terms "Host", "Client", "Proxy/ 690 Server", "Gateway" and "Relay" refer to "AERO/OMNI Host", "AERO/OMNI 691 Client", "AERO/OMNI Proxy/Server", "AERO/OMNI Gateway" and "AERO/OMNI 692 Relay", respectively. Capitalization is used to distinguish these 693 terms from other common Internetworking uses in which they appear 694 without capitalization, and implies that the node in question both 695 configures an OMNI interface and engages the OMNI Adaptation Layer. 697 The terminology of IPv6 ND [RFC4861], DHCPv6 [RFC8415] and OMNI 698 [I-D.templin-6man-omni] (including the names of node variables, 699 messages and protocol constants) is used throughout this document. 700 The terms "All-Routers multicast", "All-Nodes multicast", "Solicited- 701 Node multicast" and "Subnet-Router anycast" are defined in [RFC4291]. 702 Also, the term "IP" is used to generically refer to either Internet 703 Protocol version, i.e., IPv4 [RFC0791] or IPv6 [RFC8200]. 705 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 706 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 707 "OPTIONAL" in this document are to be interpreted as described in BCP 708 14 [RFC2119][RFC8174] when, and only when, they appear in all 709 capitals, as shown here. 711 3. Automatic Extended Route Optimization (AERO) 713 The following sections specify the operation of IP over OMNI links 714 using the AERO service: 716 3.1. AERO Node Types 718 AERO Hosts configure an OMNI interface over an underlay interface 719 connected to a Client's ENET and coordinate with both other AERO 720 Hosts and Clients over the ENET. As an implementation matter, the 721 Host either assigns the same (MNP-based) IP address from the underlay 722 interface to the OMNI interface, or configures the "OMNI interface" 723 as a virtual sublayer of the underlay interface itself. AERO Hosts 724 treat the ENET as an ANET, and treat the upstream Client for the ENET 725 as a Proxy/Server. AERO Hosts are seen as OMNI link termination 726 endpoints. 728 AERO Clients can be deployed as fixed infrastructure nodes close to 729 end systems, or as Mobile Nodes (MNs) that can change their network 730 attachment points dynamically. AERO Clients configure OMNI 731 interfaces over underlay interfaces with addresses that may change 732 due to mobility. AERO Clients register their Mobile Network Prefixes 733 (MNPs) with the AERO service, and distribute the MNPs to ENETs (which 734 may connect AERO Hosts and other Clients). AERO Clients provide 735 Proxy/Server-like services for Hosts and other Clients on downstream- 736 attached ENETs. 738 AERO Gateways, Proxy/Servers and Relays are critical infrastructure 739 elements in fixed (i.e., non-mobile) INET deployments and hence have 740 permanent and unchanging INET addresses. Together, they constitute 741 the AERO service which provides an OMNI link virtual overlay for 742 connecting AERO Clients and Hosts. AERO Gateways (together with 743 Proxy/Servers) provide the secured backbone supporting infrastructure 744 for a Segment Routing Topology (SRT) spanning tree for the OMNI link. 746 AERO Gateways forward carrier packets both within the same SRT 747 segment and between disjoint SRT segments based on an IPv6 748 encapsulation mid-layer known as the OMNI Adaptation Layer (OAL) 749 [I-D.templin-6man-omni]. The OMNI interface and OAL provide an 750 adaptation layer forwarding service that upper layers perceive as L2 751 bridging, since the inner IP TTL/Hop Limit is not decremented. Each 752 Gateway also peers with Proxy/Servers and other Gateways in a dynamic 753 routing protocol instance to provide a Distributed Mobility 754 Management (DMM) service for the list of active MNPs (see 755 Section 3.2.3). Gateways assign one or more Mobility Service 756 Prefixes (MSPs) to the OMNI link and configure secured tunnels with 757 Proxy/Servers, Relays and other Gateways; they further maintain 758 forwarding table entries for each MNP or non-MNP prefix in service on 759 the OMNI link. 761 AERO Proxy/Servers distributed across one or more SRT segments 762 provide default forwarding and mobility/multilink services for AERO 763 Client mobile nodes. Each Proxy/Server also peers with Gateways in a 764 dynamic routing protocol instance to advertise its list of associated 765 MNPs (see Section 3.2.3). Hub Proxy/Servers provide prefix 766 delegation/registration services and track the mobility/multilink 767 profiles of each of their associated Clients, where each delegated 768 prefix becomes an MNP taken from an MSP. Proxy/Servers at ANET/INET 769 boundaries provide a forwarding service for ANET Clients and Hosts to 770 communicate with peers in external INETs, while Proxy/Servers in the 771 open INET provide an authentication service for INET Client IPv6 ND 772 messages but only a secondary forwarding service when the Client 773 cannot forward directly to a peer or Gateway. Source Clients 774 securely coordinate with target Clients by sending control messages 775 via a First-Hop Segment (FHS) Proxy/Server which forwards them over 776 the SRT spanning tree to a Last-Hop Segment (LHS) Proxy/Server which 777 finally forwards them to the target. 779 AERO Relays are Proxy/Servers that provide forwarding services to 780 exchange original IP packets between the OMNI link and nodes on other 781 links/networks. Relays run a dynamic routing protocol to discover 782 any non-MNP prefixes in service on other links/networks, and Relays 783 that connect to larger Internetworks (such as the Internet) may 784 originate default routes. The Relay redistributes OMNI link MSP(s) 785 into other links/networks, and redistributes non-MNP prefixes via 786 OMNI link Gateway BGP peerings. 788 3.2. The AERO Service over OMNI Links 790 3.2.1. AERO/OMNI Reference Model 792 Figure 1 presents the basic OMNI link reference model: 794 +-----------------+ 795 | AERO Gateway G1 | 796 | Nbr: S1, S2, P1 | 797 |(X1->S1; X2->S2) | 798 | MSP M1 | 799 +--------+--------+ 800 +--------------+ | +--------------+ 801 | AERO P/S S1 | | | AERO P/S S2 | 802 | Nbr: C1, G1 | | | Nbr: C2, G1 | 803 | default->G1 | | | default->G1 | 804 | X1->C1 | | | X2->C2 | 805 +-------+------+ | +------+-------+ 806 | OMNI link | | 807 X===+===+==================+===================+===+===X 808 | | 809 +-----+--------+ +--------+-----+ 810 |AERO Client C1| |AERO Client C2| 811 | Nbr: S1 | | Nbr: S2 | 812 | default->S1 | | default->S2 | 813 | MNP X1 | | MNP X2 | 814 +------+-------+ +-----+--------+ 815 | | 816 .-. .-. 817 ,-( _)-. +-------+ +-------+ ,-( _)-. 818 .-(_ IP )-. | AERO | | AERO | .-(_ IP )-. 819 (__ ENET )--|Host H1| |Host H2|--(__ ENET ) 820 `-(______)-' +-------+ +-------+ `-(______)-' 822 Figure 1: AERO/OMNI Reference Model 824 In this model: 826 * the OMNI link is an overlay network service configured over one or 827 more underlay SRT segments which may be managed by different 828 administrative authorities and have incompatible protocols and/or 829 addressing plans. 831 * AERO Gateway G1 aggregates Mobility Service Prefix (MSP) M1, 832 discovers Mobile Network Prefixes (MNPs) X* and advertises the MSP 833 via BGP peerings over secured tunnels to Proxy/Servers (S1, S2). 834 Gateways provide the backbone for an SRT spanning tree for the 835 OMNI link. 837 * AERO Proxy/Servers S1 and S2 configure secured tunnels with 838 Gateway G1 and also provide mobility, multilink, multicast and 839 default router services for the MNPs of their associated Clients 840 C1 and C2. (Proxy/Servers that act as Relays can also advertise 841 non-MNP routes for non-mobile correspondent nodes the same as for 842 MNP Clients.) 844 * AERO Clients C1 and C2 associate with Proxy/Servers S1 and S2, 845 respectively. They receive MNP delegations X1 and X2, and also 846 act as default routers for their associated physical or internal 847 virtual ENETs. 849 * AERO Hosts H1 and H2 attach to the ENETs served by Clients C1 and 850 C2, respectively. 852 An OMNI link configured over a single underlay network appears as a 853 single unified link with a consistent addressing plan; all nodes on 854 the link can exchange carrier packets via simple L2 encapsulation 855 (i.e., following any necessary NAT traversal) since the underlay is 856 connected. In common practice, however, OMNI links are often 857 configured over an SRT spanning tree that bridges multiple distinct 858 underlay network segments managed under different administrative 859 authorities (e.g., as for worldwide aviation service providers such 860 as ARINC, SITA, Inmarsat, etc.). Individual underlay networks may 861 also be partitioned internally, in which case each internal partition 862 appears as a separate segment. 864 The addressing plan of each SRT segment is consistent internally but 865 will often bear no relation to the addressing plans of other 866 segments. Each segment is also likely to be separated from others by 867 network security devices (e.g., firewalls, proxys, packet filtering 868 gateways, etc.), and disjoint segments often have no common physical 869 link connections. Therefore, nodes can only be assured of exchanging 870 carrier packets directly with correspondents in the same segment, and 871 not with those in other segments. The only means for joining the 872 segments therefore is through inter-domain peerings between AERO 873 Gateways. 875 The OMNI link spans multiple SRT segments using the OMNI Adaptation 876 Layer (OAL) [I-D.templin-6man-omni] to provide the network layer with 877 a virtual abstraction similar to a bridged campus LAN. The OAL is an 878 OMNI interface sublayer that inserts a mid-layer IPv6 encapsulation 879 header for inter-segment forwarding (i.e., bridging) without 880 decrementing the network-layer TTL/Hop Limit of the original IP 881 packet. An example OMNI link SRT is shown in Figure 2: 883 . . . . . . . . . . . . . . . . . . . . . . . 884 . . 885 . .-(::::::::) . 886 . .-(::::::::::::)-. +-+ . 887 . (:::: Segment A :::)--|G|---+ . 888 . `-(::::::::::::)-' +-+ | . 889 . `-(::::::)-' | . 890 . | . 891 . .-(::::::::) | . 892 . .-(::::::::::::)-. +-+ | . 893 . (:::: Segment B :::)--|G|---+ . 894 . `-(::::::::::::)-' +-+ | . 895 . `-(::::::)-' | . 896 . | . 897 . .-(::::::::) | . 898 . .-(::::::::::::)-. +-+ | . 899 . (:::: Segment C :::)--|G|---+ . 900 . `-(::::::::::::)-' +-+ | . 901 . `-(::::::)-' | . 902 . | . 903 . ..(etc).. x . 904 . . 905 . . 906 . <- Segment Routing Topology (SRT) -> . 907 . (Spanned by OMNI Link) . 908 . . . . . . . . . . . . . .. . . . . . . . . 910 Figure 2: OMNI Link Segment Routing Topology (SRT) 912 Gateway, Proxy/Server and Relay OMNI interfaces are configured over 913 both secured tunnels and open INET underlay interfaces within their 914 respective SRT segments. Within each segment, Gateways configure 915 "hub-and-spokes" BGP peerings with Proxy/Servers and Relays as 916 "spokes". Adjacent SRT segments are joined by Gateway-to-Gateway 917 peerings to collectively form a spanning tree over the entire SRT. 918 The "secured" spanning tree supports authentication and integrity for 919 critical control plane messages. The "unsecured" spanning tree 920 conveys ordinary carrier packets without security codes and that must 921 be treated by destinations according to data origin authentication 922 procedures. AERO nodes can employ route optimization to cause 923 carrier packets to take more direct paths between OMNI link neighbors 924 without having to follow strict spanning tree paths. 926 The AERO Multinet service concatenates SRT segments to form larger 927 networks through Gateway-to-Gateway peerings as originally suggested 928 in the "Catenet Model for Internetworking" [IEN48]; especially 929 Figure 2 follows directly from the illustrations in [IEN48-2]. The 930 original Catenet vision proposed a "network-of-networks" 931 concatenation of independent and diverse Internetwork "segments" to 932 form a much larger network supporting end-to-end services. 934 The original Catenet vision first articulated in the 1970's was 935 distorted through the evolution of the Internet in later decades, 936 since a critical element was missing from the architecture. As a 937 result, the Internet evolved as a single, large public routing and 938 addressing domain interconnecting private domains (i.e., instead of a 939 true network-of-networks) which has impeded flexibility and inhibited 940 end-to-end services. With the advent of the adaptation layer 941 established by the AERO/OMNI services, however, the original Catenet 942 "network-of-networks" vision is now made possible. 944 3.2.2. Addressing and Node Identification 946 AERO nodes on OMNI links use the Link-Local Address (LLA) prefix 947 fe80::/64 [RFC4291] to assign LLAs to the OMNI interface in a latent 948 state and do not employ LLAs for any operational purposes (instead, 949 nodes assign LLAs solely to satisfy the requirements of [RFC4861]). 950 AERO Clients configure LLAs constructed from MNPs (i.e., "LLA-MNPs") 951 while AERO infrastructure nodes construct LLAs based on 56-bit random 952 values ("LLA-RNDs") per [I-D.templin-6man-omni]. Non-MNP routes are 953 also represented the same as for MNPs, but may include a prefix that 954 is not properly covered by an MSP. 956 AERO nodes also use the Unique Local Address (ULA) prefix fd00::/8 957 followed by a pseudo-random 40-bit Global ID to form the prefix 958 {ULA}::/48, then include a 16-bit Subnet ID '*' to form the prefix 959 {ULA*}::/64 [RFC4291]. The AERO node then uses the prefix 960 {ULA*}::/64 to form "ULA-MNPs" or "ULA-RNDs" as specified in 961 [I-D.templin-6man-omni] to support OAL addressing. (The prefix 962 {ULA*}::/64 appearing alone and with no suffix represents "default" 963 for that prefix.) 964 AERO Clients also use Temporary Local Addresses (TLAs) and eXtended 965 Local Addresses (XLAs) constructed per [I-D.templin-6man-omni], where 966 TLAs are distinguished from ordinary ULAs based on the prefix 967 fd00::/16 and XLAs are distinguished from ULAs/TLAs based on the 968 prefix fd00::/64. Clients use TLA-RNDs only in initial control 969 message exchanges until a stable MNP is assigned, but may sometimes 970 also use them for sustained communications within a local routing 971 region. AERO nodes use XLA-MNPs to provide forwarding information 972 for the global routing table as well as IPv6 ND message addressing 973 information. 975 AERO MSPs, MNPs and non-MNP routes are typically based on Global 976 Unicast Addresses (GUAs), but in some cases may be based on IPv4 977 private addresses [RFC1918] or IPv6 ULA-C's [RFC4193]. A GUA block 978 is also reserved for OMNI link anycast purposes. See 979 [I-D.templin-6man-omni] for a full specification of LLAs, ULAs, TLAs, 980 XLAs, GUAs and anycast addresses used by AERO nodes on OMNI links. 982 Finally, AERO Clients and Proxy/Servers configure node identification 983 values as specified in [I-D.templin-6man-omni]. 985 3.2.3. AERO Routing System 987 The AERO routing system comprises a private Border Gateway Protocol 988 (BGP) [RFC4271] service coordinated between Gateways and Proxy/ 989 Servers (Relays also engage in the routing system as simplified 990 Proxy/Servers). The service supports carrier packet forwarding at a 991 layer below IP and does not interact with the public Internet BGP 992 routing system, but supports redistribution of information for other 993 links and networks connected by Relays. 995 In a reference deployment, each Proxy/Server is configured as an 996 Autonomous System Border Router (ASBR) for a stub Autonomous System 997 (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within 998 the BGP instance, and each Proxy/Server further uses eBGP to peer 999 with one or more Gateways but does not peer with other Proxy/Servers. 1000 Each SRT segment in the OMNI link must include one or more Gateways 1001 in a "hub" AS, which peer with the Proxy/Servers within that segment 1002 as "spoke" ASes. All Gateways within the same segment are members of 1003 the same hub AS, and use iBGP to maintain a consistent view of all 1004 active routes currently in service. The Gateways of different 1005 segments peer with one another using eBGP. 1007 Gateways maintain forwarding table entries only for ULA prefixes for 1008 infrastructure elements and XLA-MNPs corresponding to MNP and non-MNP 1009 routes that are currently active; Gateways also maintain black-hole 1010 routes for the OMNI link MSPs so that carrier packets destined to 1011 non-existent more-specific routes are dropped with a Destination 1012 Unreachable message returned. In this way, Proxy/Servers and Relays 1013 have only partial topology knowledge (i.e., they only maintain 1014 routing information for their directly associated Clients and non- 1015 AERO links) and they forward all other carrier packets to Gateways 1016 which have full topology knowledge. 1018 Each OMNI link segment assigns a unique sub-prefix of {ULA}::/48 1019 known as the "SRT prefix". For example, a first segment could assign 1020 {ULA}:1000::/56, a second could assign {ULA}:2000::/56, a third could 1021 assign {ULA}:3000::/56, etc. Within each segment, each Proxy/Server 1022 configures a ULA-RND within the segment's SRT prefix with a 56-bit 1023 random value in the interface identifier as specified in 1024 [I-D.templin-6man-omni]. 1026 The administrative authorities for each segment must therefore 1027 coordinate to assure mutually-exclusive ULA prefix assignments, but 1028 internal provisioning of ULAs is an independent local consideration 1029 for each administrative authority. For each ULA prefix, the 1030 Gateway(s) that connect that segment assign the all-zero's address of 1031 the prefix as a Subnet Router Anycast address. For example, the 1032 Subnet Router Anycast address for {ULA}:1023::/64 is simply 1033 {ULA}:1023::/64. 1035 ULA prefixes are statically represented in Gateway forwarding tables. 1036 Gateways join multiple SRT segments into a unified OMNI link over 1037 multiple diverse network administrative domains. They support a 1038 virtual bridging service by first establishing forwarding table 1039 entries for their ULA prefixes either via standard BGP routing or 1040 static routes. For example, if three Gateways ('A', 'B' and 'C') 1041 from different segments serviced {ULA}:1000::/60, {ULA}:2000::/56 and 1042 {ULA}:3000::/56 respectively, then the forwarding tables in each 1043 Gateway appear as follows: 1045 A: {ULA}:1000::/56->local, {ULA}:2000::/56->B, {ULA}:3000::/56->C 1047 B: {ULA}:1000::/56->A, {ULA}:2000::/56->local, {ULA}:3000::/56->C 1049 C: {ULA}:1000::/56->A, {ULA}:2000::/56->B, {ULA}:3000::/56->local 1051 These forwarding table entries rarely change, since they correspond 1052 to fixed infrastructure elements in their respective segments. 1054 MNP (and non-MNP) routes are instead dynamically advertised in the 1055 AERO routing system by Proxy/Servers and Relays that provide service 1056 for their corresponding MNPs. The routes are advertised as XLA-MNP 1057 prefixes, i.e., as fd00::{MNP} (see: [I-D.templin-6man-omni]). For 1058 example, if three Proxy/Servers ('D', 'E' and 'F') service the MNPs 1059 2001:db8:1000:2000::/56, 2001:db8:3000:4000::/56 and 1060 2001:db8:5000:6000::/56 then the routing system would include: 1062 D: fd00::2001:db8:1000:2000/120 1064 E: fd00::2001:db8:3000:4000/120 1066 F: fd00::2001:db8:5000:6000/120 1068 A full discussion of the BGP-based routing system used by AERO is 1069 found in [I-D.ietf-rtgwg-atn-bgp]. 1071 3.2.4. Segment Routing Topologies (SRTs) 1073 The distinct {ULA}::/48 prefixes in an OMNI link domain identify 1074 distinct Segment Routing Topologies (SRTs). Each SRT is a mutually- 1075 exclusive OMNI link overlay instance using a distinct set of ULAs, 1076 and emulates a bridged campus LAN service for the OMNI link. In some 1077 cases (e.g., when redundant topologies are needed for fault tolerance 1078 and reliability) it may be beneficial to deploy multiple SRTs that 1079 act as independent overlay instances. A communication failure in one 1080 instance therefore will not affect communications in other instances. 1082 Each SRT is identified by a distinct value in the 40-bit ULA Global 1083 ID field and assigns an OMNI IPv6 anycast address used for OMNI 1084 interface determination in Safety-Based Multilink (SBM) as discussed 1085 in [I-D.templin-6man-omni]. Each OMNI interface further applies 1086 Performance-Based Multilink (PBM) internally. 1088 The Gateways and Proxy/Servers of each independent SRT engage in BGP 1089 peerings to form a spanning tree with the Gateways in non-leaf nodes 1090 and the Proxy/Servers in leaf nodes. The spanning tree is configured 1091 over both secured and unsecured underlay network paths. The secured 1092 spanning tree is used to convey secured control messages between 1093 Proxy/Servers and Gateways, while the unsecured spanning tree 1094 forwards data messages and/or unsecured control messages. 1096 Each SRT segment is identified by a unique ULA prefix used by all 1097 Proxy/Servers and Gateways in the segment. Each AERO node must 1098 therefore discover an SRT prefix that correspondents can use to 1099 determine the correct segment, and must publish the SRT prefix in 1100 IPv6 ND messages. 1102 Note: The distinct ULA prefixes in an OMNI link domain can be carried 1103 either in a common BGP routing protocol instance for all OMNI links 1104 or in distinct BGP routing protocol instances for different OMNI 1105 links. In some SBM environments, such separation may be necessary to 1106 ensure that distinct OMNI links do not include any common 1107 infrastructure elements as single points of failure. In other 1108 environments, carrying the ULAs of multiple OMNI links within a 1109 common routing system may be acceptable. 1111 3.2.5. Segment Routing For OMNI Link Selection 1113 Original IPv6 sources can direct IPv6 packets to an AERO node by 1114 including a standard IPv6 Segment Routing Header (SRH) [RFC8754] with 1115 the OMNI IPv6 anycast address for the selected OMNI link as either 1116 the IPv6 destination or as an intermediate hop within the SRH. This 1117 allows the original source to determine the specific OMNI link SRT an 1118 original IPv6 packet will traverse when there may be multiple 1119 alternatives. 1121 When an AERO node processes the SRH and forwards the original IPv6 1122 packet to the correct OMNI interface, the OMNI interface writes the 1123 next IPv6 address from the SRH into the IPv6 destination address and 1124 decrements Segments Left. If decrementing would cause Segments Left 1125 to become 0, the OMNI interface deletes the SRH before forwarding. 1126 This form of Segment Routing supports Safety-Based Multilink (SBM). 1128 3.3. OMNI Interface Characteristics 1130 OMNI interfaces are virtual interfaces configured over one or more 1131 underlay interfaces classified as follows: 1133 * ANET interfaces connect to a protected and secured ANET that is 1134 separated from the open INET by Proxy/Servers. The ANET interface 1135 may be either on the same L2 link segment as a Proxy/Server, or 1136 separated from a Proxy/Server by multiple IP hops. (Note that 1137 NATs may appear internally within an ANET and may require NAT 1138 traversal on the path to the Proxy/Server the same as for the INET 1139 case.) 1141 * INET interfaces connect to an INET either natively or through one 1142 or several IPv4 Network Address Translators (NATs). Native INET 1143 interfaces have global IP addresses that are reachable from any 1144 INET correspondent. NATed INET interfaces typically have private 1145 IP addresses and connect to a private network behind one or more 1146 NATs with the outermost NAT providing INET access. 1148 * ENET interfaces connect a Client's downstream-attached networks, 1149 where the Client provides forwarding services for ENET Host and 1150 Client communications to remote peers. An ENET can be as simple 1151 as a small stub network that travels with a mobile Client (e.g., 1152 an Internet-of-Things) to as complex as a large private enterprise 1153 network that the Client connects to a larger ANET or INET. 1155 * VPNed interfaces use security encapsulation over an underlay 1156 network to a Client or Proxy/Server acting as a Virtual Private 1157 Network (VPN) gateway. Other than the link-layer encapsulation 1158 format, VPNed interfaces behave the same as for Direct interfaces. 1160 * Direct (aka "point-to-point") interfaces connect directly to a 1161 Client or Proxy/Server without crossing any networked paths. An 1162 example is a line-of-sight link between a remote pilot and an 1163 unmanned aircraft. 1165 OMNI interfaces use OAL encapsulation and fragmentation as discussed 1166 in Section 3.6. OMNI interfaces use L2 encapsulation (see: 1167 Section 3.6) to exchange carrier packets with OMNI link neighbors 1168 over INET or VPNed interfaces as well as over ANET interfaces for 1169 which the Client and FHS Proxy/Server may be multiple IP hops away. 1170 OMNI interfaces use link-layer encapsulation only (i.e., and no other 1171 L2 encapsulations) over Direct underlay interfaces or ANET interfaces 1172 when the Client and FHS Proxy/Server are known to be on the same 1173 underlay link. 1175 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 1176 state the same as for any interface. OMNI interfaces use IPv6 ND 1177 messages including Router Solicitation (RS), Router Advertisement 1178 (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA) and 1179 Redirect for neighbor cache management. In environments where 1180 spoofing may be a threat, OMNI neighbors should invoke OAL 1181 Identification window synchronization in their IPv6 ND message 1182 exchanges. 1184 OMNI interfaces send IPv6 ND messages with an OMNI option formatted 1185 as specified in [I-D.templin-6man-omni]. The OMNI option includes 1186 prefix registration information, Interface Attributes and/or AERO 1187 Forwarding Parameters (AFPs) containing link information parameters 1188 for the OMNI interface's underlay interfaces and any other per- 1189 neighbor information. 1191 A Host's OMNI interface is configured over an underlay interface 1192 connected to an ENET provided by an upstream Client. From the Host's 1193 perspective, the ENET appears as an ANET and the upstream Client 1194 appears as a Proxy/Server. The Host does not provide OMNI 1195 intermediate node services and is therefore a logical termination 1196 point for the OMNI link. 1198 A Client's OMNI interface may be configured over multiple ANET/INET 1199 underlay interfaces. For example, common mobile handheld devices 1200 have both wireless local area network ("WLAN") and cellular wireless 1201 links. These links are often used "one at a time" with low-cost WLAN 1202 preferred and highly-available cellular wireless as a standby, but a 1203 simultaneous-use capability could provide benefits. In a more 1204 complex example, aircraft frequently have many wireless data link 1205 types (e.g. satellite-based, cellular, terrestrial, air-to-air 1206 directional, etc.) with diverse performance and cost properties. 1208 If a Client's multiple ANET/INET underlay interfaces are used "one at 1209 a time" (i.e., all other interfaces are in standby mode while one 1210 interface is active), then successive IPv6 ND messages all include 1211 OMNI option Interface Attributes, Traffic Selector and/or AFP sub- 1212 options with the same underlay interface ifIndex. In that case, the 1213 Client would appear to have a single underlay interface but with a 1214 dynamically changing link-layer address. 1216 If the Client has multiple active ANET/INET underlay interfaces, then 1217 from the perspective of IPv6 ND it would appear to have multiple 1218 link-layer addresses. In that case, IPv6 ND message OMNI options MAY 1219 include sub-options with different underlay interface ifIndexes. 1221 Proxy/Servers on the open Internet include only a single INET 1222 underlay interface. INET Clients therefore discover only the L2ADDR 1223 information for the Proxy/Server's INET interface. Proxy/Servers on 1224 an ANET/INET boundary include both an ANET and INET underlay 1225 interface. ANET Clients therefore must discover both the ANET and 1226 INET L2ADDR information for the Proxy/Server. 1228 Gateway and Proxy/Server OMNI interfaces are configured over underlay 1229 interfaces that provide both secured tunnels for carrying IPv6 ND and 1230 BGP protocol control plane messages and open INET access for carrying 1231 unsecured messages. The OMNI interface configures a ULA-RND and acts 1232 as an OAL source to encapsulate original IP packets, then fragments 1233 the resulting OAL packets and presents the resulting carrier packets 1234 over the secured or unsecured underlay paths. Note that Gateway and 1235 Proxy/Server end-to-end transport protocol sessions used by the BGP 1236 run directly over the OMNI interface and use ULA-RND source and 1237 destination addresses. The ULA-RND addresses that appear in BGP 1238 protocol session original IP packets may therefore be the same as 1239 those that appear in the OAL IPv6 encapsulation header. 1241 3.4. OMNI Interface Initialization 1243 AERO Proxy/Servers, Clients and Hosts configure OMNI interfaces as 1244 their point of attachment to the OMNI link. AERO nodes assign the 1245 MSPs for the link to their OMNI interfaces (i.e., as a "route-to- 1246 interface") to ensure that original IP packets with destination 1247 addresses covered by an MNP not explicitly associated with another 1248 interface are directed to an OMNI interface. 1250 OMNI interface initialization procedures for Proxy/Servers, Clients 1251 Hosts and Gateways are discussed in the following sections. 1253 3.4.1. AERO Proxy/Server and Relay Behavior 1255 When a Proxy/Server enables an OMNI interface, it assigns a ULA-RND 1256 appropriate for the given OMNI link SRT segment. The Proxy/Server 1257 also configures secured underlay interface tunnels and engages in BGP 1258 routing protocol sessions over the OMNI interface with one or more 1259 neighboring Gateways. 1261 The OMNI interface provides a single interface abstraction to the IP 1262 layer, but internally includes an NBMA nexus for sending carrier 1263 packets to OMNI interface neighbors over underlay interfaces and 1264 secured tunnels. The Proxy/Server further configures a service to 1265 facilitate IPv6 ND exchanges with AERO Clients and manages per-Client 1266 neighbor cache entries and IP forwarding table entries based on 1267 control message exchanges. 1269 Relays are simply Proxy/Servers that run a dynamic routing protocol 1270 to redistribute routes between the OMNI interface and INET/ENET 1271 interfaces (see: Section 3.2.3). The Relay provisions MNPs to 1272 networks on the INET/ENET interfaces (i.e., the same as a Client 1273 would do) and advertises the MSP(s) for the OMNI link over the INET/ 1274 ENET interfaces. The Relay further provides an attachment point of 1275 the OMNI link to a non-MNP-based global topology. 1277 3.4.2. AERO Client Behavior 1279 When a Client enables an OMNI interface, it assigns either an XLA-MNP 1280 or a TLA and sends OMNI-encapsulated RS messages over its ANET/INET 1281 underlay interfaces to an FHS Proxy/Server, which coordinates with a 1282 Hub Proxy/Server that returns an RA message with corresponding 1283 parameters. The RS/RA messages may pass through one or more NATs in 1284 the path between the Client and FHS Proxy/Server. (Note: if the 1285 Client used a TLA in its initial RS messages, it may discover ULA- 1286 MNPs in the corresponding RAs that it receives from FHS Proxy/Servers 1287 and begin using these new addresses. If the Client is operating 1288 outside the context of AERO infrastructure such as in a Mobile Ad-hoc 1289 Network (MANET), however, it may continue using TLAs for Client-to- 1290 Client communications at least until it encounters an infrastructure 1291 element that can delegate MNPs.) 1293 A Client can further extend the OMNI link over its (downstream) ENET 1294 interfaces where it provides a first-hop router for Hosts and other 1295 AERO Clients connected to the ENET. A downstream Client that 1296 connects via the ENET serviced by an upstream Client can in turn 1297 service further downstream ENETs that connect other Hosts and 1298 Clients. This OMNI link extension can be applied recursively over a 1299 "chain" of ENET Clients. 1301 3.4.3. AERO Host Behavior 1303 When a Host enables an OMNI interface, it assigns an address taken 1304 from the ENET underlay interface which may itself be a GUA delegated 1305 by the upstream Client. The Host does not assign a link-local 1306 address to the OMNI interface, since no autoconfiguration is 1307 necessary on that interface. (As an implementation matter, the Host 1308 could instead configure the "OMNI interface" as a virtual sublayer of 1309 the ENET underlay interface itself.) 1311 The Host sends OMNI-encapsulated RS messages over its ENET underlay 1312 interface to the upstream Client, which returns encapsulated RAs and 1313 provides routing services in the same fashion that Proxy/Servers 1314 provides services for Clients. Hosts represent the leaf end systems 1315 in recursively-nested chain of concatenated ENETs, i.e., they 1316 represent terminating endpoints for the OMNI link. 1318 3.4.4. AERO Gateway Behavior 1320 AERO Gateways configure an OMNI interface and assign a ULA-RND and 1321 corresponding Subnet Router Anycast address for each OMNI link SRT 1322 segment they connect to. Gateways configure underlay interface 1323 secured tunnels with Proxy/Servers in the same SRT segment and other 1324 Gateways in the same (or an adjacent) SRT segment. Gateways then 1325 engage in a BGP routing protocol session with neighbors over the 1326 secured spanning tree (see: Section 3.2.3). 1328 3.5. OMNI Interface Neighbor Cache Maintenance 1330 Each Client, Proxy/Server and Gateway OMNI interface maintains a 1331 network layer conceptual neighbor cache per [RFC1256] or [RFC4861] 1332 the same as for any IP interface. The OMNI interface network layer 1333 neighbor cache is maintained through static and/or dynamic neighbor 1334 cache entry configurations. 1336 Each OMNI interface also maintains a separate internal OAL 1337 (adaptation layer) conceptual neighbor cache that includes a Neighbor 1338 Cache Entry (NCE) for each of its active OAL neighbors per [RFC4861]. 1339 Throughout this document, the terms "neighbor cache" and "NCE" refer 1340 to this OAL neighbor cache unless otherwise specified. 1342 Each OMNI interface NCE is indexed by the network layer address of 1343 the neighbor and determines the context for Identification 1344 verification. Clients and Proxy/Servers maintain NCEs through 1345 dynamic RS/RA message exchanges, and also maintain NCEs for any 1346 active correspondent peers through dynamic NS/NA message exchanges. 1348 Hosts also maintain NCEs for Clients and other Hosts through the 1349 exchange of RS/RA, NS/NA or Redirect messages. Each NCE is indexed 1350 by the address assigned to the Host ENET interface, which is the same 1351 address used for OMNI L2 encapsulation (i.e., without the insertion 1352 of an OAL header). This encapsulation format identifies the NCE as a 1353 Host-based entry where the Host is a leaf end system in the 1354 recursively extended OMNI link. 1356 Gateways also maintain NCEs for Clients within their local segments 1357 based on NS/NA route optimization messaging (see: Section 3.13.3). 1358 When a Gateway creates/updates a NCE for a local segment Client based 1359 on NS/NA route optimization, it also maintains AFVI and L2ADDR state 1360 for messages destined to this local segment Client. 1362 Proxy/Servers add an additional state DEPARTED to the list of NCE 1363 states found in Section 7.3.2 of [RFC4861]. When a Client terminates 1364 its association, the Proxy/Server OMNI interface sets a "DepartTime" 1365 variable for the NCE to "DEPART_TIME" seconds. DepartTime is 1366 decremented unless a new IPv6 ND message causes the state to return 1367 to REACHABLE. While a NCE is in the DEPARTED state, the Proxy/Server 1368 forwards carrier packets destined to the target Client to the 1369 Client's new FHS/Hub Proxy/Server instead. It is RECOMMENDED that 1370 DEPART_TIME be set to the default constant value 10 seconds to accept 1371 any carrier packets that may be in flight. When DepartTime 1372 decrements to 0, the NCE is deleted. 1374 Clients determine the service profiles for their FHS and Hub Proxy/ 1375 Servers by setting the N/A/U flags in a Neighbor Coordination sub- 1376 option of the first OMNI option in RS messages. When the N/A/U flags 1377 are clear, Proxy/Servers forward all NS/NA messages to the Client, 1378 while the Client performs mobility update signaling through the 1379 transmission of uNA messages to all active neighbors following a 1380 mobility event. However, in some environments this may result in 1381 excessive NS/NA control message overhead especially for Clients 1382 connected to low-end data links. 1384 To minimize NS/NA message overhead, Clients can set the N/A/U flags 1385 in the OMNI Neighbor Coordination sub-option of RS messages they 1386 send. If the N flag is set, the FHS Proxy/Server that forwards the 1387 RS message assumes the role of responding to NS messages and 1388 maintains peer NCEs associated with the NCE for this Client. If the 1389 A flag is set, the Hub Proxy/Server that processes the RS message 1390 assumes the role of responding to NS(AR) messages on behalf of this 1391 Client NCE. If the U flag is set, the Hub Proxy/Server that 1392 processes the RS message becomes responsible for maintaining a 1393 "Report List" of sources/targets for NS(AR) messages it forwards on 1394 behalf of this Client NCE. The Hub Proxy/Server maintains each 1395 Report List entry for REPORT_TIME seconds, and sends uNA messages to 1396 each member of the Report List when it receives a Client mobility 1397 update indication (e.g., through receipt of an RS with updated 1398 Interface Attributes and/or Traffic Selectors). 1400 Clients and their Hub Proxy/Servers have full knowledge of the 1401 Client's current underlay Interface Attributes and Traffic Selectors, 1402 while FHS Proxy/Servers acting in "proxy" mode have knowledge of only 1403 the individual Client underlay interfaces they service. Clients 1404 determine their FHS and Hub Proxy/Server service models by setting 1405 the N/A/U flags in the RS messages they send as discussed above. 1407 When an Address Resolution Source (ARS) sends an NS(AR) message 1408 toward an Address Resolution Target (ART) Client/Relay, the OMNI link 1409 routing system directs the NS(AR) to a Hub Proxy/Server for the ART. 1410 The Hub then either acts as an Address Resolution Responder (ARR) on 1411 behalf of the ART or forwards the NS(AR) to the ART which acts as an 1412 ARR on its own behalf. The ARR returns an NA(AR) response to the 1413 ARS, which creates or updates a NCE for the ART while caching L3 and 1414 L2 addressing information. The ARS then (re)sets ReachableTime for 1415 the NCE to REACHABLE_TIME seconds and performs unicast NS/NA 1416 exchanges over specific underlay interface pairs to determine paths 1417 for forwarding carrier packets directly to the ART. The ARS 1418 otherwise decrements ReachableTime while no further solicited NA 1419 messages arrive. It is RECOMMENDED that REACHABLE_TIME be set to the 1420 default constant value 30 seconds as specified in [RFC4861]. 1422 AERO nodes also use the value MAX_UNICAST_SOLICIT to limit the number 1423 of NS messages sent when a correspondent may have gone unreachable, 1424 the value MAX_RTR_SOLICITATIONS to limit the number of RS messages 1425 sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT 1426 to limit the number of unsolicited NAs that can be sent based on a 1427 single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT, 1428 MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the 1429 same as specified in [RFC4861]. 1431 Different values for the above constants MAY be administratively set; 1432 however, if different values are chosen, all nodes on the link MUST 1433 consistently configure the same values. Most importantly, 1434 DEPART_TIME and REPORT_TIME SHOULD be set to a value that is 1435 sufficiently longer than REACHABLE_TIME to avoid packet loss due to 1436 stale route optimization state. 1438 3.5.1. OMNI ND Messages 1440 OMNI interfaces prepare IPv6 ND messages the same as for standard 1441 IPv6 ND, but also include a new option type termed the OMNI option 1442 [I-D.templin-6man-omni]. OMNI interfaces use ULAs instead of LLAs as 1443 IPv6 ND message source and destination addresses. This allows 1444 multiple different OMNI links to be joined into a single link at some 1445 future time without requiring a global renumbering event. 1447 For each IPv6 ND message, the OMNI interface includes one or more 1448 OMNI options (and any other ND message options) then completely 1449 populates all option information. If the OMNI interface includes an 1450 authentication signature, it sets the IPv6 ND message Checksum field 1451 to 0 and calculates the authentication signature over the entire 1452 length of the OAL packet or super-packet beginning with a pseudo- 1453 header of the IPv6 header. Otherwise, the OMNI interface calculates 1454 the standard IPv6 ND message checksum over the OAL packet or super- 1455 packet and writes the value in the Checksum field. OMNI interfaces 1456 verify authentication and integrity of each IPv6 ND message received 1457 according to the specific check(s) included, and process the message 1458 further only following verification. 1460 OMNI options include per-neighbor information that provides multilink 1461 forwarding, link-layer address and traffic selector information for 1462 the neighbor's underlay interfaces. This information is stored in 1463 the neighbor cache and provides the basis for the forwarding 1464 algorithm specified in Section 3.10. The information is cumulative 1465 and reflects the union of the OMNI information from the most recent 1466 IPv6 ND messages received from the neighbor. 1468 The OMNI option is distinct from any Source/Target Link-Layer Address 1469 Options (S/TLLAOs) that may appear in an IPv6 ND message according to 1470 the appropriate IPv6 over specific link layer specification (e.g., 1471 [RFC2464]). If both OMNI options and S/TLLAOs appear, the former 1472 pertains to encapsulation addresses while the latter pertains to the 1473 native L2 address format of the underlay media. 1475 OMNI interface IPv6 ND messages may also include other IPv6 ND 1476 options. In particular, solicitation messages may include a Nonce 1477 option if required for verification of advertisement replies. If an 1478 OMNI IPv6 ND solicitation message includes a Nonce option, the 1479 advertisement reply must echo the same Nonce. If an OMNI IPv6 ND 1480 advertisement message includes a Timestamp option, the recipient 1481 should check the Timestamp to determine if the message is current. 1483 AERO Clients send RS messages to the link-scoped All-Routers 1484 multicast address or a ULA-RND while using unicast or anycast OAL/L2 1485 addresses. AERO Proxy/Servers respond by returning unicast RA 1486 messages. During the RS/RA exchange, AERO Clients and Proxy/Servers 1487 include state synchronization parameters to establish Identification 1488 windows and other state. 1490 AERO Hosts and Clients on ENET underlay networks send RS messages to 1491 the link-scoped All-Routers multicast address, a ULA-RND of a remote 1492 Hub Proxy/Server or the ULA-MNP of an upstream Client while using 1493 unicast or anycast OAL/L2 addresses. The upstream AERO Client 1494 responds by returning a unicast RA message. 1496 AERO nodes use NS/NA messages for the following purposes: 1498 * NS/NA(AR) messages are used for address resolution and optionally 1499 to establish sequence number windows. The ARS sends an NS(AR) to 1500 the solicited-node multicast address of the ART, and an ARR with 1501 addressing information for the ART returns a unicast NA(AR) that 1502 contains current, consistent and authentic target address 1503 resolution information. NS/NA(AR) messages must be secured. 1505 * Ordinary NS/NA messages are used determine target reachability, 1506 establish and maintain NAT state, and/or establish AFIB state. 1507 The source sends an NS to the unicast address of the target while 1508 optionally including an OMNI AERO Forwarding Parameters (AFP) sub- 1509 option naming a specific underlay interface pair, and the target 1510 returns a unicast NA that includes a responsive AFP if necessary. 1511 NS/NA messages that use an in-window sequence number and do not 1512 update any other state need not include an authentication 1513 signature but instead must include an IPv6 ND message checksum. 1514 NS/NA messages used to establish window synchronization and/or 1515 AFIB state must be secured. 1517 * Unsolicited NA (uNA) messages are used to signal addressing and/or 1518 other neighbor state changes (e.g., address changes due to 1519 mobility, signal degradation, traffic selector updates, etc.). uNA 1520 messages that update state information must be secured. 1522 * NS/NA(DAD) messages are not used in AERO, since Duplicate Address 1523 Detection is not required. 1525 Additionally, nodes may set the OMNI option PNG flag in NA/RA 1526 messages to receive a uNA response from the neighbor. The uNA 1527 response MUST set the ACK flag (without also setting the SYN or PNG 1528 flags) with the Acknowledgement field set to the Identification used 1529 in the PNG message. 1531 3.5.2. OMNI Neighbor Advertisement Message Flags 1533 As discussed in Section 4.4 of [RFC4861] NA messages include three 1534 flag bits R, S and O. OMNI interface NA messages treat the flags as 1535 follows: 1537 * R: The R ("Router") flag is set to 1 in the NA messages sent by 1538 all AERO/OMNI node types. Simple hosts that would set R to 0 do 1539 not occur on the OMNI link itself, but may occur on the downstream 1540 links of Clients and Relays. 1542 * S: The S ("Solicited") flag is set exactly as specified in 1543 Section 4.4. of [RFC4861], i.e., it is set to 1 for Solicited NAs 1544 and set to 0 for uNAs (both unicast and multicast). 1546 * O: The O ("Override") flag is set to 0 for solicited NAs returned 1547 by a Proxy/Server ARR and set to 1 for all other solicited and 1548 unsolicited NAs. For further study is whether solicited NAs for 1549 anycast targets apply for OMNI links. Since XLA-MNPs must be 1550 uniquely assigned to Clients to support correct IPv6 ND protocol 1551 operation, however, no role is currently seen for assigning the 1552 same XLA-MNP to multiple Clients. 1554 3.5.3. OMNI Neighbor Window Synchronization 1556 In secured environments (e.g., between secured spanning tree 1557 neighbors, between neighbors on the same secured ANET, etc.), OMNI 1558 interface neighbors can exchange OAL packets using randomly- 1559 initialized and monotonically-increasing Identification values 1560 (modulo 2**32) without window synchronization. In environments where 1561 spoofing is considered a threat, OMNI interface neighbors instead 1562 invoke window synchronization by including OMNI Neighbor Coordination 1563 sub-options in RS/RA or NS/NA message exchanges to maintain send/ 1564 receive window state in their respective neighbor cache entries as 1565 specified in [I-D.templin-6man-omni]. 1567 3.6. OMNI Interface Encapsulation and Fragmentation 1569 When the network layer forwards an original IP packet into an OMNI 1570 interface, the interface locates or creates a Neighbor Cache Entry 1571 (NCE) that matches the destination. The OMNI interface then invokes 1572 the OMNI Adaptation Layer (OAL) as discussed in 1573 [I-D.templin-6man-omni] which encapsulates the packet in an IPv6 1574 header to produce an OAL packet. For example, an original IP packet 1575 with source address 2001:db8:1:2::1 and destination address 1576 2001:db8:1234:5678::1 might cause the OAL encapsulation header to 1577 include source address {XLA*}::2001:db8:1:2 (i.e., an XLA-MNP) and 1578 destination address {ULA*}::0012:3456:789a:bcde (i.e., a ULA-RND). 1580 Following encapsulation, the OAL source then calculates and includes 1581 a 2-octet OAL checksum, then fragments the OAL packet while including 1582 an identical Identification value for each fragment that must be 1583 within the window for the neighbor. This fragmentation causes the 1584 OAL checksum to appear as the final 2 octets of the final fragment, 1585 i.e., as a "trailer". 1587 The OAL source next includes an identical Compressed Routing Header 1588 with 32-bit ID fields (CRH-32) [I-D.bonica-6man-comp-rtg-hdr] with 1589 each fragment containing one or more AERO Forwarding Vector Indices 1590 (AFVIs) if necessary as discussed in Section 3.13. The OAL source 1591 can instead invoke OAL header compression by replacing the OAL IPv6 1592 header, CRH-32 and Fragment Header with an OAL Compressed Header 1593 (OCH). 1595 The OAL source finally encapsulates each resulting OAL fragment in L2 1596 headers to form an OAL carrier packet, with source address set to its 1597 own L2 address (e.g., 192.0.2.100) and destination set to the L2 1598 address of the next hop OAL intermediate node or destination (e.g., 1599 192.0.2.1). The carrier packet encapsulation format in the above 1600 example is shown in Figure 3: 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | L2 Headers | 1604 | src = 192.0.2.100 | 1605 | dst = 192.0.2.1 | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | OAL IPv6 Header | 1608 | src = {XLA*}::2001:db8:1:2 | 1609 |dst={ULA*}::0012:3456:789a:bcde| 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | CRH-32 (if necessary) | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | OAL Fragment Header | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | Original IP Header | 1616 | (first-fragment only) | 1617 | src = 2001:db8:1:2::1 | 1618 | dst = 2001:db8:1234:5678::1 | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | | 1621 ~ ~ 1622 ~ Original Packet Body/Fragment ~ 1623 ~ ~ 1624 | | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | OAL Trailing Checksum | 1627 | (final-fragment only) | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 Figure 3: Carrier Packet Format 1632 Note: that carrier packets exchanged by Hosts on ENETs do not include 1633 the OAL IPv6 or CRH-32 headers, i.e., the OAL encapsulation is NULL 1634 and only the Fragment Header and L2 encapsulations are included. 1636 In this format, the OAL source encapsulates the original IP header 1637 and packet body/fragment in an OAL IPv6 header prepared according to 1638 [RFC2473], the CRH-32 is a Routing Header extension of the OAL 1639 header, the Fragment Header identifies each fragment, and the L2 1640 headers are prepared as discussed in [I-D.templin-6man-omni]. The 1641 OAL source transmits each such carrier packet into the SRT spanning 1642 tree, where they are forwarded over possibly multiple OAL 1643 intermediate nodes until they arrive at the OAL destination. 1645 The OMNI link control plane service distributes Client XLA-MNP prefix 1646 information that may change occasionally due to regional node 1647 mobility, as well as XLA-MNP prefix information for Relay non-MNPs 1648 and per-segment ULA prefix information that rarely changes. OMNI 1649 link Gateways and Proxy/Servers use the information to establish and 1650 maintain a forwarding plane spanning tree that connects all nodes on 1651 the link. The spanning tree supports a carrier packet virtual 1652 bridging service according to link-layer (instead of network-layer) 1653 information, but may often include longer paths than necessary. 1655 Each OMNI interface therefore also includes an AERO Forwarding 1656 Information Base (AFIB) that caches AERO Forwarding Vectors (AFVs) 1657 which can provide more direct forwarding "shortcuts" that avoid 1658 strict spanning tree paths. As a result, the spanning tree is always 1659 available but OMNI interfaces can often use the AFIB to greatly 1660 improve performance and reduce load on critical infrastructure 1661 elements. 1663 For carrier packets undergoing re-encapsulation at an OAL 1664 intermediate node, the OMNI interface removes the L2 encapsulation 1665 headers and reassembles if necessary to obtain the OAL packet. The 1666 OMNI interface then decrements the OAL IPv6 header Hop Limit and 1667 discards the packet if the Hop Limit reaches 0. Otherwise, the OMNI 1668 interface updates the OAL addresses if necessary, recalculates the 1669 OAL checksum, re-fragments and re-encapsulates each fragment in new 1670 L2 encapsulation headers appropriate for next segment forwarding. 1672 When an FHS Gateway forwards a carrier packet to an LHS Gateway over 1673 the unsecured spanning tree, it reconstructs the OAL header based on 1674 AFV state, inserts a CRH-32 immediately following the OAL header and 1675 adjusts the OAL payload length and destination address field. The 1676 FHS Gateway includes a single AFVI in the CRH-32 that will be 1677 meaningful to the LHS Gateway, then forwards the carrier packet over 1678 the unsecured spanning tree. When the LHS Gateway receives the 1679 carrier packet, it locates the AFV for the next hop based on the 1680 CRH-32 AFVI then re-applies header compression (resulting in the 1681 removal of the CRH-32) and forwards the carrier packet to the next 1682 hop. 1684 3.7. OMNI Interface Decapsulation 1686 When an OAL node receives carrier packets with OAL headers addressed 1687 to another node, it discards the L2 headers and includes new L2 1688 headers appropriate for the next hop in the forwarding path to the 1689 OAL destination. The node then forwards these new carrier packets 1690 into the next hop underlay interface. 1692 When an OAL node receives carrier packets with OAL headers addressed 1693 to itself, it discards the L2 headers, verifies the Identification, 1694 reassembles to obtain the original OAL packet (or super-packet - see: 1695 [I-D.templin-6man-omni]) then finally verifies the OAL checksum. 1696 Next, if the original IP packet (or super-packet) is destined either 1697 to itself or to a destination reached via an interface other than the 1698 OMNI interface, the OAL node discards the OAL encapsulation and 1699 forwards the original IP packet(s) to the network layer. 1701 If the original IP packet (or super-packet) is destined to another 1702 node reached by the OMNI interface, the OAL node instead changes the 1703 OAL source to its own address, changes the OAL destination to the ULA 1704 of the next-hop node over the OMNI interface, decrements the Hop 1705 Limit, recalculates the OAL checksum, refragments if necessary, 1706 includes new L2 headers appropriate for the next hop, then forwards 1707 these new carrier packets into the next hop underlay interface. 1709 3.8. OMNI Interface Data Origin Authentication 1711 AERO nodes employ simple data origin authentication procedures. In 1712 particular: 1714 * AERO Gateways and Proxy/Servers accept carrier packets received 1715 from the secured spanning tree. 1717 * AERO Proxy/Servers and Clients accept carrier packets and original 1718 IP packets that originate from within the same secured ANET. 1720 * AERO Clients and Relays accept original IP packets from downstream 1721 network correspondents based on ingress filtering. 1723 * AERO Hosts, Clients, Relays, Proxy/Servers and Gateways verify 1724 carrier packet L2 encapsulation addresses according to 1725 [I-D.templin-6man-omni]. 1727 * AERO nodes accept carrier packets addressed to themselves with 1728 Identification values within the current window for the OAL source 1729 neighbor and drop any carrier packets with out-of-window 1730 Identification values. (AERO nodes may forward carrier packets 1731 not addressed to themselves without verifying the Identification 1732 value.) 1734 AERO nodes silently drop any packets that do not satisfy the above 1735 data origin authentication procedures. Further security 1736 considerations are discussed in Section 6. 1738 3.9. OMNI Interface MTU 1740 The OMNI interface observes the link nature of tunnels, including the 1741 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 1742 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 1743 The OMNI interface employs an OMNI Adaptation Layer (OAL) that 1744 accommodates multiple underlay links with diverse MTUs while 1745 observing both a minimum and per-path Maximum Payload Size (MPS). 1746 The functions of the OAL and OMNI interface MTU/MRU/MPS 1747 considerations are specified in [I-D.templin-6man-omni]. (Note that 1748 the OMNI interface accommodates an assured MTU of 65535 octets due to 1749 the use of fragmentation, and can optionally expose larger MTUs to 1750 upper layers for best-effort Jumbogram services.) 1752 When the network layer presents an original IP packet to the OMNI 1753 interface, the OAL source encapsulates and fragments the original IP 1754 packet if necessary. When the network layer presents the OMNI 1755 interface with multiple original IP packets bound to the same OAL 1756 destination, the OAL source can concatenate them as a single OAL 1757 super-packet as discussed in [I-D.templin-6man-omni] before applying 1758 fragmentation. The OAL source then encapsulates each OAL fragment in 1759 L2 headers for transmission as carrier packets over an underlay 1760 interface connected to either a physical link (e.g., Ethernet, WiFi, 1761 Cellular, etc.) or a virtual link such as an Internet or higher-layer 1762 tunnel (see the definition of link in [RFC8200]). 1764 Note: Although a CRH-32 may be inserted or removed by a Gateway in 1765 the path (see: Section 3.10.4), this does not interfere with the 1766 destination's ability to reassemble since the CRH-32 is not included 1767 in the fragmentable part and its removal/transformation does not 1768 invalidate fragment header information. 1770 3.10. OMNI Interface Forwarding Algorithm 1772 Original IP packets enter a node's OMNI interface either from the 1773 network layer (i.e., from a local application or the IP forwarding 1774 system) while carrier packets enter from the link layer (i.e., from 1775 an OMNI interface neighbor). All original IP packets and carrier 1776 packets entering a node's OMNI interface first undergo data origin 1777 authentication as discussed in Section 3.8. Those that satisfy data 1778 origin authentication are processed further, while all others are 1779 dropped silently. 1781 Original IP packets that enter the OMNI interface from the network 1782 layer are forwarded to an OMNI interface neighbor using OAL 1783 encapsulation and fragmentation to produce carrier packets for 1784 transmission over underlay interfaces. (If forwarding state 1785 indicates that the original IP packet should instead be forwarded 1786 back to the network layer, the packet is dropped to avoid looping). 1787 Carrier packets that enter the OMNI interface from the link layer are 1788 either re-encapsulated and re-admitted into the link layer, or 1789 reassembled and forwarded to the network layer where they are subject 1790 to either local delivery or IP forwarding. 1792 When the network layer forwards an original IP packet into the OMNI 1793 interface, it decrements the TTL/Hop Limit following standard IP 1794 router conventions. Once inside the OMNI interface, however, the OAL 1795 does not further decrement the original IP packet TTL/Hop Limit since 1796 its forwarding actions occur below the network layer. The original 1797 IP packet's TTL/Hop Limit will therefore be the same when it exits 1798 the destination OMNI interface as when it first entered the source 1799 OMNI interface. 1801 When an OAL intermediate node forwards an OAL packet or carrier 1802 packet not addressed to itself, it decrements the OAL Hop Limit 1803 without decrementing the network layer IP TTL/Hop Limit. If 1804 decrementing would cause the OAL Hop Limit to become 0, the OAL 1805 intermediate node drops the OAL packet or carrier packet. This 1806 ensures that the original IP packet cannot enter an endless loop. 1808 OMNI interfaces may have multiple underlay interfaces and/or neighbor 1809 cache entries for neighbors with multiple underlay interfaces (see 1810 Section 3.3). The OAL uses Interface Attributes and/or Traffic 1811 Selectors to select an outbound underlay interface for each OAL 1812 packet and also to select segment routing and/or link-layer 1813 destination addresses based on the neighbor's target underlay 1814 interfaces. AERO implementations SHOULD permit network management to 1815 dynamically adjust Traffic Selector values at runtime. 1817 If an OAL packet matches the Interface Attributes and/or Traffic 1818 Selectors of multiple outgoing interfaces and/or neighbor interfaces, 1819 the OMNI interface replicates the packet and sends a separate copy 1820 via each of the (outgoing / neighbor) interface pairs; otherwise, it 1821 sends a single copy via an interface with the best matching 1822 attributes/selectors. (While not strictly required, the likelihood 1823 of successful reassembly may improve when the OMNI interface sends 1824 all fragments of the same fragmented OAL packet consecutively over 1825 the same underlay interface pair to avoid complicating factors such 1826 as delay variance and reordering.) AERO nodes keep track of which 1827 underlay interfaces are currently "reachable" or "unreachable", and 1828 only use "reachable" interfaces for forwarding purposes. 1830 The Subnet ID value in ULAs is used only for subnet coordination 1831 within a local OMNI link segment. When a node forwards a packet with 1832 a ULA with a foreign Global and/or Subnet ID value it forwards the 1833 packet based solely on the OMNI link routing information. For this 1834 reason, OMNI link routing and forwarding table entries always include 1835 both ULAs with their associated prefix lengths and XLA-MNPs which 1836 encode an MNP while leaving the Global and Subnet ID values set to 0. 1838 The following sections discuss the OMNI interface-specific forwarding 1839 algorithms for Hosts, Clients, Proxy/Servers and Gateways. In the 1840 following discussion, an original IP packet's destination address is 1841 said to "match" if it is the same as a cached address, or if it is 1842 covered by a cached prefix (which may be encoded in an {ULA,XLA}- 1843 MNP). 1845 3.10.1. Host Forwarding Algorithm 1847 When an original IP packet enters a Host's OMNI interface from the 1848 network layer the Host searches for a NCE that matches the 1849 destination. If there is a matching NCE, the Host performs L2 1850 encapsulation, fragments the encapsulated packet if necessary and 1851 forwards the packets into the ENET addressed to the L2 address of the 1852 neighbor. If there is no match, the host instead forwards the packet 1853 to its upstream Client. 1855 After forwarding a packet, the Host may receive a Redirect message 1856 from its upstream Client to inform it of another AERO node on the 1857 same ENET that would provide a better first hop. The Host 1858 authenticates the Redirect message, then updates its neighbor cache 1859 accordingly. 1861 3.10.2. Client Forwarding Algorithm 1863 When an original IP packet enters a Client's OMNI interface from the 1864 network layer the Client searches for a NCE that matches the 1865 destination. If there is a matching NCE for a neighbor reached via 1866 an ANET/INET interface (i.e., an upstream interface), the Client 1867 selects one or more "reachable" neighbor interfaces in the entry for 1868 forwarding purposes. Otherwise, the Client forwards the packet to an 1869 FHS Proxy/Server while either invoking address resolution and 1870 multilink forwarding procedures per Section 3.13 or allowing the FHS 1871 Proxy/Server to invoke these procedures on its behalf. If there is a 1872 matching NCE for a neighbor reached via an ENET interface (i.e., a 1873 downstream interface), the Client instead performs OAL and/or L2 1874 encapsulation and forwards the packet to the downstream Host or 1875 Client. 1877 When a carrier packet enters a Client's OMNI interface from the link 1878 layer, the Client first examines the OAL destination. If the OAL 1879 destination matches one of the Client's ULAs the Client (acting as an 1880 OAL destination) verifies that the Identification is in-window for 1881 this OAL source, then reassembles, decapsulates as necessary and 1882 delivers the original IP packet to the network layer. If the OAL 1883 destination matches a NCE for a Client on an ENET interface, the 1884 Client instead forwards the carrier packet to the Client while 1885 decrementing the OAL Hop Limit. If the OAL destination matches a NCE 1886 for a Host on an ENET interface, the Client instead reassembles then 1887 forwards the original IP packet to the Host while using IP-in-IP 1888 encapsulation and fragmentation if necessary. If the OAL destination 1889 does not match, the Client drops the original IP packet and MAY 1890 return a network-layer ICMP Destination Unreachable message subject 1891 to rate limiting (see: Section 3.11). 1893 When a Client forwards a carrier packet from an ENET Host to a 1894 neighbor connected to the same ENET, it also returns a Redirect 1895 message to inform the Host that it can reach the neighbor directly as 1896 an ENET peer. 1898 Note: Clients and their FHS Proxy/Server (and other Client) peers can 1899 exchange original IP packets over ANET underlay interfaces without 1900 invoking the OAL, since the ANET is secured at the link and physical 1901 layers. By forwarding original IP packets without invoking the OAL, 1902 however, the ANET peers can engage only in classical path MTU 1903 discovery since the packets are subject to loss and/or corruption due 1904 to the various per-link MTU limitations that may occur within the 1905 ANET. Moreover, the original IP packets do not include either the 1906 OAL integrity check or per-packet Identification values that can be 1907 used for data origin authentication and link-layer retransmissions. 1908 The tradeoff therefore involves an assessment of the per-packet 1909 encapsulation overhead saved by bypassing the OAL vs. inheritance of 1910 classical network "brittleness". (Note however that ANET peers can 1911 send small original IP packets without invoking the OAL, while 1912 invoking the OAL for larger packets. This presents the beneficial 1913 aspects of both small packet efficiency and large packet robustness, 1914 with delay variance and reordering as possible side effects.) 1916 Note: The forwarding table entries established in peer Clients of a 1917 multihop forwarding region are based on ULA-MNPs and/or TLAs used to 1918 seed the multihop routing protocols. When ULA-MNPs are used, the ULA 1919 /64 prefix provides topological relevance for the multihop forwarding 1920 region, while the 64-bit Interface Identifier encodes the Client MNP. 1921 Therefore, Clients can forward atomic fragments with compressed OAL 1922 headers that do not include ULA or AFVI information by examining the 1923 MNP-based addresses in the actual IP packet header. In other words, 1924 each forwarding table entry contains two pieces of forwarding 1925 information - the ULA information in the prefix and the MNP 1926 information in the interface identifier. 1928 3.10.3. Proxy/Server and Relay Forwarding Algorithm 1930 When the network layer admits an original IP packet into a Proxy/ 1931 Server's OMNI interface, the OAL drops the packet to avoid looping if 1932 forwarding state indicates that it should be forwarded back to the 1933 network layer. Otherwise, the OAL examines the IP destination 1934 address to determine if it matches the ULA of a neighboring Gateway 1935 found in the OMNI interface's network layer neighbor cache. If so, 1936 the Proxy/Server performs OAL encapsulation and forwards the 1937 resulting carrier packets to the neighboring Gateway over a secured 1938 tunnel to support the operation of the BGP routing protocol. If the 1939 destination is a non-ULA, the Proxy/Server instead assumes the Relay 1940 role and forwards the original IP packet in a similar manner as for 1941 Clients. Specifically, if there is a matching NCE the Proxy/Server 1942 selects one or more "reachable" neighbor interfaces in the entry for 1943 forwarding purposes; otherwise, the Proxy/Server forwards the packet 1944 while invoking address resolution and multilink forwarding procedures 1945 per Section 3.13. 1947 When the Proxy/Server receives carrier packets on underlay interfaces 1948 with both a source and destination OAL address that correspond to the 1949 same Client's delegated MNP, the Proxy/Server drops the packets 1950 regardless of their OMNI link point of origin. The Proxy/Server also 1951 drops original IP packets received on underlay interfaces either 1952 directly from an ANET Client or following reassembly of carrier 1953 packets received from an ANET/INET Client if the original IP 1954 destination corresponds to the same Client's delegated MNP. Proxy/ 1955 Servers also drop carrier packets with foreign OAL destinations that 1956 do not match their own ULA, the ULA of one of their Clients or a ULA 1957 corresponding to one of their GUA routes. These checks are essential 1958 to prevent forwarding inconsistencies from accidentally or 1959 intentionally establishing endless loops that could congest nodes 1960 and/or ANET/INET links. 1962 Proxy/Servers process carrier packets with OCH headers or with 1963 destinations that match their ULA and also include a CRH-32 header 1964 that encodes one or more AFVIs. The Proxy/Server examines the next 1965 AFVI in the carrier packet to locate the corresponding AFV entry in 1966 the AFIB. If the carrier packets were not received from the secured 1967 spanning tree, the Proxy/Server must then verify that the L2 1968 addresses are "trusted" according to the AFV. If the carrier packets 1969 were trusted, the Proxy/Server then forwards them according to the 1970 AFV state while decrementing the OAL Hop Limit. 1972 For carrier packets with destinations that match their ULA but do not 1973 include a CRH-32/OCH, the Proxy/Server instead discards the L2 1974 headers and performs OAL reassembly if necessary to obtain the 1975 original IP packet. For data packets addressed to their own ULA that 1976 arrived via the secured spanning tree, the Proxy/Server delivers the 1977 original IP packet to the network layer to support secured BGP 1978 routing protocol control messaging. For data packets originating 1979 from one of its dependent Clients, the Proxy/Server instead forwards 1980 the packet while invoking address resolution and multilink forwarding 1981 procedures per Section 3.13. For IPv6 ND control messages, the 1982 Proxy/Server instead authenticates the message and processes it as 1983 specified in later sections of this document while updating neighbor 1984 cache and/or AFIB state accordingly. 1986 When the Proxy/Server receives a carrier packet with OAL destination 1987 set to a {ULA,XLA}-MNP of one of its Client neighbors established 1988 through RS/RA exchanges, it accepts the carrier packet only if data 1989 origin authentication succeeds. If the NCE state is DEPARTED, the 1990 Proxy/Server changes the OAL destination address to the ULA of the 1991 new Proxy/Server, decrements the OAL Hop Limit, then supplies new L2 1992 headers and forwards the carrier packet into the spanning tree which 1993 will eventually deliver it to the new Proxy/Server. If the neighbor 1994 cache state for the Client is REACHABLE and the Proxy/Server is a Hub 1995 responsible for serving as the Client's address resolution responder 1996 and/or default router, it submits the carrier packet for reassembly 1997 then decapsulates and processes the resulting IPv6 ND message or 1998 original IP packet accordingly. Otherwise, the Proxy/Server 1999 decrements the OAL Hop Limit, supplies new L2 headers and forwards 2000 the carrier packets to the Client which must then perform data origin 2001 verification and reassembly. (In the latter case, the Client may 2002 receive fragments of the same original packet from different Proxy/ 2003 Servers but this will not interfere with reassembly.) 2005 When the Proxy/Server receives a carrier packet with OAL destination 2006 set to a {ULA,XLA}-MNP that does not match the MSP, it accepts the 2007 carrier packet only if data origin authentication succeeds and if 2008 there is a network layer forwarding table entry for a GUA route that 2009 matches the MNP. The Proxy/Server then reassembles and decapsulates 2010 to obtain the original IP packet, then acts as a Relay to present it 2011 to the network layer where it will be delivered according to standard 2012 IP forwarding. 2014 Clients and their FHS Proxy/Server peers can exchange original IP 2015 packets over ANET underlay interfaces without invoking the OAL, since 2016 the ANET is secured at the link and physical layers. By forwarding 2017 original IP packets without invoking the OAL, however, the Client and 2018 Proxy/Server can engage only in classical path MTU discovery since 2019 the packets are subject to loss and/or corruption due to the various 2020 per-link MTU limitations that may occur within the ANET. Moreover, 2021 the original IP packets do not include either the OAL integrity check 2022 or per-packet Identification values that can be used for data origin 2023 authentication and link-layer retransmissions. The tradeoff 2024 therefore involves an assessment of the per-packet encapsulation 2025 overhead saved by bypassing the OAL vs. inheritance of classical 2026 network "brittleness". (Note however that ANET peers can send small 2027 original IP packets without invoking the OAL, while invoking the OAL 2028 for larger packets. This presents the beneficial aspects of both 2029 small packet efficiency and large packet robustness.) 2031 Proxy/Servers forward secure control plane carrier packets via the 2032 SRT secured spanning tree and forward other carrier packets via the 2033 unsecured spanning tree. When a Proxy/Server receives a carrier 2034 packet from the secured spanning tree, it considers the message as 2035 authentic without having to verify upper layer authentication 2036 signatures. When a Proxy/Server receives a carrier packet from the 2037 unsecured spanning tree, it applies data origin authentication itself 2038 and/or forwards the unsecured message toward the destination which 2039 must apply data origin authentication on its own behalf. 2041 If the Proxy/Server has multiple original IP packets to send to the 2042 same neighbor, it can concatenate them as a single OAL super-packet 2043 [I-D.templin-6man-omni]. If the first packet in the super-packet is 2044 a control message to be sent over the secured spanning tree, the 2045 remainder of the super-packet is also sent over the secured spanning 2046 tree. 2048 3.10.4. Gateway Forwarding Algorithm 2050 When the network layer admits an original IP packet into the 2051 Gateway's OMNI interface, the OAL drops the packet if routing 2052 indicates that it should be forwarded back to the network layer to 2053 avoid looping. Otherwise, the Gateway examines the IP destination 2054 address to determine if it matches the ULA of a neighboring Gateway 2055 or Proxy/Server by examining the OMNI interface's network layer 2056 neighbor cache. If so, the Gateway performs OAL and L2 encapsulation 2057 and forwards the resulting carrier packets to the neighboring Gateway 2058 or Proxy/Server over a secured tunnel to support the operation of the 2059 BGP routing protocol between OAL neighbors. 2061 Gateways forward spanning tree carrier packets while decrementing the 2062 OAL Hop Limit but not the original IP header TTL/Hop Limit. Gateways 2063 convey carrier packets that encapsulate critical IPv6 ND control 2064 messages or BGP routing protocol control messages via the SRT secured 2065 spanning tree, and may convey other carrier packets via the secured/ 2066 unsecured spanning tree or via more direct paths according to AFIB 2067 information. When the Gateway receives a carrier packet, it removes 2068 the L2 headers and searches for an AFIB entry that matches an AFVI or 2069 an IP forwarding table entry that matches the OAL destination 2070 address. 2072 Gateways process carrier packets with OAL destinations that do not 2073 match their ULA or the SRT Subnet Router Anycast address in the same 2074 manner as for traditional IP forwarding within the OAL, i.e., they 2075 use IP forwarding to forward packets not explicitly addressed to 2076 themselves. Gateways locally process carrier packets with OCH 2077 headers or full OAL headers with their ULA or the SRT Subnet Router 2078 Anycast address as the OAL destination. If the packet contains an 2079 OCH or a full OAL header with a CRH-32 extension, the Gateway 2080 examines the next AFVI in the carrier packet to locate the AFV entry 2081 in the AFIB for next hop forwarding. If an AFV is found, the Gateway 2082 uses the next hop AFVI to forward the carrier packet to the next hop 2083 while decrementing the OAL Hop Limit but without reassembling. If 2084 the Gateway has a NCE for the target Client with an entry for the 2085 target underlay interface and current L2 addresses, the Gateway 2086 instead forwards the carrier packet directly to the target Client 2087 while using the final hop AFVI instead of the next hop (see: 2088 Section 3.13.3). 2090 If the carrier packet includes a full OAL header addressed to itself 2091 but does not include an AFVI, the Gateway instead reassembles if 2092 necessary, verifies the OAL checksum, and processes the OAL packet 2093 further. The Gateway first determines whether the OAL packet 2094 includes an NS/NA message then processes the message according to the 2095 multilink forwarding procedures discussed in Section 3.13. If the 2096 carrier packets arrived over the secured spanning tree and the 2097 reassembled original IP packet is addressed to its ULA, the Gateway 2098 instead discards the OAL header and forwards the original IP packet 2099 to the network layer to support secured BGP routing protocol control 2100 messaging. The Gateway instead drops all other OAL packets. 2102 Gateways forward carrier packets received from a first segment via 2103 the secured spanning tree to the next segment also via the secured 2104 spanning tree. Gateways forward carrier packets received from a 2105 first segment via the unsecured spanning tree to the next segment 2106 also via the unsecured spanning tree. Gateways use a single IPv6 2107 routing table that always determines the same next hop for a given 2108 OAL destination, where the secured/unsecured spanning tree is 2109 determined through the selection of the underlay interface to be used 2110 for transmission (i.e., a secured tunnel or an open INET interface). 2112 As for Proxy/Servers, Gateways must verify that the L2 addresses of 2113 carrier packets not received from the secured spanning tree are 2114 "trusted" before forwarding according to an AFV (otherwise, the 2115 carrier packet must be dropped). 2117 3.11. OMNI Interface Error Handling 2119 When an AERO node admits an original IP packet into the OMNI 2120 interface, it may receive link-layer or network-layer error 2121 indications. The AERO node may also receive OMNI link error 2122 indications in OAL-encapsulated uNA messages that include 2123 authentication signatures. 2125 A link-layer error indication is an ICMP error message generated by a 2126 router in an underlay network on the path to the neighbor or by the 2127 neighbor itself. The message includes an IP header with the address 2128 of the node that generated the error as the source address and with 2129 the link-layer address of the AERO node as the destination address. 2131 The IP header is followed by an ICMP header that includes an error 2132 Type, Code and Checksum. Valid type values include "Destination 2133 Unreachable", "Time Exceeded" and "Parameter Problem" 2134 [RFC0792][RFC4443]. (OMNI interfaces ignore link-layer IPv4 2135 "Fragmentation Needed" and IPv6 "Packet Too Big" messages for carrier 2136 packets that are no larger than the minimum/path MPS as discussed in 2137 Section 3.9, however these messages may provide useful hints of probe 2138 failures during path MPS probing.) 2140 The ICMP header is followed by the leading portion of the carrier 2141 packet that generated the error, also known as the "packet-in-error". 2142 For ICMPv6, [RFC4443] specifies that the packet-in-error includes: 2143 "As much of invoking packet as possible without the ICMPv6 packet 2144 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 2145 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 2146 "Internet Header + 64 bits of Original Data Datagram", however 2147 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 2148 ICMP datagram SHOULD contain as much of the original datagram as 2149 possible without the length of the ICMP datagram exceeding 576 2150 bytes". 2152 The link-layer error message format is shown in Figure 4: 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 ~ ~ 2156 | IP Header of link layer | 2157 | error message | 2158 ~ ~ 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | ICMP Header | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2162 ~ ~ P 2163 | carrier packet L2 and OAL | a 2164 | encapsulation headers | c 2165 ~ ~ k 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 2167 ~ ~ t 2168 | original IP packet headers | 2169 | (first-fragment only) | i 2170 ~ ~ n 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 ~ ~ e 2173 | Portion of the body of | r 2174 | the original IP packet | r 2175 | (all fragments) | o 2176 ~ ~ r 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2179 Figure 4: OMNI Interface Link-Layer Error Message Format 2181 The AERO node rules for processing these link-layer error messages 2182 are as follows: 2184 * When an AERO node receives a link-layer Parameter Problem message, 2185 it processes the message the same as described as for ordinary 2186 ICMP errors in the normative references [RFC0792][RFC4443]. 2188 * When an AERO node receives persistent link-layer Time Exceeded 2189 messages, the IP ID field may be wrapping before earlier fragments 2190 awaiting reassembly have been processed. In that case, the node 2191 should begin including integrity checks and/or institute rate 2192 limits for subsequent packets. 2194 * When an AERO node receives persistent link-layer Destination 2195 Unreachable messages in response to carrier packets that it sends 2196 to one of its neighbor correspondents, the node should process the 2197 message as an indication that a path may be failing, and 2198 optionally initiate NUD over that path. If it receives 2199 Destination Unreachable messages over multiple paths, the node 2200 should allow future carrier packets destined to the correspondent 2201 to flow through a default route and re-initiate route 2202 optimization. 2204 * When an AERO Client receives persistent link-layer Destination 2205 Unreachable messages in response to carrier packets that it sends 2206 to one of its neighbor Proxy/Servers, the Client should mark the 2207 path as unusable and use another path. If it receives Destination 2208 Unreachable messages on many or all paths, the Client should 2209 associate with a new Proxy/Server and release its association with 2210 the old Proxy/Server as specified in Section 3.15.5. 2212 * When an AERO Proxy/Server receives persistent link-layer 2213 Destination Unreachable messages in response to carrier packets 2214 that it sends to one of its neighbor Clients, the Proxy/Server 2215 should mark the underlay path as unusable and use another underlay 2216 path. 2218 * When an AERO Proxy/Server receives link-layer Destination 2219 Unreachable messages in response to a carrier packet that it sends 2220 to one of its permanent neighbors, it treats the messages as an 2221 indication that the path to the neighbor may be failing. However, 2222 the dynamic routing protocol should soon reconverge and correct 2223 the temporary outage. 2225 When an AERO Gateway receives a carrier packet for which the network- 2226 layer destination address is covered by an MSP assigned to a black- 2227 hole route, the Gateway drops the packet if there is no more-specific 2228 routing information for the destination and returns an OMNI interface 2229 Destination Unreachable message subject to rate limiting. 2231 When an AERO node receives a carrier packet for which reassembly is 2232 currently congested, it returns an OMNI interface Packet Too Big 2233 (PTB) message as discussed in [I-D.templin-6man-omni] (note that the 2234 PTB messages could indicate either "hard" or "soft" errors). 2236 AERO nodes include ICMPv6 error messages intended for an OAL source 2237 as sub-options in the OMNI option of secured uNA messages. When the 2238 OAL source receives the uNA message, it can extract the ICMPv6 error 2239 message enclosed in the OMNI option and either process it locally or 2240 translate it into a network-layer error to return to the original 2241 source. 2243 3.12. AERO Mobility Service Coordination 2245 AERO nodes observes the Router Discovery and Prefix Registration 2246 specifications found in Section 15 of [I-D.templin-6man-omni]. AERO 2247 nodes further coordinate their autoconfiguration actions with the 2248 mobility service as discussed in the following sections. 2250 3.12.1. AERO Service Model 2252 Each AERO Proxy/Server on the OMNI link is configured to facilitate 2253 Client prefix delegation/registration requests. Each Proxy/Server is 2254 provisioned with a database of MNP-to-Client ID mappings for all 2255 Clients enrolled in the AERO service, as well as any information 2256 necessary to authenticate each Client. The Client database is 2257 maintained by a central administrative authority for the OMNI link 2258 and securely distributed to all Proxy/Servers, e.g., via the 2259 Lightweight Directory Access Protocol (LDAP) [RFC4511], via static 2260 configuration, etc. Clients receive the same service regardless of 2261 the Proxy/Servers they select. 2263 Clients associate each of their ANET/INET underlay interfaces with a 2264 FHS Proxy/Server. Each FHS Proxy/Server locally services one or more 2265 of the Client's underlay interfaces, and the Client typically selects 2266 one among them to serve as the Hub Proxy/Server (the Client may 2267 instead select a "third-party" Hub Proxy/Server that does not 2268 directly service any of its underlay interfaces). All of the 2269 Client's other FHS Proxy/Servers forward proxyed copies of RS/RA 2270 messages between the Hub Proxy/Server and Client without assuming the 2271 Hub role functions themselves. 2273 Each Client associates with a single Hub Proxy/Server at a time, 2274 while all other Proxy/Servers are candidates for providing the Hub 2275 role for other Clients. An FHS Proxy/Server assumes the Hub role 2276 when it receives an RS message with its own ULA or link-scoped All- 2277 Routers multicast as the destination. An FHS Proxy/Server assumes 2278 the proxy role when it receives an RS message with the ULA of another 2279 Proxy/Server as the destination. (An FHS Proxy/Server can also 2280 assume the proxy role when it receives an RS message addressed to 2281 link-scoped All-Routers multicast if it can determine the ULA of 2282 another Proxy/Server to serve as a Hub.) 2284 Hosts and Clients on ENET interfaces associate with an upstream 2285 Client on the ENET the same as a Client would associate with an ANET 2286 Proxy/Server. In particular, the Host/Client sends an RS message via 2287 the ENET which directs the message to the upstream Client. The 2288 upstream Client returns an RA message. In this way, the downstream 2289 nodes see the ENET as an ANET and see the upstream Client as a Proxy/ 2290 Server for that ANET. 2292 AERO Hosts, Clients and Proxy/Servers use IPv6 ND messages to 2293 maintain neighbor cache entries. AERO Proxy/Servers configure their 2294 OMNI interfaces as advertising NBMA interfaces, and therefore send 2295 unicast RA messages with a short Router Lifetime value (e.g., 2296 ReachableTime seconds) in response to a Client's RS message. 2297 Thereafter, Clients send additional RS messages to keep Proxy/Server 2298 state alive. 2300 AERO Clients and Hub Proxy/Servers include prefix delegation and/or 2301 registration parameters in RS/RA messages. The IPv6 ND messages are 2302 exchanged between the Client and Hub Proxy/Server (via any FHS Proxy/ 2303 Servers acting as proxys) according to the prefix management schedule 2304 required by the service. If the Client knows its MNP in advance, it 2305 can employ prefix registration by including its XLA-MNP as the source 2306 address of an RS message and with an OMNI option with valid prefix 2307 registration information for the MNP. If the Hub Proxy/Server 2308 accepts the Client's MNP assertion, it injects the MNP into the 2309 routing system and establishes the necessary neighbor cache state. 2310 If the Client does not have a pre-assigned MNP, it can instead employ 2311 prefix delegation by including a TLA as the source address of an RS 2312 message and with an OMNI option with prefix delegation parameters to 2313 request an MNP. 2315 The following sections outlines Host, Client and Proxy/Server 2316 behaviors based on the Router Discovery and Prefix Registration 2317 specifications found in Section 15 of [I-D.templin-6man-omni]. These 2318 sections observe all of the OMNI specifications, and include 2319 additional specifications of the interactions of Client-Proxy/Server 2320 RS/RA exchanges with the AERO mobility service. 2322 3.12.2. AERO Host and Client Behavior 2324 AERO Hosts and Clients discover the addresses of candidate Proxy/ 2325 Servers by resolving the Potential Router List (PRL) in a similar 2326 manner as described in [RFC5214]. Discovery methods include static 2327 configuration (e.g., a flat-file map of Proxy/Server addresses and 2328 locations), or through an automated means such as Domain Name System 2329 (DNS) name resolution [RFC1035]. Alternatively, the Host/Client can 2330 discover Proxy/Server addresses through a layer 2 data link login 2331 exchange, or through an RA response to a multicast/anycast RS as 2332 described below. In the absence of other information, the Host/ 2333 Client can resolve the DNS Fully-Qualified Domain Name (FQDN) 2334 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 2335 text string and "[domainname]" is a DNS suffix for the OMNI link 2336 (e.g., "example.com"). The name resolution returns a set of resource 2337 records with Proxy/Server address information. 2339 The Host/Client then performs RS/RA exchanges over each of its 2340 underlay interfaces to associate with (possibly multiple) FHS Proxy/ 2341 Serves and a single Hub Proxy/Server as specified in Section 15 of 2342 [I-D.templin-6man-omni]. The Host/Client then sends each RS (either 2343 directly via Direct interfaces, via a VPN for VPNed interfaces, via 2344 an access router for ANET interfaces or via INET encapsulation for 2345 INET interfaces) and waits up to RetransTimer milliseconds for an RA 2346 message reply (see Section 3.12.3) while retrying up to 2347 MAX_RTR_SOLICITATIONS if necessary. If the Host/Client receives no 2348 RAs, or if it receives an RA with Router Lifetime set to 0, the 2349 Client SHOULD abandon attempts through the first candidate Proxy/ 2350 Server and try another Proxy/Server. 2352 After the Host/Client registers its underlay interfaces, it may wish 2353 to change one or more registrations, e.g., if an interface changes 2354 address or becomes unavailable, if traffic selectors change, etc. To 2355 do so, the Host/Client prepares an RS message to send over any 2356 available underlay interface as above. The RS includes an OMNI 2357 option with prefix registration/delegation information and with an 2358 Interface Attributes sub-option specific to the selected underlay 2359 interface. When the Host/Client receives the Hub Proxy/Server's RA 2360 response, it has assurance that both the Hub and FHS Proxy/Servers 2361 have been updated with the new information. 2363 If the Host/Client wishes to discontinue use of a Hub Proxy/Server it 2364 issues an RS message over any underlay interface with an OMNI option 2365 with a prefix release indication (i.e., by setting the OMNI Neighbor 2366 Coordination sub-option Preflen to 0). When the Hub Proxy/Server 2367 processes the message, it releases the MNP, sets the NCE state for 2368 the Host/Client to DEPARTED and returns an RA reply with Router 2369 Lifetime set to 0. After a short delay (e.g., 2 seconds), the Hub 2370 Proxy/Server withdraws the MNP from the routing system. 2371 (Alternatively, when the Host/Client associates with a new FHS/Hub 2372 Proxy/Server it can include an OMNI "Proxy/Server Departure" sub- 2373 option in RS messages with the ULAs of the Old FHS/Hub Proxy/ 2374 Servers.) 2376 3.12.3. AERO Proxy/Server Behavior 2378 AERO Proxy/Servers act as both IP routers and IPv6 ND proxys, and 2379 support a prefix delegation/registration service for Clients. Proxy/ 2380 Servers arrange to add their ULAs to the PRL maintained in a static 2381 map of Proxy/Server addresses for the link, the DNS resource records 2382 for the FQDN "linkupnetworks.[domainname]", etc. before entering 2383 service. The PRL should be arranged such that Clients can discover 2384 the addresses of Proxy/Servers that are geographically and/or 2385 topologically "close" to their underlay network connections. 2387 When a FHS/Hub Proxy/Server receives a prospective Client's RS 2388 message, it SHOULD return an immediate RA reply with Router Lifetime 2389 set to 0 if it is currently too busy or otherwise unable to service 2390 the Client; otherwise, it processes the RS as specified in Section 15 2391 of [I-D.templin-6man-omni]. When the Hub Proxy/Server receives the 2392 RS, it determines the correct MNPs to provide to the Client by 2393 processing the XLA-MNP prefix parameters and/or the DHCPv6 OMNI sub- 2394 option. When the Hub Proxy/Server returns the MNPs, it also creates 2395 an XLA-MNP forwarding table entry for the MNP resulting in a BGP 2396 update (see: Section 3.2.3). The Hub Proxy/Server then returns an RA 2397 to the Client with destination set to the source of the RS (if an FHS 2398 Proxy/Server on the return path proxys the RA, it changes the 2399 destination to the Client's ULA-MNP). 2401 After the initial RS/RA exchange, the Hub Proxy/Server maintains a 2402 ReachableTime timer for each of the Client's underlay interfaces 2403 individually (and for the Client's NCE collectively) set to expire 2404 after ReachableTime seconds. If the Client (or an FHS Proxy/Server) 2405 issues additional RS messages, the Hub Proxy/Server sends an RA 2406 response and resets ReachableTime. If the Hub Proxy/Server receives 2407 an IPv6 ND message with a prefix release indication it sets the 2408 Client's NCE to the DEPARTED state and withdraws the MNP route from 2409 the routing system after a short delay (e.g., 2 seconds). If 2410 ReachableTime expires before a new RS is received on an individual 2411 underlay interface, the Hub Proxy/Server marks the interface as DOWN. 2412 If ReachableTime expires before any new RS is received on any 2413 individual underlay interface, the Hub Proxy/Server sets the NCE 2414 state to STALE and sets a 10 second timer. If the Hub Proxy/Server 2415 has not received a new RS or uNA message with a prefix release 2416 indication before the 10 second timer expires, it deletes the NCE and 2417 withdraws the XLA-MNP from the routing system. 2419 The Hub Proxy/Server processes any IPv6 ND messages pertaining to the 2420 Client while forwarding to the Client or responding on the Client's 2421 behalf as necessary. The Hub Proxy/Server may also issue unsolicited 2422 RA messages, e.g., with reconfigure parameters to cause the Client to 2423 renegotiate its prefix delegation/registrations, with Router Lifetime 2424 set to 0 if it can no longer service this Client, etc. The Hub 2425 Proxy/Server may also receive carrier packets via the secured 2426 spanning tree that contain initial data packets sent while route 2427 optimization is in progress. The Hub Proxy/Server reassembles, then 2428 re-encapsulates/re-fragments and forwards the packets to the target 2429 Client via an FHS Proxy/Server if necessary. Finally, If the NCE is 2430 in the DEPARTED state, the old Hub Proxy/Server forwards any carrier 2431 packets it receives from the secured spanning tree and destined to 2432 the Client to the new Hub Proxy/Server, then deletes the entry after 2433 DepartTime expires. 2435 Note: Clients SHOULD arrange to notify former Hub Proxy/Servers of 2436 their departures, but Hub Proxy/Servers are responsible for expiring 2437 neighbor cache entries and withdrawing XLA-MNP routes even if no 2438 departure notification is received (e.g., if the Client leaves the 2439 network unexpectedly). Hub Proxy/Servers SHOULD therefore set Router 2440 Lifetime to ReachableTime seconds in solicited RA messages to 2441 minimize persistent stale cache information in the absence of Client 2442 departure notifications. A short Router Lifetime also ensures that 2443 proactive RS/RA messaging between Clients and FHS Proxy/Servers will 2444 keep any NAT state alive (see above). 2446 Note: All Proxy/Servers on an OMNI link MUST advertise consistent 2447 values in the RA Cur Hop Limit, M and O flags, Reachable Time and 2448 Retrans Timer fields the same as for any link, since unpredictable 2449 behavior could result if different Proxy/Servers on the same link 2450 advertised different values. 2452 3.12.3.1. Additional Proxy/Server Considerations 2454 AERO Clients register with FHS Proxy/Servers for each underlay 2455 interface. Each of the Client's FHS Proxy/Servers must inform a 2456 single Hub Proxy/Server of the Client's underlay interface(s) that it 2457 services. For Clients on Direct and VPNed underlay interfaces, the 2458 FHS Proxy/Server for each interface is directly connected, for 2459 Clients on ANET underlay interfaces the FHS Proxy/Server is located 2460 on the ANET/INET boundary, and for Clients on INET underlay 2461 interfaces the FHS Proxy/Server is located somewhere in the connected 2462 Internetwork. When FHS Proxy/Server "B" processes a Client 2463 registration, it must either assume the Hub role or forward a proxyed 2464 registration to another Proxy/Server "A" acting as the Hub. Proxy/ 2465 Servers satisfy these requirements as follows: 2467 * when FHS Proxy/Server "B" receives a Client RS message, it first 2468 verifies that the OAL Identification is within the window for the 2469 NCE that matches the {UAL,XLA}-MNP in the RS source address for 2470 this Client neighbor and authenticates the message. If no NCE was 2471 found, Proxy/Server "B" instead creates one in the STALE state and 2472 caches the Client-supplied Interface Attributes, Origin Indication 2473 and OMNI Neighbor Coordination sub-option window synchronization 2474 parameters as well as the Client's observed L2 addresses (noting 2475 that they may differ from the Origin addresses if there were NATs 2476 on the path). Proxy/Server "B" then examines the RS destination 2477 address. If the destination address is the ULA of a different 2478 Proxy/Server "A", Proxy/Server "B" prepares a separate proxyed 2479 version of the RS message with an OAL header with source set to 2480 its own ULA and destination set to Proxy/Server B's ULA. Proxy/ 2481 Server "B" also writes its own information over the Interface 2482 Attributes sub-option supplied by the Client, omits or zeros the 2483 Origin Indication sub-option then forwards the message into the 2484 OMNI link secured spanning tree. 2486 * when Hub Proxy/Server "A" receives the RS, it assume the Hub role, 2487 delegates an MNP for the Client if necessary, and creates/updates 2488 a NCE indexed by the Client's XLA-MNP with FHS Proxy/Server "B"'s 2489 Interface Attributes as the link-layer address information for 2490 this FHS ifIndex. Hub Proxy/Server "A" then prepares an RA 2491 message with source set to its own ULA and destination set to the 2492 source of the RS message, then encapsulates the RA in an OAL 2493 header with source set to its own ULA and destination set to the 2494 ULA of FHS Proxy/Server "B". Hub Proxy/Server "A" then performs 2495 fragmentation if necessary and sends the resulting carrier packets 2496 into the secured spanning tree. 2498 * when FHS Proxy/Server "B" reassembles the RA, it locates the 2499 Client NCE based on the RA destination. If the RA message 2500 includes an OMNI "Proxy/Server Departure" sub-option, Proxy/Server 2501 "B" first sends a uNA to the old FHS/Hub Proxy/Servers named in 2502 the sub-option. If the RA message delegates a new XLA-MNP, Proxy/ 2503 Server "B" then resets the RA destination to the corresponding 2504 ULA-MNP for this interface. Proxy/Server "B" then re-encapsulates 2505 the message with OAL source set to its own ULA and OAL destination 2506 set to ULA that appeared in the Client's RS message OAL source, 2507 with an appropriate Identification value, with an authentication 2508 signature if necessary, with the Client's Interface Attributes 2509 sub-option echoed and with the cached observed L2 addresses 2510 written into an Origin Indication sub-option. Proxy/Server "B" 2511 sets the P flag in the RA flags field to indicate that the message 2512 has passed through a proxy [RFC4389], includes responsive window 2513 synchronization parameters, then fragments the RA if necessary and 2514 returns the fragments to the Client. 2516 * The Client repeats this process over each of its additional 2517 underlay interfaces while treating each additional FHS Proxy/ 2518 Server "C", "D", "E", etc. as a proxy to facilitate RS/RA 2519 exchanges between the Hub and the Client. The Client creates/ 2520 updates NCEs for each such FHS Proxy/Server as well as the Hub 2521 Proxy/Server in the process. 2523 After the initial RS/RA exchanges each FHS Proxy/Server forwards any 2524 of the Client's carrier packets with OAL destinations for which there 2525 is no matching NCE to a Gateway using OAL encapsulation with its own 2526 ULA as the source and with destination determined by the Client. The 2527 Proxy/Server instead forwards any carrier packets destined to a 2528 neighbor cache target directly to the target according to the OAL/ 2529 link-layer information - the process of establishing neighbor cache 2530 entries is specified in Section 3.13. 2532 While the Client is still associated with FHS Proxy/Servers "B", "C", 2533 "D", etc., each FHS Proxy/Server can send NS, RS and/or unsolicited 2534 NA messages to update the neighbor cache entries of other AERO nodes 2535 on behalf of the Client based on changes in Interface Attributes, 2536 Traffic Selectors, etc. This allows for higher-frequency Proxy- 2537 initiated RS/RA messaging over well-connected INET infrastructure 2538 supplemented by lower-frequency Client-initiated RS/RA messaging over 2539 constrained ANET data links. 2541 If the Hub Proxy/Server "A" ceases to send solicited RAs, FHS Proxy/ 2542 Servers "B", "C", "D" can send unsolicited RAs over the Client's 2543 underlay interface with destination set to (link-local) All-Nodes 2544 multicast and with Router Lifetime set to zero to inform Clients that 2545 the Hub Proxy/Server has failed. Although FHS Proxy/Servers "B", "C" 2546 and "D" can engage in IPv6 ND exchanges on behalf of the Client, the 2547 Client can also send IPv6 ND messages on its own behalf, e.g., if it 2548 is in a better position to convey state changes. The IPv6 ND 2549 messages sent by the Client include the Client's XLA-MNP as the 2550 source in order to differentiate them from the IPv6 ND messages sent 2551 by a FHS Proxy/Server. 2553 If the Client becomes unreachable over all underlay interface it 2554 serves, the Hub Proxy/Server sets the NCE state to DEPARTED and 2555 retains the entry for DepartTime seconds. While the state is 2556 DEPARTED, the Hub Proxy/Server forwards any carrier packets destined 2557 to the Client to a Gateway via OAL encapsulation. When DepartTime 2558 expires, the Hub Proxy/Server deletes the NCE, withdraws the XLA-MNP 2559 route and discards any further carrier packets destined to the former 2560 Client. 2562 In some ANETs that employ a Proxy/Server, the Client's MNP can be 2563 injected into the ANET routing system. In that case, the Client can 2564 send original IP packets without invoking the OAL so that the ANET 2565 routing system transports the original IP packets to the Proxy/ 2566 Server. This can be beneficial, e.g., if the Client connects to the 2567 ANET via low-end data links such as some aviation wireless links. 2569 If the ANET first-hop access router is on the same underlay link as 2570 the Client and recognizes the AERO/OMNI protocol, the Client can 2571 avoid OAL encapsulation for both its control and data messages. When 2572 the Client connects to the link, it can send an unencapsulated RS 2573 message with source address set to its own XLA-MNP (or to a TLA), and 2574 with destination address set to the ULA of the Client's selected 2575 Proxy/Server or to link-scoped All-Routers multicast. The Client 2576 includes an OMNI option formatted as specified in 2577 [I-D.templin-6man-omni]. The Client then sends the unencapsulated RS 2578 message, which will be intercepted by the AERO-aware ANET access 2579 router. 2581 The ANET access router then performs OAL encapsulation on the RS 2582 message and forwards it to a Proxy/Server at the ANET/INET boundary. 2583 When the access router and Proxy/Server are one and the same node, 2584 the Proxy/Server would share an underlay link with the Client but its 2585 message exchanges with outside correspondents would need to pass 2586 through a security gateway at the ANET/INET border. The method for 2587 deploying access routers and Proxys (i.e. as a single node or 2588 multiple nodes) is an ANET-local administrative consideration. 2590 Note: When a Proxy/Server alters the IPv6 ND message contents before 2591 forwarding (e.g., such as altering the OMNI option contents), the 2592 original IPv6 ND message checksum or authentication signature is 2593 invalidated, and a new checksum or authentication signature must be 2594 calculated and included. 2596 Note: When a Proxy/Server receives a secured Client NS message, it 2597 performs the same proxying procedures as for described for RS 2598 messages above. The proxying procedures for NS/NA message exchanges 2599 is specified in Section 3.13. 2601 3.12.3.2. Detecting and Responding to Proxy/Server Failures 2603 In environments where fast recovery from Proxy/Server failure is 2604 required, FHS Proxy/Servers SHOULD use proactive Neighbor 2605 Unreachability Detection (NUD) to track Hub Proxy/Server reachability 2606 in a similar fashion as for Bidirectional Forwarding Detection (BFD) 2607 [RFC5880]. Each FHS Proxy/Server can then quickly detect and react 2608 to failures so that cached information is re-established through 2609 alternate paths. The NS/NA control messaging is carried only over 2610 well-connected ground domain networks (i.e., and not low-end 2611 aeronautical radio links) and can therefore be tuned for rapid 2612 response. 2614 FHS Proxy/Servers perform continuous NS/NA exchanges with the Hub 2615 Proxy/Server, e.g., one exchange per second. The FHS Proxy/Server 2616 sends the NS message via the spanning tree with its own ULA as the 2617 source and the ULA of the Hub Proxy/Server as the destination, and 2618 the Hub Proxy/Server responds with an NA. When the FHS Proxy/Server 2619 is also sending RS messages to a Hub Proxy/Server on behalf of 2620 Clients, the resulting RA responses can be considered as equivalent 2621 hints of forward progress. This means that the FHS Proxy/Server need 2622 not also send a periodic NS if it has already sent an RS within the 2623 same period. If the Hub Proxy/Server fails (i.e., if the FHS Proxy/ 2624 Server ceases to receive advertisements), the FHS Proxy/Server can 2625 quickly inform Clients by sending unsolicited RA messages 2627 The FHS Proxy/Server sends unsolicited RA messages with source 2628 address set to the Hub Proxy/Server's address, destination address 2629 set to (link-local) All-Nodes multicast, and Router Lifetime set to 2630 0. The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA 2631 messages separated by small delays [RFC4861]. Any Clients that had 2632 been using the failed Hub Proxy/Server will receive the RA messages 2633 and select one of its other FHS Proxy/Servers to assume the Hub role 2634 (i.e., by sending an RS with destination set to the ULA of the new 2635 Hub). 2637 3.12.3.3. DHCPv6-Based Prefix Registration 2639 When a Client is not pre-provisioned with an MNP, it will need for 2640 the Hub Proxy/Server to select one or more MNPs on its behalf and set 2641 up the correct state in the AERO routing service. (A Client with a 2642 pre-provisioned MNP may also request the Hub Proxy/Server to select 2643 additional MNPs.) The DHCPv6 service [RFC8415] is used to support 2644 this requirement. 2646 When a Client needs to have the Hub Proxy/Server select MNPs, it 2647 sends an RS message with source address set to a TLA and with an OMNI 2648 option that includes a DHCPv6 message sub-option with DHCPv6 Prefix 2649 Delegation (DHCPv6-PD) parameters. When the Hub Proxy/Server 2650 receives the RS message, it extracts the DHCPv6-PD message from the 2651 OMNI option. 2653 The Hub Proxy/Server then acts as a "Proxy DHCPv6 Client" in a 2654 message exchange with the locally-resident DHCPv6 server, which 2655 delegates MNPs and returns a DHCPv6-PD Reply message. (If the Hub 2656 Proxy/Server wishes to defer creation of MN state until the DHCPv6-PD 2657 Reply is received, it can instead act as a Lightweight DHCPv6 Relay 2658 Agent per [RFC6221] by encapsulating the DHCPv6-PD message in a 2659 Relay-forward/reply exchange with Relay Message and Interface ID 2660 options.) 2662 When the Hub Proxy/Server receives the DHCPv6-PD Reply, it creates an 2663 XLA based on the delegated MNP adds an XLA-MNP route to the routing 2664 system. The Hub Proxy/Server then sends an RA back to the Client 2665 either directly or via an FHS Proxy/Server acting as a proxy. The 2666 Proxy/Server that returns the RA directly to the Client sets the 2667 (newly-created) ULA-MNP as the destination address and with the 2668 DHCPv6-PD Reply message and OMNI Neighbor Coordination sub-option 2669 Preflen coded in the OMNI option. When the Client receives the RA, 2670 it creates a default route, assigns the Subnet Router Anycast address 2671 and sets its {ULA,XLA}-MNP based on the delegated MNP. 2673 Note: Further details of the DHCPv6-PD based MNP registration (as 2674 well as a minimal MNP delegation alternative that avoids including a 2675 DHCPv6 message sub-option in the RS) are found in 2676 [I-D.templin-6man-omni]. 2678 Note: when the Hub Proxy/Server forwards an RA to the Client via a 2679 different node acting as a FHS Proxy/Server, the Hub sets the RA 2680 destination to the same address that appeared in the RS source. The 2681 FHS Proxy/Server then subsequently sets the RA destination to the 2682 ULA-MNP when it forwards the Proxyed version of the RA to the Client 2683 - see [I-D.templin-6man-omni] for further details. 2685 3.13. AERO Address Resolution, Multilink Forwarding and Route 2686 Optimization 2688 AERO nodes invoke address resolution, multilink forwarding and route 2689 optimization when they need to forward initial packets to new 2690 neighbors over ANET/INET interfaces and for ongoing multilink 2691 forwarding coordination with existing neighbors. Address resolution 2692 is based on an IPv6 ND NS/NA(AR) messaging exchange between an 2693 Address Resolution Source (ARS) and the target neighbor as the 2694 Address Resolution Target (ART). Either the ART itself or the ART's 2695 current Hub Proxy/Server serves as the Address Resolution Responder 2696 (ARR). 2698 Address resolution is initiated by the first eligible ARS closest to 2699 the original source as follows: 2701 * For Clients on VPNed and Direct interfaces, the Client's FHS 2702 Proxy/Server is the ARS. 2704 * For Clients on ANET interfaces, either the Client or the FHS 2705 Proxy/Server may be the ARS. 2707 * For Clients on INET interfaces, the Client itself is the ARS. 2709 * For correspondent nodes on INET/ENET interfaces serviced by a 2710 Relay, the Relay is the ARS. 2712 * For Clients that engage the Hub Proxy/Server in "mobility anchor" 2713 mode, the Hub Proxy/Server is the ARS. 2715 * For peers within the same ANET/ENET, route optimization is through 2716 receipt of Redirect messages. 2718 The AERO routing system directs an address resolution request sent by 2719 the ARS to the ARR. The ARR then returns an address resolution reply 2720 which must include information that is current, consistent and 2721 authentic. Both the ARS and ARR are then jointly responsible for 2722 periodically refreshing the address resolution, and for quickly 2723 informing each other of any changes. Following address resolution, 2724 the ARS and ART perform continuous unicast multilink forwarding and 2725 route optimization exchanges to maintain optimal forwarding profiles. 2727 The address resolution, multilink forwarding and route optimization 2728 procedures are specified in the following sections. 2730 3.13.1. Multilink Address Resolution 2732 When one or more original IP packets from a source node destined to a 2733 target node arrives, the ARS checks for a NCE with an XLA-MNP that 2734 matches the target destination. If there is a NCE in the REACHABLE 2735 state, the ARS invokes the OAL and forwards the resulting carrier 2736 packets according to the cached state then returns from processing. 2738 Otherwise, if there is no NCE the ARS creates one in the INCOMPLETE 2739 state. The ARS then prepares an NS message for Address Resolution 2740 (NS(AR)) to send toward an ART while including the original IP 2741 packet(s) as trailing data following the NS(AR) in an OAL super- 2742 packet [I-D.templin-6man-omni]. The resulting NS(AR) message must be 2743 sent securely, and includes: 2745 * the ULA of the ARS as the source address. 2747 * the XLA corresponding to the original IP packet's destination as 2748 the Target Address, e.g., for 2001:db8:1:2::10:2000 the Target 2749 Address is fd00::2001:db8:1:2. 2751 * the Solicited-Node multicast address [RFC4291] formed from the 2752 lower 24 bits of the original IP packet's destination as the 2753 destination address, e.g., for 2001:db8:1:2::10:2000 the NS(AR) 2754 destination address is ff02:0:0:0:0:1:ff10:2000. 2756 The NS(AR) message also includes an OMNI option with an 2757 authentication sub-option if necessary and with an OMNI Neighbor 2758 Coordination sub-option with Preflen set to the prefix length 2759 associated with the NS(AR) source. The ARS also includes Interface 2760 Attributes and/or Traffic Selectors for all of the source Client's 2761 underlay interfaces, calculates the authentication signature or 2762 checksum, includes window synchronization parameters then submits the 2763 NS(AR) message for OAL encapsulation. The ARS sets the OAL source to 2764 its own ULA and sets the OAL destination according to the Client's RS 2765 message Neighbor Coordination 'U' flag (see: 2766 [I-D.templin-6man-omni]). If the 'U' flag was set, the ARS sets the 2767 OAL destination to the ULA of its Hub Proxy/Server which maintains a 2768 Report List; otherwise, the ARS sets the destination to the XLA-MNP 2769 corresponding to the ART. The ARS then selects an identification 2770 value, inserts a fragment header, calculates the OAL checksum, 2771 performs fragmentation and L2 encapsulation, then sends the resulting 2772 carrier packets into the SRT secured spanning tree without 2773 decrementing the network-layer TTL/Hop Limit field. 2775 When the ARS is a Client, it must instead use the ULA of one of its 2776 FHS Proxy/Servers as the OAL destination. The ARS Client then 2777 fragments, performs L2 encapsulation and forwards the carrier packets 2778 to the FHS Proxy/Server. The FHS Proxy/Server then reassembles, 2779 verifies the NS(AR) authentication signature or checksum, changes the 2780 OAL source to its own ULA and changes the OAL destination to the ULA 2781 of the Hub Proxy/Server or XLA-MNP corresponding to the ART as 2782 specified above. The FHS Proxy/Server then selects an appropriate 2783 Identification, calculates the OAL checksum, re-fragments and 2784 forwards the resulting carrier packets into the secured spanning tree 2785 on behalf of the Client. 2787 Note: both the source and target Client/Relay and their Hub Proxy/ 2788 Servers include current and accurate information for their multilink 2789 Interface Attributes profile. The Hub Proxy/Servers can be trusted 2790 to provide an authoritative ARR response and/or mobility update 2791 message on behalf of the source/target should the need arise. While 2792 the source or target itself has no such trust basis, any attempt to 2793 mount an attack by providing false Interface Attributes information 2794 would only result in black-holing of return traffic, i.e., the 2795 "attack" could only result in denial of service to the source/target 2796 itself. Therefore, the source/target's asserted Interface Attributes 2797 need not be validated by the Hub Proxy/Server. 2799 3.13.1.1. ARS Hub Proxy/Server NS(AR) Processing 2801 If the ARS Client's Hub Proxy/Server maintains a Report List, the 2802 carrier packets containing the NS(AR) will first arrive at the at the 2803 Hub due to the OAL destination address supplied by the ARS (see 2804 above). This source Hub then discards the L2 headers, reassembles 2805 then records the NS Target Address in the Report List for this source 2806 Client. The Hub then leaves the OAL source address unchanged, but 2807 changes the OAL destination address to the XLA corresponding to the 2808 NS Target Address. The Hub then decrements the OAL header Hop Limit, 2809 includes an appropriate Identification, recalculates the OAL 2810 checksum, refragments, and sends the resulting carrier packets into 2811 the secured spanning tree. 2813 3.13.1.2. Relaying the NS(AR) 2815 When a Gateway receives carrier packets containing the NS(AR), it 2816 discards the L2 headers and determines the next hop by consulting its 2817 standard IPv6 forwarding table for the OAL header XLA destination 2818 address. The Gateway next decrements the OAL header Hop Limit, then 2819 includes new L2 headers and forwards the carrier packet(s) via the 2820 secured spanning tree the same as for any IPv6 router, where they may 2821 traverse multiple OMNI link segments. The final-hop Gateway will 2822 deliver the carrier packets via the secured spanning tree to the Hub 2823 Proxy/Server (or Relay) that services the ART. 2825 3.13.1.3. NS(AR) Processing at the ARR/ART 2827 When the ART's Hub Proxy/Server receives the NS(AR) secured carrier 2828 packets with the XLA-MNP of the ART as the OAL destination, it 2829 discards the L2 headers, reassembles, verifies the OAL checksum then 2830 either forwards the NS(AR) to the ART or processes it locally if it 2831 is acting as a Relay or as the ART's designated ARR. The Hub Proxy/ 2832 Server processes the message as follows: 2834 * if the NS(AR) target matches a Client NCE in the DEPARTED state, 2835 the (old) Hub Proxy/Server resets the OAL destination address to 2836 the ULA of the Client's new Hub Proxy/Server. The old Hub Proxy/ 2837 Server then decrements the OAL header Hop Limit, recalculates the 2838 OAL checksum, re-fragments, includes appropriate L2 headers then 2839 forwards the resulting carrier packets over the secured spanning 2840 tree. 2842 * If the NS(AR) target matches a Client NCE in the REACHABLE state, 2843 the Hub Proxy/Server notes whether the NS(AR) arrived from the 2844 secured spanning tree. If the message arrived via the secured 2845 spanning tree the Hub Proxy/Server verifies the NS checksum; 2846 otherwise, it must verify the message authentication signature. 2848 If the Hub Proxy/Server maintains a Report List for the ART, it 2849 next records the NS source address in the Report List for this 2850 ART. If the Hub Proxy/Server is the ART's designated ARR, it 2851 prepares to return an NA(AR) as discussed below; otherwise, the 2852 Hub Proxy/Server determines the underlay interface for the ART and 2853 proceeds as follows: 2855 - If the Hub Proxy/Server is also the FHS Proxy/Server on the 2856 underlay interface used to convey the NS(AR) to the ART, it 2857 either recalculates the NS(AR) checksum or includes an 2858 authentication signature as necessary. The Hub then changes 2859 the OAL source to its own ULA and OAL destination to the ULA- 2860 MNP of the ART, decrements the OAL Hop Limit, includes a 2861 suitable identification value, recalculates the OAL checksum, 2862 re-fragments if necessary, includes appropriate L2 headers and 2863 forwards the resulting carrier packets over the underlay 2864 interface to the ART. 2866 - If the Hub Proxy/Server is not the FHS Proxy/Server on the 2867 underlay interface used to convey the NS(AR) to the ART, it 2868 instead recalculates the NS(AR) checksum, changes the OAL 2869 source to its own ULA and changes the OAL destination to the 2870 ULA of the FHS Proxy/Server for this ART interface. The Hub 2871 Proxy/Server next decrements the OAL Hop Limit, includes a 2872 suitable Identification value, recalculates the OAL checksum, 2873 re-fragments if necessary, includes appropriate L2 headers and 2874 forwards the resulting carrier packets over the secured 2875 spanning tree. 2877 - When the FHS Proxy/Server receives the carrier packets, it 2878 reassembles and verifies the OAL and NS(AR) checksums, then 2879 forwards to the ART the same as described above. 2881 * If the NS(AR) target matches one of its non-MNP routes, the Hub 2882 Proxy/Server serves as both a Relay and an ARR, since the Relay 2883 forwards IP packets toward the (fixed network) target at the 2884 network layer. 2886 If the ARR is a Relay or the ART itself, it first creates or updates 2887 a NCE for the NS(AR) source address while processing the window 2888 synchronization parameters and caching all Interface Attributes and 2889 Traffic Selector information. Next, the ARR prepares a (solicited) 2890 NA(AR) message to return to the ARS with the source address set to 2891 the ART's XLA, the destination address set to the NS(AR) ULA source 2892 address and the Target Address set to the same value that appeared in 2893 the NS(AR) Target Address. The ARR includes an OMNI option with OMNI 2894 Neighbor Coordination sub-option Preflen set to the prefix length 2895 associated with the NA(AR) source address. 2897 The ARR then includes Interface Attributes and Traffic Selector sub- 2898 options for all of the ART's underlay interfaces with current 2899 information for each interface. The ARR also includes either an 2900 authentication signature or an NA message checksum as necessary. The 2901 ARR next sets the NA(AR) message R flag to 1 (as a router) and S flag 2902 to 1 (as a response to a solicitation) and sets the O flag to 1 (as 2903 an authoritative responder). The ARR then submits the NA(AR) for OAL 2904 encapsulation with source set to its own ULA and destination set to 2905 the ULA that appeared in the NS(AR) OAL source, selects an 2906 appropriate Identification, and includes window synchronization 2907 parameters if necessary. The ARR then includes an authentication 2908 signature or checksum, calculates the OAL checksum, fragments, 2909 includes appropriate L2 headers and forwards the resulting 2910 (L2-encapsulated) carrier packets. 2912 When the Proxy/Server for the ART receives the carrier packets sent 2913 by an ART acting as an ARR on its own behalf, it reassembles if 2914 necessary, verifies the authentication signature or checksum and 2915 includes a new authentication signature or checksum. The Proxy/ 2916 Server then changes the OAL source address to its own ULA, changes 2917 the OAL destination to the ULA corresponding to the NA(AR) 2918 destination, decrements the OAL Hop Limit, includes an appropriate 2919 Identification, recalculates the NA and OAL checksums and fragments 2920 if necessary. The Proxy/Server finally includes appropriate L2 2921 headers and forwards the carrier packets into the secured spanning 2922 tree. 2924 Note: If the Hub Proxy/Server is acting as the ARR but not as a 2925 Relay, it prepares the NA(AR) with the R flag set to 0 but without 2926 setting the SYN/ACK flags in the OMNI Neighbor Coordination sub- 2927 option window synchronization parameters. This informs the ARS that 2928 it must initiate multilink route optimization to synchronize with the 2929 target either directly or via an LHS Proxy/Server (see: 2930 Section 3.13.2). In all other ways, the Hub Proxy/Server prepares 2931 and returns the NA(AR) the same as for the ART Proxy/Server case 2932 above. 2934 3.13.1.4. Relaying the NA(AR) 2936 When a Gateway receives NA(AR) carrier packets, it discards the L2 2937 headers and determines the next hop by consulting its standard IPv6 2938 forwarding table for the OAL header destination address. The Gateway 2939 then decrements the OAL header Hop Limit, re-encapsulates the carrier 2940 packets with new L2 headers and forwards them via the SRT secured 2941 spanning tree where they may traverse multiple OMNI link segments. 2942 The final-hop Gateway will deliver the carrier packets via the 2943 secured spanning tree to a Proxy/Server for the ARS. 2945 3.13.1.5. Processing the NA(AR) at the ARS 2947 When the ARS receives the NA(AR) message, it first searches for a NCE 2948 that matches the NA(AR) target address. The ARS then processes the 2949 message the same as for standard IPv6 Address Resolution [RFC4861]. 2950 In the process, it caches all OMNI option information in the NCE for 2951 the ART (including Interface Attributes, Traffic Selectors, etc.), 2952 and caches the NA(AR) XLA source address as the address of the ART. 2954 When the ARS is a Client, the SRT secured spanning tree will first 2955 deliver the solicited NA(AR) message to the FHS Proxy/Server, which 2956 re-adjusts the OAL header and forwards the message to the Client. If 2957 the Client is on a well-managed ANET, physical security and protected 2958 spectrum ensures security for the NA(AR) without needing an 2959 additional authentication signature; if the Client is on the open 2960 INET the Proxy/Server must instead include an authentication 2961 signature (while adjusting the OMNI option size, if necessary). The 2962 Proxy/Server uses its own ULA as the OAL source and the ULA-MNP of 2963 the Client as the OAL destination when it forwards the NA(AR). The 2964 Proxy/Server then decrements the OAL Hop Limit, includes an 2965 appropriate Identification, recalculates the OAL checksum, re- 2966 fragments, includes appropriate L2 headers and forwards the carrier 2967 packets over the underlay interface to the Client. 2969 3.13.1.6. Reliability 2971 After the ARS transmits the first NS(AR), it should wait up to 2972 RETRANS_TIMER seconds to receive a responsive NA(AR). The ARR can 2973 then retransmit the NS(AR) up to MAX_UNICAST_SOLICIT times before 2974 giving up. 2976 3.13.2. Multilink Forwarding 2978 Following address resolution, the ARS and ART can assert multilink 2979 forwarding paths through underlay interface pairs serviced by the 2980 same source/destination ULAs by sending unicast NS/NA messages with 2981 OMNI AERO Forwarding Parameter (AFP) and/or Neighbor Coordination 2982 sub-options. The unicast NS/NA messages establish multilink 2983 forwarding state in OAL intermediate nodes in the path between the 2984 ARS and ART. Note that either the ARS or ART can independently 2985 initiate multilink forwarding by sending unicast NS messages on 2986 behalf of specific underlay interface pairs. 2988 Nodes that configure OMNI interfaces include an additional forwarding 2989 table termed the AERO Forwarding Information Base (AFIB) that 2990 supports carrier packet forwarding based on OMNI neighbor underlay 2991 interface pairs. The AFIB contains AERO Forwarding Vectors (AFVs) 2992 identified by locally-unique 4-octet values known as AFV Indexes 2993 (AFVIs). The AFVs cache uncompressed OAL header information as well 2994 as the previous/next-hop addressing and AFVI information. 2996 OAL source, intermediate and target nodes create AFVs/AFVIs when they 2997 process an NS message with an AFP sub-option with Job code '00' 2998 (Initialize; Build B) or a solicited NA message with Job code '01' 2999 (Follow B; Build A) (see: [I-D.templin-6man-omni]). The OAL source 3000 of the NS (which is also the OAL destination of the solicited NA) is 3001 considered to reside in the "First Hop Segment (FHS)", while the OAL 3002 destination of the NS (which is also the OAL source of the solicited 3003 NA) is considered to reside in the "Last Hop Segment (LHS)". 3005 The FHS and LHS roles are determined on a per-interface-pair basis. 3006 After address resolution, either peer is equally entitled to initiate 3007 multilink forwarding on behalf of a specific FHS/LHS underlay 3008 interface pair. The peer that sends the initiating NS with Job code 3009 '00' message for a specific pair becomes the FHS peer while the one 3010 that returns the NA response becomes the LHS peer for that pair only. 3011 It is therefore quite possible (and even commonplace) that both peers 3012 may assume the FHS role for some pairs while assuming the LHS role 3013 for other pairs, i.e., even though each peer maintains only a single 3014 NCE. 3016 When an OAL node initiates or forwards an NS with Job code '00', it 3017 creates an AFV, records the NS source and destination ULAs then 3018 generates and assigns a locally-unique "B" AFVI (while also caching 3019 the "B" values for all previous OAL hops on the path from the FHS OAL 3020 source). When the OAL node receives future carrier packets that 3021 include "B", it can unambiguously locate the correct AFV and 3022 determine directionality without examining addresses. When the AFV 3023 is indexed by its "B" AFVI, it returns the ULAs in (dst,src) order 3024 the opposite of how they appeared in the OAL header of the original 3025 NS to support full header reconstruction for reverse-path forwarding. 3026 (If the NS message included a nested OAL encapsulation, the ULAs of 3027 both OAL headers are returned.) 3029 When an OAL node initiates or forwards a solicited NA with Job code 3030 '01', it uses the "B" AFVI to locate the AFV created by the NS then 3031 generates and assigns a locally-unique "A" AFVI (while also caching 3032 the "A" values for all previous OAL hops on the path from the LHS OAL 3033 source). When the OAL node receives future carrier packets that 3034 include "A", it can unambiguously locate the correct AFV and 3035 determine directionality without examining addresses. When the AFV 3036 is indexed by its "A" AFVI, it returns the ULAs in (src,dst) order 3037 the same as they appeared in the OAL header of the original NS to 3038 support full header reconstruction for forward-path forwarding. (If 3039 the NS message included a nested OAL encapsulation, the ULAs of both 3040 OAL headers are returned.) 3042 OAL nodes generate random non-zero 32-bit values as candidate AFVIs 3043 which must first be tested for local uniqueness. If a candidate AFVI 3044 s already in use, the OAL node repeats the random generation process 3045 until it obtains a unique non-zero value. Since the number of AFVs 3046 in service at each OAL node is likely to be much smaller than 2**32, 3047 the process will generate a unique value after a small number of 3048 tries. Since the uniqueness property is node-local only, an AFVI 3049 locally generated by a first OAL node must not be tested for 3050 uniqueness by other OAL nodes. 3052 OAL nodes cache AFVs for up to ReachableTime seconds following their 3053 initial creation. If the node processes another NS or NA message 3054 specific to an AFV, it resets ReachableTime to REACHABLE_TIME 3055 seconds, i.e., the same as for NCEs. If ReachableTime expires, the 3056 node deletes the AFV and frees its associated AFVIs so they can be 3057 reused for future AFVs. 3059 The following sections provide the detailed specifications of these 3060 NS/NA exchanges for all nodes along the forward and reverse paths. 3062 3.13.2.1. FHS Client-Proxy/Server NS Forwarding 3064 When an FHS OAL source has an original IP packet to send to an LHS 3065 OAL target following multilink address resolution, it first selects a 3066 source and target underlay interface pair. The FHS source uses its 3067 cached information for the target underlay interface as LHS 3068 information then prepares an NS message with an AFP sub-option with 3069 Job code '00' and with the NS source set to its own ULA or XLA and 3070 the NS destination set to the ULA or XLA of the LHS target. The FHS 3071 source then sets window synchronization information in the OMNI 3072 Neighbor Coordination sub-option and creates a NCE for the selected 3073 target ULA or XLA in the INCOMPLETE state. The FHS source next 3074 creates an AFV then generates and assigns a locally-unique "B" AFVI 3075 to the AFV while also including it as the first "B" entry in the AFP 3076 AFVI List. The FHS source then includes any FHS/LHS addressing 3077 information it knows locally in the AFP sub-option, i.e., based on 3078 information discovered through address resolution. 3080 If the FHS source is the FHS Proxy/Server, it then examines the LHS 3081 FMT code. If FMT-Forward is clear and FMT-Mode is set, the FHS 3082 Proxy/Server checks for a NCE for the ULA of the LHS Proxy/Server. 3083 If there is no NCE, the FHS Proxy/Server creates one in the 3084 INCOMPLETE state. If a new NCE was created (or if the existing NCE 3085 requires fresh window synchronization), the FHS Proxy/Server then 3086 writes window synchronization parameters into the AFP Tunnel Window 3087 Synchronization fields. The FHS Proxy/Server then performs OAL 3088 encapsulation while setting the OAL source to its own ULA and setting 3089 the OAL destination to the FHS Subnet Router Anycast ULA determined 3090 by applying the FHS SRT prefix length to its ULA. The FHS Proxy/ 3091 Server then selects an appropriate Identification value, calculates 3092 the OAL checksum, fragments if necessary, encapsulates in appropriate 3093 L2 headers then forwards the carrier packets into the secured 3094 spanning tree which will deliver them to a Gateway interface that 3095 assigns the FHS Subnet Router Anycast ULA. 3097 If the FHS source is the FHS Client, it instead includes an 3098 authentication signature if necessary. If FHS FMT-Forward is set and 3099 LHS FMT-Forward is clear, the FHS Client creates/updates a NCE for 3100 the ULA of the LHS Proxy/Server as above and includes Tunnel Window 3101 Synchronization parameters. The FHS Client then performs OAL 3102 encapsulation, sets the OAL source to its own ULA-MNP and sets the 3103 OAL destination to the ULA of the FHS Proxy/Server. The FHS Client 3104 finally selects an appropriate Identification value for the FHS 3105 Proxy/Server, calculates the OAL checksum, fragments if necessary, 3106 encapsulates in appropriate L2 headers then forwards the carrier 3107 packets to the FHS Proxy/Server. 3109 When the FHS Proxy/Server receives the carrier packets, it verifies 3110 the Identification then reassembles to obtain the NS, verifies the 3111 OAL checksum and verifies the NS authentication signature or 3112 checksum. The FHS Proxy/Server then creates an AFV (i.e., the same 3113 as the FHS Client had done) while caching the AFP AFVI List "B" entry 3114 along with the FHS Client addressing information as previous hop 3115 information for this AFV. The FHS Proxy/Server next generates a new 3116 locally-unique "B" AFVI, then both assigns it as the AFV index and 3117 writes it as the next "B" entry in the AFP AFVI List (while also 3118 writing any FHS Client and Proxy/Server addressing information). The 3119 FHS Proxy/Server then checks FHS/LHS FMT-Forward/Mode to determine 3120 whether to create a NCE for the LHS Proxy/Server ULA and include 3121 Tunnel Window Synchronization parameters the same as above. The FHS 3122 Proxy/Server then calculates the NS checksum and sets the OAL source 3123 address to its own ULA and destination address to the FHS Subnet 3124 Router Anycast ULA. The FHS Proxy/Server finally decrements the OAL 3125 Hop Limit, includes an Identification appropriate for the secured 3126 spanning tree, calculates the OAL checksum and re-fragments if 3127 necessary. The FHS Proxy/Server finally includes appropriate L2 3128 headers and forwards the carrier packets into the secured spanning 3129 tree. 3131 3.13.2.2. Gateway NS Forwarding 3133 Gateways in the spanning tree forward carrier packets not explicitly 3134 addressed to themselves, while forwarding those that arrived via the 3135 secured spanning tree to the next hop also via the secured spanning 3136 tree and forwarding all others via the unsecured spanning tree. When 3137 an FHS Gateway receives a carrier packet over the secured spanning 3138 tree addressed to its ULA or the FHS Subnet Router Anycast ULA, it 3139 instead reassembles to obtain the NS then verifies the OAL and NS 3140 checksums. The FHS Gateway next creates an AFV (i.e., the same as 3141 the FHS Proxy/Server had done) while caching the AFP FHS Client and 3142 Proxy/Server addressing information and corresponding AFVI List "B" 3143 list values in the AFV to enable future reverse path forwarding to 3144 this FHS Client. The FHS Gateway then generates a locally-unique "B" 3145 AFVI for the AFV and also writes it as the next "B" entry in the NS 3146 AFP AFVI List. 3148 The FHS Gateway then examines the SRT prefixes corresponding to both 3149 FHS and LHS. If the FHS Gateway has a local interface connection to 3150 both the FHS and LHS (whether they are the same or different 3151 segments), the FHS/LHS Gateway caches the NS AFP LHS information in 3152 the AFV, writes its LHS ULA and L2ADDR into the NS AFP LHS fields, 3153 then sets its LHS ULA as the OAL source and the ULA of the LHS Proxy/ 3154 Server as the OAL destination. If the FHS and LHS prefixes are 3155 different, the FHS Gateway instead sets its FHS ULA as the OAL source 3156 and the LHS Subnet Router Anycast ULA as the OAL destination. The 3157 FHS Gateway then decrements the OAL Hop Limit, selects an appropriate 3158 Identification, recalculates the NS and OAL checksums, re-fragments 3159 if necessary, then finally includes appropriate L2 headers and 3160 forwards the carrier packets into the secured spanning tree. 3162 When the FHS and LHS Gateways are different, the LHS Gateway will 3163 receive carrier packets over the secured spanning tree from the FHS 3164 Gateway, noting there may be many intermediate Gateways in the path 3165 between FHS and LHS which will simply forward the carrier packets 3166 without further processing. The LHS Gateway then reassembles to 3167 obtain the NS, verifies the OAL and NS checksums then creates an AFV 3168 (i.e., the same as the FHS Gateway had done) while caching the AFP 3169 "B" AFVIs and addressing information of previous OAL forwarding hops. 3170 In particular, the LHS Gateway caches the ULA of the FHS Gateway as 3171 the spanning tree address for the previous-hop, caches the LHS 3172 information then generates a locally-unique "B" AFVI for the AFV. 3173 The LHS Gateway then writes its own LHS ULA and L2ADDR into the AFP 3174 sub-option while also writing "B" as the next entry in the AFP AFVI 3175 List. The LHS Gateway then sets its own ULA as the OAL source and 3176 the ULA of the LHS Proxy/Server as the OAL destination, decrements 3177 the OAL Hop Limit selects an appropriate Identification, recalculates 3178 the NS and OAL checksums, re-fragments if necessary, then finally 3179 includes appropriate L2 headers and forwards the carrier packets into 3180 the secured spanning tree. 3182 3.13.2.3. LHS Proxy/Server-Client NS Receipt and NA Forwarding 3184 When the LHS Proxy/Server receives the carrier packets from the 3185 secured spanning tree, it reassembles to obtain the NS, verifies the 3186 OAL and NS checksums then verifies that the LHS information supplied 3187 by the FHS source is consistent with its own cached information. If 3188 the information is consistent, the LHS Proxy/Server then creates an 3189 AFV and caches the AFP "B" AFVIs and addressing information of 3190 previous OAL forwarding hops the same as for the prior hop. If the 3191 NS destination is the XLA of the LHS Client, the LHS Proxy/Server 3192 also generates a locally-unique "B" AFVI and assigns it both to the 3193 AFVI and as the next "B" entry in the AFVI List. The LHS Proxy/ 3194 Server then examines FHS FMT; if FMT-Forward is clear and FMT-Mode is 3195 set, the LHS Proxy/Server creates a NCE for the ULA of the FHS Proxy/ 3196 Server (if necessary) and sets the state to STALE, then caches any 3197 Tunnel Window Synchronization parameters. 3199 If the NS destination matches its own ULA, the LHS Proxy/Server next 3200 prepares to return a solicited NA with Job code '01'. If the NS 3201 source was the XLA of the FHS Client, the LHS Proxy/Server first 3202 creates or updates an NCE for the XLA with state set to STALE. The 3203 LHS Proxy/Server next caches the NS OMNI Neighbor Coordination sub- 3204 option window synchronization parameters and AFP information 3205 (including the AFVI List) in the NCE corresponding to the ULA source. 3206 When the LHS Proxy/Server forwards future carrier packets based on 3207 the NCE, it can populate forwarding information in a CRH-32 routing 3208 header to enable forwarding based on the cached AFVI List "B" entries 3209 instead of ULA addresses. 3211 The LHS Proxy/Server then creates an NA with Job code '01' while 3212 copying the NS AFP sub-option into the NA. The LHS Proxy/Server then 3213 generates a locally-unique "A" AFVI and both assigns it to the AFV 3214 and includes it as the first "A" entry in the AFP sub-option AFVI 3215 List (see: [I-D.templin-6man-omni] for details on AFVI List A/B 3216 processing). The LHS Proxy/Server then includes end-to-end window 3217 synchronization parameters in the OMNI Neighbor Coordination sub- 3218 option (if necessary) and also tunnel window synchronization 3219 parameters in the AFP sub-option (if necessary). The LHS Proxy/ 3220 Server then encapsulates the NA with OAL source set to its own ULA 3221 and OAL destination set to the ULA of the LHS Gateway. The LHS 3222 Proxy/Server then selects an appropriate Identification value, 3223 calculates the NA and OAL checksums, fragments if necessary then 3224 finally includes appropriate L2 headers and forwards the carrier 3225 packets into the secured spanning tree. 3227 If the NS destination was the XLA of the LHS Client, the LHS Proxy/ 3228 Server instead includes an authentication signature in the NS if 3229 necessary (otherwise recalculates the checksum), then changes the OAL 3230 source to its own ULA and changes the OAL destination to the ULA-MNP 3231 of the LHS Client. The LHS Proxy/Server then decrements the OAL Hop 3232 Limit, selects an appropriate Identification value, calculates the 3233 OAL checksum, fragments if necessary then finally includes 3234 appropriate L2 headers and forwards the carrier packets to the LHS 3235 Client. When the LHS Client receives the carrier packets, it 3236 verifies the Identification and reassembles to obtain the NS then 3237 verifies the OAL checksum and NS authentication signature or 3238 checksum. The LHS Client then creates a NCE for the NS ULA source 3239 address in the STALE state and examines the AFP sub-option. If LHS 3240 FMT-Forward is set, FHS FMT-Forward is clear and the NS source was an 3241 XLA, the Client also creates a NCE for the ULA of the FHS Proxy/ 3242 Server in the STALE state and caches any Tunnel Window 3243 Synchronization parameters. The Client then caches the NS OMNI 3244 Neighbor Coordination and AFP sub-options in the NCE corresponding to 3245 the NS ULA source, then creates an AFV, caches the addressing 3246 information and "B" entries of the previous OAL hops then finally 3247 generates and assigns a locally-unique "A" AFVI the same as for 3248 previous hops. 3250 The LHS Client then prepares an NA using exactly the same procedures 3251 as for the LHS Proxy/Server above, except that it uses its XLA as the 3252 NA source and the NS source as the NA destination. The LHS Client 3253 also includes an authentication signature if necessary (otherwise 3254 calculates the checksum), then encapsulates the NA with OAL source 3255 set to its own ULA-MNP and OAL destination set to the ULA of the LHS 3256 Proxy/Server. The LHS Client finally includes an appropriate 3257 Identification, calculates the OAL checksum, fragments if necessary 3258 then includes appropriate L2 headers and forwards the carrier packets 3259 to the LHS Proxy/Server. When the LHS Proxy/Server receives the 3260 carrier packets, it verifies the Identifications, reassembles to 3261 obtain the NA, verifies the OAL checksum and NA authentication 3262 signature or checksum, then uses the current AFP AFVI List "B" entry 3263 to locate the AFV. The LHS Proxy/Server then caches the addressing 3264 and "A" information for the LHS Client in the AFV, then generates a 3265 locally-unique "A" AFVI and both assigns it to the AFV and writes it 3266 as the next AFP AFVI List "A" entry. The LHS Proxy/Server then 3267 examines the FHS/LHS FMT codes to determine if it needs to include 3268 Tunnel Window Synchronization parameters. The LHS Proxy/Server then 3269 calculates the NA checksum, sets the OAL source to its own ULA and 3270 destination to the ULA of the LHS Gateway, decrements the OAL Hop 3271 Limit, includes an appropriate Identification, calculates the OAL 3272 checksum, re-fragments if necessary then finally includes appropriate 3273 L2 headers and forwards the carrier packets into the secured spanning 3274 tree. 3276 3.13.2.4. Gateway NA Forwarding 3278 When the LHS Gateway receives the carrier packets containing the NA 3279 message, it reassembles and verifies the OAL and NA checksums then 3280 uses the current NA AFP AFVI List "B" entry to locate the AFV. The 3281 LHS Gateway then caches the AFP addressing and AFVI List "A" 3282 information for the previous hops in the AFV, then generates a 3283 locally-unique "A" AFVI and both assigns it to the AFV and writes it 3284 as the next AFP AFVI List "A" entry. The LHS Gateway then 3285 recalculates the NA checksum. If the LHS Gateway is connected 3286 directly to both the FHS and LHS segments (whether the segments are 3287 the same or different), the LHS Gateway will have already cached the 3288 FHS/LHS information based on the original NS; the LHS Gateway then 3289 sets the OAL source to its FHS ULA and OAL destination to the ULA of 3290 the FHS Proxy/Server. Otherwise, the LHS Gateway sets the OAL source 3291 to its LHS ULA and OAL destination to the ULA of the FHS Gateway. 3292 The LHS Gateway then decrements the OAL Hop Limit, selects an 3293 appropriate Identification, recalculates the OAL checksum, re- 3294 fragments if necessary, includes appropriate L2 headers and finally 3295 forwards the carrier packets into the secured spanning tree. 3297 When the FHS and LHS Gateways are different, the FHS Gateway will 3298 receive carrier packets containing the NA message from the LHS 3299 Gateway over the secured spanning tree, where there may have been 3300 many intermediate Gateway forwarding hops. The FHS Gateway then 3301 reassembles to obtain the NA, verifies the OAL and NA checksums and 3302 locates the AFV based on the current AFP AFVI List "B" entry. The 3303 FHS Gateway then caches the addressing and "A" information for the 3304 previous hops in the AFV and generates a locally-unique "A" AFVI. 3305 The FHS Gateway then assigns the new "A" value to the AFV, records 3306 "A" in the AFP AFVI List then writes its FHS ULA and L2ADDR into the 3307 AFP FHS Gateway fields. The FHS Gateway then recalculates the NA 3308 checksum, sets its FHS ULA as the OAL source and sets the ULA of the 3309 FHS Proxy/Server as the OAL destination. The FHS Gateway then 3310 decrements the OAL Hop Limit, selects an appropriate Identification 3311 value, recalculates the OAL checksum, re-fragments if necessary, 3312 includes appropriate L2 headers and finally forwards the carrier 3313 packets into the secured spanning tree. 3315 3.13.2.5. FHS Proxy/Server-Client NA Receipt 3317 When the FHS Proxy/Server receives the carrier packets from the 3318 secured spanning tree, it reassembles to obtain the NA, verifies the 3319 OAL and NA checksums then locates the AFV based on the current AFP 3320 AFVI List "B" entry. The FHS Proxy/Server then caches the AFP 3321 addressing and "A" information for the previous hops. If the NA 3322 destination matches its own ULA, the FHS Proxy/Server then examines 3323 LHS FMT. If FMT-Forward is clear, the FHS Proxy/Server locates the 3324 NCE for the ULA of the LHS Proxy/Server and sets the state to 3325 REACHABLE then caches any Tunnel Window Synchronization parameters. 3326 If the NA source is the XLA of the LHS Client, the FHS Proxy/Server 3327 then locates the LHS Client NCE and sets the state to REACHABLE then 3328 caches the OMNI Neighbor Coordination window synchronization 3329 parameters and prepares to return an acknowledgement, if necessary. 3331 If the NA destination is the XLA of the FHS Client, the FHS Proxy/ 3332 Server also searches for and updates the NCE for the ULA of the LHS 3333 Proxy/Server if necessary the same as above. The FHS Proxy/Server 3334 then generates a locally-unique "A" AFVI and assigns it both to the 3335 AFV and as the next AFP AFVI List "A" entry, then includes an 3336 authentication signature or checksum in the NA message. The FHS 3337 Proxy/Server then sets the OAL source to its own ULA and sets the OAL 3338 destination to the ULA-MNP of the FHS Client. The FHS Proxy/Server 3339 then decrements the OAL Hop Limit, selects an appropriate 3340 Identification value, recalculates the OAL checksum, re-fragments if 3341 necessary, includes appropriate L2 headers and finally forwards the 3342 carrier packets to the FHS Client. 3344 When the FHS Client receives the carrier packets, it verifies the 3345 Identification, reassembles to obtain the NA, verifies the OAL 3346 checksum and NA authentication signature or checksum, then locates 3347 the AFV based on the current AFP AFVI List "B" entry. The FHS Client 3348 then caches the previous hop addressing and "A" information the same 3349 as for prior hops. The FHS Client then examines LHS FMT. If FMT- 3350 Forward is clear, the FHS Client locates the NCE for the ULA of the 3351 LHS Proxy/Server and sets the state to REACHABLE then caches any 3352 Tunnel Window Synchronization parameters. If the NA source is the 3353 XLA of the LHS Client, the FHS Client then locates the LHS Client NCE 3354 and sets the state to REACHABLE then caches the OMNI Neighbor 3355 Coordination window synchronization parameters and prepares to return 3356 an unsolicited NA (uNA) acknowledgement, if necessary. 3358 3.13.2.6. Returning Window Acknowledgements 3360 If either the FHS Client or FHS Proxy/Server needs to return an 3361 acknowledgement to complete window synchronization, it prepares a uNA 3362 message with an AFP sub-option with Job code set to '10' (Follow A; 3363 Record B) (note that this step is unnecessary when Rapid Commit route 3364 optimization is used per Section 3.13.2.8). The FHS node sets the 3365 uNA source to its own ULA or XLA, sets the uNA destination to the ULA 3366 or XLA of the LHS node then includes Tunnel Window Synchronization 3367 parameters if necessary. The FHS node next sets the AFP AFVI List to 3368 the cached list of "A" entries received in the Job code '01' NA, but 3369 need not set any other FHS/LHS information. The FHS node then 3370 encapsulates the uNA message in an OAL header with its own ULA as the 3371 OAL source. If the FHS node is the Client, it next sets the ULA of 3372 the FHS Proxy/Server as the OAL destination, includes an 3373 authentication signature or checksum, selects an appropriate 3374 Identification value, calculates the OAL checksum, fragments if 3375 necessary, includes appropriate L2 headers and finally forwards the 3376 carrier packets to the FHS Proxy/Server. The FHS Proxy/Server then 3377 verifies the Identification, reassembles if necessary, verifies the 3378 OAL checksum and uNA authentication signature or checksum, then uses 3379 the current AFVI List "A" entry to locate the AFV. The FHS Proxy/ 3380 Server then writes its "B" AFVI as the next AFP AFVI List "B" entry 3381 and determines whether it needs to include Tunnel Window 3382 Synchronization parameters the same as it had done when it forwarded 3383 the original NS with Job code '00'. 3385 The FHS Proxy/Server recalculates the uNA checksum then sets its own 3386 ULA as the OAL source and the ULA of the FHS Gateway as the OAL 3387 destination, The FHS Proxy/Server finally decrements the OAL Hop 3388 Limit, selects an appropriate Identification, recalculates the OAL 3389 checksum, includes appropriate L2 headers and finally forwards the 3390 carrier packets into the secured spanning tree. When the FHS Gateway 3391 receives the carrier packets, it reassembles to obtain the uNA, 3392 verifies the OAL and uNA checksums then uses the current AFVI List 3393 "A" entry to locate the AFV. The FHS Gateway then writes its "B" 3394 AFVI as the next AFP AFVI List "B" entry, then sets the OAL source to 3395 its own ULA. If the FHS Gateway is also the LHS Gateway, it sets the 3396 OAL destination to the ULA of the LHS Proxy/Server; otherwise it sets 3397 the OAL destination to the ULA of the LHS Gateway. The FHS Gateway 3398 recalculates the uNA checksum then decrements the OAL Hop Limit, 3399 selects an appropriate Identification, recalculates the OAL checksum, 3400 re-fragments if necessary, includes appropriate L2 headers and 3401 finally forwards the carrier packets into the secured spanning tree. 3402 If an LHS Gateway receives the carrier packets, it processes them 3403 exactly the same as the FHS Gateway had done while re-setting the OAL 3404 destination to the ULA of the LHS Proxy/Server. 3406 When the LHS Proxy/Server receives the carrier packets, it 3407 reassembles to obtain the uNA message then verifies the OAL and uNA 3408 checksums. The LHS Proxy/Server then locates the AFV based on the 3409 current AFP AFVI List "A" entry then determines whether it is a 3410 tunnel ingress the same as for the original NS. If so, the LHS 3411 Proxy/Server updates the NCE for the tunnel far-end based on the 3412 Tunnel Window Synchronization parameters. If the uNA destination 3413 matches its own ULA, the LHS Proxy/Server next updates the NCE for 3414 the source ULA based on the OMNI Neighbor Coordination sub-option 3415 window synchronization parameters and MAY compare the AFVI List to 3416 the version it had cached in the AFV based on the original NS. 3418 If the uNA destination is the XLA of the LHS Client, the LHS Proxy/ 3419 Server instead writes its "B" AFVI as the next AFP AFVI List "B" 3420 entry and includes an authentication signature or checksum. The LHS 3421 Proxy/Server then writes its own ULA as the OAL source and the ULA- 3422 MNP of the Client as the OAL destination, then decrements the OAL Hop 3423 Limit, selects an appropriate Identification and recalculates the OAL 3424 checksum. The LHS Proxy/Server finally re-fragments if necessary, 3425 includes appropriate L2 headers and forwards the resulting carrier 3426 packets to the LHS Client. When the LHS Client receives the carrier 3427 packets, it verifies the Identification, reassembles to obtain the 3428 uNA, verifies the OAL checksum and uNA authentication signature or 3429 checksum then processes the message exactly the same as for the LHS 3430 Proxy/Server case above. 3432 3.13.2.7. OAL End System Exchanges Following Synchronization 3434 Following the initial NS/NA exchange with AFP sub-options, OAL end 3435 systems and tunnel endpoints can begin exchanging ordinary carrier 3436 packets that include "A/B" AFVIs and with Identification values 3437 within their respective send/receive windows without requiring 3438 security signatures and/or secured spanning tree traversal. OAL end 3439 systems and intermediate nodes can also consult their AFIBs when they 3440 receive carrier packets that include "A/B" AFVIs to unambiguously 3441 locate the correct AFV and can use any discovered "A/B" values of 3442 other OAL nodes to forward carrier packets to nodes that configure 3443 the corresponding AFVIs. OAL end systems must then perform 3444 continuous NS/NA exchanges to update window state, register new 3445 interface pairs for optimized multilink forwarding, confirm 3446 reachability and/or refresh AFIB cache state in the path before 3447 ReachableTime expires. 3449 While the OAL end systems continue to actively exchange packets, they 3450 are jointly responsible for updating cache state and per-interface 3451 reachability before expiration. Window synchronization state is 3452 shared by all underlay interfaces in the FHS peer's NCE that use the 3453 same destination ULA so that a single NS/NA exchange applies for all 3454 interfaces regardless of the specific interface used to conduct the 3455 exchange. However, the window synchronization exchange only confirms 3456 target Client reachability over the specific underlay interface pair. 3457 Reachability for other underlay interfaces that share the same window 3458 synchronization state must be determined individually using 3459 additional NS/NA messages. 3461 To update AFIB state in the path, the FHS node that sent the original 3462 NS message with AFP Job code '00' can send additional NS messages 3463 with Job code '10' (Follow "A"; Record "B"). The message will be 3464 processed by all intermediate OAL nodes which will refresh AFV timers 3465 and forward the NS onward toward the LHS node that returned the 3466 original NA message. When the LHS node receives the NS, it returns 3467 an NA message with AFP Job code '11' (Follow "B"; Record "A"). 3469 At the same time, the LHS node that received the original NS message 3470 with Job code '00' can send additional NS messages with Job code '11' 3471 in order to cause the FHS node to return an NA message with AFP Job 3472 code '10'. The process can therefore be coordinated asynchronously 3473 with the FHS/LHS nodes initiating an NS/NA exchange independently of 3474 one another. The exchanges will succeed as long as the AFIB state in 3475 the path remains active. Note that all intermediate node processing 3476 of Job code '10' and '11' NS/NA messages is conducted the same as for 3477 the initial NS/NA exchange according to the detailed specifications 3478 above. 3480 OAL sources can also begin including CRH-32s in carrier packets with 3481 a list of "A/B" AFVIs that OAL intermediate nodes can use for 3482 shortest-path carrier packet forwarding based on AFVIs instead of 3483 spanning tree addresses. OAL sources and intermediate nodes can 3484 instead forward carrier packets with OAL compressed headers termed 3485 "OCH" (see: [I-D.templin-6man-omni]) that include only a single "A/B" 3486 AFVI meaningful to the next hop, since all OAL nodes in the path up 3487 to (and sometimes including) the OAL destination have already 3488 established AFVs. Note that when an FHS OAL source receives a 3489 solicited NA with Job code '01', the AFP sub-option will contain an 3490 AFVI List with "A" entries populated in the reverse order needed for 3491 populating a CRH-32 routing header. The FHS OAL source must 3492 therefore write the AFP AFVI List "A" entries last-to-first when it 3493 populates a CRH-32, or must select the correct "A" entry to include 3494 in an OCH header based on the intended OAL intermediate node or 3495 destination. 3497 When a Gateway receives unsecured carrier packets destined to a local 3498 SRT segment Client that has asserted direct reachability, the Gateway 3499 performs direct carrier packet forwarding while bypassing the local 3500 Proxy/Server based on the Client's advertised AFVIs and discovered 3501 NATed L2ADDR information (see: Section 3.13.3). If the Client cannot 3502 be reached directly (or if NAT traversal has not yet converged), the 3503 Gateway instead forwards carrier packets directly to the local 3504 segment Proxy/Server. 3506 When a Proxy/Server receives carrier packets destined to a local SRT 3507 segment Client or forwards carrier packets received from a local 3508 segment Client, it first locates the correct AFV. If the carrier 3509 packets include a secured IPv6 ND message, the Proxy/Server uses the 3510 Client's NCE established through RS/RA exchanges to re-encapsulate/ 3511 re-fragment while forwarding outbound secured carrier packets via the 3512 secured spanning tree and forwarding inbound secured carrier packets 3513 while including an authentication signature or checksum. For 3514 ordinary carrier packets, the Proxy/Server uses the same AFV if 3515 directed by AFVI and/or OAL addressing. Otherwise it locates an AFV 3516 established through an NS/NA exchange between the Client and the 3517 remote SRT segment peer, and forwards the carrier packets without 3518 first reassembling/decapsulating. 3520 When a Proxy/Server or Client configured as a tunnel ingress receives 3521 a carrier packet with a full OAL header with a ULA-MNP source and 3522 CRH-32 routing header, or an OCH header with an AFVI that matches an 3523 AFV, the ingress encapsulates the carrier packet in a new full OAL 3524 header or an OCH header containing the next hop AFVI and an 3525 Identification value appropriate for the end-to-end window and the 3526 outer header containing an Identification value appropriate for the 3527 tunnel endpoints. When a Proxy/Server or Client configured as a 3528 tunnel egress receives an encapsulated carrier packet, it verifies 3529 the Identification in the outer header, then discards the outer 3530 header and forwards the inner carrier packet to the final 3531 destination. 3533 When a Proxy/Server with FMT-Forward/Mode set to 0/1 for a source 3534 Client receives carrier packets from the source Client, it first 3535 reassembles to obtain the original OAL packet then re-fragments if 3536 necessary to cause the Client's packets to fit within the MPS on the 3537 path from the Proxy/Server as a tunnel ingress to the tunnel egress. 3538 The Proxy/Server then performs OAL-in-OAL encapsulation and forwards 3539 the resulting carrier packets to the tunnel egress. When a Proxy/ 3540 Server with FMT-Forward/Mode set to 0/1 for a target Client receives 3541 carrier packets from a tunnel ingress, it first decapsulates to 3542 obtain the original fragments then reassembles to obtain the original 3543 OAL packet. The Proxy/Server then re-fragments if necessary to cause 3544 the fragments to match the target Client's underlay interface (Path) 3545 MTU and forwards the resulting carrier packets to the target Client. 3547 When a source Client forwards carrier packets it can employ header 3548 compression according to the AFVIs established through an NS/NA 3549 exchange with a remote or local peer. When the source Client 3550 forwards to a remote peer, it can forward carrier packets to a local 3551 SRT Gateway (following the establishment of L2ADDR information) while 3552 bypassing the Proxy/Server following route optimization (see: 3553 Section 3.13.3). When a target Client receives carrier packets that 3554 match a local AFV, the Client first verifies the Identification then 3555 decompresses the headers if necessary, reassembles if necessary to 3556 obtain the OAL packet then decapsulates and delivers the IP packet to 3557 upper layers. 3559 When synchronized peer Clients in the same SRT segment with FMT- 3560 Forward and FMT-Mode set discover each other's NATed L2ADDR 3561 addresses, they can exchange carrier packets directly with header 3562 compression using AFVIs discovered as above (see: Section 3.13.4). 3563 The FHS Client will have cached the "A" AFVI for the LHS Client, 3564 which will have cached the "B" AFVI for the FHS Client. 3566 When the FHS Client or FHS Proxy/Server sends an NS for the purpose 3567 of establishing multilink forwarding state, it should wait up to 3568 RETRANS_TIMER seconds to receive a responsive NA. The FHS node can 3569 then retransmit the NS up to MAX_UNICAST_SOLICIT times before giving 3570 up. Note that each successive attempt establishes new AFV state in 3571 the OAL intermediate nodes, but that any abandoned stale AFV state 3572 will be quickly reclaimed. 3574 3.13.2.8. Rapid Commit Multilink Forwarding 3576 Multilink forwarding can often be invoked simultaneously with Address 3577 Resolution in order to reduce control message overhead and round-trip 3578 delays. When an ART acting as an ARR receives an NS(AR) with a set 3579 of Interface Attributes for the ARS source Client, it can perform 3580 "rapid commit" by immediately invoking multilink forwarding as above 3581 at the same time as returning the NA(AR). 3583 In order to perform rapid commit, the ARR includes an AFP sub-option 3584 with Job code '00' as the first OMNI sub-option in the NA(AR) as 3585 though it were initiating a multilink coordination NS/NA exchange as 3586 specified above. The ARR then includes any Interface Attributes and/ 3587 or Traffic Selector sub-options as necessary to satisfy the address 3588 resolution request, and can also include ordinary IP packets as 3589 additional super-packet extensions to this NA(AR) message if it has 3590 immediate data to send to the ARS. The ARR then returns the NA(AR) 3591 to the ARS using the same hop-by-hop OAL addressing disciplines as 3592 specified above for an ordinary multilink NS/NA exchange. This will 3593 cause the NA(AR) to visit all OAL intermediate nodes on the path 3594 towards the ARS. 3596 When the NA(AR) traverses the return path to the ARS, OAL 3597 intermediate nodes in the path process the NS AFP information exactly 3598 the same as for an ordinary multilink forwarding exchange as 3599 specified above, i.e., without examining the remaining NA(AR) message 3600 contents. This results in the ARR node now assuming the FHS role and 3601 the ARS assuming the LHS role from the perspective of multilink 3602 forwarding coordination. When the NA(AR) arrives, the ARS processes 3603 the window synchronization parameters while also processing all other 3604 NA(AR) OMNI option information, thereby eliminating an extraneous 3605 message transmission and associated delay. The ARS (now acting as an 3606 LHS peer) then completes the exchange by returning a responsive NA; 3607 if no NA response is received within RETRANS_TIMER seconds, the ARR 3608 can retransmit the NA(AR) up to MAX_UNICAST_SOLICIT times before 3609 giving up. 3611 This very importantly implies that the type of IPv6 ND message used 3612 to convey an AFP with Job codes '00' and '01' (i.e., NS or NA) is 3613 unimportant from the perspective of multilink forwarding. This means 3614 that Job code '00' serves as the solicitation indication and Job code 3615 '01' serves as the response such that either an NS or NA message 3616 carrying an AFP with Job code '00' will invoke a responsive NA 3617 message carrying an AFP with Job code '01'. Also importantly, this 3618 condition does not apply for Job codes '10' and '11'; for those job 3619 codes, an NA is only sent in response to an NS and never in response 3620 to another NA. 3622 3.13.3. Client/Gateway Route Optimization 3624 Following multilink route optimization for specific underlay 3625 interface pairs, FHS/LHS Clients located on open INETs can invoke 3626 Client/Gateway route optimization to improve performance and reduce 3627 load and congestion on their respective Proxy/Servers. To initiate 3628 Client/Gateway route optimization, the Client prepares an NS message 3629 with its own XLA address as the source and the ULA of its Gateway as 3630 the destination while creating a NCE for the Gateway if necessary. 3632 The NS message must be no larger than the minimum MPS and 3633 encapsulated as an atomic fragment. 3635 The Client then includes an Interface Attributes sub-option for its 3636 underlay interface as well as an authentication signature but does 3637 not include window synchronization parameters. The Client then 3638 performs OAL encapsulation with its own ULA-MNP as the source and the 3639 ULA of the Gateway as the destination while including a randomly- 3640 chosen Identification value, then performs L2 encapsulation on the 3641 atomic fragment and sends the resulting carrier packet directly to 3642 the Gateway. 3644 When the Gateway receives the carrier packet, it verifies the 3645 authentication signature then creates a NCE for the Client. The 3646 Gateway then caches the L2 encapsulation addresses (which may have 3647 been altered by one or more NATs on the path) as well as the 3648 Interface Attributes for this Client ifIndex, and marks this Client 3649 underlay interface as "trusted". The Gateway then prepares an NA 3650 reply with its own ULA as the source and the XLA of the Client as the 3651 destination where the NA again must be no larger than the minimum 3652 MPS. 3654 The Gateway then echoes the Client's Interface Attributes, includes 3655 an Origin Indication with the Client's observed L2 addresses and 3656 includes an authentication signature. The Gateway then performs OAL 3657 encapsulation with its own ULA as the source and the ULA-MNP of the 3658 Client as the destination while using the same Identification value 3659 that appeared in the NS, then performs L2 encapsulation on the atomic 3660 fragment and sends the resulting carrier packet directly to the 3661 Client. 3663 When the Client receives the NA reply, it caches the carrier packet 3664 L2 source address information as the Gateway target address via this 3665 underlay interface while marking the interface as "trusted". The 3666 Client also caches the Origin Indication L2 address information as 3667 its own (external) source address for this underlay interface. 3669 After the Client and Gateway have established NCEs as well as 3670 "trusted" status for a particular underlay interface pair, each node 3671 can begin forwarding ordinary carrier packets intended for this 3672 multilink route optimization directly to one another while omitting 3673 the Proxy/Server from the forwarding path while the status is 3674 "trusted". The NS/NA messaging will have established the correct 3675 state in any NATs in the path so that NAT traversal is naturally 3676 supported. The Client and Gateway must maintain a timer that watches 3677 for activity on the path; if no carrier packets and/or NS/NA messages 3678 are sent or received over the path before NAT state is likely to have 3679 expired, the underlay interface pair status becomes "untrusted". 3681 Thereafter, when the Client forwards a carrier packet with an AFVI 3682 toward the Gateway as the next hop, the Client uses the AFVI for the 3683 Gateway (discovered during multilink route optimization) instead of 3684 the AFVI for its Proxy/Server; the Gateway will accept the packet 3685 from the Client if and only if the AFVI matches the correct AFV and 3686 the underlay interface status is trusted. (The same is true in the 3687 reverse direction when the Gateway sends carrier packets directly to 3688 the Client.) 3690 Note that the Client and Gateway each maintain a single NCE, but that 3691 the NCE may aggregate multiple underlay interface pairs. Each 3692 underlay interface pair may use differing source and target L2 3693 addresses according to NAT mappings, and the "trusted/untrusted" 3694 status of each pair must be tested independently. When no "trusted" 3695 pairs remain, the NCE is deleted. 3697 Note that the above method requires Gateways to participate in NS/NA 3698 message authentication signature application and verification. In an 3699 alternate approach, the Client could instead exchange NS/NA messages 3700 with authentication signatures via its Proxy/Server but addressed to 3701 the ULA of the Gateway, and the Proxy/Server and Gateway could relay 3702 the messages over the secured spanning tree. However, this would 3703 still require the Client to send additional messages toward the L2 3704 address of the Gateway to populate NAT state; hence the savings in 3705 complexity for Gateways would result in increased message overhead 3706 for Clients. 3708 3.13.4. Client/Client Route Optimization 3710 When the FHS/LHS Clients are both located on the same SRT segment, 3711 Client-to-Client route optimization is possible following the 3712 establishment of any necessary state in NATs in the path. Both 3713 Clients will have already established state via their respective 3714 shared segment Proxy/Servers (and possibly also the shared segment 3715 Gateway) and can begin forwarding packets directly via NAT traversal 3716 while avoiding any Proxy/Server and/or Gateway hops. 3718 When the FHS/LHS Clients on the same SRT segment perform the initial 3719 NS/NA exchange to establish AFIB state, they also include an Origin 3720 Indication (i.e., in addition to an AFP sub-option) with the mapped 3721 addresses discovered during the RS/RA exchanges with their respective 3722 Proxy/Servers. After the AFV paths have been established, both 3723 Clients can begin sending packets via strict AFV paths while 3724 establishing a direct path for Client-to-Client route optimization. 3726 To establish the direct path, either Client (acting as the source) 3727 transmits a bubble to the mapped L2 address for the target Client 3728 which primes its local chain of NATs for reception of future packets 3729 from that L2 address (see: [RFC4380] and [I-D.templin-6man-omni]). 3730 The source Client then prepares an NS message with its own XLA as the 3731 source, with the XLA of the target as the destination and with an 3732 OMNI option with an Interface Attributes sub-option. The source 3733 Client then encapsulates the NS in an OAL header with its own ULA-MNP 3734 as the source, with the ULA-MNP of the target Client as the 3735 destination and with an in-window Identification for the target. The 3736 source Client then fragments and encapsulates in L2 headers addressed 3737 to its Proxy/Server then forwards the resulting carrier packets to 3738 the Proxy/Server. 3740 When the Proxy/Server receives the carrier packets, it re- 3741 encapsulates and forwards them as unsecured carrier packets according 3742 to AFIB state where they will eventually arrive at the target Client 3743 which can verify that the identifications are within the acceptable 3744 window and reassemble if necessary. Following reassembly, the target 3745 Client prepares an NA message with its own XLA as the source, with 3746 the XLA of the source Client as the destination and with an OMNI 3747 option with an Interface Attributes sub-option. The target Client 3748 then encapsulates the NA in an OAL header with its own ULA-MNP as the 3749 source, with the ULA-MNP of the source Client as the destination and 3750 with an in-window Identification for the source Client. The target 3751 Client then fragments and encapsulates in L2 headers addressed to the 3752 source Client's Origin addresses then forwards the resulting carrier 3753 packets directly to the source Client. 3755 Following the initial NS/NA exchange, both Clients mark their 3756 respective (source, target) underlay interface pairs as "trusted" for 3757 no more than ReachableTime seconds. While the Clients continue to 3758 exchange carrier packets via the direct path avoiding all Proxy/ 3759 Servers and Gateways, they should perform additional NS/NA exchanges 3760 via their local Proxy/Servers to refresh NCE state as well as send 3761 additional bubbles to the peer's Origin address information if 3762 necessary to refresh NAT state. 3764 Note that these procedures are suitable for a widely-deployed but 3765 basic class of NATs. Procedures for advanced NAT classes are 3766 outlined in [RFC6081], which provides mechanisms that can be employed 3767 equally for AERO using the corresponding sub-options specified by 3768 OMNI. 3770 Note also that each communicating pair of Clients may need to 3771 maintain NAT state for peer to peer communications via multiple 3772 underlay interface pairs. It is therefore important that Origin 3773 Indications are maintained with the correct peer interface and that 3774 the NCE may cache information for multiple peer interfaces. 3776 Note that the source and target Client exchange Origin information 3777 during the secured NS/NA multilink route optimization exchange. This 3778 allows for subsequent NS/NA exchanges to proceed using only the 3779 Identification value as a data origin confirmation. However, Client- 3780 to-Client peerings that require stronger security may also include 3781 authentication signatures for mutual authentication. 3783 3.13.5. Client-to-Client OMNI Link Extension 3785 Clients may be recursively nested within the ENETs of other Clients. 3786 When a Client is the downstream-attached ENET neighbor of an upstream 3787 Client, it still supports the route optimization functions discussed 3788 above by maintaining an AFIB and assigning AFVI values. When the 3789 Client processes an IPv6 ND NS/NA message that includes an AFP sub- 3790 option, it writes its AFVI information as the first/last AFVI list 3791 entry the same as for the single Client case discussed above. 3793 The Client then forwards the NS/NA message to the next Client in the 3794 extended OMNI link toward the FHS/LHS Proxy/Server, which records the 3795 AFVI value then overwrites the AFVI list entry with its own AFVI 3796 value. This process iteratively continues until the Client that will 3797 forward the NS/NA message to the FHS/LHS Proxy/Server is reached, at 3798 which point the NS/NA AFVI list entries are populated by the 3799 intermediate nodes on the path to the LHS/FHS the same as discussed 3800 above. 3802 In this way, each Client in the extended OMNI link discovers the A/B 3803 AFVIs of the next/previous Client without intruding into the AFP sub- 3804 option AFVI list. Therefore the list can remain fixed at 5 entries 3805 even though the Client-to-Client OMNI link extension can be 3806 arbitrarily long. Therefore, route optimization is not possible 3807 between consecutive Client members of the extended OMNI link but 3808 becomes possible at the Internetworking border that separates the FHS 3809 and LHS elements. 3811 3.13.6. Intra-ANET/ENET Route Optimization for AERO Peers 3813 When a Client forwards a packet from a Host or another Client 3814 connected to one of its downstream ENETs to a peer within the same 3815 downstream ENET, the Client returns an IPv6 ND Redirect message to 3816 inform the source that that target can be reached directly. The 3817 contents of the Redirect message are the same as specified in 3818 [RFC4861]. 3820 In the same fashion, when a Proxy/Server forwards a packet from a 3821 Host or Client connected to one of its downstream ANETs to a peer 3822 within the same downstream ANET, the Proxy/Server returns an IPv6 ND 3823 Redirect message. 3825 All other route optimization functions are conducted per the NS/NA 3826 messaging discussed in the previous sections. 3828 3.14. Neighbor Unreachability Detection (NUD) 3830 AERO nodes perform Neighbor Unreachability Detection (NUD) per 3831 [RFC4861] either reactively in response to persistent link-layer 3832 errors (see Section 3.11) or proactively to confirm reachability. 3833 The NUD algorithm is based on periodic control message exchanges and 3834 may further be seeded by IPv6 ND hints of forward progress, but care 3835 must be taken to avoid inferring reachability based on spoofed 3836 information. For example, IPv6 ND message exchanges that include 3837 authentication codes and/or in-window Identifications may be 3838 considered as acceptable hints of forward progress, while spurious 3839 random carrier packets should be ignored. 3841 AERO nodes can perform NS/NA exchanges over the OMNI link secured 3842 spanning tree (i.e. the same as described above) to test reachability 3843 without risk of DoS attacks from nodes pretending to be a neighbor. 3844 These NS/NA messages use the unicast XLAs/ULAs of the parties 3845 involved in the NUD test. When only reachability information is 3846 required without updating any other NCE state, AERO nodes can instead 3847 perform NS/NA exchanges directly between neighbors without employing 3848 the secured spanning tree as long as they include in-window 3849 Identifications and either an authentication signature or checksum. 3851 After route optimization directs a source FHS peer to a target LHS 3852 peer with one or more link-layer addresses, either node may invoke 3853 multilink forwarding state initialization to establish authentic 3854 intermediate node state between specific underlay interface pairs 3855 which also tests their reachability. Thereafter, either node acting 3856 as the source may perform additional reachability probing through NS 3857 messages over the SRT secured or unsecured spanning tree, or through 3858 NS messages sent directly to an underlay interface of the target 3859 itself. While testing a target underlay interface, the source can 3860 optionally continue to forward carrier packets via alternate 3861 interfaces, maintain a small queue of carrier packets until target 3862 reachability is confirmed or include them as trailing data with the 3863 NS in an OAL super-packet [I-D.templin-6man-omni]. 3865 NS messages are encapsulated, fragmented and transmitted as carrier 3866 packets the same as for ordinary original IP data packets, however 3867 the encapsulated destinations are either the ULA or XLA of the source 3868 and either the ULA of the LHS Proxy/Server or the XLA of the target 3869 itself. The source encapsulates the NS message the same as described 3870 in Section 3.13.2 and includes an Interface Attributes sub-option 3871 with ifIndex set to identify its underlay interface used for 3872 forwarding. The source then includes an in-window Identification, 3873 fragments the OAL packet and forwards the resulting carrier packets 3874 into the unsecured spanning tree, directly to the target if it is in 3875 the local segment or directly to a Gateway in the local segment. 3877 When the target receives the NS carrier packets, it verifies that it 3878 has a NCE for this source and that the Identification is in-window, 3879 then submits the carrier packets for reassembly. The target then 3880 verifies the authentication signature or checksum, then searches for 3881 Interface Attributes in its NCE for the source that match the NS for 3882 the NA reply. The target then prepares the NA with the source and 3883 destination addresses reversed, encapsulates and sets the OAL source 3884 and destination, includes an Interface Attributes sub-option in the 3885 NA to identify the ifIndex of the underlay interface the NS arrived 3886 on and sets the Target Address to the same value included in the NS. 3887 The target next sets the R flag to 1, the S flag to 1 and the O flag 3888 to 1, then selects an in-window Identification for the source and 3889 performs fragmentation. The node then forwards the carrier packets 3890 into the unsecured spanning tree, directly to the source if it is in 3891 the local segment or directly to a Gateway in the local segment. 3893 When the source receives the NA, it marks the target underlay 3894 interface tested as "trusted". Note that underlay interface states 3895 are maintained independently of the overall NCE REACHABLE state, and 3896 that a single NCE may have multiple target underlay interfaces in 3897 various "trusted/untrusted" states while the NCE state as a whole 3898 remains REACHABLE. 3900 3.15. Mobility Management and Quality of Service (QoS) 3902 AERO is a fully Distributed Mobility Management (DMM) service in 3903 which each Proxy/Server is responsible for only a small subset of the 3904 Clients on the OMNI link. This is in contrast to a Centralized 3905 Mobility Management (CMM) service where there are only one or a few 3906 network mobility collective entities for large Client populations. 3907 Clients coordinate with their associated FHS and Hub Proxy/Servers 3908 via RS/RA exchanges to maintain the DMM profile, and the AERO routing 3909 system tracks all current Client/Proxy/Server peering relationships. 3911 Hub Proxy/Servers provide a designated router service for their 3912 dependent Clients, while FHS Proxy/Servers provide a proxy conduit 3913 between the Client and both the Hub and OMNI link in general. 3914 Clients are responsible for maintaining neighbor relationships with 3915 their Proxy/Servers through periodic RS/RA exchanges, which also 3916 serves to confirm neighbor reachability. When a Client's underlay 3917 interface attributes change, the Client is responsible for updating 3918 the Hub Proxy/Server through new RS/RA exchanges using the FHS Proxy/ 3919 Server as a first-hop conduit. The FHS Proxy/Server can also act as 3920 a proxy to perform some IPv6 ND exchanges on the Client's behalf 3921 without consuming bandwidth on the Client underlay interface. 3923 Mobility management considerations are specified in the following 3924 sections. 3926 3.15.1. Mobility Update Messaging 3928 Hub Proxy/Servers (and/or the mobile Clients themselves) accommodate 3929 mobility and/or multilink change events by sending secured uNA 3930 messages to each of the Client's active neighbors. When a node sends 3931 a uNA message to each specific neighbor on behalf of a mobile Client, 3932 it sets the IPv6 source address to its own ULA or XLA, sets the 3933 destination address to the neighbor's ULA or XLA and sets the Target 3934 Address to the mobile Client's XLA. The uNA also includes an OMNI 3935 option with OMNI Neighbor Coordination sub-option Preflen set to the 3936 prefix length associated with the mobile Client's XLA, includes 3937 Interface Attributes and Traffic Selectors for the mobile Client's 3938 underlay interfaces and includes an authentication signature if 3939 necessary. The node then sets the uNA R flag to 1, S flag to 0 and O 3940 flag to 1, then encapsulates the message in an OAL header with source 3941 set to its own ULA and destination set to either the specific 3942 neighbor's ULA or the FHS Proxy/Server's ULA. The uNA message will 3943 then follow the secured spanning tree and arrive at the specific 3944 neighbor. 3946 As discussed in Section 7.2.6 of [RFC4861], the transmission and 3947 reception of uNA messages is unreliable but provides a useful 3948 optimization. In well-connected Internetworks with robust data links 3949 uNA messages will be delivered with high probability, but in any case 3950 the node can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT uNAs to 3951 each neighbor to increase the likelihood that at least one will be 3952 received. Alternatively, the node can set the PNG flag in the uNA 3953 OMNI option header to request a uNA acknowledgement as specified in 3954 [I-D.templin-6man-omni]. 3956 When the FHS/LHS Proxy/Server receives a uNA message prepared as 3957 above, if the uNA destination was its own ULA the Proxy/Server uses 3958 the included OMNI option information to update its NCE for the target 3959 but does not reset ReachableTime since the receipt of a uNA message 3960 does not provide confirmation that any forward paths to the target 3961 Client are working. If the destination was the XLA of the FHS/LHS 3962 Client, the Proxy/Server instead changes the OAL source to its own 3963 ULA, includes an authentication signature if necessary, and includes 3964 an in-window Identification for this Client. Finally, if the uNA 3965 message PNG flag was set, the node that processes the uNA returns a 3966 uNA acknowledgement as specified in [I-D.templin-6man-omni]. 3968 3.15.2. Announcing Link-Layer Information Changes 3970 When a Client needs to change its underlay Interface Attributes and/ 3971 or Traffic Selectors for one or more underlay interfaces (e.g., due 3972 to a mobility event), the Client sends RS messages to its Hub Proxy/ 3973 Server (via first-hop FHS Proxy/Servers if necessary). Each RS 3974 includes an OMNI option with Interface Attributes and/or Traffic 3975 Selector sub-options for the ifIndex in question. 3977 Note that the first FHS Proxy/Server may change due to the underlay 3978 interface change. If the Client supplies the address of the former 3979 FHS Proxy/Server, the new FHS Proxy/Server can send a departure 3980 indication (see below); otherwise, any stale state in the former FHS 3981 Proxy/Server will simply expire after ReachableTime expires with no 3982 effect on the Hub Proxy/Server. 3984 Up to MAX_RTR_SOLICITATIONS RS messages MAY be sent in parallel with 3985 sending carrier packets containing user data in case one or more RAs 3986 are lost. If all RAs are lost, the Client SHOULD re-associate with a 3987 new Proxy/Server. 3989 After performing the RS/RA exchange, the Client sends uNA messages to 3990 all neighbors the same as described in the previous section. 3992 3.15.3. Bringing New Links Into Service 3994 When a Client needs to bring new underlay interfaces into service 3995 (e.g., when it activates a new data link), it sends an RS message to 3996 the Hub Proxy/Server via a FHS Proxy/Server for the underlay 3997 interface (if necessary) with an OMNI option that includes an 3998 Interface Attributes sub-option with appropriate link quality values 3999 and with link-layer address information for the new link. The Client 4000 then again sends uNA messages to all neighbors the same as described 4001 above. 4003 3.15.4. Deactivating Existing Links 4005 When a Client needs to deactivate an existing underlay interface, it 4006 sends a uNA message toward the Hub Proxy/Server via an FHS Proxy/ 4007 Server with an OMNI option with appropriate Interface Attributes 4008 values for the deactivated link - in particular, the link quality 4009 value 0 assures that neighbors will cease to use the link. 4011 If the Client needs to send uNA messages over an underlay interface 4012 other than the one being deactivated, it MUST include Interface 4013 Attributes with appropriate link quality values for any underlay 4014 interfaces being deactivated. The Client then again sends uNA 4015 messages to all neighbors the same as described above. 4017 Note that when a Client deactivates an underlay interface, neighbors 4018 that receive the ensuing uNA messages need not purge all references 4019 for the underlay interface from their neighbor cache entries. The 4020 Client may reactivate or reuse the underlay interface and/or its 4021 ifIndex at a later point in time, when it will send new RS messages 4022 to an FHS Proxy/Server with fresh interface parameters to update any 4023 neighbors. 4025 3.15.5. Moving Between Proxy/Servers 4027 The Client performs the procedures specified in Section 3.12.2 when 4028 it first associates with a new Hub Proxy/Server or renews its 4029 association with an existing Hub Proxy/Server. 4031 When a Client associates with a new Hub Proxy/Server, it sends RS 4032 messages to register its underlay interfaces with the new Hub while 4033 including the old Hub's ULA in the "Old Hub Proxy/Server ULA" field 4034 of a Proxy/Server Departure OMNI sub-option. When the new Hub Proxy/ 4035 Server returns the RA message via the FHS Proxy/Server (acting as a 4036 Proxy), the FHS Proxy/Server sends a uNA to the old Hub Proxy/Server 4037 (i.e., if the ULA is non-zero and different from its own). The uNA 4038 has the XLA of the Client as the source and the ULA of the old hub as 4039 the destination and with OMNI Neighbor Coordination sub-option 4040 Preflen set to 0. The FHS Proxy/Server encapsulates the uNA in an 4041 OAL header with the ULA of the new Hub as the source and the ULA of 4042 the old Hub as the destination, the fragments and sends the carrier 4043 packets via the secured spanning tree. 4045 When the old Hub Proxy/Server receives the uNA, it changes the 4046 Client's NCE state to DEPARTED, resets DepartTime and caches the new 4047 Hub Proxy/Server ULA. After a short delay (e.g., 2 seconds) the old 4048 Hub Proxy/Server withdraws the Client's MNP from the routing system. 4049 While in the DEPARTED state, the old Hub Proxy/Server forwards any 4050 carrier packets received via the secured spanning tree destined to 4051 the Client's ULA-MNP to the new Hub Proxy/Server's ULA. After 4052 DepartTime expires, the old Hub Proxy/Server deletes the Client's 4053 NCE. 4055 Mobility events may also cause a Client to change to a new FHS Proxy/ 4056 Server over a specific underlay interface at any time such that a 4057 Client RS/RA exchange over the underlay interface will engage the new 4058 FHS Proxy/Server instead of the old. The Client can arrange to 4059 inform the old FHS Proxy/Server of the departure by including a 4060 Proxy/Server Departure sub-option with a ULA for the "Old FHS Proxy/ 4061 Server ULA", and the new FHS Proxy/Server will issue a uNA using the 4062 same procedures as outlined for the Hub above while using its own ULA 4063 as the source address. This can often result in successful delivery 4064 of packets that would otherwise be lost due to the mobility event. 4066 Clients SHOULD NOT move rapidly between Hub Proxy/Servers in order to 4067 avoid causing excessive oscillations in the AERO routing system. 4068 Examples of when a Client might wish to change to a different Hub 4069 Proxy/Server include a Hub Proxy/Server that has gone unreachable, 4070 topological movements of significant distance, movement to a new 4071 geographic region, movement to a new OMNI link segment, etc. 4073 3.16. Multicast 4075 Clients provide an IGMP (IPv4) [RFC2236] or MLD (IPv6) [RFC3810] 4076 proxy service for its ENETs and/or hosted applications [RFC4605] and 4077 act as a Protocol Independent Multicast - Sparse-Mode (PIM-SM, or 4078 simply "PIM") Designated Router (DR) [RFC7761] on the OMNI link. 4079 Proxy/Servers act as OMNI link PIM routers for Clients on ANET, VPNed 4080 or Direct interfaces, and Relays also act as OMNI link PIM routers on 4081 behalf of nodes on other links/networks. 4083 Clients on VPNed, Direct or ANET underlay interfaces for which the 4084 ANET has deployed native multicast services forward IGMP/MLD messages 4085 into the ANET. The IGMP/MLD messages may be further forwarded by a 4086 first-hop ANET access router acting as an IGMP/MLD-snooping switch 4087 [RFC4541], then ultimately delivered to an ANET Proxy/Server. The 4088 FHS Proxy/Server then acts as an ARS to send NS(AR) messages to an 4089 ARR for the multicast source. Clients on INET and ANET underlay 4090 interfaces without native multicast services instead send NS(AR) 4091 messages as an ARS to cause their FHS Proxy/Server forward the 4092 message to an ARR. When the ARR prepares an NA(AR) response, it 4093 initiates PIM protocol messaging according to the Source-Specific 4094 Multicast (SSM) and Any-Source Multicast (ASM) operational modes as 4095 discussed in the following sections. 4097 3.16.1. Source-Specific Multicast (SSM) 4099 When an ARS "X" (i.e., either a Client or Proxy/Server) acting as PIM 4100 router receives a Join/Prune message from a node on its downstream 4101 interfaces containing one or more ((S)ource, (G)roup) pairs, it 4102 updates its Multicast Routing Information Base (MRIB) accordingly. 4103 For each S belonging to a prefix reachable via X's non-OMNI 4104 interfaces, X then forwards the (S, G) Join/Prune to any PIM routers 4105 on those interfaces per [RFC7761]. 4107 For each S belonging to a prefix reachable via X's OMNI interface, X 4108 sends an NS(AR) message (see: Section 3.13) using its own ULA or XLA 4109 as the source address, the solicited node multicast address 4110 corresponding to S as the destination and the XLA of S as the target 4111 address. X then encapsulates the NS(AR) in an OAL header with source 4112 address set to its own ULA and destination address set to the ULA for 4113 S, then forwards the message into the secured spanning tree which 4114 delivers it to ARR "Y" that services S. The resulting NA(AR) will 4115 return an OMNI option with Interface Attributes for any underlay 4116 interfaces that are currently servicing S. 4118 When X processes the NA(AR) it selects one or more underlay 4119 interfaces for S and performs an NS/NA multilink route optimization 4120 exchange over the secured spanning tree while including a PIM Join/ 4121 Prune message for each multicast group of interest in the OMNI 4122 option. If S is located behind any Proxys "Z"*, each Z* then updates 4123 its MRIB accordingly and maintains the XLA of X as the next hop in 4124 the reverse path. Since Gateways forward messages not addressed to 4125 themselves without examining them, this means that the (reverse) 4126 multicast tree path is simply from each Z* (and/or S) to X with no 4127 other multicast-aware routers in the path. 4129 Following the initial combined Join/Prune and NS/NA messaging, X 4130 maintains a NCE for each S the same as if X was sending unicast data 4131 traffic to S. In particular, X performs additional NS/NA exchanges 4132 to keep the NCE alive for up to t_periodic seconds [RFC7761]. If no 4133 new Joins are received within t_periodic seconds, X allows the NCE to 4134 expire. Finally, if X receives any additional Join/Prune messages 4135 for (S,G) it forwards the messages over the secured spanning tree. 4137 Client C that holds an MNP for source S may later depart from a first 4138 Proxy/Server Z1 and/or connect via a new Proxy/Server Z2. In that 4139 case, Y sends a uNA message to X the same as specified for unicast 4140 mobility in Section 3.15. When X receives the uNA message, it 4141 updates its NCE for the XLA for source S and sends new Join messages 4142 in NS/NA exchanges addressed to the new target Client underlay 4143 interface connection for S. There is no requirement to send any 4144 Prune messages to old Proxy/Server Z1 since source S will no longer 4145 source any multicast data traffic via Z1. Instead, the multicast 4146 state for (S,G) in Proxy/Server Z1 will soon expire since no new 4147 Joins will arrive. 4149 3.16.2. Any-Source Multicast (ASM) 4151 When an ARS X acting as a PIM router receives Join/Prune messages 4152 from a node on its downstream interfaces containing one or more (*,G) 4153 pairs, it updates its Multicast Routing Information Base (MRIB) 4154 accordingly. X first performs an NS/NA(AR) exchange to receive 4155 address resolution information for Rendezvous Point (RP) R for each 4156 G. X then includes a copy of each Join/Prune message in the OMNI 4157 option of an NS message with its own ULA or XLA as the source address 4158 and the ULA or XLA for R as the destination address, then 4159 encapsulates the NS message in an OAL header with its own ULA as the 4160 source and the ULA of R's Proxy/Server as the destination then sends 4161 the message into the secured spanning tree. 4163 For each source S that sends multicast traffic to group G via R, 4164 Client S* that aggregates S (or its Proxy/Server) encapsulates the 4165 original IP packets in PIM Register messages, includes the PIM 4166 Register messages in the OMNI options of uNA messages, performs OAL 4167 encapsulation and fragmentation then forwards the resulting carrier 4168 packets with Identification values within the receive window for 4169 Client R* that aggregates R. Client R* may then elect to send a PIM 4170 Join to S* in the OMNI option of a uNA over the secured spanning 4171 tree. This will result in an (S,G) tree rooted at S* with R as the 4172 next hop so that R will begin to receive two copies of the original 4173 IP packet; one native copy from the (S, G) tree and a second copy 4174 from the pre-existing (*, G) tree that still uses uNA PIM Register 4175 encapsulation. R can then issue a uNA PIM Register-stop message over 4176 the secured spanning tree to suppress the Register-encapsulated 4177 stream. At some later time, if Client S* moves to a new Proxy/ 4178 Server, it resumes sending original IP packets via uNA PIM Register 4179 encapsulation via the new Proxy/Server. 4181 At the same time, as multicast listeners discover individual S's for 4182 a given G, they can initiate an (S,G) Join for each S under the same 4183 procedures discussed in Section 3.16.1. Once the (S,G) tree is 4184 established, the listeners can send (S, G) Prune messages to R so 4185 that multicast original IP packets for group G sourced by S will only 4186 be delivered via the (S, G) tree and not from the (*, G) tree rooted 4187 at R. All mobility considerations discussed for SSM apply. 4189 3.16.3. Bi-Directional PIM (BIDIR-PIM) 4191 Bi-Directional PIM (BIDIR-PIM) [RFC5015] provides an alternate 4192 approach to ASM that treats the Rendezvous Point (RP) as a Designated 4193 Forwarder (DF). Further considerations for BIDIR-PIM are out of 4194 scope. 4196 3.17. Operation over Multiple OMNI Links 4198 An AERO Client can connect to multiple OMNI links the same as for any 4199 data link service. In that case, the Client maintains a distinct 4200 OMNI interface for each link, e.g., 'omni0' for the first link, 4201 'omni1' for the second, 'omni2' for the third, etc. Each OMNI link 4202 would include its own distinct set of Gateways and Proxy/Servers, 4203 thereby providing redundancy in case of failures. 4205 Each OMNI link could utilize the same or different ANET connections. 4206 The links can be distinguished at the link-layer via the SRT prefix 4207 in a similar fashion as for Virtual Local Area Network (VLAN) tagging 4208 (e.g., IEEE 802.1Q) and/or through assignment of distinct sets of 4209 MSPs on each link. This gives rise to the opportunity for supporting 4210 multiple redundant networked paths (see: Section 3.2.4). 4212 The Client's IP layer can select the outgoing OMNI interface 4213 appropriate for a given traffic profile while (in the reverse 4214 direction) correspondent nodes must have some way of steering their 4215 original IP packets destined to a target via the correct OMNI link. 4217 In a first alternative, if each OMNI link services different MSPs the 4218 Client can receive a distinct MNP from each of the links. IP routing 4219 will therefore assure that the correct OMNI link is used for both 4220 outbound and inbound traffic. This can be accomplished using 4221 existing technologies and approaches, and without requiring any 4222 special supporting code in correspondent nodes or Gateways. 4224 In a second alternative, if each OMNI link services the same MSP(s) 4225 then each link could assign a distinct "OMNI link Anycast" address 4226 that is configured by all Gateways on the link. Correspondent nodes 4227 can then perform Segment Routing to select the correct SRT, which 4228 will then direct the original IP packet over multiple hops to the 4229 target. 4231 3.18. DNS Considerations 4233 AERO Client MNs and INET correspondent nodes consult the Domain Name 4234 System (DNS) the same as for any Internetworking node. When 4235 correspondent nodes and Client MNs use different IP protocol versions 4236 (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain 4237 A records for IPv4 address mappings to MNs which must then be 4238 populated in Relay NAT64 mapping caches. In that way, an IPv4 4239 correspondent node can send original IPv4 packets to the IPv4 address 4240 mapping of the target MN, and the Relay will translate the IPv4 4241 header and destination address into an IPv6 header and IPv6 4242 destination address of the MN. 4244 When an AERO Client registers with an AERO Proxy/Server, the Proxy/ 4245 Server can return the address(es) of DNS servers in RDNSS options 4246 [RFC6106]. The DNS server provides the IP addresses of other MNs and 4247 correspondent nodes in AAAA records for IPv6 or A records for IPv4. 4249 3.19. Transition/Coexistence Considerations 4251 OAL encapsulation ensures that dissimilar INET partitions can be 4252 joined into a single unified OMNI link, even though the partitions 4253 themselves may have differing protocol versions and/or incompatible 4254 addressing plans. However, a commonality can be achieved by 4255 incrementally distributing globally routable (i.e., native) IP 4256 prefixes to eventually reach all nodes (both mobile and fixed) in all 4257 OMNI link segments. This can be accomplished by incrementally 4258 deploying AERO Gateways on each INET partition, with each Gateway 4259 distributing its MNPs and/or discovering non-MNP IP GUA prefixes on 4260 its INET links. 4262 This gives rise to the opportunity to eventually distribute native IP 4263 addresses to all nodes, and to present a unified OMNI link view even 4264 if the INET partitions remain in their current protocol and 4265 addressing plans. In that way, the OMNI link can serve the dual 4266 purpose of providing a mobility/multilink service and a transition/ 4267 coexistence service. Or, if an INET partition is transitioned to a 4268 native IP protocol version and addressing scheme that is compatible 4269 with the OMNI link MNP-based addressing scheme, the partition and 4270 OMNI link can be joined by Gateways. 4272 Relays that connect INETs/ENETs with dissimilar IP protocol versions 4273 may need to employ a network address and protocol translation 4274 function such as NAT64 [RFC6146]. 4276 3.20. Proxy/Server-Gateway Bidirectional Forwarding Detection 4278 In environments where rapid failure recovery is required, Proxy/ 4279 Servers and Gateways SHOULD use Bidirectional Forwarding Detection 4280 (BFD) [RFC5880]. Nodes that use BFD can quickly detect and react to 4281 failures so that cached information is re-established through 4282 alternate nodes. BFD control messaging is carried only over well- 4283 connected ground domain networks (i.e., and not low-end radio links) 4284 and can therefore be tuned for rapid response. 4286 Proxy/Servers and Gateways maintain BFD sessions in parallel with 4287 their BGP peerings. If a Proxy/Server or Gateway fails, BGP peers 4288 will quickly re-establish routes through alternate paths the same as 4289 for common BGP deployments. 4291 3.21. Time-Varying MNPs 4293 In some use cases, it is desirable, beneficial and efficient for the 4294 Client to receive a constant MNP that travels with the Client 4295 wherever it moves. For example, this would allow air traffic 4296 controllers to easily track aircraft, etc. In other cases, however 4297 (e.g., intelligent transportation systems), the MN may be willing to 4298 sacrifice a modicum of efficiency in order to have time-varying MNPs 4299 that can be changed every so often to defeat adversarial tracking. 4301 The DHCPv6 service offers a way for Clients that desire time-varying 4302 MNPs to obtain short-lived prefixes (e.g., on the order of a small 4303 number of minutes). In that case, the identity of the Client would 4304 not be bound to the MNP but rather to a Node Identification value 4305 (see: [I-D.templin-6man-omni]) to be used as the Client ID seed for 4306 MNP prefix delegation. The Client would then be obligated to 4307 renumber its internal networks whenever its MNP (and therefore also 4308 its XLA) changes. This should not present a challenge for Clients 4309 with automated network renumbering services, however presents limits 4310 for the durations of ongoing sessions that would prefer to use a 4311 constant address. 4313 4. Implementation Status 4315 An early AERO implementation based on OpenVPN (https://openvpn.net/) 4316 was announced on the v6ops mailing list on January 10, 2018 and an 4317 initial public release of the AERO proof-of-concept source code was 4318 announced on the intarea mailing list on August 21, 2015. 4320 Many AERO/OMNI functions are implemented and undergoing final 4321 integration. OAL fragmentation/reassembly buffer management code has 4322 been cleared for public release. 4324 5. IANA Considerations 4326 The IANA has assigned the UDP port number "8060" for an earlier 4327 experimental first version of AERO [RFC6706]. This document together 4328 with [I-D.templin-6man-omni] reclaims UDP port number "8060" as the 4329 service port for UDP/IP encapsulation. This document makes no 4330 request of IANA, since [I-D.templin-6man-omni] already provides 4331 instructions. (Note: although [RFC6706] was not widely implemented 4332 or deployed, it need not be obsoleted since its messages use the 4333 invalid ICMPv6 message type number '0' which implementations of this 4334 specification can easily distinguish and ignore.) 4336 No further IANA actions are required. 4338 6. Security Considerations 4340 AERO Gateways configure underlay interface secured tunnels with AERO 4341 Proxy/Servers and Relays within their local OMNI link segments. 4342 Applicable secured tunnel alternatives include IPsec [RFC4301], TLS/ 4343 SSL [RFC8446], DTLS [RFC6347], WireGuard [WG], etc. The AERO 4344 Gateways of all OMNI link segments in turn configure underlay 4345 interface secured tunnels with neighboring AERO Gateways for other 4346 OMNI link segments in a secured spanning tree topology. Therefore, 4347 control messages exchanged between any pair of OMNI link neighbors 4348 over the secured spanning tree are already protected. (Note that 4349 this inter-segment Gateway arrangement mirrors the "half-gateway" 4350 model discussed in the original Catenet proposal.) 4352 To prevent unauthorized local applications from congesting the 4353 secured spanning tree, Proxy/Servers and Gateways should configure 4354 local firewall settings to permit only the BGP protocol service 4355 daemon to source packets with the ULA assigned to the OMNI interface 4356 as the source and the ULA of a neighboring Proxy/Server or Gateway as 4357 the destination. This could be implemented as a port/address 4358 filtering configuration that permits only TCP port 179 (as defined in 4359 the IANA Service Names and Port Numbers registry for the Border 4360 Gateway Protocol (bgp)) when using the ULA assigned to the OMNI 4361 interface. 4363 To prevent spoofing vectors, Proxy/Servers MUST discard without 4364 responding to any unsecured NS/NA(AR) messages. Also, Proxy/Servers 4365 MUST discard without forwarding any original IP packets received from 4366 one of their own Clients (whether directly or following OAL 4367 reassembly) with a source address that does not match the Client's 4368 MNP and/or a destination address that does match the Client's MNP. 4369 Finally, Proxy/Servers MUST discard without forwarding any carrier 4370 packets with an OAL source and destination that both match the same 4371 MNP. 4373 For INET partitions that require strong security in the data plane, 4374 two options for securing communications include 1) disable route 4375 optimization so that all traffic is conveyed over the secured 4376 spanning tree, or 2) enable on-demand secure tunnel creation between 4377 Client neighbors. Option 1) would result in longer routes than 4378 necessary and impose traffic concentration on critical infrastructure 4379 elements. Option 2) could be coordinated between Clients using NS/NA 4380 messages with OMNI Host Identity Protocol (HIP) "Initiator/Responder" 4381 message sub-options [RFC7401][I-D.templin-6man-omni] to create a 4382 secured tunnel on-demand, or to use the QUIC-TLS protocol to 4383 establish a secured connection [RFC9000][RFC9001][RFC9002]. 4385 AERO Clients that connect to secured ANETs need not apply security to 4386 their IPv6 ND messages, since the messages will be authenticated and 4387 forwarded by a perimeter Proxy/Server that applies security on its 4388 INET-facing interface as part of the secured spanning tree (see 4389 above). AERO Clients connected to the open INET can use network and/ 4390 or transport layer security services such as VPNs or can by some 4391 other means establish a direct link to a Proxy/Server. When a VPN or 4392 direct link may be impractical, however, INET Clients and Proxy/ 4393 Servers SHOULD include and verify authentication signatures for their 4394 IPv6 ND messages as specified in [I-D.templin-6man-omni]. 4396 Application endpoints SHOULD use transport-layer (or higher-layer) 4397 security services such as QUIC-TLS, TLS/SSL, DTLS or SSH [RFC4251] to 4398 assure the same level of protection as for critical secured Internet 4399 services. AERO Clients that require host-based VPN services SHOULD 4400 use network and/or transport layer security services such as IPsec, 4401 TLS/SSL, DTLS, etc. AERO Proxys and Proxy/Servers can also provide a 4402 network-based VPN service on behalf of the Client, e.g., if the 4403 Client is located within a secured enclave and cannot establish a VPN 4404 on its own behalf. 4406 AERO Proxy/Servers and Gateways present targets for traffic 4407 amplification Denial of Service (DoS) attacks. This concern is no 4408 different than for widely-deployed VPN security gateways in the 4409 Internet, where attackers could send spoofed packets to the gateways 4410 at high data rates. This can be mitigated through the AERO/OMNI data 4411 origin authentication procedures, as well as connecting Proxy/Servers 4412 and Gateways over dedicated links with no connections to the Internet 4413 and/or when connections to the Internet are only permitted through 4414 well-managed firewalls. Traffic amplification DoS attacks can also 4415 target an AERO Client's low data rate links. This is a concern not 4416 only for Clients located on the open Internet but also for Clients in 4417 secured enclaves. AERO Proxy/Servers and Proxys can institute rate 4418 limits that protect Clients from receiving packet floods that could 4419 DoS low data rate links. 4421 AERO Relays must implement ingress filtering to avoid a spoofing 4422 attack in which spurious messages with ULA addresses are injected 4423 into an OMNI link from an outside attacker. AERO Clients MUST ensure 4424 that their connectivity is not used by unauthorized nodes on their 4425 ENETs to gain access to a protected network, i.e., AERO Clients that 4426 act as routers MUST NOT provide routing services for unauthorized 4427 nodes. (This concern is no different than for ordinary hosts that 4428 receive an IP address delegation but then "share" the address with 4429 other nodes via some form of Internet connection sharing such as 4430 tethering.) 4432 The PRL MUST be well-managed and secured from unauthorized tampering, 4433 even though the list contains only public information. The PRL can 4434 be conveyed to the Client in a similar fashion as in [RFC5214] (e.g., 4435 through layer 2 data link login messaging, secure upload of a static 4436 file, DNS lookups, etc.). 4438 The AERO service for open INET Clients depends on a public key 4439 distribution service in which Client public keys and identities are 4440 maintained in a shared database accessible to all open INET Proxy/ 4441 Servers. Similarly, each Client must be able to determine the public 4442 key of each Proxy/Server, e.g. by consulting an online database. 4443 When AERO nodes register their public keys indexed by a unique Host 4444 Identity Tag (HIT) [RFC7401] in a distributed database such as the 4445 DNS, and use the HIT as an identity for applying IPv6 ND message 4446 authentication signatures, a means for determining public key 4447 attestation is available. 4449 Security considerations for IPv6 fragmentation and reassembly are 4450 discussed in [I-D.templin-6man-omni]. In environments where spoofing 4451 is considered a threat, OAL nodes SHOULD employ Identification window 4452 synchronization and OAL destinations SHOULD configure an (end-system- 4453 based) firewall. 4455 SRH authentication facilities are specified in [RFC8754]. Security 4456 considerations for accepting link-layer ICMP messages and reflected 4457 packets are discussed throughout the document. 4459 7. Acknowledgements 4461 Discussions in the IETF, aviation standards communities and private 4462 exchanges helped shape some of the concepts in this work. 4463 Individuals who contributed insights include Mikael Abrahamsson, Mark 4464 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Scott Burleigh, 4465 Brian Carpenter, Wojciech Dec, Pavel Drasil, Ralph Droms, Adrian 4466 Farrel, Nick Green, Sri Gundavelli, Brian Haberman, Bernhard Haindl, 4467 Joel Halpern, Tom Herbert, Bob Hinden, Sascha Hlusiak, Lee Howard, 4468 Christian Huitema, Zdenek Jaron, Andre Kostur, Hubert Kuenig, Eliot 4469 Lear, Ted Lemon, Andy Malis, Satoru Matsushima, Tomek Mrugalski, 4470 Thomas Narten, Madhu Niraula, Alexandru Petrescu, Behcet Saikaya, 4471 Michal Skorepa, Dave Thaler, Joe Touch, Bernie Volz, Ryuji Wakikawa, 4472 Tony Whyman, Lloyd Wood and James Woodyatt. Members of the IESG also 4473 provided valuable input during their review process that greatly 4474 improved the document. Special thanks go to Stewart Bryant, Joel 4475 Halpern and Brian Haberman for their shepherding guidance during the 4476 publication of the AERO first edition. 4478 This work has further been encouraged and supported by Boeing 4479 colleagues including Akash Agarwal, Kyle Bae, M. Wayne Benson, Dave 4480 Bernhardt, Cam Brodie, John Bush, Balaguruna Chidambaram, Irene Chin, 4481 Bruce Cornish, Claudiu Danilov, Don Dillenburg, Joe Dudkowski, Wen 4482 Fang, Samad Farooqui, Anthony Gregory, Jeff Holland, Seth Jahne, 4483 Brian Jaury, Greg Kimberly, Ed King, Madhuri Madhava Badgandi, Laurel 4484 Matthew, Gene MacLean III, Kyle Mikos, Rob Muszkiewicz, Sean 4485 O'Sullivan, Satish Raghavendran, Vijay Rajagopalan, Greg Saccone, 4486 Bhargava Raman Sai Prakash, Rod Santiago, Madhanmohan Savadamuthu, 4487 Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Katie Tran, 4488 Brendan Williams, Amelia Wilson, Julie Wulff, Yueli Yang, Eric Yeh 4489 and other members of the Boeing mobility, networking and autonomy 4490 teams. Akash Agarwal, Kyle Bae, Wayne Benson, Madhuri Madhava 4491 Badgandi, Vijayasarathy Rajagopalan, Bhargava Raman Sai Prakash, 4492 Katie Tran and Eric Yeh are especially acknowledged for their work on 4493 the AERO implementation. Chuck Klabunde is honored and remembered 4494 for his early leadership, and we mourn his untimely loss. 4496 This work was inspired by the support and encouragement of countless 4497 outstanding colleagues, managers and program directors over the span 4498 of many decades. Beginning in the late 1980s,' the Digital Equipment 4499 Corporation (DEC) Ultrix Engineering and DECnet Architects groups 4500 identified early issues with fragmentation and bridging links with 4501 diverse MTUs. In the early 1990s, engagements at DEC Project Sequoia 4502 at UC Berkeley and the DEC Western Research Lab in Palo Alto included 4503 investigations into large-scale networked filesystems, ATM vs 4504 Internet and network security proxys. In the mid-1990s to early 4505 2000s employment at the NASA Ames Research Center (Sterling Software) 4506 and SRI International supported early investigations of IPv6, ONR UAV 4507 Communications and the IETF. An employment at Nokia where important 4508 IETF documents were published gave way to a present-day engagement 4509 with The Boeing Company. The work matured at Boeing through major 4510 programs including Future Combat Systems, Advanced Airplane Program, 4511 DTN for the International Space Station, Mobility Vision Lab, CAST, 4512 Caravan, Airplane Internet of Things, the NASA UAS/CNS program, the 4513 FAA/ICAO ATN/IPS program and many others. An attempt to name all who 4514 gave support and encouragement would double the current document size 4515 and result in many unintentional omissions - but to all a humble 4516 thanks. 4518 Earlier works on NBMA tunneling approaches are found in 4519 [RFC2529][RFC5214][RFC5569]. 4521 Many of the constructs presented in this second edition of AERO are 4522 based on the author's earlier works, including: 4524 * The Internet Routing Overlay Network (IRON) 4525 [RFC6179][I-D.templin-ironbis] 4527 * Virtual Enterprise Traversal (VET) 4528 [RFC5558][I-D.templin-intarea-vet] 4530 * The Subnetwork Encapsulation and Adaptation Layer (SEAL) 4531 [RFC5320][I-D.templin-intarea-seal] 4533 * AERO, First Edition [RFC6706] 4535 Note that these works cite numerous earlier efforts that are not also 4536 cited here due to space limitations. The authors of those earlier 4537 works are acknowledged for their insights. 4539 This work is aligned with the NASA Safe Autonomous Systems Operation 4540 (SASO) program under NASA contract number NNA16BD84C. 4542 This work is aligned with the FAA as per the SE2025 contract number 4543 DTFAWA-15-D-00030. 4545 This work is aligned with the Boeing Commercial Airplanes (BCA) 4546 Internet of Things (IoT) and autonomy programs. 4548 This work is aligned with the Boeing Information Technology (BIT) 4549 MobileNet program. 4551 8. References 4553 8.1. Normative References 4555 [I-D.templin-6man-omni] 4556 Templin, F. L., "Transmission of IP Packets over Overlay 4557 Multilink Network (OMNI) Interfaces", Work in Progress, 4558 Internet-Draft, draft-templin-6man-omni-63, 13 June 2022, 4559 . 4562 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4563 DOI 10.17487/RFC0791, September 1981, 4564 . 4566 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 4567 RFC 792, DOI 10.17487/RFC0792, September 1981, 4568 . 4570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4571 Requirement Levels", BCP 14, RFC 2119, 4572 DOI 10.17487/RFC2119, March 1997, 4573 . 4575 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 4576 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 4577 December 1998, . 4579 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 4580 "SEcure Neighbor Discovery (SEND)", RFC 3971, 4581 DOI 10.17487/RFC3971, March 2005, 4582 . 4584 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 4585 RFC 3972, DOI 10.17487/RFC3972, March 2005, 4586 . 4588 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 4589 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 4590 November 2005, . 4592 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 4593 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 4594 . 4596 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 4597 Network Address Translations (NATs)", RFC 4380, 4598 DOI 10.17487/RFC4380, February 2006, 4599 . 4601 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 4602 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 4603 DOI 10.17487/RFC4861, September 2007, 4604 . 4606 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 4607 Address Autoconfiguration", RFC 4862, 4608 DOI 10.17487/RFC4862, September 2007, 4609 . 4611 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 4612 DOI 10.17487/RFC6081, January 2011, 4613 . 4615 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 4616 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 4617 RFC 7401, DOI 10.17487/RFC7401, April 2015, 4618 . 4620 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 4621 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 4622 February 2016, . 4624 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4625 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4626 May 2017, . 4628 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4629 (IPv6) Specification", STD 86, RFC 8200, 4630 DOI 10.17487/RFC8200, July 2017, 4631 . 4633 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 4634 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 4635 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 4636 RFC 8415, DOI 10.17487/RFC8415, November 2018, 4637 . 4639 8.2. Informative References 4641 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 4642 2016. 4644 [EUI] IEEE, I., "Guidelines for Use of Extended Unique 4645 Identifier (EUI), Organizationally Unique Identifier 4646 (OUI), and Company ID, https://standards.ieee.org/wp- 4647 content/uploads/import/documents/tutorials/eui.pdf", 3 4648 August 2017. 4650 [I-D.bonica-6man-comp-rtg-hdr] 4651 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 4652 Jalil, "The IPv6 Compact Routing Header (CRH)", Work in 4653 Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- 4654 28, 18 May 2022, . 4657 [I-D.bonica-6man-crh-helper-opt] 4658 Li, X., Bao, C., Ruan, E., and R. Bonica, "Compressed 4659 Routing Header (CRH) Helper Option", Work in Progress, 4660 Internet-Draft, draft-bonica-6man-crh-helper-opt-04, 11 4661 October 2021, . 4664 [I-D.ietf-intarea-frag-fragile] 4665 Bonica, R., Baker, F., Huston, G., Hinden, R. M., Troan, 4666 O., and F. Gont, "IP Fragmentation Considered Fragile", 4667 Work in Progress, Internet-Draft, draft-ietf-intarea-frag- 4668 fragile-17, 30 September 2019, 4669 . 4672 [I-D.ietf-intarea-tunnels] 4673 Touch, J. and M. Townsley, "IP Tunnels in the Internet 4674 Architecture", Work in Progress, Internet-Draft, draft- 4675 ietf-intarea-tunnels-10, 12 September 2019, 4676 . 4679 [I-D.ietf-ipwave-vehicular-networking] 4680 Jeong, J. P., "IPv6 Wireless Access in Vehicular 4681 Environments (IPWAVE): Problem Statement and Use Cases", 4682 Work in Progress, Internet-Draft, draft-ietf-ipwave- 4683 vehicular-networking-29, 19 May 2022, 4684 . 4687 [I-D.ietf-rtgwg-atn-bgp] 4688 Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. 4689 Moreno, "A Simple BGP-based Mobile Routing System for the 4690 Aeronautical Telecommunications Network", Work in 4691 Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-18, 14 4692 June 2022, . 4695 [I-D.templin-6man-dhcpv6-ndopt] 4696 Templin, F. L., "A Unified Stateful/Stateless 4697 Configuration Service for IPv6", Work in Progress, 4698 Internet-Draft, draft-templin-6man-dhcpv6-ndopt-11, 1 4699 January 2021, . 4702 [I-D.templin-intarea-seal] 4703 Templin, F. L., "The Subnetwork Encapsulation and 4704 Adaptation Layer (SEAL)", Work in Progress, Internet- 4705 Draft, draft-templin-intarea-seal-68, 3 January 2014, 4706 . 4709 [I-D.templin-intarea-vet] 4710 Templin, F. L., "Virtual Enterprise Traversal (VET)", Work 4711 in Progress, Internet-Draft, draft-templin-intarea-vet-40, 4712 3 May 2013, . 4715 [I-D.templin-ipwave-uam-its] 4716 Templin, F. L., "Urban Air Mobility Implications for 4717 Intelligent Transportation Systems", Work in Progress, 4718 Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January 4719 2021, . 4722 [I-D.templin-ironbis] 4723 Templin, F. L., "The Interior Routing Overlay Network 4724 (IRON)", Work in Progress, Internet-Draft, draft-templin- 4725 ironbis-16, 28 March 2014, 4726 . 4729 [I-D.templin-v6ops-pdhost] 4730 Templin, F. L., "IPv6 Prefix Delegation and Multi- 4731 Addressing Models", Work in Progress, Internet-Draft, 4732 draft-templin-v6ops-pdhost-27, 1 January 2021, 4733 . 4736 [IEN48] Cerf, V., "The Catenet Model For Internetworking, 4737 https://www.rfc-editor.org/ien/ien48.txt", July 1978. 4739 [IEN48-2] Cerf, V., "The Catenet Model For Internetworking (with 4740 figures), http://www.postel.org/ien/pdf/ien048.pdf", July 4741 1978. 4743 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 4745 [RFC1035] Mockapetris, P., "Domain names - implementation and 4746 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4747 November 1987, . 4749 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", 4750 RFC 1256, DOI 10.17487/RFC1256, September 1991, 4751 . 4753 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 4754 RFC 1812, DOI 10.17487/RFC1812, June 1995, 4755 . 4757 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 4758 J., and E. Lear, "Address Allocation for Private 4759 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 4760 February 1996, . 4762 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 4763 DOI 10.17487/RFC2003, October 1996, 4764 . 4766 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4767 DOI 10.17487/RFC2004, October 1996, 4768 . 4770 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 4771 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 4772 . 4774 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 4775 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 4776 . 4778 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 4779 Domains without Explicit Tunnels", RFC 2529, 4780 DOI 10.17487/RFC2529, March 1999, 4781 . 4783 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4784 RFC 2983, DOI 10.17487/RFC2983, October 2000, 4785 . 4787 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4788 of Explicit Congestion Notification (ECN) to IP", 4789 RFC 3168, DOI 10.17487/RFC3168, September 2001, 4790 . 4792 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 4793 DOI 10.17487/RFC3330, September 2002, 4794 . 4796 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 4797 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 4798 DOI 10.17487/RFC3810, June 2004, 4799 . 4801 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4802 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4803 DOI 10.17487/RFC4122, July 2005, 4804 . 4806 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 4807 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 4808 January 2006, . 4810 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 4811 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 4812 DOI 10.17487/RFC4271, January 2006, 4813 . 4815 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4816 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4817 2006, . 4819 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4820 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 4821 December 2005, . 4823 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 4824 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 4825 2006, . 4827 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 4828 Control Message Protocol (ICMPv6) for the Internet 4829 Protocol Version 6 (IPv6) Specification", STD 89, 4830 RFC 4443, DOI 10.17487/RFC4443, March 2006, 4831 . 4833 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 4834 Protocol (LDAP): The Protocol", RFC 4511, 4835 DOI 10.17487/RFC4511, June 2006, 4836 . 4838 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 4839 "Considerations for Internet Group Management Protocol 4840 (IGMP) and Multicast Listener Discovery (MLD) Snooping 4841 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 4842 . 4844 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 4845 "Internet Group Management Protocol (IGMP) / Multicast 4846 Listener Discovery (MLD)-Based Multicast Forwarding 4847 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 4848 August 2006, . 4850 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 4851 Algorithms in Cryptographically Generated Addresses 4852 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 4853 . 4855 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 4856 "Bidirectional Protocol Independent Multicast (BIDIR- 4857 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 4858 . 4860 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 4861 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 4862 DOI 10.17487/RFC5214, March 2008, 4863 . 4865 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 4866 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 4867 February 2010, . 4869 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 4870 Route Optimization Requirements for Operational Use in 4871 Aeronautics and Space Exploration Mobile Networks", 4872 RFC 5522, DOI 10.17487/RFC5522, October 2009, 4873 . 4875 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 4876 RFC 5558, DOI 10.17487/RFC5558, February 2010, 4877 . 4879 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 4880 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 4881 January 2010, . 4883 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 4884 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 4885 . 4887 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 4888 "IPv6 Router Advertisement Options for DNS Configuration", 4889 RFC 6106, DOI 10.17487/RFC6106, November 2010, 4890 . 4892 [RFC6139] Russert, S., Ed., Fleischman, E., Ed., and F. Templin, 4893 Ed., "Routing and Addressing in Networks with Global 4894 Enterprise Recursion (RANGER) Scenarios", RFC 6139, 4895 DOI 10.17487/RFC6139, February 2011, 4896 . 4898 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4899 NAT64: Network Address and Protocol Translation from IPv6 4900 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4901 April 2011, . 4903 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 4904 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 4905 . 4907 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 4908 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 4909 DOI 10.17487/RFC6221, May 2011, 4910 . 4912 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 4913 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 4914 DOI 10.17487/RFC6273, June 2011, 4915 . 4917 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4918 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4919 January 2012, . 4921 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 4922 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 4923 DOI 10.17487/RFC6355, August 2011, 4924 . 4926 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 4927 for Equal Cost Multipath Routing and Link Aggregation in 4928 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 4929 . 4931 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 4932 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 4933 . 4935 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 4936 UDP Checksums for Tunneled Packets", RFC 6935, 4937 DOI 10.17487/RFC6935, April 2013, 4938 . 4940 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 4941 for the Use of IPv6 UDP Datagrams with Zero Checksums", 4942 RFC 6936, DOI 10.17487/RFC6936, April 2013, 4943 . 4945 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 4946 Korhonen, "Requirements for Distributed Mobility 4947 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 4948 . 4950 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 4951 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 4952 Multicast - Sparse Mode (PIM-SM): Protocol Specification 4953 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 4954 2016, . 4956 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 4957 Decraene, B., Litkowski, S., and R. Shakir, "Segment 4958 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 4959 July 2018, . 4961 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4962 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4963 . 4965 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 4966 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 4967 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 4968 . 4970 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 4971 Multiplexed and Secure Transport", RFC 9000, 4972 DOI 10.17487/RFC9000, May 2021, 4973 . 4975 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 4976 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 4977 . 4979 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 4980 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 4981 May 2021, . 4983 [WG] Wireguard, "WireGuard, https://www.wireguard.com", August 4984 2020. 4986 Appendix A. Non-Normative Considerations 4988 AERO can be applied to a multitude of Internetworking scenarios, with 4989 each having its own adaptations. The following considerations are 4990 provided as non-normative guidance: 4992 A.1. Implementation Strategies for Route Optimization 4994 Address resolution and route optimization as discussed in 4995 Section 3.13 results in the creation of NCEs. The NCE state is set 4996 to REACHABLE for at most ReachableTime seconds. In order to refresh 4997 the NCE lifetime before the ReachableTime timer expires, the 4998 specification requires implementations to issue a new NS/NA(AR) 4999 exchange to reset ReachableTime while data packets are still flowing. 5000 However, the decision of when to initiate a new NS/NA(AR) exchange 5001 and to perpetuate the process is left as an implementation detail. 5003 One possible strategy may be to monitor the NCE watching for data 5004 packets for (ReachableTime - 5) seconds. If any data packets have 5005 been sent to the neighbor within this timeframe, then send an NS(AR) 5006 to receive a new NA(AR). If no data packets have been sent, wait for 5007 5 additional seconds and send an immediate NS(AR) if any data packets 5008 are sent within this "expiration pending" 5 second window. If no 5009 additional data packets are sent within the 5 second window, reset 5010 the NCE state to STALE. 5012 The monitoring of the neighbor data packet traffic therefore becomes 5013 an ongoing process during the NCE lifetime. If the NCE expires, 5014 future data packets will trigger a new NS/NA(AR) exchange while the 5015 packets themselves are delivered over a longer path until route 5016 optimization state is re-established. 5018 A.2. Implicit Mobility Management 5020 OMNI interface neighbors MAY provide a configuration option that 5021 allows them to perform implicit mobility management in which no IPv6 5022 ND messaging is used. In that case, the Client only transmits 5023 packets over a single interface at a time, and the neighbor always 5024 observes packets arriving from the Client from the same link-layer 5025 source address. 5027 If the Client's underlay interface address changes (either due to a 5028 readdressing of the original interface or switching to a new 5029 interface) the neighbor immediately updates the NCE for the Client 5030 and begins accepting and sending packets according to the Client's 5031 new address. This implicit mobility method applies to use cases such 5032 as cellphones with both WiFi and Cellular interfaces where only one 5033 of the interfaces is active at a given time, and the Client 5034 automatically switches over to the backup interface if the primary 5035 interface fails. 5037 A.3. Direct Underlying Interfaces 5039 When a Client's OMNI interface is configured over a Direct interface, 5040 the neighbor at the other end of the Direct link can receive packets 5041 without any encapsulation. In that case, the Client sends packets 5042 over the Direct link according to traffic selectors. If the Direct 5043 interface is selected, then the Client's IP packets are transmitted 5044 directly to the peer without going through an ANET/INET. If other 5045 interfaces are selected, then the Client's IP packets are transmitted 5046 via a different interface, which may result in the inclusion of 5047 Proxy/Servers and Gateways in the communications path. Direct 5048 interfaces must be tested periodically for reachability, e.g., via 5049 NUD. 5051 A.4. AERO Critical Infrastructure Considerations 5053 AERO Gateways can be either Commercial off-the Shelf (COTS) standard 5054 IP routers or virtual machines in the cloud. Gateways must be 5055 provisioned, supported and managed by the INET administrative 5056 authority, and connected to the Gateways of other INETs via inter- 5057 domain peerings. Cost for purchasing, configuring and managing 5058 Gateways is nominal even for very large OMNI links. 5060 AERO INET Proxy/Servers can be standard dedicated server platforms, 5061 but most often will be deployed as virtual machines in the cloud. 5062 The only requirements for INET Proxy/Servers are that they can run 5063 the AERO/OMNI code and have at least one network interface connection 5064 to the INET. INET Proxy/Servers must be provisioned, supported and 5065 managed by the INET administrative authority. Cost for purchasing, 5066 configuring and managing cloud Proxy/Servers is nominal especially 5067 for virtual machines. 5069 AERO ANET Proxy/Servers are most often standard dedicated server 5070 platforms with one underlay interface connected to the ANET and a 5071 second interface connected to an INET. As with INET Proxy/Servers, 5072 the only requirements are that they can run the AERO/OMNI code and 5073 have at least one interface connection to the INET. ANET Proxy/ 5074 Servers must be provisioned, supported and managed by the ANET 5075 administrative authority. Cost for purchasing, configuring and 5076 managing Proxys is nominal, and borne by the ANET administrative 5077 authority. 5079 AERO Relays are simply Proxy/Servers connected to INETs and/or ENETs 5080 that provide forwarding services for non-MNP destinations. The Relay 5081 connects to the OMNI link and engages in eBGP peering with one or 5082 more Gateways as a stub AS. The Relay then injects its MNPs and/or 5083 non-MNP prefixes into the BGP routing system, and provisions the 5084 prefixes to its downstream-attached networks. The Relay can perform 5085 ARS/ARR services the same as for any Proxy/Server, and can route 5086 between the MNP and non-MNP address spaces. 5088 A.5. AERO Server Failure Implications 5090 AERO Proxy/Servers may appear as a single point of failure in the 5091 architecture, but such is not the case since all Proxy/Servers on the 5092 link provide identical services and loss of a Proxy/Server does not 5093 imply immediate and/or comprehensive communication failures. Proxy/ 5094 Server failure is quickly detected and conveyed by Bidirectional 5095 Forward Detection (BFD) and/or proactive NUD allowing Clients to 5096 migrate to new Proxy/Servers. 5098 If a Proxy/Server fails, ongoing packet forwarding to Clients will 5099 continue by virtue of the neighbor cache entries that have already 5100 been established through address resolution and route optimization. 5101 If a Client also experiences mobility events at roughly the same time 5102 the Proxy/Server fails, uNA messages may be lost but neighbor cache 5103 entries in the DEPARTED state will ensure that packet forwarding to 5104 the Client's new locations will continue for up to DepartTime 5105 seconds. 5107 If a Client is left without a Proxy/Server for a considerable length 5108 of time (e.g., greater than ReachableTime seconds) then existing 5109 neighbor cache entries will eventually expire and both ongoing and 5110 new communications will fail. The original source will continue to 5111 retransmit until the Client has established a new Proxy/Server 5112 relationship, after which time continuous communications will resume. 5114 Therefore, providing many Proxy/Servers on the link with high 5115 availability profiles provides resilience against loss of individual 5116 Proxy/Servers and assurance that Clients can establish new Proxy/ 5117 Server relationships quickly in event of a Proxy/Server failure. 5119 A.6. AERO Client / Server Architecture 5121 The AERO architectural model is client / server in the control plane, 5122 with route optimization in the data plane. The same as for common 5123 Internet services, the AERO Client discovers the addresses of AERO 5124 Proxy/Servers and connects to one or more of them. The AERO service 5125 is analogous to common Internet services such as google.com, 5126 yahoo.com, cnn.com, etc. However, there is only one AERO service for 5127 the link and all Proxy/Servers provide identical services. 5129 Common Internet services provide differing strategies for advertising 5130 server addresses to clients. The strategy is conveyed through the 5131 DNS resource records returned in response to name resolution queries. 5132 As of January 2020 Internet-based 'nslookup' services were used to 5133 determine the following: 5135 * When a client resolves the domainname "google.com", the DNS always 5136 returns one A record (i.e., an IPv4 address) and one AAAA record 5137 (i.e., an IPv6 address). The client receives the same addresses 5138 each time it resolves the domainname via the same DNS resolver, 5139 but may receive different addresses when it resolves the 5140 domainname via different DNS resolvers. But, in each case, 5141 exactly one A and one AAAA record are returned. 5143 * When a client resolves the domainname "ietf.org", the DNS always 5144 returns one A record and one AAAA record with the same addresses 5145 regardless of which DNS resolver is used. 5147 * When a client resolves the domainname "yahoo.com", the DNS always 5148 returns a list of 4 A records and 4 AAAA records. Each time the 5149 client resolves the domainname via the same DNS resolver, the same 5150 list of addresses are returned but in randomized order (i.e., 5151 consistent with a DNS round-robin strategy). But, interestingly, 5152 the same addresses are returned (albeit in randomized order) when 5153 the domainname is resolved via different DNS resolvers. 5155 * When a client resolves the domainname "amazon.com", the DNS always 5156 returns a list of 3 A records and no AAAA records. As with 5157 "yahoo.com", the same three A records are returned from any 5158 worldwide Internet connection point in randomized order. 5160 The above example strategies show differing approaches to Internet 5161 resilience and service distribution offered by major Internet 5162 services. The Google approach exposes only a single IPv4 and a 5163 single IPv6 address to clients. Clients can then select whichever IP 5164 protocol version offers the best response, but will always use the 5165 same IP address according to the current Internet connection point. 5166 This means that the IP address offered by the network must lead to a 5167 highly-available server and/or service distribution point. In other 5168 words, resilience is predicated on high availability within the 5169 network and with no client-initiated failovers expected (i.e., it is 5170 all-or-nothing from the client's perspective). However, Google does 5171 provide for worldwide distributed service distribution by virtue of 5172 the fact that each Internet connection point responds with a 5173 different IPv6 and IPv4 address. The IETF approach is like google 5174 (all-or-nothing from the client's perspective), but provides only a 5175 single IPv4 or IPv6 address on a worldwide basis. This means that 5176 the addresses must be made highly-available at the network level with 5177 no client failover possibility, and if there is any worldwide service 5178 distribution it would need to be conducted by a network element that 5179 is reached via the IP address acting as a service distribution point. 5181 In contrast to the Google and IETF philosophies, Yahoo and Amazon 5182 both provide clients with a (short) list of IP addresses with Yahoo 5183 providing both IP protocol versions and Amazon as IPv4-only. The 5184 order of the list is randomized with each name service query 5185 response, with the effect of round-robin load balancing for service 5186 distribution. With a short list of addresses, there is still 5187 expectation that the network will implement high availability for 5188 each address but in case any single address fails the client can 5189 switch over to using a different address. The balance then becomes 5190 one of function in the network vs function in the end system. 5192 The same implications observed for common highly-available services 5193 in the Internet apply also to the AERO client/server architecture. 5194 When an AERO Client connects to one or more ANETs, it discovers one 5195 or more AERO Proxy/Server addresses through the mechanisms discussed 5196 in earlier sections. Each Proxy/Server address presumably leads to a 5197 fault-tolerant clustering arrangement such as supported by Linux-HA, 5198 Extended Virtual Synchrony or Paxos. Such an arrangement has 5199 precedence in common Internet service deployments in lightweight 5200 virtual machines without requiring expensive hardware deployment. 5201 Similarly, common Internet service deployments set service IP 5202 addresses on service distribution points that may relay requests to 5203 many different servers. 5205 For AERO, the expectation is that a combination of the Google/IETF 5206 and Yahoo/Amazon philosophies would be employed. The AERO Client 5207 connects to different ANET access points and can receive 1-2 Proxy/ 5208 Server ULAs at each point. It then selects one AERO Proxy/Server 5209 address, and engages in RS/RA exchanges with the same Proxy/Server 5210 from all ANET connections. The Client remains with this Proxy/Server 5211 unless or until the Proxy/Server fails, in which case it can switch 5212 over to an alternate Proxy/Server. The Client can likewise switch 5213 over to a different Proxy/Server at any time if there is some reason 5214 for it to do so. So, the AERO expectation is for a balance of 5215 function in the network and end system, with fault tolerance and 5216 resilience at both levels. 5218 Appendix B. Change Log 5220 << RFC Editor - remove prior to publication >> 5222 Changes from earlier versions: 5224 * Submit for RFC publication. 5226 Author's Address 5228 Fred L. Templin (editor) 5229 Boeing Research & Technology 5230 P.O. Box 3707 5231 Seattle, WA 98124 5232 United States of America 5233 Email: fltemplin@acm.org