idnits 2.17.1 draft-templin-6man-aero-57.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 (1 July 2022) is 663 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3971' is defined on line 4587, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 4592, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 4596, but no explicit reference was found in the text == Unused Reference: 'RFC7739' is defined on line 4628, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 4649, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-crh-helper-opt' is defined on line 4665, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-frag-fragile' is defined on line 4672, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-dhcpv6-ndopt' is defined on line 4703, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-v6ops-pdhost' is defined on line 4737, but no explicit reference was found in the text == Unused Reference: 'OVPN' is defined on line 4751, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 4770, but no explicit reference was found in the text == Unused Reference: 'RFC2004' is defined on line 4774, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 4791, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 4795, but no explicit reference was found in the text == Unused Reference: 'RFC3330' is defined on line 4800, but no explicit reference was found in the text == Unused Reference: 'RFC4122' is defined on line 4809, but no explicit reference was found in the text == Unused Reference: 'RFC4982' is defined on line 4858, but no explicit reference was found in the text == Unused Reference: 'RFC6139' is defined on line 4900, but no explicit reference was found in the text == Unused Reference: 'RFC6273' is defined on line 4920, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 4929, but no explicit reference was found in the text == Unused Reference: 'RFC6438' is defined on line 4934, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 4943, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 4948, but no explicit reference was found in the text == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-67 == 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 1 July 2022 5 Expires: 2 January 2023 7 Automatic Extended Route Optimization (AERO) 8 draft-templin-6man-aero-57 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 2 January 2023. 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 . . . . . . . . . . . . . . 27 70 3.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 28 71 3.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 28 72 3.4.3. AERO Host Behavior . . . . . . . . . . . . . . . . . 29 73 3.4.4. AERO Gateway Behavior . . . . . . . . . . . . . . . . 29 74 3.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 29 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 . . . . . . . . 34 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 . . . . 42 86 3.10.4. Gateway Forwarding Algorithm . . . . . . . . . . . . 45 87 3.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 46 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 . . . . . . . . . . . . . . . . 66 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 . . . . . . . . . . . . . . . . . . . . . . 98 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 122 8.1. Normative References . . . . . . . . . . . . . . . . . . 99 123 8.2. Informative References . . . . . . . . . . . . . . . . . 101 124 Appendix A. Non-Normative Considerations . . . . . . . . . . . . 109 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 764 an adaptation layer dynamic routing protocol instance to advertise 765 its list of associated MNPs (see Section 3.2.3). Hub Proxy/Servers 766 provide prefix delegation/registration services and track the 767 mobility/multilink profiles of each of their associated Clients, 768 where each delegated prefix becomes an MNP taken from an MSP. Proxy/ 769 Servers at ANET/INET boundaries provide a forwarding service for ANET 770 Clients and Hosts to communicate with peers in external INETs, while 771 Proxy/Servers in the open INET provide an authentication service for 772 INET Client IPv6 ND messages but only a secondary forwarding service 773 when the Client cannot forward directly to a peer or Gateway. Source 774 Clients securely coordinate with target Clients by sending control 775 messages via a First-Hop Segment (FHS) Proxy/Server which forwards 776 them over the SRT spanning tree to a Last-Hop Segment (LHS) Proxy/ 777 Server which 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 (and any trailing data plane message 920 extensions). The "unsecured" spanning tree conveys ordinary carrier 921 packets without security codes and that must be treated by 922 destinations according to data origin authentication procedures. 923 AERO nodes can employ route optimization to cause carrier packets to 924 take more direct paths between OMNI link neighbors without having to 925 follow strict spanning tree paths. 927 The AERO Multinet service concatenates SRT segments to form a larger 928 network through Gateway-to-Gateway peerings as originally suggested 929 in the "Catenet Model for Internetworking" [IEN48]; especially 930 Figure 2 follows directly from the illustrations in [IEN48-2]. The 931 Catenet concept suggested a "network-of-networks" concatenation of 932 independent and diverse Internetwork "segments" to form a much larger 933 network supporting end-to-end services. 935 The Catenet concept first articulated in the 1970's was distorted 936 through the evolution of the Internet in later decades, since a 937 critical element was missing from the architecture. As a result, the 938 Internet evolved as a single, large public routing and addressing 939 domain interconnecting private domains (i.e., instead of a true 940 network-of-networks) which has impeded flexibility and inhibited end- 941 to-end services. With the advent of the adaptation layer established 942 by the AERO/OMNI services, however, the original Catenet "network-of- 943 networks" vision is now made possible. 945 3.2.2. Addressing and Node Identification 947 AERO nodes on OMNI links use the Link-Local Address (LLA) prefix 948 fe80::/64 [RFC4291] to assign LLAs to the OMNI interface to satisfy 949 the requirements of [RFC4861]. AERO Clients configure LLAs 950 constructed from MNPs (i.e., "LLA-MNPs") while AERO infrastructure 951 nodes construct LLAs based on 56-bit random values ("LLA-RNDs") per 952 [I-D.templin-6man-omni]. Non-MNP routes are also represented the 953 same as for MNPs, but may include a prefix that is not properly 954 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.) 965 AERO Clients also use Temporary Local Addresses (TLAs) and eXtended 966 Local Addresses (XLAs) constructed per [I-D.templin-6man-omni], where 967 TLAs are distinguished from ordinary ULAs based on the prefix 968 fd00::/16 and XLAs are distinguished from ULAs/TLAs based on the 969 prefix fd00::/64. Clients use TLA-RNDs only in initial control 970 message exchanges until a stable MNP is assigned, but may sometimes 971 also use them for sustained communications within a local routing 972 region. AERO nodes use XLA-MNPs to provide forwarding information 973 for the global routing table as well as IPv6 ND message addressing 974 information. 976 AERO MSPs, MNPs and non-MNP routes are typically based on Global 977 Unicast Addresses (GUAs), but in some cases may be based on IPv4 978 private addresses [RFC1918] or IPv6 ULA-C's [RFC4193]. A GUA block 979 is also reserved for OMNI link anycast purposes. See 980 [I-D.templin-6man-omni] for a full specification of LLAs, ULAs, TLAs, 981 XLAs, GUAs and anycast addresses used by AERO nodes on OMNI links. 983 Finally, AERO Clients and Proxy/Servers configure node identification 984 values as specified in [I-D.templin-6man-omni]. 986 3.2.3. AERO Routing System 988 The AERO routing system comprises a private Border Gateway Protocol 989 (BGP) [RFC4271] service coordinated between Gateways and Proxy/ 990 Servers (Relays also engage in the routing system as simplified 991 Proxy/Servers). The service supports carrier packet forwarding at a 992 layer below IP and does not interact with the public Internet BGP 993 routing system, but supports redistribution of information for other 994 links and networks connected by Relays. 996 In a reference deployment, each Proxy/Server is configured as an 997 Autonomous System Border Router (ASBR) for a stub Autonomous System 998 (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within 999 the BGP instance, and each Proxy/Server further uses eBGP to peer 1000 with one or more Gateways but does not peer with other Proxy/Servers. 1001 Each SRT segment in the OMNI link must include one or more Gateways 1002 in a "hub" AS, which peer with the Proxy/Servers within that segment 1003 as "spoke" ASes. All Gateways within the same segment are members of 1004 the same hub AS, and use iBGP to maintain a consistent view of all 1005 active routes currently in service. The Gateways of different 1006 segments peer with one another using eBGP. 1008 Gateways maintain forwarding table entries only for ULA prefixes for 1009 infrastructure elements and XLA-MNPs corresponding to MNP and non-MNP 1010 routes that are currently active; Gateways also maintain black-hole 1011 routes for the OMNI link MSPs so that carrier packets destined to 1012 non-existent more-specific routes are dropped with a Destination 1013 Unreachable message returned. In this way, Proxy/Servers and Relays 1014 have only partial topology knowledge (i.e., they only maintain 1015 routing information for their directly associated Clients and non- 1016 AERO links) and they forward all other carrier packets to Gateways 1017 which have full topology knowledge. 1019 Each OMNI link segment assigns a unique sub-prefix of {ULA}::/48 1020 known as the "SRT prefix". For example, a first segment could assign 1021 {ULA}:1000::/56, a second could assign {ULA}:2000::/56, a third could 1022 assign {ULA}:3000::/56, etc. Within each segment, each Proxy/Server 1023 configures a ULA-RND within the segment's SRT prefix with a 56-bit 1024 random value in the interface identifier as specified in 1025 [I-D.templin-6man-omni]. 1027 The administrative authorities for each segment must therefore 1028 coordinate to assure mutually-exclusive ULA prefix assignments, but 1029 internal provisioning of ULAs is an independent local consideration 1030 for each administrative authority. For each ULA prefix, the 1031 Gateway(s) that connect that segment assign the all-zero's address of 1032 the prefix as a Subnet Router Anycast address. For example, the 1033 Subnet Router Anycast address for {ULA}:1023::/64 is simply 1034 {ULA}:1023::/64. 1036 ULA prefixes are statically represented in Gateway forwarding tables. 1037 Gateways join multiple SRT segments into a unified OMNI link over 1038 multiple diverse network administrative domains. They support a 1039 virtual bridging service by first establishing forwarding table 1040 entries for their ULA prefixes either via standard BGP routing or 1041 static routes. For example, if three Gateways ('A', 'B' and 'C') 1042 from different segments serviced {ULA}:1000::/60, {ULA}:2000::/56 and 1043 {ULA}:3000::/56 respectively, then the forwarding tables in each 1044 Gateway appear as follows: 1046 A: {ULA}:1000::/56->local, {ULA}:2000::/56->B, {ULA}:3000::/56->C 1048 B: {ULA}:1000::/56->A, {ULA}:2000::/56->local, {ULA}:3000::/56->C 1050 C: {ULA}:1000::/56->A, {ULA}:2000::/56->B, {ULA}:3000::/56->local 1052 These forwarding table entries rarely change, since they correspond 1053 to fixed infrastructure elements in their respective segments. 1055 MNP (and non-MNP) routes are instead dynamically advertised in the 1056 AERO routing system by Proxy/Servers and Relays that provide service 1057 for their corresponding MNPs. The routes are advertised as XLA-MNP 1058 prefixes, i.e., as fd00::{MNP} (see: [I-D.templin-6man-omni]). For 1059 example, if three Proxy/Servers ('D', 'E' and 'F') service the MNPs 1060 2001:db8:1000:2000::/56, 2001:db8:3000:4000::/56 and 1061 2001:db8:5000:6000::/56 then the routing system would include: 1063 D: fd00::2001:db8:1000:2000/120 1065 E: fd00::2001:db8:3000:4000/120 1067 F: fd00::2001:db8:5000:6000/120 1069 A full discussion of the BGP-based routing system used by AERO is 1070 found in [I-D.ietf-rtgwg-atn-bgp]. 1072 3.2.4. Segment Routing Topologies (SRTs) 1074 The distinct {ULA}::/48 prefixes in an OMNI link domain identify 1075 distinct Segment Routing Topologies (SRTs). Each SRT is a mutually- 1076 exclusive OMNI link overlay instance using a distinct set of ULAs, 1077 and emulates a bridged campus LAN service for the OMNI link. In some 1078 cases (e.g., when redundant topologies are needed for fault tolerance 1079 and reliability) it may be beneficial to deploy multiple SRTs that 1080 act as independent overlay instances. A communication failure in one 1081 instance therefore will not affect communications in other instances. 1083 Each SRT is identified by a distinct value in the 40-bit ULA Global 1084 ID field and assigns an OMNI IPv6 anycast address used for OMNI 1085 interface determination in Safety-Based Multilink (SBM) as discussed 1086 in [I-D.templin-6man-omni]. Each OMNI interface further applies 1087 Performance-Based Multilink (PBM) internally. 1089 The Gateways and Proxy/Servers of each independent SRT engage in BGP 1090 peerings to form a spanning tree with the Gateways in non-leaf nodes 1091 and the Proxy/Servers in leaf nodes. The spanning tree is configured 1092 over both secured and unsecured underlay network paths. The secured 1093 spanning tree is used to convey secured control messages (and 1094 sometimes data message extensions) between Proxy/Servers and 1095 Gateways, while the unsecured spanning tree forwards bulk data 1096 messages and/or unsecured control messages. 1098 Each SRT segment is identified by a unique ULA prefix used by all 1099 Proxy/Servers and Gateways in the segment. Each AERO node must 1100 therefore discover an SRT prefix that correspondents can use to 1101 determine the correct segment, and must publish the SRT prefix in 1102 IPv6 ND messages. 1104 Note: The distinct ULA prefixes in an OMNI link domain can be carried 1105 either in a common BGP routing protocol instance for all OMNI links 1106 or in distinct BGP routing protocol instances for different OMNI 1107 links. In some SBM environments, such separation may be necessary to 1108 ensure that distinct OMNI links do not include any common 1109 infrastructure elements as single points of failure. In other 1110 environments, carrying the ULAs of multiple OMNI links within a 1111 common routing system may be acceptable. 1113 3.2.5. Segment Routing For OMNI Link Selection 1115 Original IPv6 sources can direct IPv6 packets to an AERO node by 1116 including a standard IPv6 Segment Routing Header (SRH) [RFC8754] with 1117 the OMNI IPv6 anycast address for the selected OMNI link as either 1118 the IPv6 destination or as an intermediate hop within the SRH. This 1119 allows the original source to determine the specific OMNI link SRT an 1120 original IPv6 packet will traverse when there may be multiple 1121 alternatives. 1123 When an AERO node processes the SRH and forwards the original IPv6 1124 packet to the correct OMNI interface, the OMNI interface writes the 1125 next IPv6 address from the SRH into the IPv6 destination address and 1126 decrements Segments Left. If decrementing would cause Segments Left 1127 to become 0, the OMNI interface deletes the SRH before forwarding. 1128 This form of Segment Routing supports Safety-Based Multilink (SBM). 1130 3.3. OMNI Interface Characteristics 1132 OMNI interfaces are virtual interfaces configured over one or more 1133 underlay interfaces classified as follows: 1135 * ANET interfaces connect to a protected and secured ANET that is 1136 separated from the open INET by Proxy/Servers. The ANET interface 1137 may be either on the same L2 link segment as a Proxy/Server, or 1138 separated from a Proxy/Server by multiple IP hops. (Note that 1139 NATs may appear internally within an ANET and may require NAT 1140 traversal on the path to the Proxy/Server the same as for the INET 1141 case.) 1143 * INET interfaces connect to an INET either natively or through one 1144 or several IPv4 Network Address Translators (NATs). Native INET 1145 interfaces have global IP addresses that are reachable from any 1146 INET correspondent. NATed INET interfaces typically have private 1147 IP addresses and connect to a private network behind one or more 1148 NATs with the outermost NAT providing INET access. 1150 * ENET interfaces connect a Client's downstream-attached networks, 1151 where the Client provides forwarding services for ENET Host and 1152 Client communications to remote peers. An ENET can be as simple 1153 as a small stub network that travels with a mobile Client (e.g., 1154 an Internet-of-Things) to as complex as a large private enterprise 1155 network that the Client connects to a larger ANET or INET. 1157 * VPNed interfaces use security encapsulation over an underlay 1158 network to a Client or Proxy/Server acting as a Virtual Private 1159 Network (VPN) gateway. Other than the link-layer encapsulation 1160 format, VPNed interfaces behave the same as for Direct interfaces. 1162 * Direct (aka "point-to-point") interfaces connect directly to a 1163 Client or Proxy/Server without crossing any networked paths. An 1164 example is a line-of-sight link between a remote pilot and an 1165 unmanned aircraft. 1167 OMNI interfaces use OAL encapsulation and fragmentation as discussed 1168 in Section 3.6. OMNI interfaces use L2 encapsulation (see: 1169 Section 3.6) to exchange carrier packets with OMNI link neighbors 1170 over INET or VPNed interfaces as well as over ANET interfaces for 1171 which the Client and FHS Proxy/Server may be multiple IP hops away. 1172 OMNI interfaces use link-layer encapsulation only (i.e., and no other 1173 L2 encapsulations) over Direct underlay interfaces or ANET interfaces 1174 when the Client and FHS Proxy/Server are known to be on the same 1175 underlay link. 1177 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 1178 state the same as for any interface. OMNI interfaces use IPv6 ND 1179 messages including Router Solicitation (RS), Router Advertisement 1180 (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA) and 1181 Redirect for neighbor cache management. In environments where 1182 spoofing may be a threat, OMNI neighbors should invoke OAL 1183 Identification window synchronization in their IPv6 ND message 1184 exchanges. 1186 OMNI interfaces send IPv6 ND messages with an OMNI option formatted 1187 as specified in [I-D.templin-6man-omni]. The OMNI option includes 1188 prefix registration information, Interface Attributes and/or AERO 1189 Forwarding Parameters (AFPs) containing link information parameters 1190 for the OMNI interface's underlay interfaces and any other per- 1191 neighbor information. 1193 A Host's OMNI interface is configured over an underlay interface 1194 connected to an ENET provided by an upstream Client. From the Host's 1195 perspective, the ENET appears as an ANET and the upstream Client 1196 appears as a Proxy/Server. The Host does not provide OMNI 1197 intermediate node services and is therefore a logical termination 1198 point for the OMNI link. 1200 A Client's OMNI interface may be configured over multiple ANET/INET 1201 underlay interfaces. For example, common mobile handheld devices 1202 have both wireless local area network ("WLAN") and cellular wireless 1203 links. These links are often used "one at a time" with low-cost WLAN 1204 preferred and highly-available cellular wireless as a standby, but a 1205 simultaneous-use capability could provide benefits. In a more 1206 complex example, aircraft frequently have many wireless data link 1207 types (e.g. satellite-based, cellular, terrestrial, air-to-air 1208 directional, etc.) with diverse performance and cost properties. 1210 If a Client's multiple ANET/INET underlay interfaces are used "one at 1211 a time" (i.e., all other interfaces are in standby mode while one 1212 interface is active), then successive IPv6 ND messages all include 1213 OMNI option Interface Attributes, Traffic Selector and/or AFP sub- 1214 options with the same underlay interface ifIndex. In that case, the 1215 Client would appear to have a single underlay interface but with a 1216 dynamically changing link-layer address. 1218 If the Client has multiple active ANET/INET underlay interfaces, then 1219 from the perspective of IPv6 ND it would appear to have multiple 1220 link-layer addresses. In that case, IPv6 ND message OMNI options MAY 1221 include sub-options with different underlay interface ifIndexes. 1223 Proxy/Servers on the open Internet include only a single INET 1224 underlay interface. INET Clients therefore discover only the L2ADDR 1225 information for the Proxy/Server's INET interface. Proxy/Servers on 1226 an ANET/INET boundary include both an ANET and INET underlay 1227 interface. ANET Clients therefore must discover both the ANET and 1228 INET L2ADDR information for their Proxy/Servers. 1230 Gateway and Proxy/Server OMNI interfaces are configured over underlay 1231 interfaces that provide both secured tunnels for carrying IPv6 ND and 1232 BGP protocol control plane messages and open INET access for carrying 1233 unsecured messages. The OMNI interface configures a ULA-RND and acts 1234 as an OAL source to encapsulate original IP packets, then fragments 1235 the resulting OAL packets and presents the resulting carrier packets 1236 over the secured or unsecured underlay paths. Note that Gateway and 1237 Proxy/Server end-to-end transport protocol sessions used by the BGP 1238 run directly over the OMNI interface and use ULA-RND source and 1239 destination addresses. The ULA-RND addresses that appear in BGP 1240 protocol session original IP packets may therefore be the same as 1241 those that appear in the OAL IPv6 encapsulation header. 1243 3.4. OMNI Interface Initialization 1245 AERO Proxy/Servers, Clients and Hosts configure OMNI interfaces as 1246 their point of attachment to the OMNI link. AERO nodes assign the 1247 MSPs for the link to their OMNI interfaces (i.e., as a "route-to- 1248 interface") to ensure that original IP packets with destination 1249 addresses covered by an MNP not explicitly associated with another 1250 interface are directed to an OMNI interface. 1252 OMNI interface initialization procedures for Proxy/Servers, Clients 1253 Hosts and Gateways are discussed in the following sections. 1255 3.4.1. AERO Proxy/Server and Relay Behavior 1257 When a Proxy/Server enables an OMNI interface, it assigns a ULA-RND 1258 appropriate for the given OMNI link SRT segment. The Proxy/Server 1259 also configures secured underlay interface tunnels and engages in BGP 1260 routing protocol sessions over the OMNI interface with one or more 1261 neighboring Gateways. 1263 The OMNI interface provides a single interface abstraction to the IP 1264 layer, but internally includes an NBMA nexus for sending carrier 1265 packets to OMNI interface neighbors over underlay interfaces and/or 1266 secured tunnels. The Proxy/Server further configures a service to 1267 facilitate IPv6 ND exchanges with AERO Clients and manages per-Client 1268 neighbor cache entries and IP forwarding table entries based on 1269 control message exchanges. 1271 Relays are simply Proxy/Servers that run a dynamic routing protocol 1272 to redistribute routes between the OMNI interface and INET/ENET 1273 interfaces (see: Section 3.2.3). The Relay provisions MNPs to 1274 networks on the INET/ENET interfaces (i.e., the same as a Client 1275 would do) and advertises the MSP(s) for the OMNI link over the INET/ 1276 ENET interfaces. The Relay further provides an attachment point of 1277 the OMNI link to a non-MNP-based global topology. 1279 3.4.2. AERO Client Behavior 1281 When a Client enables an OMNI interface, it assigns either an XLA-MNP 1282 or a TLA and sends OMNI-encapsulated RS messages over its ANET/INET 1283 underlay interfaces to an FHS Proxy/Server, which coordinates with a 1284 Hub Proxy/Server that returns an RA message with corresponding 1285 parameters. The RS/RA messages may pass through one or more NATs in 1286 the path between the Client and FHS Proxy/Server. (Note: if the 1287 Client used a TLA in its initial RS messages, it may discover ULA- 1288 MNPs in the corresponding RAs that it receives from FHS Proxy/Servers 1289 and begin using these new addresses. If the Client is operating 1290 outside the context of AERO infrastructure such as in a Mobile Ad-hoc 1291 Network (MANET), however, it may continue using TLAs for Client-to- 1292 Client communications at least until it encounters an infrastructure 1293 element that can delegate MNPs.) 1295 A Client can further extend the OMNI link over its (downstream) ENET 1296 interfaces where it provides a first-hop router for Hosts and other 1297 AERO Clients connected to the ENET. A downstream Client that 1298 connects via the ENET serviced by an upstream Client can in turn 1299 service further downstream ENETs that connect other Hosts and 1300 Clients. This OMNI link extension can be applied recursively over a 1301 "chain" of ENET Clients. 1303 3.4.3. AERO Host Behavior 1305 When a Host enables an OMNI interface, it assigns an address taken 1306 from the ENET underlay interface which may itself be a GUA delegated 1307 by the upstream Client. The Host does not assign a link-local 1308 address to the OMNI interface, since no autoconfiguration is 1309 necessary on that interface. (As an implementation matter, the Host 1310 could instead configure the "OMNI interface" as a virtual sublayer of 1311 the ENET underlay interface itself.) 1313 The Host sends OMNI-encapsulated RS messages over its ENET underlay 1314 interface to the upstream Client, which returns encapsulated RAs and 1315 provides routing services in the same fashion that Proxy/Servers 1316 provides services for Clients. Hosts represent the leaf end systems 1317 in recursively-nested chain of concatenated ENETs, i.e., they 1318 represent terminating endpoints for the OMNI link. 1320 3.4.4. AERO Gateway Behavior 1322 AERO Gateways configure an OMNI interface and assign a ULA-RND and 1323 corresponding Subnet Router Anycast address for each OMNI link SRT 1324 segment they connect to. Gateways configure underlay interface 1325 secured tunnels with Proxy/Servers in the same SRT segment and other 1326 Gateways in the same (or an adjacent) SRT segment. Gateways then 1327 engage in a BGP routing protocol session with neighbors over the 1328 secured spanning tree (see: Section 3.2.3). 1330 3.5. OMNI Interface Neighbor Cache Maintenance 1332 Each Client, Proxy/Server and Gateway OMNI interface maintains a 1333 network layer conceptual neighbor cache per [RFC1256] or [RFC4861] 1334 the same as for any IP interface. The OMNI interface network layer 1335 neighbor cache is maintained through static and/or dynamic neighbor 1336 cache entry configurations. 1338 Each OMNI interface also maintains a separate internal adaptation 1339 layer conceptual neighbor cache that includes a Neighbor Cache Entry 1340 (NCE) for each of its active OAL neighbors per [RFC4861]. Throughout 1341 this document, the terms "neighbor cache" and "NCE" refer to this 1342 adaptation layer neighbor cache unless otherwise specified. 1344 Each OMNI interface NCE is indexed by the ULA of the neighbor found 1345 in the ND message IPv6 header and determines the context for 1346 Identification verification. Clients and Proxy/Servers maintain NCEs 1347 through dynamic RS/RA message exchanges, and also maintain NCEs for 1348 any active correspondent peers through dynamic NS/NA message 1349 exchanges. 1351 Hosts also maintain NCEs for Clients and other Hosts through the 1352 exchange of RS/RA, NS/NA or Redirect messages. Each NCE is indexed 1353 by the IP address assigned to the Host ENET interface, which is the 1354 same address used for OMNI L2 encapsulation (i.e., without the 1355 insertion of an OAL header). This encapsulation format identifies 1356 the NCE as a Host-based entry where the Host is a leaf end system in 1357 the recursively extended OMNI link. 1359 Gateways also maintain NCEs for Clients within their local segments 1360 based on NS/NA route optimization messaging (see: Section 3.13.3). 1361 When a Gateway creates/updates a NCE for a local segment Client based 1362 on NS/NA route optimization, it also maintains AFIB state for 1363 messages destined to this local segment Client. 1365 Proxy/Servers add an additional state DEPARTED to the list of NCE 1366 states found in Section 7.3.2 of [RFC4861]. When a Client terminates 1367 its association, the Proxy/Server OMNI interface sets a "DepartTime" 1368 variable for the NCE to "DEPART_TIME" seconds. DepartTime is 1369 decremented unless a new IPv6 ND message causes the state to return 1370 to REACHABLE. While a NCE is in the DEPARTED state, the Proxy/Server 1371 forwards carrier packets destined to the target Client to the 1372 Client's new FHS/Hub Proxy/Server instead. It is RECOMMENDED that 1373 DEPART_TIME be set to the default constant value 10 seconds to accept 1374 any carrier packets that may be in flight. When DepartTime 1375 decrements to 0, the NCE is deleted. 1377 Clients determine the service profiles for their FHS and Hub Proxy/ 1378 Servers by setting the N/A/U flags in a Neighbor Coordination sub- 1379 option of the first OMNI option in RS messages. When the N/A/U flags 1380 are clear, Proxy/Servers forward all NS/NA messages to the Client, 1381 while the Client performs mobility update signaling through the 1382 transmission of uNA messages to all active neighbors following a 1383 mobility event. However, in some environments this may result in 1384 excessive NS/NA control message overhead especially for Clients 1385 connected to low-end data links. 1387 To minimize NS/NA message overhead, Clients can set the N/A/U flags 1388 in the OMNI Neighbor Coordination sub-option of RS messages they 1389 send. If the N flag is set, the FHS Proxy/Server that forwards the 1390 RS message assumes the role of responding to NS messages and 1391 maintains peer NCEs associated with the NCE for this Client. If the 1392 A flag is set, the Hub Proxy/Server that processes the RS message 1393 assumes the role of responding to NS(AR) messages on behalf of this 1394 Client NCE. If the U flag is set, the Hub Proxy/Server that 1395 processes the RS message becomes responsible for maintaining a 1396 "Report List" of sources/targets for NS(AR) messages it forwards on 1397 behalf of this Client NCE. The Hub Proxy/Server maintains each 1398 Report List entry for REPORT_TIME seconds, and sends uNA messages to 1399 each member of the Report List when it receives a Client mobility 1400 update indication (e.g., through receipt of an RS with updated 1401 Interface Attributes and/or Traffic Selectors). 1403 Both the Client and its Hub Proxy/Server have full knowledge of the 1404 Client's current underlay Interface Attributes and Traffic Selectors, 1405 while FHS Proxy/Servers acting in "proxy" mode have knowledge of only 1406 the individual Client underlay interfaces they service. Clients 1407 determine their FHS and Hub Proxy/Server service models by setting 1408 the N/A/U flags in the RS messages they send as discussed above. 1410 When an Address Resolution Source (ARS) sends an NS(AR) message 1411 toward an Address Resolution Target (ART) Client/Relay, the OMNI link 1412 routing system directs the NS(AR) to a Hub Proxy/Server for the ART. 1413 The Hub then either acts as an Address Resolution Responder (ARR) on 1414 behalf of the ART or forwards the NS(AR) to the ART which acts as an 1415 ARR on its own behalf. The ARR returns an NA(AR) response to the 1416 ARS, which creates or updates a NCE for the ART while caching L3 and 1417 L2 addressing information. The ARS then (re)sets ReachableTime for 1418 the NCE to REACHABLE_TIME seconds and performs unicast NS/NA 1419 exchanges over specific underlay interface pairs to determine paths 1420 for forwarding carrier packets directly to the ART. The ARS 1421 otherwise decrements ReachableTime while no further solicited NA 1422 messages arrive. It is RECOMMENDED that REACHABLE_TIME be set to the 1423 default constant value 30 seconds as specified in [RFC4861]. 1425 AERO nodes also use the value MAX_UNICAST_SOLICIT to limit the number 1426 of NS messages sent when a correspondent may have gone unreachable, 1427 the value MAX_RTR_SOLICITATIONS to limit the number of RS messages 1428 sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT 1429 to limit the number of unsolicited NAs that can be sent based on a 1430 single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT, 1431 MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the 1432 same as specified in [RFC4861]. 1434 Different values for the above constants MAY be administratively set; 1435 however, if different values are chosen, all nodes on the link MUST 1436 consistently configure the same values. Most importantly, 1437 DEPART_TIME and REPORT_TIME SHOULD be set to a value that is 1438 sufficiently longer than REACHABLE_TIME to avoid packet loss due to 1439 stale route optimization state. 1441 3.5.1. OMNI ND Messages 1443 OMNI interfaces prepare IPv6 ND messages the same as for standard 1444 IPv6 ND, but also include a new option type termed the OMNI option 1445 [I-D.templin-6man-omni]. OMNI interfaces use ULAs instead of LLAs as 1446 IPv6 ND message source and destination addresses. This allows 1447 multiple different OMNI links to be joined into a single link at some 1448 future time without requiring a global renumbering event. 1450 For each IPv6 ND message, the OMNI interface includes one or more 1451 OMNI options (and any other ND message options) then completely 1452 populates all option information. If the OMNI interface includes an 1453 authentication signature, it sets the IPv6 ND message Checksum field 1454 to 0 and calculates the authentication signature over the entire 1455 length of the OAL packet or super-packet beginning with a pseudo- 1456 header of the IPv6 header. Otherwise, the OMNI interface calculates 1457 the standard IPv6 ND message checksum over the OAL packet or super- 1458 packet and writes the value in the Checksum field. OMNI interfaces 1459 verify authentication and integrity of each IPv6 ND message received 1460 according to the specific check(s) included, and process the message 1461 further only following verification. 1463 OMNI options include per-neighbor information that provides multilink 1464 forwarding, link-layer address and traffic selector information for 1465 the neighbor's underlay interfaces. This information is stored in 1466 the neighbor cache and provides the basis for the forwarding 1467 algorithm specified in Section 3.10. The information is cumulative 1468 and reflects the union of the OMNI information from the most recent 1469 IPv6 ND messages received from the neighbor. 1471 The OMNI option is distinct from any Source/Target Link-Layer Address 1472 Options (S/TLLAOs) that may appear in an IPv6 ND message according to 1473 the appropriate IPv6 over specific link layer specification (e.g., 1474 [RFC2464]). If both OMNI options and S/TLLAOs appear, the former 1475 pertains to adaptation layer to underlay interface address mappings 1476 while the latter pertains to the native L2 address format of the 1477 underlay media. 1479 OMNI interface IPv6 ND messages may also include other IPv6 ND 1480 options. In particular, solicitation messages may include a Nonce 1481 option if required for verification of advertisement replies. If an 1482 OMNI IPv6 ND solicitation message includes a Nonce option, the 1483 advertisement reply must echo the same Nonce. If an OMNI IPv6 ND 1484 solicitation message includes a Timestamp option, the recipient must 1485 include a Timestamp option in its advertisement reply. All 1486 unsolicited advertisement and redirect messages should include a 1487 Timestamp option. 1489 AERO Clients send RS messages to the link-scoped All-Routers 1490 multicast address or a ULA-RND while using unicast or anycast OAL/L2 1491 addresses. AERO Proxy/Servers respond by returning unicast RA 1492 messages. During the RS/RA exchange, AERO Clients and Proxy/Servers 1493 include state synchronization parameters to establish Identification 1494 windows and other state. 1496 AERO Hosts and Clients on ENET underlay networks send RS messages to 1497 the link-scoped All-Routers multicast address, a ULA-RND of a remote 1498 Hub Proxy/Server or the ULA-MNP of an upstream Client while using 1499 unicast or anycast OAL/L2 addresses. The upstream AERO Client 1500 responds by returning a unicast RA message. 1502 AERO nodes use NS/NA messages for the following purposes: 1504 * NS/NA(AR) messages are used for address resolution and optionally 1505 to establish sequence number windows. The ARS sends an NS(AR) to 1506 the solicited-node multicast address of the ART, and an ARR with 1507 addressing information for the ART returns a unicast NA(AR) that 1508 contains current, consistent and authentic target address 1509 resolution information. NS(AR) messages include a solicited-node 1510 multicast destination address to distinguish them from ordinary NS 1511 messages. NS/NA(AR) messages must be secured. 1513 * Ordinary NS/NA messages are used determine target reachability, 1514 establish and maintain NAT state, and/or establish AFIB state. 1515 The source sends an NS to the unicast address of the target while 1516 optionally including an OMNI AERO Forwarding Parameters (AFP) sub- 1517 option naming a specific underlay interface pair, and the target 1518 returns a unicast NA that includes a responsive AFP if necessary. 1519 NS/NA messages that use an in-window sequence number and do not 1520 update any other state need not include an authentication 1521 signature but instead must include an IPv6 ND message checksum. 1522 NS/NA messages used to establish window synchronization and/or 1523 AFIB state must be secured. 1525 * Unsolicited NA (uNA) messages are used to signal addressing and/or 1526 other neighbor state changes (e.g., address changes due to 1527 mobility, signal degradation, traffic selector updates, etc.). uNA 1528 messages that update state information must be secured. 1530 * NS/NA(DAD) messages are not used in AERO, since Duplicate Address 1531 Detection is not required. 1533 Additionally, nodes may set the OMNI option PNG flag in NA/RA 1534 messages to receive a uNA response from the neighbor. The uNA 1535 response MUST set the ACK flag (without also setting the SYN or PNG 1536 flags) with the Acknowledgement field set to the Identification used 1537 in the PNG message. 1539 3.5.2. OMNI Neighbor Advertisement Message Flags 1541 As discussed in Section 4.4 of [RFC4861] NA messages include three 1542 flag bits R, S and O. OMNI interface NA messages treat the flags as 1543 follows: 1545 * R: The R ("Router") flag is set to 1 in the NA messages sent by 1546 all AERO/OMNI node types. Simple hosts that would set R to 0 do 1547 not occur on the OMNI link itself, but may occur on the downstream 1548 links of Clients and Relays. 1550 * S: The S ("Solicited") flag is set exactly as specified in 1551 Section 4.4. of [RFC4861], i.e., it is set to 1 for Solicited NAs 1552 and set to 0 for uNAs (both unicast and multicast). 1554 * O: The O ("Override") flag is set to 0 for solicited NAs returned 1555 by a Proxy/Server ARR and set to 1 for all other solicited and 1556 unsolicited NAs. For further study is whether solicited NAs for 1557 anycast targets apply for OMNI links. Since XLA-MNPs must be 1558 uniquely assigned to Clients to support correct IPv6 ND protocol 1559 operation, however, no role is currently seen for assigning the 1560 same XLA-MNP to multiple Clients. 1562 3.5.3. OMNI Neighbor Window Synchronization 1564 In secured environments (e.g., between secured spanning tree 1565 neighbors, between neighbors on the same secured ANET, etc.), OMNI 1566 interface neighbors can exchange OAL packets using randomly- 1567 initialized and monotonically-increasing Identification values 1568 (modulo 2**32) without window synchronization. In environments where 1569 spoofing is considered a threat, OMNI interface neighbors instead 1570 invoke window synchronization by including OMNI Neighbor Coordination 1571 sub-options in RS/RA or NS/NA message exchanges to maintain send/ 1572 receive window state in their respective neighbor cache entries as 1573 specified in [I-D.templin-6man-omni]. 1575 3.6. OMNI Interface Encapsulation and Fragmentation 1577 When the network layer forwards an original IP packet into an OMNI 1578 interface, the interface locates or creates a Neighbor Cache Entry 1579 (NCE) that matches the destination. The OMNI interface then invokes 1580 the OMNI Adaptation Layer (OAL) as discussed in 1581 [I-D.templin-6man-omni] which encapsulates the packet in an IPv6 1582 header to produce an OAL packet. For example, an original IP packet 1583 with source address 2001:db8:1:2::1 and destination address 1584 2001:db8:1234:5678::1 might cause the OAL encapsulation header to 1585 include source address {XLA*}::2001:db8:1:2 (i.e., an XLA-MNP) and 1586 destination address {ULA*}::0012:3456:789a:bcde (i.e., a ULA-RND). 1588 Following encapsulation, the OAL source then calculates and includes 1589 a 2-octet OAL checksum, then fragments the OAL packet while including 1590 an identical Identification value for each fragment that must be 1591 within the window for the neighbor. This fragmentation causes the 1592 OAL checksum to appear as the final 2 octets of the final fragment, 1593 i.e., as a "trailer". 1595 The OAL source next includes an identical Compressed Routing Header 1596 with 32-bit ID fields (CRH-32) [I-D.bonica-6man-comp-rtg-hdr] with 1597 each fragment containing one or more AERO Forwarding Vector Indices 1598 (AFVIs) if necessary as discussed in Section 3.13. The OAL source 1599 can instead invoke OAL header compression by replacing the OAL IPv6 1600 header, CRH-32 and Fragment Header with an OAL Compressed Header 1601 (OCH). 1603 The OAL source finally encapsulates each resulting OAL fragment in L2 1604 headers to form an OAL carrier packet, with source address set to its 1605 own L2 address (e.g., 192.0.2.100) and destination set to the L2 1606 address of the next hop OAL intermediate node or destination (e.g., 1607 192.0.2.1). The carrier packet encapsulation format in the above 1608 example is shown in Figure 3: 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | L2 Headers | 1612 | src = 192.0.2.100 | 1613 | dst = 192.0.2.1 | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | OAL IPv6 Header | 1616 | src = {XLA*}::2001:db8:1:2 | 1617 |dst={ULA*}::0012:3456:789a:bcde| 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | CRH-32 (if necessary) | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | OAL Fragment Header | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | Original IP Header | 1624 | (first-fragment only) | 1625 | src = 2001:db8:1:2::1 | 1626 | dst = 2001:db8:1234:5678::1 | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | | 1629 ~ ~ 1630 ~ Original Packet Body/Fragment ~ 1631 ~ ~ 1632 | | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | OAL Trailing Checksum | 1635 | (final-fragment only) | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 Figure 3: Carrier Packet Format 1640 Note: that carrier packets exchanged by Hosts on ENETs do not include 1641 the OAL IPv6 or CRH-32 headers, i.e., the OAL encapsulation is NULL 1642 and only the Fragment Header and L2 encapsulations are included. 1644 In this format, the OAL source encapsulates the original IP header 1645 and packet body/fragment in an OAL IPv6 header prepared according to 1646 [RFC2473], the CRH-32 is a Routing Header extension of the OAL 1647 header, the Fragment Header identifies each fragment, and the L2 1648 headers are prepared as discussed in [I-D.templin-6man-omni]. The 1649 OAL source transmits each such carrier packet into the SRT spanning 1650 tree, where they are forwarded over possibly multiple OAL 1651 intermediate nodes until they arrive at the OAL destination. 1653 The OMNI link control plane service distributes Client XLA-MNP prefix 1654 information that may change occasionally due to regional node 1655 mobility, as well as XLA-MNP prefix information for Relay non-MNPs 1656 and per-segment ULA prefix information that rarely changes. OMNI 1657 link Gateways and Proxy/Servers use the information to establish and 1658 maintain a forwarding plane spanning tree that connects all nodes on 1659 the link. The spanning tree supports a carrier packet virtual 1660 bridging service according to link-layer (instead of network-layer) 1661 information, but may often include longer paths than necessary. 1663 Each OMNI interface therefore also includes an AERO Forwarding 1664 Information Base (AFIB) that caches AERO Forwarding Vectors (AFVs) 1665 which can provide more direct forwarding "shortcuts" that avoid 1666 strict spanning tree paths. As a result, the spanning tree is always 1667 available but OMNI interfaces can often use the AFIB to greatly 1668 improve performance and reduce load on critical infrastructure 1669 elements. 1671 For carrier packets undergoing re-encapsulation at an OAL 1672 intermediate node, the OMNI interface removes the L2 encapsulation 1673 headers and reassembles if necessary to obtain the OAL packet. The 1674 OMNI interface then decrements the OAL IPv6 header Hop Limit and 1675 discards the packet if the Hop Limit reaches 0. Otherwise, the OMNI 1676 interface updates the OAL addresses if necessary, recalculates the 1677 OAL checksum, re-fragments and re-encapsulates each fragment in new 1678 L2 encapsulation headers appropriate for next segment forwarding. 1680 When an FHS Gateway forwards a carrier packet to an LHS Gateway over 1681 the unsecured spanning tree, it reconstructs the OAL header based on 1682 AFV state, inserts a CRH-32 immediately following the OAL header and 1683 adjusts the OAL payload length and destination address field. The 1684 FHS Gateway includes a single AFVI in the CRH-32 that will be 1685 meaningful to the LHS Gateway, then forwards the carrier packet over 1686 the unsecured spanning tree. When the LHS Gateway receives the 1687 carrier packet, it locates the AFV for the next hop based on the 1688 CRH-32 AFVI then re-applies header compression (resulting in the 1689 removal of the CRH-32) and forwards the carrier packet to the next 1690 hop. 1692 3.7. OMNI Interface Decapsulation 1694 When an OAL node receives carrier packets with OAL headers addressed 1695 to another node, it discards the L2 headers and includes new L2 1696 headers appropriate for the next hop in the forwarding path to the 1697 OAL destination. The node then forwards these new carrier packets 1698 into the next hop underlay interface. 1700 When an OAL node receives carrier packets with OAL headers addressed 1701 to itself, it discards the L2 headers, verifies the Identification, 1702 reassembles to obtain the original OAL packet (or super-packet - see: 1703 [I-D.templin-6man-omni]) then finally verifies the OAL checksum. 1704 Next, if the original IP packet (or super-packet) is destined either 1705 to itself or to a destination reached via an interface other than the 1706 OMNI interface, the OAL node discards the OAL encapsulation and 1707 forwards the original IP packet(s) to the network layer. 1709 If the original IP packet (or super-packet) is destined to another 1710 node reached by the OMNI interface, the OAL node instead changes the 1711 OAL source to its own address, changes the OAL destination to the ULA 1712 of the next-hop node over the OMNI interface, decrements the Hop 1713 Limit, recalculates the OAL checksum, refragments if necessary, 1714 includes new L2 headers appropriate for the next hop, then forwards 1715 these new carrier packets into the next hop underlay interface. 1717 3.8. OMNI Interface Data Origin Authentication 1719 AERO nodes employ simple data origin authentication procedures. In 1720 particular: 1722 * AERO Gateways and Proxy/Servers accept carrier packets received 1723 from the secured spanning tree. 1725 * AERO Proxy/Servers and Clients accept carrier packets and original 1726 IP packets that originate from within the same secured ANET. 1728 * AERO Clients and Relays accept original IP packets from downstream 1729 network correspondents based on ingress filtering. 1731 * AERO Hosts, Clients, Relays, Proxy/Servers and Gateways verify 1732 carrier packet L2 encapsulation addresses according to 1733 [I-D.templin-6man-omni]. 1735 * AERO nodes accept carrier packets addressed to themselves with 1736 Identification values within the current window for the OAL source 1737 neighbor and drop any carrier packets with out-of-window 1738 Identification values. (AERO nodes may forward carrier packets 1739 not addressed to themselves without verifying the Identification 1740 value.) 1742 AERO nodes silently drop any packets that do not satisfy the above 1743 data origin authentication procedures. Further security 1744 considerations are discussed in Section 6. 1746 3.9. OMNI Interface MTU 1748 The OMNI interface observes the link nature of tunnels, including the 1749 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 1750 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 1751 The OMNI interface employs an OMNI Adaptation Layer (OAL) that 1752 accommodates multiple underlay links with diverse MTUs while 1753 observing both a minimum and per-path Maximum Payload Size (MPS). 1754 The functions of the OAL and OMNI interface MTU/MRU/MPS 1755 considerations are specified in [I-D.templin-6man-omni]. (Note that 1756 the OMNI interface accommodates an assured MTU of 65535 octets due to 1757 the use of fragmentation, and can optionally expose larger MTUs to 1758 upper layers for best-effort Jumbogram services.) 1760 When the network layer presents an original IP packet to the OMNI 1761 interface, the OAL source encapsulates and fragments the packet if 1762 necessary. When the network layer presents the OMNI interface with 1763 multiple original IP packets bound to the same OAL destination, the 1764 OAL source can concatenate them as a single OAL super-packet as 1765 discussed in [I-D.templin-6man-omni] before applying fragmentation. 1766 The OAL source then encapsulates each OAL fragment in L2 headers for 1767 transmission as carrier packets over an underlay interface connected 1768 to either a physical link (e.g., Ethernet, WiFi, Cellular, etc.) or a 1769 virtual link such as an Internet or higher-layer tunnel (see the 1770 definition of link in [RFC8200]). 1772 Note: Although a CRH-32 may be inserted or removed by a Gateway in 1773 the path (see: Section 3.10.4), this does not interfere with the 1774 destination's ability to reassemble since the CRH-32 is not included 1775 in the fragmentable part and its removal/transformation does not 1776 invalidate fragment header information. 1778 3.10. OMNI Interface Forwarding Algorithm 1780 Original IP packets enter a node's OMNI interface either from the 1781 network layer (i.e., from a local application or the IP forwarding 1782 system) while carrier packets enter from the link layer (i.e., from 1783 an OMNI interface neighbor). All original IP packets and carrier 1784 packets entering a node's OMNI interface first undergo data origin 1785 authentication as discussed in Section 3.8. Those that satisfy data 1786 origin authentication are processed further, while all others are 1787 dropped silently. 1789 Original IP packets that enter the OMNI interface from the network 1790 layer are forwarded to an OMNI interface neighbor using OAL 1791 encapsulation and fragmentation to produce carrier packets for 1792 transmission over underlay interfaces. (If forwarding state 1793 indicates that the original IP packet should instead be forwarded 1794 back to the network layer, the packet is dropped to avoid looping). 1795 Carrier packets that enter the OMNI interface from the link layer are 1796 either re-encapsulated and re-admitted into the link layer, or 1797 reassembled and forwarded to the network layer where they are subject 1798 to either local delivery or IP forwarding. 1800 When the network layer forwards an original IP packet into the OMNI 1801 interface, it decrements the TTL/Hop Limit following standard IP 1802 router conventions. Once inside the OMNI interface, however, the OAL 1803 does not further decrement the original IP packet TTL/Hop Limit since 1804 its forwarding actions occur below the network layer. The original 1805 IP packet's TTL/Hop Limit will therefore be the same when it exits 1806 the destination OMNI interface as when it first entered the source 1807 OMNI interface. 1809 When an OAL intermediate node forwards an OAL packet or carrier 1810 packet not addressed to itself, it decrements the OAL Hop Limit 1811 without decrementing the network layer IP TTL/Hop Limit. If 1812 decrementing would cause the OAL Hop Limit to become 0, the OAL 1813 intermediate node drops the OAL packet or carrier packet. This 1814 ensures that the original IP packet cannot enter an endless loop. 1816 OMNI interfaces may have multiple underlay interfaces and/or neighbor 1817 cache entries for neighbors with multiple underlay interfaces (see 1818 Section 3.3). The OAL uses Interface Attributes and/or Traffic 1819 Selectors to select an outbound underlay interface for each OAL 1820 packet and also to select segment routing and/or link-layer 1821 destination addresses based on the neighbor's target underlay 1822 interfaces. AERO implementations SHOULD permit network management to 1823 dynamically adjust Traffic Selector values at runtime. 1825 If an OAL packet matches the Interface Attributes and/or Traffic 1826 Selectors of multiple outgoing interfaces and/or neighbor interfaces, 1827 the OMNI interface replicates the packet and sends a separate copy 1828 via each of the (outgoing / neighbor) interface pairs; otherwise, it 1829 sends a single copy via an interface with the best matching 1830 attributes/selectors. (While not strictly required, the likelihood 1831 of successful reassembly may improve when the OMNI interface sends 1832 all fragments of the same fragmented OAL packet consecutively over 1833 the same underlay interface pair to avoid complicating factors such 1834 as delay variance and reordering.) AERO nodes keep track of which 1835 underlay interfaces are currently "reachable" or "unreachable", and 1836 only use "reachable" interfaces for forwarding purposes. 1838 The ULA Subnet ID value is used only for subnet coordination within a 1839 local OMNI link segment. When a node forwards a packet addressed to 1840 a ULA with a foreign Global and/or Subnet ID value, it forwards the 1841 packet based solely on the OMNI link routing information. For this 1842 reason, OMNI link routing and forwarding table entries always include 1843 both ULA-RNDs with their associated prefix lengths and XLA-MNPs which 1844 encode an MNP while leaving the Global and Subnet ID values set to 0. 1846 The following sections discuss the OMNI interface-specific forwarding 1847 algorithms for Hosts, Clients, Proxy/Servers and Gateways. In the 1848 following discussion, an original IP packet's destination address is 1849 said to "match" if it is the same as a cached address, or if it is 1850 covered by a cached prefix (which may be encoded in an {ULA,XLA}- 1851 MNP). 1853 3.10.1. Host Forwarding Algorithm 1855 When an original IP packet enters a Host's OMNI interface from the 1856 network layer the Host searches for a NCE that matches the 1857 destination. If there is a matching NCE, the Host performs OMNI L2 1858 encapsulation, fragments the encapsulated packet if necessary as 1859 discussed in Section 6.13 of [I-D.templin-6man-omni] and forwards the 1860 packets into the ENET addressed to the L2 address of the neighbor. 1861 If there is no match, the host instead forwards the packet to its 1862 upstream Client. 1864 After forwarding a packet, the Host may receive a Redirect message 1865 from its upstream Client to inform it of another AERO node on the 1866 same ENET that would provide a better first hop. The Host 1867 authenticates the Redirect message, then updates its neighbor cache 1868 accordingly. 1870 3.10.2. Client Forwarding Algorithm 1872 When an original IP packet enters a Client's OMNI interface from the 1873 network layer the Client searches for a NCE that matches the 1874 destination. If there is a matching NCE for a neighbor reached via 1875 an ANET/INET interface (i.e., an upstream interface), the Client 1876 selects one or more "reachable" neighbor interfaces in the entry for 1877 forwarding purposes. Otherwise, the Client forwards the packet to an 1878 FHS Proxy/Server while either invoking address resolution and 1879 multilink forwarding procedures per Section 3.13 or allowing the FHS 1880 Proxy/Server to invoke these procedures on its behalf. If there is a 1881 matching NCE for a neighbor reached via an ENET interface (i.e., a 1882 downstream interface), the Client instead forwards the packet to the 1883 downstream Host or Client using encapsulation and fragmentation if 1884 necessary. 1886 When a carrier packet enters a Client's OMNI interface from the link 1887 layer, the Client first examines the OAL destination. If the OAL 1888 destination matches one of the Client's ULAs the Client (acting as an 1889 OAL destination) verifies that the Identification is in-window for 1890 this OAL source, then reassembles, decapsulates as necessary and 1891 delivers the original IP packet to the network layer. If the OAL 1892 destination matches a NCE for a Client on an ENET interface, the 1893 Client instead forwards the carrier packet to the Client while 1894 decrementing the OAL Hop Limit. If the OAL destination matches a NCE 1895 for a Host on an ENET interface, the Client instead reassembles then 1896 forwards the original IP packet to the Host while using IP-in-IP 1897 encapsulation and fragmentation if necessary. If the OAL destination 1898 does not match, the Client drops the original IP packet and MAY 1899 return a network-layer ICMP Destination Unreachable message subject 1900 to rate limiting (see: Section 3.11). 1902 When a Client forwards a carrier packet from an ENET Host to a 1903 neighbor connected to the same ENET, it also returns a Redirect 1904 message to inform the Host that it can reach the neighbor directly as 1905 an ENET peer. 1907 Note: Clients and their FHS Proxy/Server (and other Client) peers can 1908 exchange original IP packets over ANET underlay interfaces without 1909 invoking the OAL, since the ANET is secured at the link and physical 1910 layers. By forwarding original IP packets without invoking the OAL, 1911 the ANET peers use the same OMNI L2 encapsulation and fragmentation 1912 procedures as specified for Hosts above. 1914 Note: The forwarding table entries established in peer Clients of a 1915 multihop forwarding region are based on ULA-MNPs and/or TLAs used to 1916 seed the multihop routing protocols. When ULA-MNPs are used, the ULA 1917 /64 prefix provides topological relevance for the multihop forwarding 1918 region, while the 64-bit Interface Identifier encodes the Client MNP. 1919 Therefore, Clients can forward atomic fragments with compressed OAL 1920 headers that do not include ULA or AFVI information by examining the 1921 MNP-based addresses in the actual IP packet header. In other words, 1922 each forwarding table entry contains two pieces of forwarding 1923 information - the ULA information in the prefix and the MNP 1924 information in the interface identifier. 1926 3.10.3. Proxy/Server and Relay Forwarding Algorithm 1928 When the network layer admits an original IP packet into a Proxy/ 1929 Server's OMNI interface, the OAL drops the packet to avoid looping if 1930 forwarding state indicates that it should be forwarded back to the 1931 network layer. Otherwise, the OAL examines the IP destination 1932 address to determine if it matches the ULA of a neighboring Gateway 1933 found in the OMNI interface's network layer neighbor cache. If so, 1934 the Proxy/Server performs OAL encapsulation and forwards the 1935 resulting carrier packets to the neighboring Gateway over a secured 1936 tunnel to support the operation of the BGP routing protocol. If the 1937 destination is a non-ULA, the Proxy/Server instead assumes the Relay 1938 role and forwards the original IP packet in a similar manner as for 1939 Clients. Specifically, if there is a matching NCE the Proxy/Server 1940 selects one or more "reachable" neighbor interfaces in the entry for 1941 forwarding purposes; otherwise, the Proxy/Server forwards the packet 1942 while invoking address resolution and multilink forwarding procedures 1943 per Section 3.13. 1945 When the Proxy/Server receives carrier packets on underlay interfaces 1946 with both a source and destination OAL address that correspond to the 1947 same Client's delegated MNP, the Proxy/Server drops the packets 1948 regardless of their OMNI link point of origin. The Proxy/Server also 1949 drops original IP packets received on underlay interfaces either 1950 directly from an ANET Client or following reassembly of carrier 1951 packets received from an ANET/INET Client if the original IP 1952 destination corresponds to the same Client's delegated MNP. Proxy/ 1953 Servers also drop carrier packets with foreign OAL destinations that 1954 do not match their own ULA, the ULA of one of their Clients or a ULA 1955 corresponding to one of their GUA routes. These checks are essential 1956 to prevent forwarding inconsistencies from accidentally or 1957 intentionally establishing endless loops that could congest nodes 1958 and/or ANET/INET links. 1960 Proxy/Servers process carrier packets with OCH headers or with 1961 destinations that match their ULA and also include a CRH-32 header 1962 that encodes one or more AFVIs. The Proxy/Server examines the next 1963 AFVI in the carrier packet to locate the corresponding AFV entry in 1964 the AFIB. If the carrier packets were not received from the secured 1965 spanning tree, the Proxy/Server must then verify that the L2 1966 addresses are "trusted" according to the AFV. If the carrier packets 1967 were trusted, the Proxy/Server then forwards them according to the 1968 AFV state while decrementing the OAL Hop Limit. 1970 For carrier packets with destinations that match their ULA but do not 1971 include a CRH-32/OCH, the Proxy/Server instead discards the L2 1972 headers and performs OAL reassembly if necessary to obtain the 1973 original IP packet. For data packets addressed to their own ULA that 1974 arrived via the secured spanning tree, the Proxy/Server delivers the 1975 original IP packet to the network layer to support secured BGP 1976 routing protocol control messaging. For data packets originating 1977 from one of its dependent Clients, the Proxy/Server instead forwards 1978 the packet while invoking address resolution and multilink forwarding 1979 procedures per Section 3.13. For IPv6 ND control messages, the 1980 Proxy/Server instead authenticates the message and processes it as 1981 specified in later sections of this document while updating neighbor 1982 cache and/or AFIB state accordingly. 1984 When the Proxy/Server receives a carrier packet with OAL destination 1985 set to a {ULA,XLA}-MNP of one of its Client neighbors established 1986 through RS/RA exchanges, it accepts the carrier packet only if data 1987 origin authentication succeeds. If the NCE state is DEPARTED, the 1988 Proxy/Server changes the OAL destination address to the ULA of the 1989 new Proxy/Server, decrements the OAL Hop Limit, then supplies new L2 1990 headers and forwards the carrier packet into the spanning tree which 1991 will eventually deliver it to the new Proxy/Server. If the neighbor 1992 cache state for the Client is REACHABLE and the Proxy/Server is a Hub 1993 responsible for serving as the Client's address resolution responder 1994 and/or default router, it submits the carrier packet for reassembly 1995 then decapsulates and processes the resulting IPv6 ND message or 1996 original IP packet accordingly. Otherwise, the Proxy/Server 1997 decrements the OAL Hop Limit, supplies new L2 headers and forwards 1998 the carrier packets to the Client which must then perform data origin 1999 verification and reassembly. (In the latter case, the Client may 2000 receive fragments of the same original packet from different Proxy/ 2001 Servers but this will not interfere with reassembly.) 2003 When the Proxy/Server receives a carrier packet with OAL destination 2004 set to a {ULA,XLA}-MNP that does not match the MSP, it accepts the 2005 carrier packet only if data origin authentication succeeds and if 2006 there is a network layer forwarding table entry for a GUA route that 2007 matches the MNP. The Proxy/Server then reassembles and decapsulates 2008 to obtain the original IP packet, then presents it to the network 2009 layer (as a Relay) where it will be delivered according to standard 2010 IP forwarding. 2012 Clients and their FHS Proxy/Server peers can exchange original IP 2013 packets over ANET underlay interfaces without invoking the OAL, since 2014 the ANET is secured at the link and physical layers. By forwarding 2015 original IP packets without invoking the OAL, however, the Client and 2016 Proxy/Server can engage only in classical path MTU discovery since 2017 the packets are subject to loss and/or corruption due to the various 2018 per-link MTU limitations that may occur within the ANET. Moreover, 2019 the original IP packets do not include either the OAL integrity check 2020 or per-packet Identification values that can be used for data origin 2021 authentication and link-layer retransmissions. The tradeoff 2022 therefore involves an assessment of the per-packet encapsulation 2023 overhead saved by bypassing the OAL vs. inheritance of classical 2024 network "brittleness". (Note however that ANET peers can send small 2025 original IP packets without invoking the OAL, while invoking the OAL 2026 for larger packets. This presents the beneficial aspects of both 2027 small packet efficiency and large packet robustness.) 2029 Proxy/Servers forward secure control plane carrier packets via the 2030 SRT secured spanning tree and forward other carrier packets via the 2031 unsecured spanning tree. When a Proxy/Server receives a carrier 2032 packet from the secured spanning tree, it considers the message as 2033 authentic without having to verify upper layer authentication 2034 signatures. When a Proxy/Server receives a carrier packet from the 2035 unsecured spanning tree, it applies data origin authentication itself 2036 and/or forwards the unsecured message toward the destination which 2037 must apply data origin authentication on its own behalf. 2039 If the Proxy/Server has multiple original IP packets to send to the 2040 same neighbor, it can concatenate them as a single OAL super-packet 2041 [I-D.templin-6man-omni]. If the first packet in the super-packet is 2042 a control message to be sent over the secured spanning tree, the 2043 remainder of the super-packet is also sent over the secured spanning 2044 tree. 2046 Note: Clients and their FHS Proxy/Server (and other Client) peers can 2047 exchange original IP packets over ANET underlay interfaces without 2048 invoking the OAL, since the ANET is secured at the link and physical 2049 layers. By forwarding original IP packets without invoking the OAL, 2050 the ANET peers use the same OMNI L2 encapsulation and fragmentation 2051 procedures as specified for Hosts above. 2053 3.10.4. Gateway Forwarding Algorithm 2055 When the network layer admits an original IP packet into the 2056 Gateway's OMNI interface, the OAL drops the packet if routing 2057 indicates that it should be forwarded back to the network layer to 2058 avoid looping. Otherwise, the Gateway examines the IP destination 2059 address to determine if it matches the ULA of a neighboring Gateway 2060 or Proxy/Server by examining the OMNI interface's network layer 2061 neighbor cache. If so, the Gateway performs OAL and L2 encapsulation 2062 and forwards the resulting carrier packets to the neighboring Gateway 2063 or Proxy/Server over a secured tunnel to support the operation of the 2064 BGP routing protocol between OAL neighbors. 2066 Gateways forward spanning tree carrier packets while decrementing the 2067 OAL Hop Limit but not the original IP header TTL/Hop Limit. Gateways 2068 convey carrier packets that encapsulate critical IPv6 ND control 2069 messages or BGP routing protocol control messages via the SRT secured 2070 spanning tree, and may convey other carrier packets via the secured/ 2071 unsecured spanning tree or via more direct paths according to AFIB 2072 information. When the Gateway receives a carrier packet, it removes 2073 the L2 headers and searches for an AFIB entry that matches an AFVI or 2074 an IP forwarding table entry that matches the OAL destination 2075 address. 2077 Gateways process carrier packets with OAL destinations that do not 2078 match their ULA or the SRT Subnet Router Anycast address in the same 2079 manner as for traditional IP forwarding within the OAL, i.e., they 2080 forward packets not explicitly addressed to themselves. Gateways 2081 locally process carrier packets with OCH headers or full OAL headers 2082 with their ULA or the SRT Subnet Router Anycast address as the OAL 2083 destination. If the packet contains an OCH or a full OAL header with 2084 a CRH-32 extension, the Gateway examines the next AFVI in the carrier 2085 packet to locate the AFV entry in the AFIB for next hop forwarding. 2086 If an AFV is found, the Gateway uses the next hop AFVI to forward the 2087 carrier packet to the next hop while decrementing the OAL Hop Limit 2088 but without reassembling. If the Gateway has a NCE for the target 2089 Client with an entry for the target underlay interface and current L2 2090 addresses, the Gateway instead forwards the carrier packet directly 2091 to the target Client while using the final hop AFVI instead of the 2092 next hop (see: Section 3.13.3). 2094 If the carrier packet includes a full OAL header addressed to itself 2095 but does not include an AFVI, the Gateway instead reassembles if 2096 necessary, verifies the OAL checksum, and processes the OAL packet 2097 further. The Gateway first determines whether the OAL packet 2098 includes an NS/NA message then processes the message according to the 2099 multilink forwarding procedures discussed in Section 3.13. If the 2100 carrier packets arrived over the secured spanning tree and the 2101 reassembled original IP packet is addressed to its ULA, the Gateway 2102 instead discards the OAL header and forwards the original IP packet 2103 to the network layer to support secured BGP routing protocol control 2104 messaging. The Gateway instead drops all other OAL packets. 2106 Gateways forward carrier packets received from a first segment via 2107 the secured spanning tree to the next segment also via the secured 2108 spanning tree. Gateways forward carrier packets received from a 2109 first segment via the unsecured spanning tree to the next segment 2110 also via the unsecured spanning tree. Gateways use a single IPv6 2111 routing table that always determines the same next hop for a given 2112 OAL destination, where the secured/unsecured spanning tree is 2113 determined through the selection of the underlay interface to be used 2114 for transmission (i.e., a secured tunnel or an open INET interface). 2116 As for Proxy/Servers, Gateways must verify that the L2 addresses of 2117 carrier packets not received from the secured spanning tree are 2118 "trusted" before forwarding according to an AFV (otherwise, the 2119 carrier packet must be dropped). 2121 3.11. OMNI Interface Error Handling 2123 When an AERO node admits an original IP packet into the OMNI 2124 interface, it may receive link-layer or network-layer error 2125 indications. The AERO node may also receive OMNI link error 2126 indications in OAL-encapsulated uNA messages that include 2127 authentication signatures. 2129 A link-layer error indication is an ICMP error message generated by a 2130 router in an underlay network on the path to the neighbor or by the 2131 neighbor itself. The message includes an IP header with the address 2132 of the node that generated the error as the source address and with 2133 the link-layer address of the AERO node as the destination address. 2135 The IP header is followed by an ICMP header that includes an error 2136 Type, Code and Checksum. Valid type values include "Destination 2137 Unreachable", "Time Exceeded" and "Parameter Problem" 2138 [RFC0792][RFC4443]. (OMNI interfaces ignore link-layer IPv4 2139 "Fragmentation Needed" and IPv6 "Packet Too Big" messages for carrier 2140 packets that are no larger than the minimum/path MPS as discussed in 2141 Section 3.9, however these messages may provide useful hints of probe 2142 failures during path MPS probing.) 2144 The ICMP header is followed by the leading portion of the carrier 2145 packet that generated the error, also known as the "packet-in-error". 2146 For ICMPv6, [RFC4443] specifies that the packet-in-error includes: 2147 "As much of invoking packet as possible without the ICMPv6 packet 2148 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 2149 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 2150 "Internet Header + 64 bits of Original Data Datagram", however 2151 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 2152 ICMP datagram SHOULD contain as much of the original datagram as 2153 possible without the length of the ICMP datagram exceeding 576 2154 bytes". 2156 The link-layer error message format is shown in Figure 4: 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 ~ ~ 2160 | IP Header of link layer | 2161 | error message | 2162 ~ ~ 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | ICMP Header | 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2166 ~ ~ P 2167 | carrier packet L2 and OAL | a 2168 | encapsulation headers | c 2169 ~ ~ k 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 2171 ~ ~ t 2172 | original IP packet headers | 2173 | (first-fragment only) | i 2174 ~ ~ n 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 ~ ~ e 2177 | Portion of the body of | r 2178 | the original IP packet | r 2179 | (all fragments) | o 2180 ~ ~ r 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2183 Figure 4: OMNI Interface Link-Layer Error Message Format 2185 The AERO node rules for processing these link-layer error messages 2186 are as follows: 2188 * When an AERO node receives a link-layer Parameter Problem message, 2189 it processes the message the same as described as for ordinary 2190 ICMP errors in the normative references [RFC0792][RFC4443]. 2192 * When an AERO node receives persistent link-layer Time Exceeded 2193 messages, the IP ID field may be wrapping before earlier fragments 2194 awaiting reassembly have been processed. In that case, the node 2195 should begin including integrity checks and/or institute rate 2196 limits for subsequent packets. 2198 * When an AERO node receives persistent link-layer Destination 2199 Unreachable messages in response to carrier packets that it sends 2200 to one of its neighbor correspondents, the node should process the 2201 message as an indication that a path may be failing, and 2202 optionally initiate NUD over that path. If it receives 2203 Destination Unreachable messages over multiple paths, the node 2204 should allow future carrier packets destined to the correspondent 2205 to flow through a default route and re-initiate route 2206 optimization. 2208 * When an AERO Client receives persistent link-layer Destination 2209 Unreachable messages in response to carrier packets that it sends 2210 to one of its neighbor Proxy/Servers, the Client should mark the 2211 path as unusable and use another path. If it receives Destination 2212 Unreachable messages on many or all paths, the Client should 2213 associate with a new Proxy/Server and release its association with 2214 the old Proxy/Server as specified in Section 3.15.5. 2216 * When an AERO Proxy/Server receives persistent link-layer 2217 Destination Unreachable messages in response to carrier packets 2218 that it sends to one of its neighbor Clients, the Proxy/Server 2219 should mark the underlay path as unusable and use another underlay 2220 path. 2222 * When an AERO Proxy/Server receives link-layer Destination 2223 Unreachable messages in response to a carrier packet that it sends 2224 to one of its permanent neighbors, it treats the messages as an 2225 indication that the path to the neighbor may be failing. However, 2226 the dynamic routing protocol should soon reconverge and correct 2227 the temporary outage. 2229 When an AERO Gateway receives a carrier packet for which the network- 2230 layer destination address is covered by an MSP assigned to a black- 2231 hole route, the Gateway drops the packet if there is no more-specific 2232 routing information for the destination and returns an OMNI interface 2233 Destination Unreachable message subject to rate limiting. 2235 When an AERO node receives a carrier packet for which reassembly is 2236 currently congested, it returns an OMNI interface Packet Too Big 2237 (PTB) message as discussed in [I-D.templin-6man-omni] (note that the 2238 PTB messages could indicate either "hard" or "soft" errors). 2240 AERO nodes include ICMPv6 error messages intended for an OAL source 2241 as sub-options in the OMNI option of secured uNA messages. When the 2242 OAL source receives the uNA message, it can extract the ICMPv6 error 2243 message enclosed in the OMNI option and either process it locally or 2244 translate it into a network-layer error to return to the original 2245 source. 2247 3.12. AERO Mobility Service Coordination 2249 AERO nodes observes the Router Discovery and Prefix Registration 2250 specifications found in Section 15 of [I-D.templin-6man-omni]. AERO 2251 nodes further coordinate their autoconfiguration actions with the 2252 mobility service as discussed in the following sections. 2254 3.12.1. AERO Service Model 2256 Each AERO Proxy/Server on the OMNI link is configured to facilitate 2257 Client prefix delegation/registration requests. Each Proxy/Server is 2258 provisioned with a database of MNP-to-Client ID mappings for all 2259 Clients enrolled in the AERO service, as well as any information 2260 necessary to authenticate each Client. The Client database is 2261 maintained by a central administrative authority for the OMNI link 2262 and securely distributed to all Proxy/Servers, e.g., via the 2263 Lightweight Directory Access Protocol (LDAP) [RFC4511], via static 2264 configuration, etc. Clients receive the same service regardless of 2265 the Proxy/Servers they select. 2267 Clients associate each of their ANET/INET underlay interfaces with a 2268 FHS Proxy/Server. Each FHS Proxy/Server locally services one or more 2269 of the Client's underlay interfaces, and the Client typically selects 2270 one among them to serve as the Hub Proxy/Server (the Client may 2271 instead select a "third-party" Hub Proxy/Server that does not 2272 directly service any of its underlay interfaces). All of the 2273 Client's other FHS Proxy/Servers forward proxyed copies of RS/RA 2274 messages between the Hub Proxy/Server and Client without assuming the 2275 Hub role functions themselves. 2277 Each Client associates with a single Hub Proxy/Server at a time, 2278 while all other Proxy/Servers are candidates for providing the Hub 2279 role for other Clients. An FHS Proxy/Server assumes the Hub role 2280 when it receives an RS message with its own ULA or link-scoped All- 2281 Routers multicast as the destination. An FHS Proxy/Server assumes 2282 the proxy role when it receives an RS message with the ULA of another 2283 Proxy/Server as the destination. (An FHS Proxy/Server can also 2284 assume the proxy role when it receives an RS message addressed to 2285 link-scoped All-Routers multicast if it can determine the ULA of 2286 another Proxy/Server to serve as a Hub.) 2288 Hosts and Clients on ENET interfaces associate with an upstream 2289 Client on the ENET the same as a Client would associate with an ANET 2290 Proxy/Server. In particular, the Host/Client sends an RS message via 2291 the ENET which directs the message to the upstream Client. The 2292 upstream Client returns an RA message. In this way, the downstream 2293 nodes see the ENET as an ANET and see the upstream Client as a Proxy/ 2294 Server for that ANET. 2296 AERO Hosts, Clients and Proxy/Servers use IPv6 ND messages to 2297 maintain neighbor cache entries. AERO Proxy/Servers configure their 2298 OMNI interfaces as advertising NBMA interfaces, and therefore send 2299 unicast RA messages with a short Router Lifetime value (e.g., 2300 ReachableTime seconds) in response to a Client's RS message. 2301 Thereafter, Clients send additional RS messages to keep Proxy/Server 2302 state alive. 2304 AERO Clients and Hub Proxy/Servers include prefix delegation and/or 2305 registration parameters in RS/RA messages. The IPv6 ND messages are 2306 exchanged between the Client and Hub Proxy/Server (via any FHS Proxy/ 2307 Servers acting as proxys) according to the prefix management schedule 2308 required by the service. If the Client knows its MNP in advance, it 2309 can employ prefix registration by including its XLA-MNP as the source 2310 address of an RS message and with an OMNI option with valid prefix 2311 registration information for the MNP. If the Hub Proxy/Server 2312 accepts the Client's MNP assertion, it injects the MNP into the 2313 routing system and establishes the necessary neighbor cache state. 2314 If the Client does not have a pre-assigned MNP, it can instead employ 2315 prefix delegation by including a TLA as the source address of an RS 2316 message and with an OMNI option with prefix delegation parameters to 2317 request an MNP. 2319 The following sections outlines Host, Client and Proxy/Server 2320 behaviors based on the Router Discovery and Prefix Registration 2321 specifications found in Section 15 of [I-D.templin-6man-omni]. These 2322 sections observe all of the OMNI specifications, and include 2323 additional specifications of the interactions of Client-Proxy/Server 2324 RS/RA exchanges with the AERO mobility service. 2326 3.12.2. AERO Host and Client Behavior 2328 AERO Hosts and Clients discover the addresses of candidate Proxy/ 2329 Servers by resolving the Potential Router List (PRL) in a similar 2330 manner as described in [RFC5214]. Discovery methods include static 2331 configuration (e.g., a flat-file map of Proxy/Server addresses and 2332 locations), or through an automated means such as Domain Name System 2333 (DNS) name resolution [RFC1035]. Alternatively, the Host/Client can 2334 discover Proxy/Server addresses through a layer 2 data link login 2335 exchange, or through an RA response to a multicast/anycast RS as 2336 described below. In the absence of other information, the Host/ 2337 Client can resolve the DNS Fully-Qualified Domain Name (FQDN) 2338 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 2339 text string and "[domainname]" is a DNS suffix for the OMNI link 2340 (e.g., "example.com"). The name resolution returns a set of resource 2341 records with Proxy/Server address information. 2343 The Host/Client then performs RS/RA exchanges over each of its 2344 underlay interfaces to associate with (possibly multiple) FHS Proxy/ 2345 Serves and a single Hub Proxy/Server as specified in Section 15 of 2346 [I-D.templin-6man-omni]. The Host/Client then sends each RS (either 2347 directly via Direct interfaces, via a VPN for VPNed interfaces, via 2348 an access router for ANET interfaces or via INET encapsulation for 2349 INET interfaces) and waits up to RetransTimer milliseconds for an RA 2350 message reply (see Section 3.12.3) while retrying up to 2351 MAX_RTR_SOLICITATIONS if necessary. If the Host/Client receives no 2352 RAs, or if it receives an RA with Router Lifetime set to 0, the 2353 Client SHOULD abandon attempts through the first candidate Proxy/ 2354 Server and try another Proxy/Server. 2356 After the Host/Client registers its underlay interfaces, it may wish 2357 to change one or more registrations, e.g., if an interface changes 2358 address or becomes unavailable, if traffic selectors change, etc. To 2359 do so, the Host/Client prepares an RS message to send over any 2360 available underlay interface as above. The RS includes an OMNI 2361 option with prefix registration/delegation information and with an 2362 Interface Attributes sub-option specific to the selected underlay 2363 interface. When the Host/Client receives the Hub Proxy/Server's RA 2364 response, it has assurance that both the Hub and FHS Proxy/Servers 2365 have been updated with the new information. 2367 If the Host/Client wishes to discontinue use of a Hub Proxy/Server it 2368 issues an RS message over any underlay interface with an OMNI option 2369 with a prefix release indication (i.e., by setting the OMNI Neighbor 2370 Coordination sub-option Preflen to 0). When the Hub Proxy/Server 2371 processes the message, it releases the MNP, sets the NCE state for 2372 the Host/Client to DEPARTED and returns an RA reply with Router 2373 Lifetime set to 0. After a short delay (e.g., 2 seconds), the Hub 2374 Proxy/Server withdraws the MNP from the routing system. 2375 (Alternatively, when the Host/Client associates with a new FHS/Hub 2376 Proxy/Server it can include an OMNI "Proxy/Server Departure" sub- 2377 option in RS messages with the ULAs of the Old FHS/Hub Proxy/ 2378 Servers.) 2380 3.12.3. AERO Proxy/Server Behavior 2382 AERO Proxy/Servers act as both IP routers and IPv6 ND proxys, and 2383 support a prefix delegation/registration service for Clients. Proxy/ 2384 Servers arrange to add their ULAs to the PRL maintained in a static 2385 map of Proxy/Server addresses for the link, the DNS resource records 2386 for the FQDN "linkupnetworks.[domainname]", etc. before entering 2387 service. The PRL should be arranged such that Clients can discover 2388 the addresses of Proxy/Servers that are geographically and/or 2389 topologically "close" to their underlay network connections. 2391 When a FHS/Hub Proxy/Server receives a prospective Client's RS 2392 message, it SHOULD return an immediate RA reply with Router Lifetime 2393 set to 0 if it is currently too busy or otherwise unable to service 2394 the Client; otherwise, it processes the RS as specified in Section 15 2395 of [I-D.templin-6man-omni]. When the Hub Proxy/Server receives the 2396 RS, it determines the correct MNPs to provide to the Client by 2397 processing the XLA-MNP prefix parameters and/or the DHCPv6 OMNI sub- 2398 option. When the Hub Proxy/Server returns the MNPs, it also creates 2399 an XLA-MNP forwarding table entry for the MNP resulting in a BGP 2400 update (see: Section 3.2.3). The Hub Proxy/Server then returns an RA 2401 to the Client with destination set to the source of the RS (if an FHS 2402 Proxy/Server on the return path proxys the RA, it changes the 2403 destination to the Client's ULA-MNP). 2405 After the initial RS/RA exchange, the Hub Proxy/Server maintains a 2406 ReachableTime timer for each of the Client's underlay interfaces 2407 individually (and for the Client's NCE collectively) set to expire 2408 after ReachableTime seconds. If the Client (or an FHS Proxy/Server) 2409 issues additional RS messages, the Hub Proxy/Server sends an RA 2410 response and resets ReachableTime. If the Hub Proxy/Server receives 2411 an IPv6 ND message with a prefix release indication it sets the 2412 Client's NCE to the DEPARTED state and withdraws the MNP route from 2413 the routing system after a short delay (e.g., 2 seconds). If 2414 ReachableTime expires before a new RS is received on an individual 2415 underlay interface, the Hub Proxy/Server marks the interface as DOWN. 2416 If ReachableTime expires before any new RS is received on any 2417 individual underlay interface, the Hub Proxy/Server sets the NCE 2418 state to STALE and sets a 10 second timer. If the Hub Proxy/Server 2419 has not received a new RS or uNA message with a prefix release 2420 indication before the 10 second timer expires, it deletes the NCE and 2421 withdraws the XLA-MNP from the routing system. 2423 The Hub Proxy/Server processes any IPv6 ND messages pertaining to the 2424 Client while forwarding to the Client or responding on the Client's 2425 behalf as necessary. The Hub Proxy/Server may also issue unsolicited 2426 RA messages, e.g., with reconfigure parameters to cause the Client to 2427 renegotiate its prefix delegation/registrations, with Router Lifetime 2428 set to 0 if it can no longer service this Client, etc. The Hub 2429 Proxy/Server may also receive carrier packets via the secured 2430 spanning tree that contain initial data packets sent while route 2431 optimization is in progress. The Hub Proxy/Server reassembles, then 2432 re-encapsulates/re-fragments and forwards the packets to the target 2433 Client via an FHS Proxy/Server if necessary. Finally, If the NCE is 2434 in the DEPARTED state, the old Hub Proxy/Server forwards any carrier 2435 packets it receives from the secured spanning tree and destined to 2436 the Client to the new Hub Proxy/Server, then deletes the entry after 2437 DepartTime expires. 2439 Note: Clients SHOULD arrange to notify former Hub Proxy/Servers of 2440 their departures, but Hub Proxy/Servers are responsible for expiring 2441 neighbor cache entries and withdrawing XLA-MNP routes even if no 2442 departure notification is received (e.g., if the Client leaves the 2443 network unexpectedly). Hub Proxy/Servers SHOULD therefore set Router 2444 Lifetime to ReachableTime seconds in solicited RA messages to 2445 minimize persistent stale cache information in the absence of Client 2446 departure notifications. A short Router Lifetime also ensures that 2447 proactive RS/RA messaging between Clients and FHS Proxy/Servers will 2448 keep any NAT state alive (see above). 2450 Note: All Proxy/Servers on an OMNI link MUST advertise consistent 2451 values in the RA Cur Hop Limit, M and O flags, Reachable Time and 2452 Retrans Timer fields the same as for any link, since unpredictable 2453 behavior could result if different Proxy/Servers on the same link 2454 advertised different values. 2456 3.12.3.1. Additional Proxy/Server Considerations 2458 AERO Clients register with FHS Proxy/Servers for each underlay 2459 interface. Each of the Client's FHS Proxy/Servers must inform a 2460 single Hub Proxy/Server of the Client's underlay interface(s) that it 2461 services. For Clients on Direct and VPNed underlay interfaces, the 2462 FHS Proxy/Server for each interface is directly connected, for 2463 Clients on ANET underlay interfaces the FHS Proxy/Server is located 2464 on the ANET/INET boundary, and for Clients on INET underlay 2465 interfaces the FHS Proxy/Server is located somewhere in the connected 2466 Internetwork. When FHS Proxy/Server "B" processes a Client 2467 registration, it must either assume the Hub role or forward a proxyed 2468 registration to another Proxy/Server "A" acting as the Hub. Proxy/ 2469 Servers satisfy these requirements as follows: 2471 * when FHS Proxy/Server "B" receives a Client RS message, it first 2472 verifies that the OAL Identification is within the window for the 2473 NCE that matches the {UAL,XLA}-MNP in the RS source address for 2474 this Client neighbor and authenticates the message. If no NCE was 2475 found, Proxy/Server "B" instead creates one in the STALE state and 2476 caches the Client-supplied Interface Attributes, Origin Indication 2477 and OMNI Neighbor Coordination sub-option window synchronization 2478 parameters as well as the Client's observed L2 addresses (noting 2479 that they may differ from the Origin addresses if there were NATs 2480 on the path). Proxy/Server "B" then examines the RS destination 2481 address. If the destination address is the ULA of a different 2482 Proxy/Server "A", Proxy/Server "B" prepares a separate proxyed 2483 version of the RS message with an OAL header with source set to 2484 its own ULA and destination set to Proxy/Server B's ULA. Proxy/ 2485 Server "B" also writes its own information over the Interface 2486 Attributes sub-option supplied by the Client, omits or zeros the 2487 Origin Indication sub-option then forwards the message into the 2488 OMNI link secured spanning tree. 2490 * when Hub Proxy/Server "A" receives the RS, it assume the Hub role, 2491 delegates an MNP for the Client if necessary, and creates/updates 2492 a NCE indexed by the Client's XLA-MNP with FHS Proxy/Server "B"'s 2493 Interface Attributes as the link-layer address information for 2494 this FHS ifIndex. Hub Proxy/Server "A" then prepares an RA 2495 message with source set to its own ULA and destination set to the 2496 source of the RS message, then encapsulates the RA in an OAL 2497 header with source set to its own ULA and destination set to the 2498 ULA of FHS Proxy/Server "B". Hub Proxy/Server "A" then performs 2499 fragmentation if necessary and sends the resulting carrier packets 2500 into the secured spanning tree. 2502 * when FHS Proxy/Server "B" reassembles the RA, it locates the 2503 Client NCE based on the RA destination. If the RA message 2504 includes an OMNI "Proxy/Server Departure" sub-option, Proxy/Server 2505 "B" first sends a uNA to the old FHS/Hub Proxy/Servers named in 2506 the sub-option. If the RA message delegates a new XLA-MNP, Proxy/ 2507 Server "B" then resets the RA destination to the corresponding 2508 ULA-MNP for this interface. Proxy/Server "B" then re-encapsulates 2509 the message with OAL source set to its own ULA and OAL destination 2510 set to ULA that appeared in the Client's RS message OAL source, 2511 with an appropriate Identification value, with an authentication 2512 signature if necessary, with the Client's Interface Attributes 2513 sub-option echoed and with the cached observed L2 addresses 2514 written into an Origin Indication sub-option. Proxy/Server "B" 2515 sets the P flag in the RA flags field to indicate that the message 2516 has passed through a proxy [RFC4389], includes responsive window 2517 synchronization parameters, then fragments the RA if necessary and 2518 returns the fragments to the Client. 2520 * The Client repeats this process over each of its additional 2521 underlay interfaces while treating each additional FHS Proxy/ 2522 Server "C", "D", "E", etc. as a proxy to facilitate RS/RA 2523 exchanges between the Hub and the Client. The Client creates/ 2524 updates NCEs for each such FHS Proxy/Server as well as the Hub 2525 Proxy/Server in the process. 2527 After the initial RS/RA exchanges each FHS Proxy/Server forwards any 2528 of the Client's carrier packets with OAL destinations for which there 2529 is no matching NCE to a Gateway using OAL encapsulation with its own 2530 ULA as the source and with destination determined by the Client. The 2531 Proxy/Server instead forwards any carrier packets destined to a 2532 neighbor cache target directly to the target according to the OAL/ 2533 link-layer information - the process of establishing neighbor cache 2534 entries is specified in Section 3.13. 2536 While the Client is still associated with FHS Proxy/Servers "B", "C", 2537 "D", etc., each FHS Proxy/Server can send NS, RS and/or unsolicited 2538 NA messages to update the neighbor cache entries of other AERO nodes 2539 on behalf of the Client based on changes in Interface Attributes, 2540 Traffic Selectors, etc. This allows for higher-frequency Proxy- 2541 initiated RS/RA messaging over well-connected INET infrastructure 2542 supplemented by lower-frequency Client-initiated RS/RA messaging over 2543 constrained ANET data links. 2545 If the Hub Proxy/Server "A" ceases to send solicited RAs, FHS Proxy/ 2546 Servers "B", "C", "D" can send unsolicited RAs over the Client's 2547 underlay interface with destination set to (link-local) All-Nodes 2548 multicast and with Router Lifetime set to zero to inform Clients that 2549 the Hub Proxy/Server has failed. Although FHS Proxy/Servers "B", "C" 2550 and "D" can engage in IPv6 ND exchanges on behalf of the Client, the 2551 Client can also send IPv6 ND messages on its own behalf, e.g., if it 2552 is in a better position to convey state changes. The IPv6 ND 2553 messages sent by the Client include the Client's XLA-MNP as the 2554 source in order to differentiate them from the IPv6 ND messages sent 2555 by a FHS Proxy/Server. 2557 If the Client becomes unreachable over all underlay interface it 2558 serves, the Hub Proxy/Server sets the NCE state to DEPARTED and 2559 retains the entry for DepartTime seconds. While the state is 2560 DEPARTED, the Hub Proxy/Server forwards any carrier packets destined 2561 to the Client to a Gateway via OAL encapsulation. When DepartTime 2562 expires, the Hub Proxy/Server deletes the NCE, withdraws the XLA-MNP 2563 route and discards any further carrier packets destined to the former 2564 Client. 2566 In some ANETs that employ a Proxy/Server, the Client's MNP can be 2567 injected into the ANET routing system. In that case, the Client can 2568 send original IP packets without invoking the OAL so that the ANET 2569 routing system transports the original IP packets to the Proxy/ 2570 Server. This can be beneficial, e.g., if the Client connects to the 2571 ANET via low-end data links such as some aviation wireless links. 2573 If the ANET first-hop access router is on the same underlay link as 2574 the Client and recognizes the AERO/OMNI protocol, the Client can 2575 avoid OAL encapsulation for both its control and data messages. When 2576 the Client connects to the link, it can send an unencapsulated RS 2577 message with source address set to its own XLA-MNP (or to a TLA), and 2578 with destination address set to the ULA of the Client's selected 2579 Proxy/Server or to link-scoped All-Routers multicast. The Client 2580 includes an OMNI option formatted as specified in 2581 [I-D.templin-6man-omni]. The Client then sends the unencapsulated RS 2582 message, which will be intercepted by the AERO-aware ANET access 2583 router. 2585 The ANET access router then performs OAL encapsulation on the RS 2586 message and forwards it to a Proxy/Server at the ANET/INET boundary. 2587 When the access router and Proxy/Server are one and the same node, 2588 the Proxy/Server would share an underlay link with the Client but its 2589 message exchanges with outside correspondents would need to pass 2590 through a security gateway at the ANET/INET border. The method for 2591 deploying access routers and Proxys (i.e. as a single node or 2592 multiple nodes) is an ANET-local administrative consideration. 2594 Note: When a Proxy/Server alters the IPv6 ND message contents before 2595 forwarding (e.g., such as altering the OMNI option contents), the 2596 original IPv6 ND message checksum or authentication signature is 2597 invalidated, and a new checksum or authentication signature must be 2598 calculated and included. 2600 Note: When a Proxy/Server receives a secured Client NS message, it 2601 performs the same proxying procedures as for described for RS 2602 messages above. The proxying procedures for NS/NA message exchanges 2603 is specified in Section 3.13. 2605 3.12.3.2. Detecting and Responding to Proxy/Server Failures 2607 In environments where fast recovery from Proxy/Server failure is 2608 required, FHS Proxy/Servers SHOULD use proactive Neighbor 2609 Unreachability Detection (NUD) to track Hub Proxy/Server reachability 2610 in a fashion that parallels Bidirectional Forwarding Detection (BFD) 2611 [RFC5880]. Each FHS Proxy/Server can then quickly detect and react 2612 to failures so that cached information is re-established through 2613 alternate paths. The NS/NA control messaging is carried only over 2614 well-connected ground domain networks (i.e., and not low-end 2615 aeronautical radio links) and can therefore be tuned for rapid 2616 response. 2618 FHS Proxy/Servers perform continuous NS/NA exchanges with the Hub 2619 Proxy/Server, e.g., one exchange per second. The FHS Proxy/Server 2620 sends the NS message via the spanning tree with its own ULA as the 2621 source and the ULA of the Hub Proxy/Server as the destination, and 2622 the Hub Proxy/Server responds with an NA. When the FHS Proxy/Server 2623 is also sending RS messages to a Hub Proxy/Server on behalf of 2624 Clients, the resulting RA responses can be considered as equivalent 2625 hints of forward progress. This means that the FHS Proxy/Server need 2626 not also send a periodic NS if it has already sent an RS within the 2627 same period. If the Hub Proxy/Server fails (i.e., if the FHS Proxy/ 2628 Server ceases to receive advertisements), the FHS Proxy/Server can 2629 quickly inform Clients by sending unsolicited RA messages 2631 The FHS Proxy/Server sends unsolicited RA messages with source 2632 address set to the Hub Proxy/Server's address, destination address 2633 set to (link-local) All-Nodes multicast, and Router Lifetime set to 2634 0. The FHS Proxy/Server SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA 2635 messages separated by small delays [RFC4861]. Any Clients that had 2636 been using the failed Hub Proxy/Server will receive the RA messages 2637 and select a different Proxy/Server to assume the Hub role (i.e., by 2638 sending an RS with destination set to the ULA of the new Hub). 2640 3.12.3.3. DHCPv6-Based Prefix Registration 2642 When a Client is not pre-provisioned with an MNP, it will need for 2643 the Hub Proxy/Server to select one or more MNPs on its behalf and set 2644 up the correct state in the AERO routing service. (A Client with a 2645 pre-provisioned MNP may also request the Hub Proxy/Server to select 2646 additional MNPs.) The DHCPv6 service [RFC8415] is used to support 2647 this requirement. 2649 When a Client needs to have the Hub Proxy/Server select MNPs, it 2650 sends an RS message with source address set to a TLA and with an OMNI 2651 option that includes a DHCPv6 message sub-option with DHCPv6 Prefix 2652 Delegation (DHCPv6-PD) parameters. When the Hub Proxy/Server 2653 receives the RS message, it extracts the DHCPv6-PD message from the 2654 OMNI option. 2656 The Hub Proxy/Server then acts as a "Proxy DHCPv6 Client" in a 2657 message exchange with the locally-resident DHCPv6 server, which 2658 delegates MNPs and returns a DHCPv6-PD Reply message. (If the Hub 2659 Proxy/Server wishes to defer creation of MN state until the DHCPv6-PD 2660 Reply is received, it can instead act as a Lightweight DHCPv6 Relay 2661 Agent per [RFC6221] by encapsulating the DHCPv6-PD message in a 2662 Relay-forward/reply exchange with Relay Message and Interface ID 2663 options.) 2665 When the Hub Proxy/Server receives the DHCPv6-PD Reply, it creates an 2666 XLA based on the delegated MNP adds an XLA-MNP route to the routing 2667 system. The Hub Proxy/Server then sends an RA back to the Client 2668 either directly or via an FHS Proxy/Server acting as a proxy. The 2669 Proxy/Server that returns the RA directly to the Client sets the 2670 (newly-created) ULA-MNP as the destination address and with the 2671 DHCPv6-PD Reply message and OMNI Neighbor Coordination sub-option 2672 Preflen coded in the OMNI option. When the Client receives the RA, 2673 it creates a default route, assigns the Subnet Router Anycast address 2674 and sets its {ULA,XLA}-MNP based on the delegated MNP. 2676 Note: Further details of the DHCPv6-PD based MNP registration (as 2677 well as a minimal MNP delegation alternative that avoids including a 2678 DHCPv6 message sub-option in the RS) are found in 2679 [I-D.templin-6man-omni]. 2681 Note: when the Hub Proxy/Server forwards an RA to the Client via a 2682 different node acting as a FHS Proxy/Server, the Hub sets the RA 2683 destination to the same address that appeared in the RS source. The 2684 FHS Proxy/Server then subsequently sets the RA destination to the 2685 ULA-MNP when it forwards the Proxyed version of the RA to the Client 2686 - see [I-D.templin-6man-omni] for further details. 2688 3.13. AERO Address Resolution, Multilink Forwarding and Route 2689 Optimization 2691 AERO nodes invoke address resolution, multilink forwarding and route 2692 optimization when they need to forward initial packets to new 2693 neighbors over ANET/INET interfaces and for ongoing multilink 2694 forwarding coordination with existing neighbors. Address resolution 2695 is based on an IPv6 ND NS/NA(AR) messaging exchange between an 2696 Address Resolution Source (ARS) and the target neighbor as the 2697 Address Resolution Target (ART). Either the ART itself or the ART's 2698 current Hub Proxy/Server serves as the Address Resolution Responder 2699 (ARR). 2701 Address resolution is initiated by the first eligible ARS closest to 2702 the original source as follows: 2704 * For Clients on VPNed and Direct interfaces, the Client's FHS 2705 Proxy/Server is the ARS. 2707 * For Clients on ANET interfaces, either the Client or the FHS 2708 Proxy/Server may be the ARS. 2710 * For Clients on INET interfaces, the Client itself is the ARS. 2712 * For correspondent nodes on INET/ENET interfaces serviced by a 2713 Relay, the Relay is the ARS. 2715 * For Clients that engage the Hub Proxy/Server in "mobility anchor" 2716 mode, the Hub Proxy/Server is the ARS. 2718 * For peers within the same ANET/ENET, route optimization is through 2719 receipt of Redirect messages. 2721 The AERO routing system directs an address resolution request sent by 2722 the ARS to the ARR. The ARR then returns an address resolution reply 2723 which must include information that is current, consistent and 2724 authentic. Both the ARS and ARR are then jointly responsible for 2725 periodically refreshing the address resolution, and for quickly 2726 informing each other of any changes. Following address resolution, 2727 the ARS and ART perform continuous unicast multilink forwarding and 2728 route optimization exchanges to maintain optimal forwarding profiles. 2730 The address resolution, multilink forwarding and route optimization 2731 procedures are specified in the following sections. 2733 3.13.1. Multilink Address Resolution 2735 When one or more original IP packets from a source node destined to a 2736 target node arrives, the ARS checks for a NCE with an XLA-MNP that 2737 matches the target destination. If there is a NCE in the REACHABLE 2738 state, the ARS invokes the OAL and forwards the resulting carrier 2739 packets according to the cached state then returns from processing. 2741 Otherwise, if there is no NCE the ARS creates one in the INCOMPLETE 2742 state. The ARS then prepares an NS message for Address Resolution 2743 (NS(AR)) to send toward an ART while including the original IP 2744 packet(s) as trailing data following the NS(AR) in an OAL super- 2745 packet [I-D.templin-6man-omni]. The resulting NS(AR) message must be 2746 sent securely, and includes: 2748 * the ULA of the ARS as the source address. 2750 * the XLA corresponding to the original IP packet's destination as 2751 the Target Address, e.g., for 2001:db8:1:2::10:2000 the Target 2752 Address is fd00::2001:db8:1:2. 2754 * the Solicited-Node multicast address [RFC4291] formed from the 2755 lower 24 bits of the original IP packet's destination as the 2756 destination address, e.g., for 2001:db8:1:2::10:2000 the NS(AR) 2757 destination address is ff02:0:0:0:0:1:ff10:2000. 2759 The NS(AR) message also includes an OMNI option with an 2760 authentication sub-option if necessary and with an OMNI Neighbor 2761 Coordination sub-option with Preflen set to the prefix length 2762 associated with the NS(AR) source. The ARS also includes Interface 2763 Attributes and/or Traffic Selectors for all of the source Client's 2764 underlay interfaces, calculates the authentication signature or 2765 checksum, includes window synchronization parameters then submits the 2766 NS(AR) message for OAL encapsulation. The ARS sets the OAL source to 2767 its own ULA and sets the OAL destination according to the Client's RS 2768 message Neighbor Coordination 'U' flag (see: 2769 [I-D.templin-6man-omni]). If the 'U' flag was set, the ARS sets the 2770 OAL destination to the ULA of its Hub Proxy/Server which maintains a 2771 Report List; otherwise, the ARS sets the destination to the XLA-MNP 2772 corresponding to the ART. The ARS then selects an identification 2773 value, inserts a fragment header, calculates the OAL checksum, 2774 performs fragmentation and L2 encapsulation, then sends the resulting 2775 carrier packets into the SRT secured spanning tree without 2776 decrementing the network-layer TTL/Hop Limit field. 2778 When the ARS is a Client, it must instead use the ULA of one of its 2779 FHS Proxy/Servers as the OAL destination. The ARS Client then 2780 fragments, performs L2 encapsulation and forwards the carrier packets 2781 to the FHS Proxy/Server. The FHS Proxy/Server then reassembles, 2782 verifies the NS(AR) authentication signature or checksum, changes the 2783 OAL source to its own ULA and changes the OAL destination to the ULA 2784 of the Hub Proxy/Server or XLA-MNP corresponding to the ART as 2785 specified above. The FHS Proxy/Server then selects an appropriate 2786 Identification, calculates the OAL checksum, re-fragments and 2787 forwards the resulting carrier packets into the secured spanning tree 2788 on behalf of the Client. 2790 Note: both the source and target Client/Relay and their Hub Proxy/ 2791 Servers include current and accurate information for their multilink 2792 Interface Attributes profile. The Hub Proxy/Servers can be trusted 2793 to provide an authoritative ARR response and/or mobility update 2794 message on behalf of the source/target should the need arise. While 2795 the source or target itself has no such trust basis, any attempt to 2796 mount an attack by providing false Interface Attributes information 2797 would only result in black-holing of return traffic, i.e., the 2798 "attack" could only result in denial of service to the source/target 2799 itself. Therefore, the source/target's asserted Interface Attributes 2800 need not be validated by the Hub Proxy/Server. 2802 3.13.1.1. ARS Hub Proxy/Server NS(AR) Processing 2804 If the ARS Client's Hub Proxy/Server maintains a Report List, the 2805 carrier packets containing the NS(AR) will first arrive at the at the 2806 Hub due to the OAL destination address supplied by the ARS (see 2807 above). This source Hub then discards the L2 headers, reassembles 2808 then records the NS Target Address in the Report List for this source 2809 Client. The Hub then leaves the OAL source address unchanged, but 2810 changes the OAL destination address to the XLA corresponding to the 2811 NS Target Address. The Hub then decrements the OAL header Hop Limit, 2812 includes an appropriate Identification, recalculates the OAL 2813 checksum, refragments, and sends the resulting carrier packets into 2814 the secured spanning tree. 2816 3.13.1.2. Relaying the NS(AR) 2818 When a Gateway receives carrier packets containing the NS(AR), it 2819 discards the L2 headers and determines the next hop by consulting its 2820 standard IPv6 forwarding table for the OAL header XLA destination 2821 address. The Gateway next decrements the OAL header Hop Limit, then 2822 includes new L2 headers and forwards the carrier packet(s) via the 2823 secured spanning tree the same as for any IPv6 router, where they may 2824 traverse multiple OMNI link segments. The final-hop Gateway will 2825 deliver the carrier packets via the secured spanning tree to the Hub 2826 Proxy/Server (or Relay) that services the ART. 2828 3.13.1.3. NS(AR) Processing at the ARR/ART 2830 When the ART's Hub Proxy/Server receives the NS(AR) secured carrier 2831 packets with the XLA-MNP of the ART as the OAL destination, it 2832 discards the L2 headers, reassembles, verifies the OAL checksum then 2833 either forwards the NS(AR) to the ART or processes it locally if it 2834 is acting as a Relay or as the ART's designated ARR. The Hub Proxy/ 2835 Server processes the message as follows: 2837 * if the NS(AR) target matches a Client NCE in the DEPARTED state, 2838 the (old) Hub Proxy/Server resets the OAL destination address to 2839 the ULA of the Client's new Hub Proxy/Server. The old Hub Proxy/ 2840 Server then decrements the OAL header Hop Limit, recalculates the 2841 OAL checksum, re-fragments, includes appropriate L2 headers then 2842 forwards the resulting carrier packets over the secured spanning 2843 tree. 2845 * If the NS(AR) target matches a Client NCE in the REACHABLE state, 2846 the Hub Proxy/Server notes whether the NS(AR) arrived from the 2847 secured spanning tree. If the message arrived via the secured 2848 spanning tree the Hub Proxy/Server verifies the NS checksum; 2849 otherwise, it must verify the message authentication signature. 2850 If the Hub Proxy/Server maintains a Report List for the ART, it 2851 next records the NS source address in the Report List for this 2852 ART. If the Hub Proxy/Server is the ART's designated ARR, it 2853 prepares to return an NA(AR) as discussed below; otherwise, the 2854 Hub Proxy/Server determines the underlay interface for the ART and 2855 proceeds as follows: 2857 - If the Hub Proxy/Server is also the FHS Proxy/Server on the 2858 underlay interface used to convey the NS(AR) to the ART, it 2859 either recalculates the NS(AR) checksum or includes an 2860 authentication signature as necessary. The Hub then changes 2861 the OAL source to its own ULA and OAL destination to the ULA- 2862 MNP of the ART, decrements the OAL Hop Limit, includes a 2863 suitable identification value, recalculates the OAL checksum, 2864 re-fragments if necessary, includes appropriate L2 headers and 2865 forwards the resulting carrier packets over the underlay 2866 interface to the ART. 2868 - If the Hub Proxy/Server is not the FHS Proxy/Server on the 2869 underlay interface used to convey the NS(AR) to the ART, it 2870 instead recalculates the NS(AR) checksum, changes the OAL 2871 source to its own ULA and changes the OAL destination to the 2872 ULA of the FHS Proxy/Server for this ART interface. The Hub 2873 Proxy/Server next decrements the OAL Hop Limit, includes a 2874 suitable Identification value, recalculates the OAL checksum, 2875 re-fragments if necessary, includes appropriate L2 headers and 2876 forwards the resulting carrier packets over the secured 2877 spanning tree. 2879 - When the FHS Proxy/Server receives the carrier packets, it 2880 reassembles and verifies the OAL and NS(AR) checksums, then 2881 forwards to the ART the same as described above. 2883 * If the NS(AR) target matches one of its non-MNP routes, the Hub 2884 Proxy/Server serves as both a Relay and an ARR, since the Relay 2885 forwards IP packets toward the (fixed network) target at the 2886 network layer. 2888 If the ARR is a Relay or the ART itself, it first creates or updates 2889 a NCE for the NS(AR) source address while processing the window 2890 synchronization parameters and caching all Interface Attributes and 2891 Traffic Selector information. Next, the ARR prepares a (solicited) 2892 NA(AR) message to return to the ARS with the source address set to 2893 the ART's XLA, the destination address set to the NS(AR) ULA source 2894 address and the Target Address set to the same value that appeared in 2895 the NS(AR) Target Address. The ARR includes an OMNI option with OMNI 2896 Neighbor Coordination sub-option Preflen set to the prefix length 2897 associated with the NA(AR) source address. 2899 The ARR then includes Interface Attributes and Traffic Selector sub- 2900 options for all of the ART's underlay interfaces with current 2901 information for each interface. The ARR also includes either an 2902 authentication signature or an NA message checksum as necessary. The 2903 ARR next sets the NA(AR) message R flag to 1 (as a router) and S flag 2904 to 1 (as a response to a solicitation) and sets the O flag to 1 (as 2905 an authoritative responder). The ARR then submits the NA(AR) for OAL 2906 encapsulation with source set to its own ULA and destination set to 2907 the ULA that appeared in the NS(AR) OAL source, selects an 2908 appropriate Identification, and includes window synchronization 2909 parameters if necessary. The ARR then includes an authentication 2910 signature or checksum, calculates the OAL checksum, fragments, 2911 includes appropriate L2 headers and forwards the resulting 2912 (L2-encapsulated) carrier packets. 2914 When the Proxy/Server for the ART receives the carrier packets sent 2915 by an ART acting as an ARR on its own behalf, it reassembles if 2916 necessary, verifies the authentication signature or checksum and 2917 includes a new authentication signature or checksum. The Proxy/ 2918 Server then changes the OAL source address to its own ULA, changes 2919 the OAL destination to the ULA corresponding to the NA(AR) 2920 destination, decrements the OAL Hop Limit, includes an appropriate 2921 Identification, recalculates the NA and OAL checksums and fragments 2922 if necessary. The Proxy/Server finally includes appropriate L2 2923 headers and forwards the carrier packets into the secured spanning 2924 tree. 2926 Note: If the Hub Proxy/Server is acting as the ARR but not as a 2927 Relay, it prepares the NA(AR) with the R flag set to 0 but without 2928 setting the SYN/ACK flags in the OMNI Neighbor Coordination sub- 2929 option window synchronization parameters. This informs the ARS that 2930 it must initiate multilink route optimization to synchronize with the 2931 target either directly or via an LHS Proxy/Server (see: 2932 Section 3.13.2). In all other ways, the Hub Proxy/Server prepares 2933 and returns the NA(AR) the same as for the ART Proxy/Server case 2934 above. 2936 3.13.1.4. Relaying the NA(AR) 2938 When a Gateway receives NA(AR) carrier packets, it discards the L2 2939 headers and determines the next hop by consulting its standard IPv6 2940 forwarding table for the OAL header destination address. The Gateway 2941 then decrements the OAL header Hop Limit, re-encapsulates the carrier 2942 packets with new L2 headers and forwards them via the SRT secured 2943 spanning tree where they may traverse multiple OMNI link segments. 2944 The final-hop Gateway will deliver the carrier packets via the 2945 secured spanning tree to a Proxy/Server for the ARS. 2947 3.13.1.5. Processing the NA(AR) at the ARS 2949 When the ARS receives the NA(AR) message, it first searches for a NCE 2950 that matches the NA(AR) target address. The ARS then processes the 2951 message the same as for standard IPv6 Address Resolution [RFC4861]. 2952 In the process, it caches all OMNI option information in the NCE for 2953 the ART (including Interface Attributes, Traffic Selectors, etc.), 2954 and caches the NA(AR) XLA source address as the address of the ART. 2956 When the ARS is a Client, the SRT secured spanning tree will first 2957 deliver the solicited NA(AR) message to the FHS Proxy/Server, which 2958 re-adjusts the OAL header and forwards the message to the Client. If 2959 the Client is on a well-managed ANET, physical security and protected 2960 spectrum ensures security for the NA(AR) without needing an 2961 additional authentication signature; if the Client is on the open 2962 INET the Proxy/Server must instead include an authentication 2963 signature (while adjusting the OMNI option size, if necessary). The 2964 Proxy/Server uses its own ULA as the OAL source and the ULA-MNP of 2965 the Client as the OAL destination when it forwards the NA(AR). The 2966 Proxy/Server then decrements the OAL Hop Limit, includes an 2967 appropriate Identification, recalculates the OAL checksum, re- 2968 fragments, includes appropriate L2 headers and forwards the carrier 2969 packets over the underlay interface to the Client. 2971 3.13.1.6. Reliability 2973 After the ARS transmits the first NS(AR), it should wait up to 2974 RETRANS_TIMER seconds to receive a responsive NA(AR). The ARR can 2975 then retransmit the NS(AR) up to MAX_UNICAST_SOLICIT times before 2976 giving up. 2978 3.13.2. Multilink Forwarding 2980 Following address resolution, the ARS and ART can assert multilink 2981 forwarding paths through underlay interface pairs serviced by the 2982 same source/destination ULAs by sending unicast NS/NA messages with 2983 OMNI AERO Forwarding Parameter (AFP) and/or Neighbor Coordination 2984 sub-options. The unicast NS/NA messages establish multilink 2985 forwarding state in OAL intermediate nodes in the path between the 2986 ARS and ART. Note that either the ARS or ART can independently 2987 initiate multilink forwarding by sending unicast NS messages on 2988 behalf of specific underlay interface pairs. 2990 Nodes that configure OMNI interfaces include an additional forwarding 2991 table termed the AERO Forwarding Information Base (AFIB) that 2992 supports carrier packet forwarding based on OMNI neighbor underlay 2993 interface pairs. The AFIB contains AERO Forwarding Vectors (AFVs) 2994 identified by locally-unique 4-octet values known as AFV Indexes 2995 (AFVIs). The AFVs cache uncompressed OAL header information as well 2996 as the previous/next-hop addressing and AFVI information. 2998 OAL source, intermediate and target nodes create AFVs/AFVIs when they 2999 process an NS message with an AFP sub-option with Job code '00' 3000 (Initialize; Build B) or a solicited NA message with Job code '01' 3001 (Follow B; Build A) (see: [I-D.templin-6man-omni]). The OAL source 3002 of the NS (which is also the OAL destination of the solicited NA) is 3003 considered to reside in the "First Hop Segment (FHS)", while the OAL 3004 destination of the NS (which is also the OAL source of the solicited 3005 NA) is considered to reside in the "Last Hop Segment (LHS)". 3007 The FHS and LHS roles are determined on a per-interface-pair basis. 3008 After address resolution, either peer is equally entitled to initiate 3009 multilink forwarding on behalf of a specific FHS/LHS underlay 3010 interface pair. The peer that sends the initiating NS with Job code 3011 '00' message for a specific pair becomes the FHS peer while the one 3012 that returns the NA response becomes the LHS peer for that pair only. 3013 It is therefore quite possible (and even commonplace) that both peers 3014 may assume the FHS role for some pairs while assuming the LHS role 3015 for other pairs, i.e., even though each peer maintains only a single 3016 NCE. 3018 When an OAL node initiates or forwards an NS with Job code '00', it 3019 creates an AFV, records the NS source and destination ULAs then 3020 generates and assigns a locally-unique "B" AFVI (while also caching 3021 the "B" values for all previous OAL hops on the path from the FHS OAL 3022 source). When the OAL node receives future carrier packets that 3023 include "B", it can unambiguously locate the correct AFV and 3024 determine directionality without examining addresses. When the AFV 3025 is indexed by its "B" AFVI, it returns the ULAs in (dst,src) order 3026 the opposite of how they appeared in the OAL header of the original 3027 NS to support full header reconstruction for reverse-path forwarding. 3028 (If the NS message included a nested OAL encapsulation, the ULAs of 3029 both OAL headers are returned.) 3031 When an OAL node initiates or forwards a solicited NA with Job code 3032 '01', it uses the "B" AFVI to locate the AFV created by the NS then 3033 generates and assigns a locally-unique "A" AFVI (while also caching 3034 the "A" values for all previous OAL hops on the path from the LHS OAL 3035 source). When the OAL node receives future carrier packets that 3036 include "A", it can unambiguously locate the correct AFV and 3037 determine directionality without examining addresses. When the AFV 3038 is indexed by its "A" AFVI, it returns the ULAs in (src,dst) order 3039 the same as they appeared in the OAL header of the original NS to 3040 support full header reconstruction for forward-path forwarding. (If 3041 the NS message included a nested OAL encapsulation, the ULAs of both 3042 OAL headers are returned.) 3044 OAL nodes generate random non-zero 32-bit values as candidate AFVIs 3045 which must first be tested for local uniqueness. If a candidate AFVI 3046 s already in use, the OAL node repeats the random generation process 3047 until it obtains a unique non-zero value. Since the number of AFVs 3048 in service at each OAL node is likely to be much smaller than 2**32, 3049 the process will generate a unique value after a small number of 3050 tries. Since the uniqueness property is node-local only, an AFVI 3051 locally generated by a first OAL node must not be tested for 3052 uniqueness by other OAL nodes. 3054 OAL nodes cache AFVs for up to ReachableTime seconds following their 3055 initial creation. If the node processes another NS or NA message 3056 specific to an AFV, it resets ReachableTime to REACHABLE_TIME 3057 seconds, i.e., the same as for NCEs. If ReachableTime expires, the 3058 node deletes the AFV and frees its associated AFVIs so they can be 3059 reused for future AFVs. 3061 The following sections provide the detailed specifications of these 3062 NS/NA exchanges for all nodes along the forward and reverse paths. 3064 3.13.2.1. FHS Client-Proxy/Server NS Forwarding 3066 When an FHS OAL source has an original IP packet to send to an LHS 3067 OAL target following multilink address resolution, it first selects a 3068 source and target underlay interface pair. The FHS source uses its 3069 cached information for the target underlay interface as LHS 3070 information then prepares an NS message with an AFP sub-option with 3071 Job code '00' and with the NS source set to its own ULA or XLA and 3072 the NS destination set to the ULA or XLA of the LHS target. The FHS 3073 source then sets window synchronization information in the OMNI 3074 Neighbor Coordination sub-option and creates a NCE for the selected 3075 target ULA or XLA in the INCOMPLETE state. The FHS source next 3076 creates an AFV then generates and assigns a locally-unique "B" AFVI 3077 to the AFV while also including it as the first "B" entry in the AFP 3078 AFVI List. The FHS source then includes any FHS/LHS addressing 3079 information it knows locally in the AFP sub-option, i.e., based on 3080 information discovered through address resolution. 3082 If the FHS source is the FHS Proxy/Server, it then examines the LHS 3083 FMT code. If FMT-Forward is clear and FMT-Mode is set, the FHS 3084 Proxy/Server checks for a NCE for the ULA of the LHS Proxy/Server. 3085 If there is no NCE, the FHS Proxy/Server creates one in the 3086 INCOMPLETE state. If a new NCE was created (or if the existing NCE 3087 requires fresh window synchronization), the FHS Proxy/Server then 3088 writes window synchronization parameters into the AFP Tunnel Window 3089 Synchronization fields. The FHS Proxy/Server then performs OAL 3090 encapsulation while setting the OAL source to its own ULA and setting 3091 the OAL destination to the FHS Subnet Router Anycast ULA determined 3092 by applying the FHS SRT prefix length to its ULA. The FHS Proxy/ 3093 Server then selects an appropriate Identification value, calculates 3094 the OAL checksum, fragments if necessary, encapsulates in appropriate 3095 L2 headers then forwards the carrier packets into the secured 3096 spanning tree which will deliver them to a Gateway interface that 3097 assigns the FHS Subnet Router Anycast ULA. 3099 If the FHS source is the FHS Client, it instead includes an 3100 authentication signature if necessary. If FHS FMT-Forward is set and 3101 LHS FMT-Forward is clear, the FHS Client creates/updates a NCE for 3102 the ULA of the LHS Proxy/Server as above and includes Tunnel Window 3103 Synchronization parameters. The FHS Client then performs OAL 3104 encapsulation, sets the OAL source to its own ULA-MNP and sets the 3105 OAL destination to the ULA of the FHS Proxy/Server. The FHS Client 3106 finally selects an appropriate Identification value for the FHS 3107 Proxy/Server, calculates the OAL checksum, fragments if necessary, 3108 encapsulates in appropriate L2 headers then forwards the carrier 3109 packets to the FHS Proxy/Server. 3111 When the FHS Proxy/Server receives the carrier packets, it verifies 3112 the Identification then reassembles to obtain the NS, verifies the 3113 OAL checksum and verifies the NS authentication signature or 3114 checksum. The FHS Proxy/Server then creates an AFV (i.e., the same 3115 as the FHS Client had done) while caching the AFP AFVI List "B" entry 3116 along with the FHS Client addressing information as previous hop 3117 information for this AFV. The FHS Proxy/Server next generates a new 3118 locally-unique "B" AFVI, then both assigns it as the AFV index and 3119 writes it as the next "B" entry in the AFP AFVI List (while also 3120 writing any FHS Client and Proxy/Server addressing information). The 3121 FHS Proxy/Server then checks FHS/LHS FMT-Forward/Mode to determine 3122 whether to create a NCE for the LHS Proxy/Server ULA and include 3123 Tunnel Window Synchronization parameters the same as above. The FHS 3124 Proxy/Server then calculates the NS checksum and sets the OAL source 3125 address to its own ULA and destination address to the FHS Subnet 3126 Router Anycast ULA. The FHS Proxy/Server finally decrements the OAL 3127 Hop Limit, includes an Identification appropriate for the secured 3128 spanning tree, calculates the OAL checksum and re-fragments if 3129 necessary. The FHS Proxy/Server finally includes appropriate L2 3130 headers and forwards the carrier packets into the secured spanning 3131 tree. 3133 3.13.2.2. Gateway NS Forwarding 3135 Gateways in the spanning tree forward carrier packets not explicitly 3136 addressed to themselves, while forwarding those that arrived via the 3137 secured spanning tree to the next hop also via the secured spanning 3138 tree and forwarding all others via the unsecured spanning tree. When 3139 an FHS Gateway receives a carrier packet over the secured spanning 3140 tree addressed to its ULA or the FHS Subnet Router Anycast ULA, it 3141 instead reassembles to obtain the NS then verifies the OAL and NS 3142 checksums. The FHS Gateway next creates an AFV (i.e., the same as 3143 the FHS Proxy/Server had done) while caching the AFP FHS Client and 3144 Proxy/Server addressing information and corresponding AFVI List "B" 3145 list values in the AFV to enable future reverse path forwarding to 3146 this FHS Client. The FHS Gateway then generates a locally-unique "B" 3147 AFVI for the AFV and also writes it as the next "B" entry in the NS 3148 AFP AFVI List. 3150 The FHS Gateway then examines the SRT prefixes corresponding to both 3151 FHS and LHS. If the FHS Gateway has a local interface connection to 3152 both the FHS and LHS (whether they are the same or different 3153 segments), the FHS/LHS Gateway caches the NS AFP LHS information in 3154 the AFV, writes its LHS ULA and L2ADDR into the NS AFP LHS fields, 3155 then sets its LHS ULA as the OAL source and the ULA of the LHS Proxy/ 3156 Server as the OAL destination. If the FHS and LHS prefixes are 3157 different, the FHS Gateway instead sets its FHS ULA as the OAL source 3158 and the LHS Subnet Router Anycast ULA as the OAL destination. The 3159 FHS Gateway then decrements the OAL Hop Limit, selects an appropriate 3160 Identification, recalculates the NS and OAL checksums, re-fragments 3161 if necessary, then finally includes appropriate L2 headers and 3162 forwards the carrier packets into the secured spanning tree. 3164 When the FHS and LHS Gateways are different, the LHS Gateway will 3165 receive carrier packets over the secured spanning tree from the FHS 3166 Gateway, noting there may be many intermediate Gateways in the path 3167 between FHS and LHS which will simply forward the carrier packets 3168 without further processing. The LHS Gateway then reassembles to 3169 obtain the NS, verifies the OAL and NS checksums then creates an AFV 3170 (i.e., the same as the FHS Gateway had done) while caching the AFP 3171 "B" AFVIs and addressing information of previous OAL forwarding hops. 3172 In particular, the LHS Gateway caches the ULA of the FHS Gateway as 3173 the spanning tree address for the previous-hop, caches the LHS 3174 information then generates a locally-unique "B" AFVI for the AFV. 3175 The LHS Gateway then writes its own LHS ULA and L2ADDR into the AFP 3176 sub-option while also writing "B" as the next entry in the AFP AFVI 3177 List. The LHS Gateway then sets its own ULA as the OAL source and 3178 the ULA of the LHS Proxy/Server as the OAL destination, decrements 3179 the OAL Hop Limit selects an appropriate Identification, recalculates 3180 the NS and OAL checksums, re-fragments if necessary, then finally 3181 includes appropriate L2 headers and forwards the carrier packets into 3182 the secured spanning tree. 3184 3.13.2.3. LHS Proxy/Server-Client NS Receipt and NA Forwarding 3186 When the LHS Proxy/Server receives the carrier packets from the 3187 secured spanning tree, it reassembles to obtain the NS, verifies the 3188 OAL and NS checksums then verifies that the LHS information supplied 3189 by the FHS source is consistent with its own cached information. If 3190 the information is consistent, the LHS Proxy/Server then creates an 3191 AFV and caches the AFP "B" AFVIs and addressing information of 3192 previous OAL forwarding hops the same as for the prior hop. If the 3193 NS destination is the XLA of the LHS Client, the LHS Proxy/Server 3194 also generates a locally-unique "B" AFVI and assigns it both to the 3195 AFVI and as the next "B" entry in the AFVI List. The LHS Proxy/ 3196 Server then examines FHS FMT; if FMT-Forward is clear and FMT-Mode is 3197 set, the LHS Proxy/Server creates a NCE for the ULA of the FHS Proxy/ 3198 Server (if necessary) and sets the state to STALE, then caches any 3199 Tunnel Window Synchronization parameters. 3201 If the NS destination matches its own ULA, the LHS Proxy/Server next 3202 prepares to return a solicited NA with Job code '01'. If the NS 3203 source was the XLA of the FHS Client, the LHS Proxy/Server first 3204 creates or updates an NCE for the XLA with state set to STALE. The 3205 LHS Proxy/Server next caches the NS OMNI Neighbor Coordination sub- 3206 option window synchronization parameters and AFP information 3207 (including the AFVI List) in the NCE corresponding to the ULA source. 3208 When the LHS Proxy/Server forwards future carrier packets based on 3209 the NCE, it can populate forwarding information in a CRH-32 routing 3210 header to enable forwarding based on the cached AFVI List "B" entries 3211 instead of ULA addresses. 3213 The LHS Proxy/Server then creates an NA with Job code '01' while 3214 copying the NS AFP sub-option into the NA. The LHS Proxy/Server then 3215 generates a locally-unique "A" AFVI and both assigns it to the AFV 3216 and includes it as the first "A" entry in the AFP sub-option AFVI 3217 List (see: [I-D.templin-6man-omni] for details on AFVI List A/B 3218 processing). The LHS Proxy/Server then includes end-to-end window 3219 synchronization parameters in the OMNI Neighbor Coordination sub- 3220 option (if necessary) and also tunnel window synchronization 3221 parameters in the AFP sub-option (if necessary). The LHS Proxy/ 3222 Server then encapsulates the NA with OAL source set to its own ULA 3223 and OAL destination set to the ULA of the LHS Gateway. The LHS 3224 Proxy/Server then selects an appropriate Identification value, 3225 calculates the NA and OAL checksums, fragments if necessary then 3226 finally includes appropriate L2 headers and forwards the carrier 3227 packets into the secured spanning tree. 3229 If the NS destination was the XLA of the LHS Client, the LHS Proxy/ 3230 Server instead includes an authentication signature in the NS if 3231 necessary (otherwise recalculates the checksum), then changes the OAL 3232 source to its own ULA and changes the OAL destination to the ULA-MNP 3233 of the LHS Client. The LHS Proxy/Server then decrements the OAL Hop 3234 Limit, selects an appropriate Identification value, calculates the 3235 OAL checksum, fragments if necessary then finally includes 3236 appropriate L2 headers and forwards the carrier packets to the LHS 3237 Client. When the LHS Client receives the carrier packets, it 3238 verifies the Identification and reassembles to obtain the NS then 3239 verifies the OAL checksum and NS authentication signature or 3240 checksum. The LHS Client then creates a NCE for the NS ULA source 3241 address in the STALE state and examines the AFP sub-option. If LHS 3242 FMT-Forward is set, FHS FMT-Forward is clear and the NS source was an 3243 XLA, the Client also creates a NCE for the ULA of the FHS Proxy/ 3244 Server in the STALE state and caches any Tunnel Window 3245 Synchronization parameters. The Client then caches the NS OMNI 3246 Neighbor Coordination and AFP sub-options in the NCE corresponding to 3247 the NS ULA source, then creates an AFV, caches the addressing 3248 information and "B" entries of the previous OAL hops then finally 3249 generates and assigns a locally-unique "A" AFVI the same as for 3250 previous hops. 3252 The LHS Client then prepares an NA using exactly the same procedures 3253 as for the LHS Proxy/Server above, except that it uses its XLA as the 3254 NA source and the NS source as the NA destination. The LHS Client 3255 also includes an authentication signature if necessary (otherwise 3256 calculates the checksum), then encapsulates the NA with OAL source 3257 set to its own ULA-MNP and OAL destination set to the ULA of the LHS 3258 Proxy/Server. The LHS Client finally includes an appropriate 3259 Identification, calculates the OAL checksum, fragments if necessary 3260 then includes appropriate L2 headers and forwards the carrier packets 3261 to the LHS Proxy/Server. When the LHS Proxy/Server receives the 3262 carrier packets, it verifies the Identifications, reassembles to 3263 obtain the NA, verifies the OAL checksum and NA authentication 3264 signature or checksum, then uses the current AFP AFVI List "B" entry 3265 to locate the AFV. The LHS Proxy/Server then caches the addressing 3266 and "A" information for the LHS Client in the AFV, then generates a 3267 locally-unique "A" AFVI and both assigns it to the AFV and writes it 3268 as the next AFP AFVI List "A" entry. The LHS Proxy/Server then 3269 examines the FHS/LHS FMT codes to determine if it needs to include 3270 Tunnel Window Synchronization parameters. The LHS Proxy/Server then 3271 calculates the NA checksum, sets the OAL source to its own ULA and 3272 destination to the ULA of the LHS Gateway, decrements the OAL Hop 3273 Limit, includes an appropriate Identification, calculates the OAL 3274 checksum, re-fragments if necessary then finally includes appropriate 3275 L2 headers and forwards the carrier packets into the secured spanning 3276 tree. 3278 3.13.2.4. Gateway NA Forwarding 3280 When the LHS Gateway receives the carrier packets containing the NA 3281 message, it reassembles and verifies the OAL and NA checksums then 3282 uses the current NA AFP AFVI List "B" entry to locate the AFV. The 3283 LHS Gateway then caches the AFP addressing and AFVI List "A" 3284 information for the previous hops in the AFV, then generates a 3285 locally-unique "A" AFVI and both assigns it to the AFV and writes it 3286 as the next AFP AFVI List "A" entry. The LHS Gateway then 3287 recalculates the NA checksum. If the LHS Gateway is connected 3288 directly to both the FHS and LHS segments (whether the segments are 3289 the same or different), the LHS Gateway will have already cached the 3290 FHS/LHS information based on the original NS; the LHS Gateway then 3291 sets the OAL source to its FHS ULA and OAL destination to the ULA of 3292 the FHS Proxy/Server. Otherwise, the LHS Gateway sets the OAL source 3293 to its LHS ULA and OAL destination to the ULA of the FHS Gateway. 3294 The LHS Gateway then decrements the OAL Hop Limit, selects an 3295 appropriate Identification, recalculates the OAL checksum, re- 3296 fragments if necessary, includes appropriate L2 headers and finally 3297 forwards the carrier packets into the secured spanning tree. 3299 When the FHS and LHS Gateways are different, the FHS Gateway will 3300 receive carrier packets containing the NA message from the LHS 3301 Gateway over the secured spanning tree, where there may have been 3302 many intermediate Gateway forwarding hops. The FHS Gateway then 3303 reassembles to obtain the NA, verifies the OAL and NA checksums and 3304 locates the AFV based on the current AFP AFVI List "B" entry. The 3305 FHS Gateway then caches the addressing and "A" information for the 3306 previous hops in the AFV and generates a locally-unique "A" AFVI. 3307 The FHS Gateway then assigns the new "A" value to the AFV, records 3308 "A" in the AFP AFVI List then writes its FHS ULA and L2ADDR into the 3309 AFP FHS Gateway fields. The FHS Gateway then recalculates the NA 3310 checksum, sets its FHS ULA as the OAL source and sets the ULA of the 3311 FHS Proxy/Server as the OAL destination. The FHS Gateway then 3312 decrements the OAL Hop Limit, selects an appropriate Identification 3313 value, recalculates the OAL checksum, re-fragments if necessary, 3314 includes appropriate L2 headers and finally forwards the carrier 3315 packets into the secured spanning tree. 3317 3.13.2.5. FHS Proxy/Server-Client NA Receipt 3319 When the FHS Proxy/Server receives the carrier packets from the 3320 secured spanning tree, it reassembles to obtain the NA, verifies the 3321 OAL and NA checksums then locates the AFV based on the current AFP 3322 AFVI List "B" entry. The FHS Proxy/Server then caches the AFP 3323 addressing and "A" information for the previous hops. If the NA 3324 destination matches its own ULA, the FHS Proxy/Server then examines 3325 LHS FMT. If FMT-Forward is clear, the FHS Proxy/Server locates the 3326 NCE for the ULA of the LHS Proxy/Server and sets the state to 3327 REACHABLE then caches any Tunnel Window Synchronization parameters. 3328 If the NA source is the XLA of the LHS Client, the FHS Proxy/Server 3329 then locates the LHS Client NCE and sets the state to REACHABLE then 3330 caches the OMNI Neighbor Coordination window synchronization 3331 parameters and prepares to return an acknowledgement, if necessary. 3333 If the NA destination is the XLA of the FHS Client, the FHS Proxy/ 3334 Server also searches for and updates the NCE for the ULA of the LHS 3335 Proxy/Server if necessary the same as above. The FHS Proxy/Server 3336 then generates a locally-unique "A" AFVI and assigns it both to the 3337 AFV and as the next AFP AFVI List "A" entry, then includes an 3338 authentication signature or checksum in the NA message. The FHS 3339 Proxy/Server then sets the OAL source to its own ULA and sets the OAL 3340 destination to the ULA-MNP of the FHS Client. The FHS Proxy/Server 3341 then decrements the OAL Hop Limit, selects an appropriate 3342 Identification value, recalculates the OAL checksum, re-fragments if 3343 necessary, includes appropriate L2 headers and finally forwards the 3344 carrier packets to the FHS Client. 3346 When the FHS Client receives the carrier packets, it verifies the 3347 Identification, reassembles to obtain the NA, verifies the OAL 3348 checksum and NA authentication signature or checksum, then locates 3349 the AFV based on the current AFP AFVI List "B" entry. The FHS Client 3350 then caches the previous hop addressing and "A" information the same 3351 as for prior hops. The FHS Client then examines LHS FMT. If FMT- 3352 Forward is clear, the FHS Client locates the NCE for the ULA of the 3353 LHS Proxy/Server and sets the state to REACHABLE then caches any 3354 Tunnel Window Synchronization parameters. If the NA source is the 3355 XLA of the LHS Client, the FHS Client then locates the LHS Client NCE 3356 and sets the state to REACHABLE then caches the OMNI Neighbor 3357 Coordination window synchronization parameters and prepares to return 3358 an unsolicited NA (uNA) acknowledgement, if necessary. 3360 3.13.2.6. Returning Window Acknowledgements 3362 If either the FHS Client or FHS Proxy/Server needs to return an 3363 acknowledgement to complete window synchronization, it prepares a uNA 3364 message with an AFP sub-option with Job code set to '10' (Follow A; 3365 Record B) (note that this step is unnecessary when Rapid Commit route 3366 optimization is used per Section 3.13.2.8). The FHS node sets the 3367 uNA source to its own ULA or XLA, sets the uNA destination to the ULA 3368 or XLA of the LHS node then includes Tunnel Window Synchronization 3369 parameters if necessary. The FHS node next sets the AFP AFVI List to 3370 the cached list of "A" entries received in the Job code '01' NA, but 3371 need not set any other FHS/LHS information. The FHS node then 3372 encapsulates the uNA message in an OAL header with its own ULA as the 3373 OAL source. If the FHS node is the Client, it next sets the ULA of 3374 the FHS Proxy/Server as the OAL destination, includes an 3375 authentication signature or checksum, selects an appropriate 3376 Identification value, calculates the OAL checksum, fragments if 3377 necessary, includes appropriate L2 headers and finally forwards the 3378 carrier packets to the FHS Proxy/Server. The FHS Proxy/Server then 3379 verifies the Identification, reassembles if necessary, verifies the 3380 OAL checksum and uNA authentication signature or checksum, then uses 3381 the current AFVI List "A" entry to locate the AFV. The FHS Proxy/ 3382 Server then writes its "B" AFVI as the next AFP AFVI List "B" entry 3383 and determines whether it needs to include Tunnel Window 3384 Synchronization parameters the same as it had done when it forwarded 3385 the original NS with Job code '00'. 3387 The FHS Proxy/Server recalculates the uNA checksum then sets its own 3388 ULA as the OAL source and the ULA of the FHS Gateway as the OAL 3389 destination, The FHS Proxy/Server finally decrements the OAL Hop 3390 Limit, selects an appropriate Identification, recalculates the OAL 3391 checksum, includes appropriate L2 headers and finally forwards the 3392 carrier packets into the secured spanning tree. When the FHS Gateway 3393 receives the carrier packets, it reassembles to obtain the uNA, 3394 verifies the OAL and uNA checksums then uses the current AFVI List 3395 "A" entry to locate the AFV. The FHS Gateway then writes its "B" 3396 AFVI as the next AFP AFVI List "B" entry, then sets the OAL source to 3397 its own ULA. If the FHS Gateway is also the LHS Gateway, it sets the 3398 OAL destination to the ULA of the LHS Proxy/Server; otherwise it sets 3399 the OAL destination to the ULA of the LHS Gateway. The FHS Gateway 3400 recalculates the uNA checksum then decrements the OAL Hop Limit, 3401 selects an appropriate Identification, recalculates the OAL checksum, 3402 re-fragments if necessary, includes appropriate L2 headers and 3403 finally forwards the carrier packets into the secured spanning tree. 3404 If an LHS Gateway receives the carrier packets, it processes them 3405 exactly the same as the FHS Gateway had done while re-setting the OAL 3406 destination to the ULA of the LHS Proxy/Server. 3408 When the LHS Proxy/Server receives the carrier packets, it 3409 reassembles to obtain the uNA message then verifies the OAL and uNA 3410 checksums. The LHS Proxy/Server then locates the AFV based on the 3411 current AFP AFVI List "A" entry then determines whether it is a 3412 tunnel ingress the same as for the original NS. If so, the LHS 3413 Proxy/Server updates the NCE for the tunnel far-end based on the 3414 Tunnel Window Synchronization parameters. If the uNA destination 3415 matches its own ULA, the LHS Proxy/Server next updates the NCE for 3416 the source ULA based on the OMNI Neighbor Coordination sub-option 3417 window synchronization parameters and MAY compare the AFVI List to 3418 the version it had cached in the AFV based on the original NS. 3420 If the uNA destination is the XLA of the LHS Client, the LHS Proxy/ 3421 Server instead writes its "B" AFVI as the next AFP AFVI List "B" 3422 entry and includes an authentication signature or checksum. The LHS 3423 Proxy/Server then writes its own ULA as the OAL source and the ULA- 3424 MNP of the Client as the OAL destination, then decrements the OAL Hop 3425 Limit, selects an appropriate Identification and recalculates the OAL 3426 checksum. The LHS Proxy/Server finally re-fragments if necessary, 3427 includes appropriate L2 headers and forwards the resulting carrier 3428 packets to the LHS Client. When the LHS Client receives the carrier 3429 packets, it verifies the Identification, reassembles to obtain the 3430 uNA, verifies the OAL checksum and uNA authentication signature or 3431 checksum then processes the message exactly the same as for the LHS 3432 Proxy/Server case above. 3434 3.13.2.7. OAL End System Exchanges Following Synchronization 3436 Following the initial NS/NA exchange with AFP sub-options, OAL end 3437 systems and tunnel endpoints can begin exchanging ordinary carrier 3438 packets that include "A/B" AFVIs and with Identification values 3439 within their respective send/receive windows without requiring 3440 security signatures and/or secured spanning tree traversal. OAL end 3441 systems and intermediate nodes can also consult their AFIBs when they 3442 receive carrier packets that include "A/B" AFVIs to unambiguously 3443 locate the correct AFV and can use any discovered "A/B" values of 3444 other OAL nodes to forward carrier packets to nodes that configure 3445 the corresponding AFVIs. OAL end systems must then perform 3446 continuous NS/NA exchanges to update window state, register new 3447 interface pairs for optimized multilink forwarding, confirm 3448 reachability and/or refresh AFIB cache state in the path before 3449 ReachableTime expires. 3451 While the OAL end systems continue to actively exchange packets, they 3452 are jointly responsible for updating cache state and per-interface 3453 reachability before expiration. Window synchronization state is 3454 shared by all underlay interfaces in the FHS peer's NCE that use the 3455 same destination ULA so that a single NS/NA exchange applies for all 3456 interfaces regardless of the specific interface used to conduct the 3457 exchange. However, the window synchronization exchange only confirms 3458 target Client reachability over the specific underlay interface pair. 3459 Reachability for other underlay interfaces that share the same window 3460 synchronization state must be determined individually using 3461 additional NS/NA messages. 3463 To update AFIB state in the path, the FHS node that sent the original 3464 NS message with AFP Job code '00' can send additional NS messages 3465 with Job code '10' (Follow "A"; Record "B"). The message will be 3466 processed by all intermediate OAL nodes which will refresh AFV timers 3467 and forward the NS onward toward the LHS node that returned the 3468 original NA message. When the LHS node receives the NS, it returns 3469 an NA message with AFP Job code '11' (Follow "B"; Record "A"). 3471 At the same time, the LHS node that received the original NS message 3472 with Job code '00' can send additional NS messages with Job code '11' 3473 in order to cause the FHS node to return an NA message with AFP Job 3474 code '10'. The process can therefore be coordinated asynchronously 3475 with the FHS/LHS nodes initiating an NS/NA exchange independently of 3476 one another. The exchanges will succeed as long as the AFIB state in 3477 the path remains active. Note that all intermediate node processing 3478 of Job code '10' and '11' NS/NA messages is conducted the same as for 3479 the initial NS/NA exchange according to the detailed specifications 3480 above. 3482 OAL sources can also begin including CRH-32s in carrier packets with 3483 a list of "A/B" AFVIs that OAL intermediate nodes can use for 3484 shortest-path carrier packet forwarding based on AFVIs instead of 3485 spanning tree addresses. OAL sources and intermediate nodes can 3486 instead forward carrier packets with OAL compressed headers termed 3487 "OCH" (see: [I-D.templin-6man-omni]) that include only a single "A/B" 3488 AFVI meaningful to the next hop, since all OAL nodes in the path up 3489 to (and sometimes including) the OAL destination have already 3490 established AFVs. Note that when an FHS OAL source receives a 3491 solicited NA with Job code '01', the AFP sub-option will contain an 3492 AFVI List with "A" entries populated in the reverse order needed for 3493 populating a CRH-32 routing header. The FHS OAL source must 3494 therefore write the AFP AFVI List "A" entries last-to-first when it 3495 populates a CRH-32, or must select the correct "A" entry to include 3496 in an OCH header based on the intended OAL intermediate node or 3497 destination. 3499 When a Gateway receives unsecured carrier packets destined to a local 3500 SRT segment Client that has asserted direct reachability, the Gateway 3501 performs direct carrier packet forwarding while bypassing the local 3502 Proxy/Server based on the Client's advertised AFVIs and discovered 3503 NATed L2ADDR information (see: Section 3.13.3). If the Client cannot 3504 be reached directly (or if NAT traversal has not yet converged), the 3505 Gateway instead forwards carrier packets directly to the local 3506 segment Proxy/Server. 3508 When a Proxy/Server receives carrier packets destined to a local SRT 3509 segment Client or forwards carrier packets received from a local 3510 segment Client, it first locates the correct AFV. If the carrier 3511 packets include a secured IPv6 ND message, the Proxy/Server uses the 3512 Client's NCE established through RS/RA exchanges to re-encapsulate/ 3513 re-fragment while forwarding outbound secured carrier packets via the 3514 secured spanning tree and forwarding inbound secured carrier packets 3515 while including an authentication signature or checksum. For 3516 ordinary carrier packets, the Proxy/Server uses the same AFV if 3517 directed by AFVI and/or OAL addressing. Otherwise it locates an AFV 3518 established through an NS/NA exchange between the Client and the 3519 remote SRT segment peer, and forwards the carrier packets without 3520 first reassembling/decapsulating. 3522 When a Proxy/Server or Client configured as a tunnel ingress receives 3523 a carrier packet with a full OAL header with a ULA-MNP source and 3524 CRH-32 routing header, or an OCH header with an AFVI that matches an 3525 AFV, the ingress encapsulates the carrier packet in a new full OAL 3526 header or an OCH header containing the next hop AFVI and an 3527 Identification value appropriate for the end-to-end window and the 3528 outer header containing an Identification value appropriate for the 3529 tunnel endpoints. When a Proxy/Server or Client configured as a 3530 tunnel egress receives an encapsulated carrier packet, it verifies 3531 the Identification in the outer header, then discards the outer 3532 header and forwards the inner carrier packet to the final 3533 destination. 3535 When a Proxy/Server with FMT-Forward/Mode set to 0/1 for a source 3536 Client receives carrier packets from the source Client, it first 3537 reassembles to obtain the original OAL packet then re-fragments if 3538 necessary to cause the Client's packets to fit within the MPS on the 3539 path from the Proxy/Server as a tunnel ingress to the tunnel egress. 3540 The Proxy/Server then performs OAL-in-OAL encapsulation and forwards 3541 the resulting carrier packets to the tunnel egress. When a Proxy/ 3542 Server with FMT-Forward/Mode set to 0/1 for a target Client receives 3543 carrier packets from a tunnel ingress, it first decapsulates to 3544 obtain the original fragments then reassembles to obtain the original 3545 OAL packet. The Proxy/Server then re-fragments if necessary to cause 3546 the fragments to match the target Client's underlay interface (Path) 3547 MTU and forwards the resulting carrier packets to the target Client. 3549 When a source Client forwards carrier packets it can employ header 3550 compression according to the AFVIs established through an NS/NA 3551 exchange with a remote or local peer. When the source Client 3552 forwards to a remote peer, it can forward carrier packets to a local 3553 SRT Gateway (following the establishment of L2ADDR information) while 3554 bypassing the Proxy/Server following route optimization (see: 3555 Section 3.13.3). When a target Client receives carrier packets that 3556 match a local AFV, the Client first verifies the Identification then 3557 decompresses the headers if necessary, reassembles if necessary to 3558 obtain the OAL packet then decapsulates and delivers the IP packet to 3559 upper layers. 3561 When synchronized peer Clients in the same SRT segment with FMT- 3562 Forward and FMT-Mode set discover each other's NATed L2ADDR 3563 addresses, they can exchange carrier packets directly with header 3564 compression using AFVIs discovered as above (see: Section 3.13.4). 3565 The FHS Client will have cached the "A" AFVI for the LHS Client, 3566 which will have cached the "B" AFVI for the FHS Client. 3568 When the FHS Client or FHS Proxy/Server sends an NS for the purpose 3569 of establishing multilink forwarding state, it should wait up to 3570 RETRANS_TIMER seconds to receive a responsive NA. The FHS node can 3571 then retransmit the NS up to MAX_UNICAST_SOLICIT times before giving 3572 up. Note that each successive attempt establishes new AFV state in 3573 the OAL intermediate nodes, but that any abandoned stale AFV state 3574 will be quickly reclaimed. 3576 3.13.2.8. Rapid Commit Multilink Forwarding 3578 Multilink forwarding can often be invoked simultaneously with Address 3579 Resolution in order to reduce control message overhead and round-trip 3580 delays. When an ART acting as an ARR receives an NS(AR) with a set 3581 of Interface Attributes for the ARS source Client, it can perform 3582 "rapid commit" by immediately invoking multilink forwarding as above 3583 at the same time as returning the NA(AR). 3585 In order to perform rapid commit, the ARR includes an AFP sub-option 3586 with Job code '00' as the first OMNI sub-option in the NA(AR) as 3587 though it were initiating a multilink coordination NS/NA exchange as 3588 specified above. The ARR then includes any Interface Attributes and/ 3589 or Traffic Selector sub-options as necessary to satisfy the address 3590 resolution request, and can also include ordinary IP packets as 3591 additional super-packet extensions to this NA(AR) message if it has 3592 immediate data to send to the ARS. The ARR then returns the NA(AR) 3593 to the ARS using the same hop-by-hop OAL addressing disciplines as 3594 specified above for an ordinary multilink NS/NA exchange. This will 3595 cause the NA(AR) to visit all OAL intermediate nodes on the path 3596 towards the ARS. 3598 When the NA(AR) traverses the return path to the ARS, OAL 3599 intermediate nodes in the path process the NS AFP information exactly 3600 the same as for an ordinary multilink forwarding exchange as 3601 specified above, i.e., without examining the remaining NA(AR) message 3602 contents. This results in the ARR node now assuming the FHS role and 3603 the ARS assuming the LHS role from the perspective of multilink 3604 forwarding coordination. When the NA(AR) arrives, the ARS processes 3605 the window synchronization parameters while also processing all other 3606 NA(AR) OMNI option information, thereby eliminating an extraneous 3607 message transmission and associated delay. The ARS (now acting as an 3608 LHS peer) then completes the exchange by returning a responsive NA; 3609 if no NA response is received within RETRANS_TIMER seconds, the ARR 3610 can retransmit the NA(AR) up to MAX_NEIGHBOR_ADVERTISEMENT times 3611 before giving up. 3613 This very importantly implies that the type of IPv6 ND message used 3614 to convey an AFP with Job codes '00' and '01' (i.e., NS or NA) is 3615 unimportant from the perspective of multilink forwarding. This means 3616 that Job code '00' serves as the solicitation indication and Job code 3617 '01' serves as the response such that either an NS or NA message 3618 carrying an AFP with Job code '00' will invoke a responsive NA 3619 message carrying an AFP with Job code '01'. Also importantly, this 3620 condition does not apply for Job codes '10' and '11'; for those job 3621 codes, an NA is only sent in response to an NS and never in response 3622 to another NA. 3624 3.13.3. Client/Gateway Route Optimization 3626 Following multilink route optimization for specific underlay 3627 interface pairs, FHS/LHS Clients located on open INETs can invoke 3628 Client/Gateway route optimization to improve performance and reduce 3629 load and congestion on their respective Proxy/Servers. To initiate 3630 Client/Gateway route optimization, the Client prepares an NS message 3631 with its own XLA address as the source and the ULA of its Gateway as 3632 the destination while creating a NCE for the Gateway if necessary. 3634 The NS message must be no larger than the minimum MPS and 3635 encapsulated as an atomic fragment. 3637 The Client then includes an Interface Attributes sub-option for its 3638 underlay interface as well as an authentication signature but does 3639 not include window synchronization parameters. The Client then 3640 performs OAL encapsulation with its own ULA-MNP as the source and the 3641 ULA of the Gateway as the destination while including a randomly- 3642 chosen Identification value, then performs L2 encapsulation on the 3643 atomic fragment and sends the resulting carrier packet directly to 3644 the Gateway. 3646 When the Gateway receives the carrier packet, it verifies the 3647 authentication signature then creates a NCE for the Client. The 3648 Gateway then caches the L2 encapsulation addresses (which may have 3649 been altered by one or more NATs on the path) as well as the 3650 Interface Attributes for this Client ifIndex, and marks this Client 3651 underlay interface as "trusted". The Gateway then prepares an NA 3652 reply with its own ULA as the source and the XLA of the Client as the 3653 destination where the NA again must be no larger than the minimum 3654 MPS. 3656 The Gateway then echoes the Client's Interface Attributes, includes 3657 an Origin Indication with the Client's observed L2 addresses and 3658 includes an authentication signature. The Gateway then performs OAL 3659 encapsulation with its own ULA as the source and the ULA-MNP of the 3660 Client as the destination while using the same Identification value 3661 that appeared in the NS, then performs L2 encapsulation on the atomic 3662 fragment and sends the resulting carrier packet directly to the 3663 Client. 3665 When the Client receives the NA reply, it caches the carrier packet 3666 L2 source address information as the Gateway target address via this 3667 underlay interface while marking the interface as "trusted". The 3668 Client also caches the Origin Indication L2 address information as 3669 its own (external) source address for this underlay interface. 3671 After the Client and Gateway have established NCEs as well as 3672 "trusted" status for a particular underlay interface pair, each node 3673 can begin forwarding ordinary carrier packets intended for this 3674 multilink route optimization directly to one another while omitting 3675 the Proxy/Server from the forwarding path while the status is 3676 "trusted". The NS/NA messaging will have established the correct 3677 state in any NATs in the path so that NAT traversal is naturally 3678 supported. The Client and Gateway must maintain a timer that watches 3679 for activity on the path; if no carrier packets and/or NS/NA messages 3680 are sent or received over the path before NAT state is likely to have 3681 expired, the underlay interface pair status becomes "untrusted". 3683 Thereafter, when the Client forwards a carrier packet with an AFVI 3684 toward the Gateway as the next hop, the Client uses the AFVI for the 3685 Gateway (discovered during multilink route optimization) instead of 3686 the AFVI for its Proxy/Server; the Gateway will accept the packet 3687 from the Client if and only if the AFVI matches the correct AFV and 3688 the underlay interface status is trusted. (The same is true in the 3689 reverse direction when the Gateway sends carrier packets directly to 3690 the Client.) 3692 Note that the Client and Gateway each maintain a single NCE, but that 3693 the NCE may aggregate multiple underlay interface pairs. Each 3694 underlay interface pair may use differing source and target L2 3695 addresses according to NAT mappings, and the "trusted/untrusted" 3696 status of each pair must be tested independently. When no "trusted" 3697 pairs remain, the NCE is deleted. 3699 Note that the above method requires Gateways to participate in NS/NA 3700 message authentication signature application and verification. In an 3701 alternate approach, the Client could instead exchange NS/NA messages 3702 with authentication signatures via its Proxy/Server but addressed to 3703 the ULA of the Gateway, and the Proxy/Server and Gateway could relay 3704 the messages over the secured spanning tree. However, this would 3705 still require the Client to send additional messages toward the L2 3706 address of the Gateway to populate NAT state; hence the savings in 3707 complexity for Gateways would result in increased message overhead 3708 for Clients. 3710 3.13.4. Client/Client Route Optimization 3712 When the FHS/LHS Clients are both located on the same SRT segment, 3713 Client-to-Client route optimization is possible following the 3714 establishment of any necessary state in NATs in the path. Both 3715 Clients will have already established state via their respective 3716 shared segment Proxy/Servers (and possibly also the shared segment 3717 Gateway) and can begin forwarding packets directly via NAT traversal 3718 while avoiding any Proxy/Server and/or Gateway hops. 3720 When the FHS/LHS Clients on the same SRT segment perform the initial 3721 NS/NA exchange to establish AFIB state, they also include an Origin 3722 Indication (i.e., in addition to an AFP sub-option) with the mapped 3723 addresses discovered during the RS/RA exchanges with their respective 3724 Proxy/Servers. After the AFV paths have been established, both 3725 Clients can begin sending packets via strict AFV paths while 3726 establishing a direct path for Client-to-Client route optimization. 3728 To establish the direct path, either Client (acting as the source) 3729 transmits a bubble to the mapped L2 address for the target Client 3730 which primes its local chain of NATs for reception of future packets 3731 from that L2 address (see: [RFC4380] and [I-D.templin-6man-omni]). 3732 The source Client then prepares an NS message with its own XLA as the 3733 source, with the XLA of the target as the destination and with an 3734 OMNI option with an Interface Attributes sub-option. The source 3735 Client then encapsulates the NS in an OAL header with its own ULA-MNP 3736 as the source, with the ULA-MNP of the target Client as the 3737 destination and with an in-window Identification for the target. The 3738 source Client then fragments and encapsulates in L2 headers addressed 3739 to its Proxy/Server then forwards the resulting carrier packets to 3740 the Proxy/Server. 3742 When the Proxy/Server receives the carrier packets, it re- 3743 encapsulates and forwards them as unsecured carrier packets according 3744 to AFIB state where they will eventually arrive at the target Client 3745 which can verify that the identifications are within the acceptable 3746 window and reassemble if necessary. Following reassembly, the target 3747 Client prepares an NA message with its own XLA as the source, with 3748 the XLA of the source Client as the destination and with an OMNI 3749 option with an Interface Attributes sub-option. The target Client 3750 then encapsulates the NA in an OAL header with its own ULA-MNP as the 3751 source, with the ULA-MNP of the source Client as the destination and 3752 with an in-window Identification for the source Client. The target 3753 Client then fragments and encapsulates in L2 headers addressed to the 3754 source Client's Origin addresses then forwards the resulting carrier 3755 packets directly to the source Client. 3757 Following the initial NS/NA exchange, both Clients mark their 3758 respective (source, target) underlay interface pairs as "trusted" for 3759 no more than ReachableTime seconds. While the Clients continue to 3760 exchange carrier packets via the direct path avoiding all Proxy/ 3761 Servers and Gateways, they should perform additional NS/NA exchanges 3762 via their local Proxy/Servers to refresh NCE state as well as send 3763 additional bubbles to the peer's Origin address information if 3764 necessary to refresh NAT state. 3766 Note that these procedures are suitable for a widely-deployed but 3767 basic class of NATs. Procedures for advanced NAT classes are 3768 outlined in [RFC6081], which provides mechanisms that can be employed 3769 equally for AERO using the corresponding sub-options specified by 3770 OMNI. 3772 Note also that each communicating pair of Clients may need to 3773 maintain NAT state for peer to peer communications via multiple 3774 underlay interface pairs. It is therefore important that Origin 3775 Indications are maintained with the correct peer interface and that 3776 the NCE may cache information for multiple peer interfaces. 3778 Note that the source and target Client exchange Origin information 3779 during the secured NS/NA multilink route optimization exchange. This 3780 allows for subsequent NS/NA exchanges to proceed using only the 3781 Identification value as a data origin confirmation. However, Client- 3782 to-Client peerings that require stronger security may also include 3783 authentication signatures for mutual authentication. 3785 3.13.5. Client-to-Client OMNI Link Extension 3787 Clients may be recursively nested within the ENETs of other Clients. 3788 When a Client is the downstream-attached ENET neighbor of an upstream 3789 Client, it still supports the route optimization functions discussed 3790 above by maintaining an AFIB and assigning AFVI values. When the 3791 Client processes an IPv6 ND NS/NA message that includes an AFP sub- 3792 option, it writes its AFVI information as the first/last AFVI list 3793 entry the same as for the single Client case discussed above. 3795 The Client then forwards the NS/NA message to the next Client in the 3796 extended OMNI link toward the FHS/LHS Proxy/Server, which records the 3797 AFVI value then overwrites the AFVI list entry with its own AFVI 3798 value. This process iteratively continues until the Client that will 3799 forward the NS/NA message to the FHS/LHS Proxy/Server is reached, at 3800 which point the NS/NA AFVI list entries are populated by the 3801 intermediate nodes on the path to the LHS/FHS the same as discussed 3802 above. 3804 In this way, each Client in the extended OMNI link discovers the A/B 3805 AFVIs of the next/previous Client without intruding into the AFP sub- 3806 option AFVI list. Therefore the list can remain fixed at 5 entries 3807 even though the Client-to-Client OMNI link extension can be 3808 arbitrarily long. Therefore, route optimization is not possible 3809 between consecutive Client members of the extended OMNI link but 3810 becomes possible at the Internetworking border that separates the FHS 3811 and LHS elements. 3813 3.13.6. Intra-ANET/ENET Route Optimization for AERO Peers 3815 When a Client forwards a packet from a Host or another Client 3816 connected to one of its downstream ENETs to a peer within the same 3817 downstream ENET, the Client returns an IPv6 ND Redirect message to 3818 inform the source that that target can be reached directly. The 3819 contents of the Redirect message are the same as specified in 3820 [RFC4861]. 3822 In the same fashion, when a Proxy/Server forwards a packet from a 3823 Host or Client connected to one of its downstream ANETs to a peer 3824 within the same downstream ANET, the Proxy/Server returns an IPv6 ND 3825 Redirect message. 3827 All other route optimization functions are conducted per the NS/NA 3828 messaging discussed in the previous sections. 3830 3.14. Neighbor Unreachability Detection (NUD) 3832 AERO nodes perform Neighbor Unreachability Detection (NUD) per 3833 [RFC4861] either reactively in response to persistent link-layer 3834 errors (see Section 3.11) or proactively to confirm reachability. 3835 The NUD algorithm is based on periodic control message exchanges and 3836 may further be seeded by IPv6 ND hints of forward progress, but care 3837 must be taken to avoid inferring reachability based on spoofed 3838 information. For example, IPv6 ND message exchanges that include 3839 authentication codes and/or in-window Identifications may be 3840 considered as acceptable hints of forward progress, while spurious 3841 random carrier packets should be ignored. 3843 AERO nodes can perform NS/NA exchanges over the OMNI link secured 3844 spanning tree (i.e. the same as described above) to test reachability 3845 without risk of DoS attacks from nodes pretending to be a neighbor. 3846 These NS/NA messages use the unicast XLAs/ULAs of the parties 3847 involved in the NUD test. When only reachability information is 3848 required without updating any other NCE state, AERO nodes can instead 3849 perform NS/NA exchanges directly between neighbors without employing 3850 the secured spanning tree as long as they include in-window 3851 Identifications and either an authentication signature or checksum. 3853 After route optimization directs a source FHS peer to a target LHS 3854 peer with one or more link-layer addresses, either node may invoke 3855 multilink forwarding state initialization to establish authentic 3856 intermediate node state between specific underlay interface pairs 3857 which also tests their reachability. Thereafter, either node acting 3858 as the source may perform additional reachability probing through NS 3859 messages over the SRT secured or unsecured spanning tree, or through 3860 NS messages sent directly to an underlay interface of the target 3861 itself. While testing a target underlay interface, the source can 3862 optionally continue to forward carrier packets via alternate 3863 interfaces, maintain a small queue of carrier packets until target 3864 reachability is confirmed or include them as trailing data with the 3865 NS in an OAL super-packet [I-D.templin-6man-omni]. 3867 NS messages are encapsulated, fragmented and transmitted as carrier 3868 packets the same as for ordinary original IP data packets, however 3869 the encapsulated destinations are either the ULA or XLA of the source 3870 and either the ULA of the LHS Proxy/Server or the XLA of the target 3871 itself. The source encapsulates the NS message the same as described 3872 in Section 3.13.2 and includes an Interface Attributes sub-option 3873 with ifIndex set to identify its underlay interface used for 3874 forwarding. The source then includes an in-window Identification, 3875 fragments the OAL packet and forwards the resulting carrier packets 3876 into the unsecured spanning tree, directly to the target if it is in 3877 the local segment or directly to a Gateway in the local segment. 3879 When the target receives the NS carrier packets, it verifies that it 3880 has a NCE for this source and that the Identification is in-window, 3881 then submits the carrier packets for reassembly. The target then 3882 verifies the authentication signature or checksum, then searches for 3883 Interface Attributes in its NCE for the source that match the NS for 3884 the NA reply. The target then prepares the NA with the source and 3885 destination addresses reversed, encapsulates and sets the OAL source 3886 and destination, includes an Interface Attributes sub-option in the 3887 NA to identify the ifIndex of the underlay interface the NS arrived 3888 on and sets the Target Address to the same value included in the NS. 3889 The target next sets the R flag to 1, the S flag to 1 and the O flag 3890 to 1, then selects an in-window Identification for the source and 3891 performs fragmentation. The node then forwards the carrier packets 3892 into the unsecured spanning tree, directly to the source if it is in 3893 the local segment or directly to a Gateway in the local segment. 3895 When the source receives the NA, it marks the target underlay 3896 interface tested as "trusted". Note that underlay interface states 3897 are maintained independently of the overall NCE REACHABLE state, and 3898 that a single NCE may have multiple target underlay interfaces in 3899 various "trusted/untrusted" states while the NCE state as a whole 3900 remains REACHABLE. 3902 3.15. Mobility Management and Quality of Service (QoS) 3904 AERO is a fully Distributed Mobility Management (DMM) service in 3905 which each Proxy/Server is responsible for only a small subset of the 3906 Clients on the OMNI link. This is in contrast to a Centralized 3907 Mobility Management (CMM) service where there are only one or a few 3908 network mobility collective entities for large Client populations. 3909 Clients coordinate with their associated FHS and Hub Proxy/Servers 3910 via RS/RA exchanges to maintain the DMM profile, and the AERO routing 3911 system tracks all current Client/Proxy/Server peering relationships. 3913 Hub Proxy/Servers provide a designated router service for their 3914 dependent Clients, while FHS Proxy/Servers provide a proxy conduit 3915 between the Client and both the Hub and OMNI link in general. 3916 Clients are responsible for maintaining neighbor relationships with 3917 their Proxy/Servers through periodic RS/RA exchanges, which also 3918 serves to confirm neighbor reachability. When a Client's underlay 3919 interface attributes change, the Client is responsible for updating 3920 the Hub Proxy/Server through new RS/RA exchanges using the FHS Proxy/ 3921 Server as a first-hop conduit. The FHS Proxy/Server can also act as 3922 a proxy to perform some IPv6 ND exchanges on the Client's behalf 3923 without consuming bandwidth on the Client underlay interface. 3925 Mobility management considerations are specified in the following 3926 sections. 3928 3.15.1. Mobility Update Messaging 3930 Mobile Clients (and/or their Hub Proxy/Servers) accommodate mobility 3931 and/or multilink change events by sending secured uNA messages to 3932 each active neighbor. When a node sends a uNA message to each 3933 specific neighbor on behalf of a mobile Client, it sets the IPv6 3934 source address to its own ULA or XLA, sets the destination address to 3935 the neighbor's ULA or XLA and sets the Target Address to the mobile 3936 Client's XLA. The uNA also includes an OMNI option with OMNI 3937 Neighbor Coordination sub-option Preflen set to the prefix length 3938 associated with the mobile Client's XLA, includes Interface 3939 Attributes and Traffic Selectors for the mobile Client's underlay 3940 interfaces and includes an authentication signature if necessary. 3941 The node then sets the uNA R flag to 1, S flag to 0 and O flag to 1, 3942 then encapsulates the message in an OAL header with source set to its 3943 own ULA and destination set to either the specific neighbor's ULA or 3944 the FHS Proxy/Server's ULA. The uNA message will then follow the 3945 secured spanning tree and arrive at the specific neighbor. 3947 As discussed in Section 7.2.6 of [RFC4861], the transmission and 3948 reception of uNA messages is unreliable but provides a useful 3949 optimization. In well-connected Internetworks with robust data links 3950 uNA messages will be delivered with high probability, but in any case 3951 the node can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT uNAs to 3952 each neighbor to increase the likelihood that at least one will be 3953 received. Alternatively, the node can set the PNG flag in the uNA 3954 OMNI option header to request a uNA acknowledgement as specified in 3955 [I-D.templin-6man-omni]. 3957 When the FHS/LHS Proxy/Server receives a secured uNA message prepared 3958 as above, if the uNA destination was its own ULA the Proxy/Server 3959 uses the included OMNI option information to update its NCE for the 3960 target but does not reset ReachableTime since the receipt of a uNA 3961 message does not provide confirmation that any forward paths to the 3962 target Client are working. If the destination was the XLA of the 3963 FHS/LHS Client, the Proxy/Server instead changes the OAL source to 3964 its own ULA, includes an authentication signature if necessary, and 3965 includes an in-window Identification for this Client. Finally, if 3966 the uNA message PNG flag was set, the node that processes the uNA 3967 returns a uNA acknowledgement as specified in 3968 [I-D.templin-6man-omni]. 3970 3.15.2. Announcing Link-Layer Information Changes 3972 When a Client needs to change its underlay Interface Attributes and/ 3973 or Traffic Selectors for one or more underlay interfaces (e.g., due 3974 to a mobility event), the Client sends RS messages to its Hub Proxy/ 3975 Server (via first-hop FHS Proxy/Servers if necessary). Each RS 3976 includes an OMNI option with Interface Attributes and/or Traffic 3977 Selector sub-options for the ifIndex in question. 3979 Note that the first FHS Proxy/Server may change due to the underlay 3980 interface change. If the Client RS includes an OMNI Proxy/Server 3981 Departure sub-option for the former FHS Proxy/Server, the new FHS 3982 Proxy/Server can send a departure indication (see Section 3.15.5); 3983 otherwise, any stale state in the former FHS Proxy/Server will simply 3984 expire after ReachableTime expires with no effect on the Hub Proxy/ 3985 Server. 3987 Up to MAX_RTR_SOLICITATIONS RS messages MAY be sent in parallel with 3988 sending carrier packets containing user data in case one or more RAs 3989 are lost. If all RAs are lost, the Client SHOULD re-associate with a 3990 new Proxy/Server. 3992 After performing the RS/RA exchange, the Client sends uNA messages to 3993 all neighbors the same as described in the previous section. 3995 3.15.3. Bringing New Links Into Service 3997 When a Client needs to bring new underlay interfaces into service 3998 (e.g., when it activates a new data link), it sends an RS message to 3999 the Hub Proxy/Server via a FHS Proxy/Server for the underlay 4000 interface (if necessary) with an OMNI option that includes an 4001 Interface Attributes sub-option with appropriate link quality values 4002 and with link-layer address information for the new link. The Client 4003 then again sends uNA messages to all neighbors the same as described 4004 above. 4006 3.15.4. Deactivating Existing Links 4008 When a Client needs to deactivate an existing underlay interface, it 4009 sends a uNA message toward the Hub Proxy/Server via an FHS Proxy/ 4010 Server with an OMNI option with appropriate Interface Attributes 4011 values for the deactivated link - in particular, the link quality 4012 value 0 assures that neighbors will cease to use the link. 4014 If the Client needs to send uNA messages over an underlay interface 4015 other than the one being deactivated, it MUST include Interface 4016 Attributes with appropriate link quality values for any underlay 4017 interfaces being deactivated. The Client then again sends uNA 4018 messages to all neighbors the same as described above. 4020 Note that when a Client deactivates an underlay interface, neighbors 4021 that receive the ensuing uNA messages need not purge all references 4022 for the underlay interface from their neighbor cache entries. The 4023 Client may reactivate or reuse the underlay interface and/or its 4024 ifIndex at a later point in time, when it will send new RS messages 4025 to an FHS Proxy/Server with fresh interface parameters to update any 4026 neighbors. 4028 3.15.5. Moving Between Proxy/Servers 4030 The Client performs the procedures specified in Section 3.12.2 when 4031 it first associates with a new Hub Proxy/Server or renews its 4032 association with an existing Hub Proxy/Server. 4034 When a Client associates with a new Hub Proxy/Server, it sends RS 4035 messages to register its underlay interfaces with the new Hub while 4036 including the old Hub's ULA in the "Old Hub Proxy/Server ULA" field 4037 of a Proxy/Server Departure OMNI sub-option. When the new Hub Proxy/ 4038 Server returns the RA message via the FHS Proxy/Server (acting as a 4039 proxy), the FHS Proxy/Server sends a uNA to the old Hub Proxy/Server 4040 (i.e., if the ULA is non-zero and different from its own). The uNA 4041 has the XLA of the Client as the source and the ULA of the old hub as 4042 the destination and with OMNI Neighbor Coordination sub-option 4043 Preflen set to 0. The FHS Proxy/Server encapsulates the uNA in an 4044 OAL header with the ULA of the new Hub as the source and the ULA of 4045 the old Hub as the destination, the fragments and sends the carrier 4046 packets via the secured spanning tree. 4048 When the old Hub Proxy/Server receives the carrier packets, it 4049 reassembles to obtain the uNA then changes the Client's NCE state to 4050 DEPARTED, resets DepartTime and caches the new Hub Proxy/Server ULA. 4051 After a short delay (e.g., 2 seconds) the old Hub Proxy/Server 4052 withdraws the Client's MNP from the routing system. While in the 4053 DEPARTED state, the old Hub Proxy/Server forwards any carrier packets 4054 received via the secured spanning tree destined to the Client's ULA- 4055 MNP to the new Hub Proxy/Server's ULA. After DepartTime expires, the 4056 old Hub Proxy/Server deletes the Client's NCE. 4058 Mobility events may also cause a Client to change to a new FHS Proxy/ 4059 Server over a specific underlay interface at any time such that a 4060 Client RS/RA exchange over the underlay interface will engage the new 4061 FHS Proxy/Server instead of the old. The Client can arrange to 4062 inform the old FHS Proxy/Server of the departure by including a 4063 Proxy/Server Departure sub-option with a ULA for the "Old FHS Proxy/ 4064 Server ULA", and the new FHS Proxy/Server will issue a uNA using the 4065 same procedures as outlined for the Hub above while using its own ULA 4066 as the source address. This can often result in successful delivery 4067 of packets that would otherwise be lost due to the mobility event. 4069 Clients SHOULD NOT move rapidly between Hub Proxy/Servers in order to 4070 avoid causing excessive oscillations in the AERO routing system. 4071 Examples of when a Client might wish to change to a different Hub 4072 Proxy/Server include a Hub Proxy/Server that has become unresponsive, 4073 topological movements of significant distance, movement to a new 4074 geographic region, movement to a new OMNI link segment, etc. 4076 3.16. Multicast 4078 Clients provide an IGMP (IPv4) [RFC2236] or MLD (IPv6) [RFC3810] 4079 proxy service for its ENETs and/or hosted applications [RFC4605] and 4080 act as a Protocol Independent Multicast - Sparse-Mode (PIM-SM, or 4081 simply "PIM") Designated Router (DR) [RFC7761] on the OMNI link. 4082 Proxy/Servers act as OMNI link PIM routers for Clients on ANET, VPNed 4083 or Direct interfaces, and Relays also act as OMNI link PIM routers on 4084 behalf of nodes on other links/networks. 4086 Clients on VPNed, Direct or ANET underlay interfaces for which the 4087 ANET has deployed native multicast services forward IGMP/MLD messages 4088 into the ANET. The IGMP/MLD messages may be further forwarded by a 4089 first-hop ANET access router acting as an IGMP/MLD-snooping switch 4090 [RFC4541], then ultimately delivered to an ANET Proxy/Server. The 4091 FHS Proxy/Server then acts as an ARS to send NS(AR) messages to an 4092 ARR for the multicast source. Clients on INET and ANET underlay 4093 interfaces without native multicast services instead send NS(AR) 4094 messages as an ARS to cause their FHS Proxy/Server to forward the 4095 message to an ARR. When the ARR prepares an NA(AR) response, it 4096 initiates PIM protocol messaging according to the Source-Specific 4097 Multicast (SSM) and Any-Source Multicast (ASM) operational modes as 4098 discussed in the following sections. 4100 3.16.1. Source-Specific Multicast (SSM) 4102 When an ARS "X" (i.e., either a Client or Proxy/Server) acting as PIM 4103 router receives a Join/Prune message from a node on its downstream 4104 interfaces containing one or more ((S)ource, (G)roup) pairs, it 4105 updates its Multicast Routing Information Base (MRIB) accordingly. 4106 For each S belonging to a prefix reachable via X's non-OMNI 4107 interfaces, X then forwards the (S, G) Join/Prune to any PIM routers 4108 on those interfaces per [RFC7761]. 4110 For each S belonging to a prefix reachable via X's OMNI interface, X 4111 sends an NS(AR) message (see: Section 3.13) using its own ULA or XLA 4112 as the source address, the solicited node multicast address 4113 corresponding to S as the destination and the XLA of S as the target 4114 address. X then encapsulates the NS(AR) in an OAL header with source 4115 address set to its own ULA and destination address set to the ULA for 4116 S, then forwards the message into the secured spanning tree which 4117 delivers it to ARR "Y" that services S. Y will then return an NA(AR) 4118 that includes an OMNI option with Interface Attributes for any 4119 underlay interfaces that are currently servicing S. 4121 When X processes the NA(AR) it selects one or more underlay 4122 interfaces for S and performs an NS/NA multilink forwarding exchange 4123 over the secured spanning tree while including a PIM Join/Prune 4124 message for each multicast group of interest in the OMNI option. If 4125 S is located behind any Proxys "Z"*, each Z* then updates its MRIB 4126 accordingly and maintains the XLA of X as the next hop in the reverse 4127 path. Since Gateways forward messages not addressed to themselves 4128 without examining them, this means that the (reverse) multicast tree 4129 path is simply from each Z* (and/or S) to X with no other multicast- 4130 aware routers in the path. 4132 Following the initial combined Join/Prune and NS/NA messaging, X 4133 maintains a NCE for each S the same as if X was sending unicast data 4134 traffic to S. In particular, X performs additional NS/NA exchanges 4135 to keep the NCE alive for up to t_periodic seconds [RFC7761]. If no 4136 new Joins are received within t_periodic seconds, X allows the NCE to 4137 expire. Finally, if X receives any additional Join/Prune messages 4138 for (S,G) it forwards the messages over the secured spanning tree. 4140 Client C that holds an MNP for source S may later depart from a first 4141 Proxy/Server Z1 and/or connect via a new Proxy/Server Z2. In that 4142 case, Y sends a uNA message to X the same as specified for unicast 4143 mobility in Section 3.15. When X receives the uNA message, it 4144 updates its NCE for the XLA for source S and sends new Join messages 4145 in NS/NA exchanges addressed to the new target Client underlay 4146 interface connection for S. There is no requirement to send any 4147 Prune messages to old Proxy/Server Z1 since source S will no longer 4148 source any multicast data traffic via Z1. Instead, the multicast 4149 state for (S,G) in Proxy/Server Z1 will soon expire since no new 4150 Joins will arrive. 4152 3.16.2. Any-Source Multicast (ASM) 4154 When an ARS "X" acting as a PIM router receives Join/Prune messages 4155 from a node on its downstream interfaces containing one or more (*,G) 4156 pairs, it updates its Multicast Routing Information Base (MRIB) 4157 accordingly. X first performs an NS/NA(AR) exchange to receive 4158 address resolution information for Rendezvous Point (RP) "R" for each 4159 G. X then includes a copy of each Join/Prune message in the OMNI 4160 option of an NS message with its own ULA or XLA as the source address 4161 and the ULA or XLA for R as the destination address, then 4162 encapsulates the NS message in an OAL header with its own ULA as the 4163 source and the ULA of R's Proxy/Server as the destination then sends 4164 the message into the secured spanning tree. 4166 For each source "S" that sends multicast traffic to group G via R, 4167 Client S* that aggregates S (or its Proxy/Server) encapsulates the 4168 original IP packets in PIM Register messages, includes the PIM 4169 Register messages in the OMNI options of uNA messages, performs OAL 4170 encapsulation and fragmentation then forwards the resulting carrier 4171 packets with Identification values within the receive window for 4172 Client R* that aggregates R. Client R* may then elect to send a PIM 4173 Join to S* in the OMNI option of a uNA over the secured spanning 4174 tree. This will result in an (S,G) tree rooted at S* with R as the 4175 next hop so that R will begin to receive two copies of the original 4176 IP packet; one native copy from the (S, G) tree and a second copy 4177 from the pre-existing (*, G) tree that still uses uNA PIM Register 4178 encapsulation. R can then issue a uNA PIM Register-stop message over 4179 the secured spanning tree to suppress the Register-encapsulated 4180 stream. At some later time, if Client S* moves to a new Proxy/ 4181 Server, it resumes sending original IP packets via uNA PIM Register 4182 encapsulation via the new Proxy/Server. 4184 At the same time, as multicast listeners discover individual S's for 4185 a given G, they can initiate an (S,G) Join for each S under the same 4186 procedures discussed in Section 3.16.1. Once the (S,G) tree is 4187 established, the listeners can send (S, G) Prune messages to R so 4188 that multicast original IP packets for group G sourced by S will only 4189 be delivered via the (S, G) tree and not from the (*, G) tree rooted 4190 at R. All mobility considerations discussed for SSM apply. 4192 3.16.3. Bi-Directional PIM (BIDIR-PIM) 4194 Bi-Directional PIM (BIDIR-PIM) [RFC5015] provides an alternate 4195 approach to ASM that treats the Rendezvous Point (RP) as a Designated 4196 Forwarder (DF). Further considerations for BIDIR-PIM are out of 4197 scope. 4199 3.17. Operation over Multiple OMNI Links 4201 An AERO Client can connect to multiple OMNI links the same as for any 4202 data link service. In that case, the Client maintains a distinct 4203 OMNI interface for each link, e.g., 'omni0' for the first link, 4204 'omni1' for the second, 'omni2' for the third, etc. Each OMNI link 4205 would include its own distinct set of Gateways and Proxy/Servers, 4206 thereby providing redundancy in case of failures. 4208 Each OMNI link could utilize the same or different ANET connections. 4209 The links can be distinguished at the link-layer via the SRT prefix 4210 in a similar fashion as for Virtual Local Area Network (VLAN) tagging 4211 (e.g., IEEE 802.1Q) and/or through assignment of distinct sets of 4212 MSPs on each link. This gives rise to the opportunity for supporting 4213 multiple redundant networked paths (see: Section 3.2.4). 4215 The Client's IP layer can select the outgoing OMNI interface 4216 appropriate for a given traffic profile while (in the reverse 4217 direction) correspondent nodes must have some way of steering their 4218 original IP packets destined to a target via the correct OMNI link. 4220 In a first alternative, if each OMNI link services different MSPs the 4221 Client can receive a distinct MNP from each of the links. IP routing 4222 will therefore assure that the correct OMNI link is used for both 4223 outbound and inbound traffic. This can be accomplished using 4224 existing technologies and approaches, and without requiring any 4225 special supporting code in correspondent nodes or Gateways. 4227 In a second alternative, if each OMNI link services the same MSP(s) 4228 then each link could assign a distinct "OMNI link Anycast" address 4229 that is configured by all Gateways on the link. Correspondent nodes 4230 can then perform Segment Routing to select the correct SRT, which 4231 will then direct the original IP packet over multiple hops to the 4232 target. 4234 3.18. DNS Considerations 4236 AERO Client MNs and INET correspondent nodes consult the Domain Name 4237 System (DNS) the same as for any Internetworking node. When 4238 correspondent nodes and Client MNs use different IP protocol versions 4239 (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain 4240 A records for IPv4 address mappings to MNs which must then be 4241 populated in Relay NAT64 mapping caches. In that way, an IPv4 4242 correspondent node can send original IPv4 packets to the IPv4 address 4243 mapping of the target MN, and the Relay will translate the IPv4 4244 header and destination address into an IPv6 header and IPv6 4245 destination address of the MN. 4247 When an AERO Client registers with an AERO Proxy/Server, the Proxy/ 4248 Server can return the address(es) of DNS servers in RDNSS options 4249 [RFC6106]. The DNS server provides the IP addresses of other MNs and 4250 correspondent nodes in AAAA records for IPv6 or A records for IPv4. 4252 3.19. Transition/Coexistence Considerations 4254 OAL encapsulation ensures that dissimilar INET partitions can be 4255 joined into a single unified OMNI link, even though the partitions 4256 themselves may have differing protocol versions and/or incompatible 4257 addressing plans. However, a commonality can be achieved by 4258 incrementally distributing globally routable (i.e., native) IP 4259 prefixes to eventually reach all nodes (both mobile and fixed) in all 4260 OMNI link segments. This can be accomplished by incrementally 4261 deploying AERO Gateways on each INET partition, with each Gateway 4262 distributing its MNPs and/or discovering non-MNP IP GUA prefixes on 4263 its INET links. 4265 This gives rise to the opportunity to eventually distribute native IP 4266 addresses to all nodes, and to present a unified OMNI link view even 4267 if the INET partitions remain in their current protocol and 4268 addressing plans. In that way, the OMNI link can serve the dual 4269 purpose of providing a mobility/multilink service and a transition/ 4270 coexistence service. Or, if an INET partition is transitioned to a 4271 native IP protocol version and addressing scheme that is compatible 4272 with the OMNI link MNP-based addressing scheme, the partition and 4273 OMNI link can be joined by Gateways. 4275 Relays that connect INETs/ENETs with dissimilar IP protocol versions 4276 may need to employ a network address and protocol translation 4277 function such as NAT64 [RFC6146]. 4279 3.20. Proxy/Server-Gateway Bidirectional Forwarding Detection 4281 In environments where rapid failure recovery is required, Proxy/ 4282 Servers and Gateways SHOULD use Bidirectional Forwarding Detection 4283 (BFD) [RFC5880]. Nodes that use BFD can quickly detect and react to 4284 failures so that cached information is re-established through 4285 alternate nodes. BFD control messaging is carried only over well- 4286 connected ground domain networks (i.e., and not low-end radio links) 4287 and can therefore be tuned for rapid response. 4289 Proxy/Servers and Gateways maintain BFD sessions in parallel with 4290 their BGP peerings. If a Proxy/Server or Gateway fails, BGP peers 4291 will quickly re-establish routes through alternate paths the same as 4292 for common BGP deployments. 4294 3.21. Time-Varying MNPs 4296 In some use cases, it is desirable, beneficial and efficient for the 4297 Client to receive a constant MNP that travels with the Client 4298 wherever it moves. For example, this would allow air traffic 4299 controllers to easily track aircraft, etc. In other cases, however 4300 (e.g., intelligent transportation systems), the MN may be willing to 4301 sacrifice a modicum of efficiency in order to have time-varying MNPs 4302 that can be changed every so often to defeat adversarial tracking. 4304 The DHCPv6 service offers a way for Clients that desire time-varying 4305 MNPs to obtain short-lived prefixes (e.g., on the order of a small 4306 number of minutes). In that case, the identity of the Client would 4307 not be bound to the MNP but rather to a Node Identification value 4308 (see: [I-D.templin-6man-omni]) to be used as the Client ID seed for 4309 MNP prefix delegation. The Client would then be obligated to 4310 renumber its internal networks whenever its MNP (and therefore also 4311 its XLA) changes. This should not present a challenge for Clients 4312 with automated network renumbering services, however presents limits 4313 for the durations of ongoing sessions that would prefer to use a 4314 constant address. 4316 4. Implementation Status 4318 An early AERO implementation based on OpenVPN (https://openvpn.net/) 4319 was announced on the v6ops mailing list on January 10, 2018 and an 4320 initial public release of the AERO proof-of-concept source code was 4321 announced on the intarea mailing list on August 21, 2015. 4323 Many AERO/OMNI functions are implemented and undergoing final 4324 integration. OAL fragmentation/reassembly buffer management code has 4325 been cleared for public release. 4327 5. IANA Considerations 4329 The IANA has assigned the UDP port number "8060" for an earlier 4330 experimental first version of AERO [RFC6706]. This document together 4331 with [I-D.templin-6man-omni] reclaims UDP port number "8060" as the 4332 service port for UDP/IP encapsulation. This document makes no 4333 request of IANA, since [I-D.templin-6man-omni] already provides 4334 instructions. (Note: although [RFC6706] was not widely implemented 4335 or deployed, it need not be obsoleted since its messages use the 4336 invalid ICMPv6 message type number '0' which implementations of this 4337 specification can easily distinguish and ignore.) 4339 No further IANA actions are required. 4341 6. Security Considerations 4343 AERO Gateways configure underlay interface secured tunnels with AERO 4344 Proxy/Servers and Relays within their local OMNI link segments. 4345 Applicable secured tunnel alternatives include IPsec [RFC4301], TLS/ 4346 SSL [RFC8446], DTLS [RFC6347], WireGuard [WG], etc. The AERO 4347 Gateways of all OMNI link segments in turn configure underlay 4348 interface secured tunnels with neighboring AERO Gateways for other 4349 OMNI link segments in a secured spanning tree topology. Therefore, 4350 control messages exchanged between any pair of OMNI link neighbors 4351 over the secured spanning tree are already protected. (Note that 4352 this inter-segment Gateway arrangement mirrors the "half-gateway" 4353 model discussed in the original Catenet proposal.) 4355 To prevent unauthorized local applications from congesting the 4356 secured spanning tree, Proxy/Servers and Gateways should configure 4357 local firewall settings to permit only the BGP protocol service 4358 daemon to source packets with the ULA assigned to the OMNI interface 4359 as the source and the ULA of a neighboring Proxy/Server or Gateway as 4360 the destination. This could be implemented as a port/address 4361 filtering configuration that permits only TCP port 179 (as defined in 4362 the IANA "Service Names and Port Numbers" registry) when using the 4363 ULA assigned to the OMNI interface. To prevent malicious Clients 4364 from congesting the secured spanning tree, Proxy/Servers should also 4365 rate-limit the secured IPv6 ND NS/NA messages they process for the 4366 same (source, target) pair, e.g., by applying IPv6 ND 4367 MAX_UNICAST_SOLICIT; MAX_NEIGHBOR_ADVERTISEMENT limits. This is 4368 especially true for NS/NA messages that include ordinary data packets 4369 as part of a super-packet. 4371 To prevent spoofing vectors, Proxy/Servers MUST discard without 4372 responding to any unsecured IPv6 ND messages that include OMNI sub- 4373 options that would affect state. Also, Proxy/Servers MUST discard 4374 without forwarding any original IP packets received from one of their 4375 own Clients (whether directly or following OAL reassembly) with a 4376 source address that does not match the Client's MNP and/or a 4377 destination address that does match the Client's MNP. Finally, 4378 Proxy/Servers MUST discard without forwarding any carrier packets 4379 with an OAL source and destination that both match the same MNP. 4381 For INET partitions that require strong security in the data plane, 4382 two options for securing communications include 1) disable route 4383 optimization so that all traffic is conveyed over the secured 4384 spanning tree, or 2) enable on-demand secure tunnel creation between 4385 Client neighbors. Option 1) would result in longer routes than 4386 necessary and impose traffic concentration on critical infrastructure 4387 elements. Option 2) could be coordinated between Clients using NS/NA 4388 messages with OMNI Host Identity Protocol (HIP) "Initiator/Responder" 4389 message sub-options [RFC7401][I-D.templin-6man-omni] to create a 4390 secured tunnel on-demand, or to use the QUIC-TLS protocol to 4391 establish a secured connection [RFC9000][RFC9001][RFC9002]. 4393 AERO Clients that connect to secured ANETs need not apply security to 4394 their IPv6 ND messages, since the messages will be authenticated and 4395 forwarded by a perimeter Proxy/Server that applies security on its 4396 INET-facing interface as part of the secured spanning tree (see 4397 above). AERO Clients connected to the open INET can use network and/ 4398 or transport layer security services such as VPNs or can by some 4399 other means establish a direct link to a Proxy/Server. When a VPN or 4400 direct link may be impractical, however, INET Clients and Proxy/ 4401 Servers SHOULD include and verify authentication signatures for their 4402 IPv6 ND messages as specified in [I-D.templin-6man-omni]. 4404 Application endpoints SHOULD use transport-layer (or higher-layer) 4405 security services such as QUIC-TLS, TLS/SSL, DTLS or SSH [RFC4251] to 4406 assure the same level of protection as for critical secured Internet 4407 services. AERO Clients that require host-based VPN services SHOULD 4408 use network and/or transport layer security services such as IPsec, 4409 TLS/SSL, DTLS, etc. AERO Proxys and Proxy/Servers can also provide a 4410 network-based VPN service on behalf of the Client, e.g., if the 4411 Client is located within a secured enclave and cannot establish a VPN 4412 on its own behalf. 4414 AERO Proxy/Servers and Gateways present targets for traffic 4415 amplification Denial of Service (DoS) attacks. This concern is no 4416 different than for widely-deployed VPN security gateways in the 4417 Internet, where attackers could send spoofed packets to the gateways 4418 at high data rates. This can be mitigated through the AERO/OMNI data 4419 origin authentication procedures, as well as connecting Proxy/Servers 4420 and Gateways over dedicated links with no connections to the Internet 4421 and/or when connections to the Internet are only permitted through 4422 well-managed firewalls. Traffic amplification DoS attacks can also 4423 target an AERO Client's low data rate links. This is a concern not 4424 only for Clients located on the open Internet but also for Clients in 4425 secured enclaves. AERO Proxy/Servers and Proxys can institute rate 4426 limits that protect Clients from receiving packet floods that could 4427 DoS low data rate links. 4429 AERO Relays must implement ingress filtering to avoid a spoofing 4430 attack in which spurious messages with ULA addresses are injected 4431 into an OMNI link from an outside attacker. AERO Clients MUST ensure 4432 that their connectivity is not used by unauthorized nodes on their 4433 ENETs to gain access to a protected network, i.e., AERO Clients that 4434 act as routers MUST NOT provide routing services for unauthorized 4435 nodes. (This concern is no different than for ordinary hosts that 4436 receive an IP address delegation but then "share" the address with 4437 other nodes via some form of Internet connection sharing such as 4438 tethering.) 4440 The PRL MUST be well-managed and secured from unauthorized tampering, 4441 even though the list contains only public information. The PRL can 4442 be conveyed to the Client in a similar fashion as in [RFC5214] (e.g., 4443 through layer 2 data link login messaging, secure upload of a static 4444 file, DNS lookups, etc.). 4446 The AERO service for open INET Clients depends on a public key 4447 distribution service in which Client public keys and identities are 4448 maintained in a shared database accessible to all open INET Proxy/ 4449 Servers. Similarly, each Client must be able to determine the public 4450 key of each Proxy/Server, e.g. by consulting an online database. 4451 When AERO nodes register their public keys indexed by a unique Host 4452 Identity Tag (HIT) [RFC7401] in a distributed database such as the 4453 DNS, and use the HIT as an identity for applying IPv6 ND message 4454 authentication signatures, a means for determining public key 4455 attestation is available. 4457 Security considerations for IPv6 fragmentation and reassembly are 4458 discussed in [I-D.templin-6man-omni]. In environments where spoofing 4459 is considered a threat, OAL nodes SHOULD employ Identification window 4460 synchronization and OAL destinations SHOULD configure an (end-system- 4461 based) firewall. 4463 SRH authentication facilities are specified in [RFC8754]. Security 4464 considerations for accepting link-layer ICMP messages and reflected 4465 packets are discussed throughout the document. 4467 7. Acknowledgements 4469 Discussions in the IETF, aviation standards communities and private 4470 exchanges helped shape some of the concepts in this work. 4471 Individuals who contributed insights include Mikael Abrahamsson, Mark 4472 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Scott Burleigh, 4473 Brian Carpenter, Wojciech Dec, Pavel Drasil, Ralph Droms, Adrian 4474 Farrel, Nick Green, Sri Gundavelli, Brian Haberman, Bernhard Haindl, 4475 Joel Halpern, Tom Herbert, Bob Hinden, Sascha Hlusiak, Lee Howard, 4476 Christian Huitema, Zdenek Jaron, Andre Kostur, Hubert Kuenig, Eliot 4477 Lear, Ted Lemon, Andy Malis, Satoru Matsushima, Tomek Mrugalski, 4478 Thomas Narten, Madhu Niraula, Alexandru Petrescu, Behcet Saikaya, 4479 Michal Skorepa, Dave Thaler, Joe Touch, Bernie Volz, Ryuji Wakikawa, 4480 Tony Whyman, Lloyd Wood and James Woodyatt. Members of the IESG also 4481 provided valuable input during their review process that greatly 4482 improved the document. Special thanks go to Stewart Bryant, Joel 4483 Halpern and Brian Haberman for their shepherding guidance during the 4484 publication of the AERO first edition. 4486 This work has further been encouraged and supported by Boeing 4487 colleagues including Akash Agarwal, Kyle Bae, M. Wayne Benson, Dave 4488 Bernhardt, Cam Brodie, John Bush, Balaguruna Chidambaram, Irene Chin, 4489 Bruce Cornish, Claudiu Danilov, Don Dillenburg, Joe Dudkowski, Wen 4490 Fang, Samad Farooqui, Anthony Gregory, Jeff Holland, Seth Jahne, 4491 Brian Jaury, Greg Kimberly, Ed King, Madhuri Madhava Badgandi, Laurel 4492 Matthew, Gene MacLean III, Kyle Mikos, Rob Muszkiewicz, Sean 4493 O'Sullivan, Satish Raghavendran, Vijay Rajagopalan, Greg Saccone, 4494 Bhargava Raman Sai Prakash, Rod Santiago, Madhanmohan Savadamuthu, 4495 Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Katie Tran, 4496 Brendan Williams, Amelia Wilson, Julie Wulff, Yueli Yang, Eric Yeh 4497 and other members of the Boeing mobility, networking and autonomy 4498 teams. Akash Agarwal, Kyle Bae, Wayne Benson, Madhuri Madhava 4499 Badgandi, Vijayasarathy Rajagopalan, Bhargava Raman Sai Prakash, 4500 Katie Tran and Eric Yeh are especially acknowledged for their work on 4501 the AERO implementation. Chuck Klabunde is honored and remembered 4502 for his early leadership, and we mourn his untimely loss. 4504 This work was inspired by the support and encouragement of countless 4505 outstanding colleagues, managers and program directors over the span 4506 of many decades. Beginning in the late 1980s,' the Digital Equipment 4507 Corporation (DEC) Ultrix Engineering and DECnet Architects groups 4508 identified early issues with fragmentation and bridging links with 4509 diverse MTUs. In the early 1990s, engagements at DEC Project Sequoia 4510 at UC Berkeley and the DEC Western Research Lab in Palo Alto included 4511 investigations into large-scale networked filesystems, ATM vs 4512 Internet and network security proxys. In the mid-1990s to early 4513 2000s employment at the NASA Ames Research Center (Sterling Software) 4514 and SRI International supported early investigations of IPv6, ONR UAV 4515 Communications and the IETF. An employment at Nokia where important 4516 IETF documents were published gave way to a present-day engagement 4517 with The Boeing Company. The work matured at Boeing through major 4518 programs including Future Combat Systems, Advanced Airplane Program, 4519 DTN for the International Space Station, Mobility Vision Lab, CAST, 4520 Caravan, Airplane Internet of Things, the NASA UAS/CNS program, the 4521 FAA/ICAO ATN/IPS program and many others. An attempt to name all who 4522 gave support and encouragement would double the current document size 4523 and result in many unintentional omissions - but to all a humble 4524 thanks. 4526 Earlier works on NBMA tunneling approaches are found in 4527 [RFC2529][RFC5214][RFC5569]. 4529 Many of the constructs presented in this second edition of AERO are 4530 based on the author's earlier works, including: 4532 * The Internet Routing Overlay Network (IRON) 4533 [RFC6179][I-D.templin-ironbis] 4535 * Virtual Enterprise Traversal (VET) 4536 [RFC5558][I-D.templin-intarea-vet] 4538 * The Subnetwork Encapsulation and Adaptation Layer (SEAL) 4539 [RFC5320][I-D.templin-intarea-seal] 4541 * AERO, First Edition [RFC6706] 4543 Note that these works cite numerous earlier efforts that are not also 4544 cited here due to space limitations. The authors of those earlier 4545 works are acknowledged for their insights. 4547 This work is aligned with the NASA Safe Autonomous Systems Operation 4548 (SASO) program under NASA contract number NNA16BD84C. 4550 This work is aligned with the FAA as per the SE2025 contract number 4551 DTFAWA-15-D-00030. 4553 This work is aligned with the Boeing Commercial Airplanes (BCA) 4554 Internet of Things (IoT) and autonomy programs. 4556 This work is aligned with the Boeing Information Technology (BIT) 4557 MobileNet program. 4559 8. References 4561 8.1. Normative References 4563 [I-D.templin-6man-omni] 4564 Templin, F. L., "Transmission of IP Packets over Overlay 4565 Multilink Network (OMNI) Interfaces", Work in Progress, 4566 Internet-Draft, draft-templin-6man-omni-67, 28 June 2022, 4567 . 4570 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4571 DOI 10.17487/RFC0791, September 1981, 4572 . 4574 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 4575 RFC 792, DOI 10.17487/RFC0792, September 1981, 4576 . 4578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4579 Requirement Levels", BCP 14, RFC 2119, 4580 DOI 10.17487/RFC2119, March 1997, 4581 . 4583 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 4584 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 4585 December 1998, . 4587 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 4588 "SEcure Neighbor Discovery (SEND)", RFC 3971, 4589 DOI 10.17487/RFC3971, March 2005, 4590 . 4592 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 4593 RFC 3972, DOI 10.17487/RFC3972, March 2005, 4594 . 4596 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 4597 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 4598 November 2005, . 4600 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 4601 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 4602 . 4604 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 4605 Network Address Translations (NATs)", RFC 4380, 4606 DOI 10.17487/RFC4380, February 2006, 4607 . 4609 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 4610 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 4611 DOI 10.17487/RFC4861, September 2007, 4612 . 4614 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 4615 Address Autoconfiguration", RFC 4862, 4616 DOI 10.17487/RFC4862, September 2007, 4617 . 4619 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 4620 DOI 10.17487/RFC6081, January 2011, 4621 . 4623 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 4624 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 4625 RFC 7401, DOI 10.17487/RFC7401, April 2015, 4626 . 4628 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 4629 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 4630 February 2016, . 4632 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4633 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4634 May 2017, . 4636 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4637 (IPv6) Specification", STD 86, RFC 8200, 4638 DOI 10.17487/RFC8200, July 2017, 4639 . 4641 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 4642 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 4643 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 4644 RFC 8415, DOI 10.17487/RFC8415, November 2018, 4645 . 4647 8.2. Informative References 4649 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 4650 2016. 4652 [EUI] IEEE, I., "Guidelines for Use of Extended Unique 4653 Identifier (EUI), Organizationally Unique Identifier 4654 (OUI), and Company ID, https://standards.ieee.org/wp- 4655 content/uploads/import/documents/tutorials/eui.pdf", 3 4656 August 2017. 4658 [I-D.bonica-6man-comp-rtg-hdr] 4659 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 4660 Jalil, "The IPv6 Compact Routing Header (CRH)", Work in 4661 Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- 4662 28, 18 May 2022, . 4665 [I-D.bonica-6man-crh-helper-opt] 4666 Li, X., Bao, C., Ruan, E., and R. Bonica, "Compressed 4667 Routing Header (CRH) Helper Option", Work in Progress, 4668 Internet-Draft, draft-bonica-6man-crh-helper-opt-04, 11 4669 October 2021, . 4672 [I-D.ietf-intarea-frag-fragile] 4673 Bonica, R., Baker, F., Huston, G., Hinden, R. M., Troan, 4674 O., and F. Gont, "IP Fragmentation Considered Fragile", 4675 Work in Progress, Internet-Draft, draft-ietf-intarea-frag- 4676 fragile-17, 30 September 2019, 4677 . 4680 [I-D.ietf-intarea-tunnels] 4681 Touch, J. and M. Townsley, "IP Tunnels in the Internet 4682 Architecture", Work in Progress, Internet-Draft, draft- 4683 ietf-intarea-tunnels-10, 12 September 2019, 4684 . 4687 [I-D.ietf-ipwave-vehicular-networking] 4688 Jeong, J. P., "IPv6 Wireless Access in Vehicular 4689 Environments (IPWAVE): Problem Statement and Use Cases", 4690 Work in Progress, Internet-Draft, draft-ietf-ipwave- 4691 vehicular-networking-29, 19 May 2022, 4692 . 4695 [I-D.ietf-rtgwg-atn-bgp] 4696 Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. 4697 Moreno, "A Simple BGP-based Mobile Routing System for the 4698 Aeronautical Telecommunications Network", Work in 4699 Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-18, 14 4700 June 2022, . 4703 [I-D.templin-6man-dhcpv6-ndopt] 4704 Templin, F. L., "A Unified Stateful/Stateless 4705 Configuration Service for IPv6", Work in Progress, 4706 Internet-Draft, draft-templin-6man-dhcpv6-ndopt-11, 1 4707 January 2021, . 4710 [I-D.templin-intarea-seal] 4711 Templin, F. L., "The Subnetwork Encapsulation and 4712 Adaptation Layer (SEAL)", Work in Progress, Internet- 4713 Draft, draft-templin-intarea-seal-68, 3 January 2014, 4714 . 4717 [I-D.templin-intarea-vet] 4718 Templin, F. L., "Virtual Enterprise Traversal (VET)", Work 4719 in Progress, Internet-Draft, draft-templin-intarea-vet-40, 4720 3 May 2013, . 4723 [I-D.templin-ipwave-uam-its] 4724 Templin, F. L., "Urban Air Mobility Implications for 4725 Intelligent Transportation Systems", Work in Progress, 4726 Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January 4727 2021, . 4730 [I-D.templin-ironbis] 4731 Templin, F. L., "The Interior Routing Overlay Network 4732 (IRON)", Work in Progress, Internet-Draft, draft-templin- 4733 ironbis-16, 28 March 2014, 4734 . 4737 [I-D.templin-v6ops-pdhost] 4738 Templin, F. L., "IPv6 Prefix Delegation and Multi- 4739 Addressing Models", Work in Progress, Internet-Draft, 4740 draft-templin-v6ops-pdhost-27, 1 January 2021, 4741 . 4744 [IEN48] Cerf, V., "The Catenet Model For Internetworking, 4745 https://www.rfc-editor.org/ien/ien48.txt", July 1978. 4747 [IEN48-2] Cerf, V., "The Catenet Model For Internetworking (with 4748 figures), http://www.postel.org/ien/pdf/ien048.pdf", July 4749 1978. 4751 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 4753 [RFC1035] Mockapetris, P., "Domain names - implementation and 4754 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4755 November 1987, . 4757 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", 4758 RFC 1256, DOI 10.17487/RFC1256, September 1991, 4759 . 4761 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 4762 RFC 1812, DOI 10.17487/RFC1812, June 1995, 4763 . 4765 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 4766 J., and E. Lear, "Address Allocation for Private 4767 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 4768 February 1996, . 4770 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 4771 DOI 10.17487/RFC2003, October 1996, 4772 . 4774 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4775 DOI 10.17487/RFC2004, October 1996, 4776 . 4778 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 4779 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 4780 . 4782 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 4783 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 4784 . 4786 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 4787 Domains without Explicit Tunnels", RFC 2529, 4788 DOI 10.17487/RFC2529, March 1999, 4789 . 4791 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4792 RFC 2983, DOI 10.17487/RFC2983, October 2000, 4793 . 4795 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4796 of Explicit Congestion Notification (ECN) to IP", 4797 RFC 3168, DOI 10.17487/RFC3168, September 2001, 4798 . 4800 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 4801 DOI 10.17487/RFC3330, September 2002, 4802 . 4804 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 4805 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 4806 DOI 10.17487/RFC3810, June 2004, 4807 . 4809 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4810 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4811 DOI 10.17487/RFC4122, July 2005, 4812 . 4814 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 4815 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 4816 January 2006, . 4818 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 4819 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 4820 DOI 10.17487/RFC4271, January 2006, 4821 . 4823 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4824 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4825 2006, . 4827 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4828 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 4829 December 2005, . 4831 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 4832 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 4833 2006, . 4835 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 4836 Control Message Protocol (ICMPv6) for the Internet 4837 Protocol Version 6 (IPv6) Specification", STD 89, 4838 RFC 4443, DOI 10.17487/RFC4443, March 2006, 4839 . 4841 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 4842 Protocol (LDAP): The Protocol", RFC 4511, 4843 DOI 10.17487/RFC4511, June 2006, 4844 . 4846 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 4847 "Considerations for Internet Group Management Protocol 4848 (IGMP) and Multicast Listener Discovery (MLD) Snooping 4849 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 4850 . 4852 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 4853 "Internet Group Management Protocol (IGMP) / Multicast 4854 Listener Discovery (MLD)-Based Multicast Forwarding 4855 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 4856 August 2006, . 4858 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 4859 Algorithms in Cryptographically Generated Addresses 4860 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 4861 . 4863 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 4864 "Bidirectional Protocol Independent Multicast (BIDIR- 4865 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 4866 . 4868 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 4869 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 4870 DOI 10.17487/RFC5214, March 2008, 4871 . 4873 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 4874 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 4875 February 2010, . 4877 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 4878 Route Optimization Requirements for Operational Use in 4879 Aeronautics and Space Exploration Mobile Networks", 4880 RFC 5522, DOI 10.17487/RFC5522, October 2009, 4881 . 4883 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 4884 RFC 5558, DOI 10.17487/RFC5558, February 2010, 4885 . 4887 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 4888 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 4889 January 2010, . 4891 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 4892 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 4893 . 4895 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 4896 "IPv6 Router Advertisement Options for DNS Configuration", 4897 RFC 6106, DOI 10.17487/RFC6106, November 2010, 4898 . 4900 [RFC6139] Russert, S., Ed., Fleischman, E., Ed., and F. Templin, 4901 Ed., "Routing and Addressing in Networks with Global 4902 Enterprise Recursion (RANGER) Scenarios", RFC 6139, 4903 DOI 10.17487/RFC6139, February 2011, 4904 . 4906 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4907 NAT64: Network Address and Protocol Translation from IPv6 4908 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4909 April 2011, . 4911 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 4912 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 4913 . 4915 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 4916 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 4917 DOI 10.17487/RFC6221, May 2011, 4918 . 4920 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 4921 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 4922 DOI 10.17487/RFC6273, June 2011, 4923 . 4925 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4926 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4927 January 2012, . 4929 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 4930 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 4931 DOI 10.17487/RFC6355, August 2011, 4932 . 4934 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 4935 for Equal Cost Multipath Routing and Link Aggregation in 4936 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 4937 . 4939 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 4940 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 4941 . 4943 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 4944 UDP Checksums for Tunneled Packets", RFC 6935, 4945 DOI 10.17487/RFC6935, April 2013, 4946 . 4948 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 4949 for the Use of IPv6 UDP Datagrams with Zero Checksums", 4950 RFC 6936, DOI 10.17487/RFC6936, April 2013, 4951 . 4953 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 4954 Korhonen, "Requirements for Distributed Mobility 4955 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 4956 . 4958 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 4959 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 4960 Multicast - Sparse Mode (PIM-SM): Protocol Specification 4961 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 4962 2016, . 4964 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 4965 Decraene, B., Litkowski, S., and R. Shakir, "Segment 4966 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 4967 July 2018, . 4969 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4970 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4971 . 4973 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 4974 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 4975 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 4976 . 4978 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 4979 Multiplexed and Secure Transport", RFC 9000, 4980 DOI 10.17487/RFC9000, May 2021, 4981 . 4983 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 4984 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 4985 . 4987 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 4988 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 4989 May 2021, . 4991 [WG] Wireguard, "WireGuard, https://www.wireguard.com", August 4992 2020. 4994 Appendix A. Non-Normative Considerations 4996 AERO can be applied to a multitude of Internetworking scenarios, with 4997 each having its own adaptations. The following considerations are 4998 provided as non-normative guidance: 5000 A.1. Implementation Strategies for Route Optimization 5002 Address resolution and route optimization as discussed in 5003 Section 3.13 results in the creation of NCEs. The NCE state is set 5004 to REACHABLE for at most ReachableTime seconds. In order to refresh 5005 the NCE lifetime before the ReachableTime timer expires, the 5006 specification requires implementations to issue a new NS/NA(AR) 5007 exchange to reset ReachableTime while data packets are still flowing. 5008 However, the decision of when to initiate a new NS/NA(AR) exchange 5009 and to perpetuate the process is left as an implementation detail. 5011 One possible strategy may be to monitor the NCE watching for data 5012 packets for (ReachableTime - 5) seconds. If any data packets have 5013 been sent to the neighbor within this timeframe, then send an NS(AR) 5014 to receive a new NA(AR). If no data packets have been sent, wait for 5015 5 additional seconds and send an immediate NS(AR) if any data packets 5016 are sent within this "expiration pending" 5 second window. If no 5017 additional data packets are sent within the 5 second window, reset 5018 the NCE state to STALE. 5020 The monitoring of the neighbor data packet traffic therefore becomes 5021 an ongoing process during the NCE lifetime. If the NCE expires, 5022 future data packets will trigger a new NS/NA(AR) exchange while the 5023 packets themselves are delivered over a longer path until route 5024 optimization state is re-established. 5026 A.2. Implicit Mobility Management 5028 OMNI interface neighbors MAY provide a configuration option that 5029 allows them to perform implicit mobility management in which no IPv6 5030 ND messaging is used. In that case, the Client only transmits 5031 packets over a single interface at a time, and the neighbor always 5032 observes packets arriving from the Client from the same link-layer 5033 source address. 5035 If the Client's underlay interface address changes (either due to a 5036 readdressing of the original interface or switching to a new 5037 interface) the neighbor immediately updates the NCE for the Client 5038 and begins accepting and sending packets according to the Client's 5039 new address. This implicit mobility method applies to use cases such 5040 as cellphones with both WiFi and Cellular interfaces where only one 5041 of the interfaces is active at a given time, and the Client 5042 automatically switches over to the backup interface if the primary 5043 interface fails. 5045 A.3. Direct Underlying Interfaces 5047 When a Client's OMNI interface is configured over a Direct interface, 5048 the neighbor at the other end of the Direct link can receive packets 5049 without any encapsulation. In that case, the Client sends packets 5050 over the Direct link according to traffic selectors. If the Direct 5051 interface is selected, then the Client's IP packets are transmitted 5052 directly to the peer without going through an ANET/INET. If other 5053 interfaces are selected, then the Client's IP packets are transmitted 5054 via a different interface, which may result in the inclusion of 5055 Proxy/Servers and Gateways in the communications path. Direct 5056 interfaces must be tested periodically for reachability, e.g., via 5057 NUD. 5059 A.4. AERO Critical Infrastructure Considerations 5061 AERO Gateways can be either Commercial off-the Shelf (COTS) standard 5062 IP routers or virtual machines in the cloud. Gateways must be 5063 provisioned, supported and managed by the INET administrative 5064 authority, and connected to the Gateways of other INETs via inter- 5065 domain peerings. Cost for purchasing, configuring and managing 5066 Gateways is nominal even for very large OMNI links. 5068 AERO INET Proxy/Servers can be standard dedicated server platforms, 5069 but most often will be deployed as virtual machines in the cloud. 5070 The only requirements for INET Proxy/Servers are that they can run 5071 the AERO/OMNI code and have at least one network interface connection 5072 to the INET. INET Proxy/Servers must be provisioned, supported and 5073 managed by the INET administrative authority. Cost for purchasing, 5074 configuring and managing cloud Proxy/Servers is nominal especially 5075 for virtual machines. 5077 AERO ANET Proxy/Servers are most often standard dedicated server 5078 platforms with one underlay interface connected to the ANET and a 5079 second interface connected to an INET. As with INET Proxy/Servers, 5080 the only requirements are that they can run the AERO/OMNI code and 5081 have at least one interface connection to the INET. ANET Proxy/ 5082 Servers must be provisioned, supported and managed by the ANET 5083 administrative authority. Cost for purchasing, configuring and 5084 managing Proxys is nominal, and borne by the ANET administrative 5085 authority. 5087 AERO Relays are simply Proxy/Servers connected to INETs and/or ENETs 5088 that provide forwarding services for non-MNP destinations. The Relay 5089 connects to the OMNI link and engages in eBGP peering with one or 5090 more Gateways as a stub AS. The Relay then injects its MNPs and/or 5091 non-MNP prefixes into the BGP routing system, and provisions the 5092 prefixes to its downstream-attached networks. The Relay can perform 5093 ARS/ARR services the same as for any Proxy/Server, and can route 5094 between the MNP and non-MNP address spaces. 5096 A.5. AERO Server Failure Implications 5098 AERO Proxy/Servers may appear as a single point of failure in the 5099 architecture, but such is not the case since all Proxy/Servers on the 5100 link provide identical services and loss of a Proxy/Server does not 5101 imply immediate and/or comprehensive communication failures. Proxy/ 5102 Server failure is quickly detected and conveyed by Bidirectional 5103 Forward Detection (BFD) and/or proactive NUD allowing Clients to 5104 migrate to new Proxy/Servers. 5106 If a Proxy/Server fails, ongoing packet forwarding to Clients will 5107 continue by virtue of the neighbor cache entries that have already 5108 been established through address resolution and route optimization. 5109 If a Client also experiences mobility events at roughly the same time 5110 the Proxy/Server fails, uNA messages may be lost but neighbor cache 5111 entries in the DEPARTED state will ensure that packet forwarding to 5112 the Client's new locations will continue for up to DepartTime 5113 seconds. 5115 If a Client is left without a Proxy/Server for a considerable length 5116 of time (e.g., greater than ReachableTime seconds) then existing 5117 neighbor cache entries will eventually expire and both ongoing and 5118 new communications will fail. The original source will continue to 5119 retransmit until the Client has established a new Proxy/Server 5120 relationship, after which time continuous communications will resume. 5122 Therefore, providing many Proxy/Servers on the link with high 5123 availability profiles provides resilience against loss of individual 5124 Proxy/Servers and assurance that Clients can establish new Proxy/ 5125 Server relationships quickly in event of a Proxy/Server failure. 5127 A.6. AERO Client / Server Architecture 5129 The AERO architectural model is client / server in the control plane, 5130 with route optimization in the data plane. The same as for common 5131 Internet services, the AERO Client discovers the addresses of AERO 5132 Proxy/Servers and connects to one or more of them. The AERO service 5133 is analogous to common Internet services such as google.com, 5134 yahoo.com, cnn.com, etc. However, there is only one AERO service for 5135 the link and all Proxy/Servers provide identical services. 5137 Common Internet services provide differing strategies for advertising 5138 server addresses to clients. The strategy is conveyed through the 5139 DNS resource records returned in response to name resolution queries. 5140 As of January 2020 Internet-based 'nslookup' services were used to 5141 determine the following: 5143 * When a client resolves the domainname "google.com", the DNS always 5144 returns one A record (i.e., an IPv4 address) and one AAAA record 5145 (i.e., an IPv6 address). The client receives the same addresses 5146 each time it resolves the domainname via the same DNS resolver, 5147 but may receive different addresses when it resolves the 5148 domainname via different DNS resolvers. But, in each case, 5149 exactly one A and one AAAA record are returned. 5151 * When a client resolves the domainname "ietf.org", the DNS always 5152 returns one A record and one AAAA record with the same addresses 5153 regardless of which DNS resolver is used. 5155 * When a client resolves the domainname "yahoo.com", the DNS always 5156 returns a list of 4 A records and 4 AAAA records. Each time the 5157 client resolves the domainname via the same DNS resolver, the same 5158 list of addresses are returned but in randomized order (i.e., 5159 consistent with a DNS round-robin strategy). But, interestingly, 5160 the same addresses are returned (albeit in randomized order) when 5161 the domainname is resolved via different DNS resolvers. 5163 * When a client resolves the domainname "amazon.com", the DNS always 5164 returns a list of 3 A records and no AAAA records. As with 5165 "yahoo.com", the same three A records are returned from any 5166 worldwide Internet connection point in randomized order. 5168 The above example strategies show differing approaches to Internet 5169 resilience and service distribution offered by major Internet 5170 services. The Google approach exposes only a single IPv4 and a 5171 single IPv6 address to clients. Clients can then select whichever IP 5172 protocol version offers the best response, but will always use the 5173 same IP address according to the current Internet connection point. 5174 This means that the IP address offered by the network must lead to a 5175 highly-available server and/or service distribution point. In other 5176 words, resilience is predicated on high availability within the 5177 network and with no client-initiated failovers expected (i.e., it is 5178 all-or-nothing from the client's perspective). However, Google does 5179 provide for worldwide distributed service distribution by virtue of 5180 the fact that each Internet connection point responds with a 5181 different IPv6 and IPv4 address. The IETF approach is like google 5182 (all-or-nothing from the client's perspective), but provides only a 5183 single IPv4 or IPv6 address on a worldwide basis. This means that 5184 the addresses must be made highly-available at the network level with 5185 no client failover possibility, and if there is any worldwide service 5186 distribution it would need to be conducted by a network element that 5187 is reached via the IP address acting as a service distribution point. 5189 In contrast to the Google and IETF philosophies, Yahoo and Amazon 5190 both provide clients with a (short) list of IP addresses with Yahoo 5191 providing both IP protocol versions and Amazon as IPv4-only. The 5192 order of the list is randomized with each name service query 5193 response, with the effect of round-robin load balancing for service 5194 distribution. With a short list of addresses, there is still 5195 expectation that the network will implement high availability for 5196 each address but in case any single address fails the client can 5197 switch over to using a different address. The balance then becomes 5198 one of function in the network vs function in the end system. 5200 The same implications observed for common highly-available services 5201 in the Internet apply also to the AERO client/server architecture. 5202 When an AERO Client connects to one or more ANETs, it discovers one 5203 or more AERO Proxy/Server addresses through the mechanisms discussed 5204 in earlier sections. Each Proxy/Server address presumably leads to a 5205 fault-tolerant clustering arrangement such as supported by Linux-HA, 5206 Extended Virtual Synchrony or Paxos. Such an arrangement has 5207 precedence in common Internet service deployments in lightweight 5208 virtual machines without requiring expensive hardware deployment. 5209 Similarly, common Internet service deployments set service IP 5210 addresses on service distribution points that may relay requests to 5211 many different servers. 5213 For AERO, the expectation is that a combination of the Google/IETF 5214 and Yahoo/Amazon philosophies would be employed. The AERO Client 5215 connects to different ANET access points and can receive 1-2 Proxy/ 5216 Server ULAs at each point. It then selects one AERO Proxy/Server 5217 address, and engages in RS/RA exchanges with the same Proxy/Server 5218 from all ANET connections. The Client remains with this Proxy/Server 5219 unless or until the Proxy/Server fails, in which case it can switch 5220 over to an alternate Proxy/Server. The Client can likewise switch 5221 over to a different Proxy/Server at any time if there is some reason 5222 for it to do so. So, the AERO expectation is for a balance of 5223 function in the network and end system, with fault tolerance and 5224 resilience at both levels. 5226 Appendix B. Change Log 5228 << RFC Editor - remove prior to publication >> 5230 Changes from earlier versions: 5232 * Submit for RFC publication. 5234 Author's Address 5236 Fred L. Templin (editor) 5237 Boeing Research & Technology 5238 P.O. Box 3707 5239 Seattle, WA 98124 5240 United States of America 5241 Email: fltemplin@acm.org