idnits 2.17.1 draft-templin-6man-aero-14.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 (June 9, 2021) is 1052 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ULA' is mentioned on line 1195, but not defined == Missing Reference: 'ULA0' is mentioned on line 1195, but not defined == Missing Reference: 'ULA1' is mentioned on line 1195, but not defined == Missing Reference: 'ULA2' is mentioned on line 1195, but not defined == Unused Reference: 'RFC3971' is defined on line 3968, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 3973, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 3981, but no explicit reference was found in the text == Unused Reference: 'RFC7739' is defined on line 4009, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 4030, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-comp-rtg-hdr' is defined on line 4033, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-crh-helper-opt' is defined on line 4039, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-frag-fragile' is defined on line 4044, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-dhcpv6-ndopt' is defined on line 4067, but no explicit reference was found in the text == Unused Reference: 'OVPN' is defined on line 4096, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 4106, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 4127, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 4131, but no explicit reference was found in the text == Unused Reference: 'RFC4122' is defined on line 4145, but no explicit reference was found in the text == Unused Reference: 'RFC4982' is defined on line 4194, but no explicit reference was found in the text == Unused Reference: 'RFC6139' is defined on line 4236, but no explicit reference was found in the text == Unused Reference: 'RFC6273' is defined on line 4256, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 4265, but no explicit reference was found in the text == Unused Reference: 'RFC6438' is defined on line 4270, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 4279, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 4284, but no explicit reference was found in the text == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-03 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-24 == Outdated reference: A later version (-04) exists of draft-bonica-6man-crh-helper-opt-03 == 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-20 == Outdated reference: A later version (-26) exists of draft-ietf-rtgwg-atn-bgp-10 -- 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 (~~), 32 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational June 9, 2021 5 Expires: December 11, 2021 7 Asymmetric Extended Route Optimization (AERO) 8 draft-templin-6man-aero-14 10 Abstract 12 This document specifies an Asymmetric Extended Route Optimization 13 (AERO) service for IP internetworking over Overlay Multilink Network 14 (OMNI) interfaces. AERO/OMNI use an IPv6 link-local address format 15 that supports operation of the IPv6 Neighbor Discovery (ND) protocol 16 and links ND to IP forwarding. Prefix delegation/registration 17 services are employed for network admission and to manage the routing 18 system. Secure multilink operation, mobility management, multicast, 19 traffic selector signaling and route optimization are naturally 20 supported through dynamic neighbor cache updates. AERO is a widely- 21 applicable mobile internetworking service especially well-suited to 22 aviation services, intelligent transportation systems, mobile Virtual 23 Private Networks (VPNs) and many 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 December 11, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 13 62 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 13 63 3.2. The AERO Service over OMNI Links . . . . . . . . . . . . 14 64 3.2.1. AERO/OMNI Reference Model . . . . . . . . . . . . . . 14 65 3.2.2. Addressing and Node Identification . . . . . . . . . 17 66 3.2.3. AERO Routing System . . . . . . . . . . . . . . . . . 18 67 3.2.4. OMNI Link Segment Routing . . . . . . . . . . . . . . 20 68 3.2.5. Segment Routing Topologies (SRTs) . . . . . . . . . . 26 69 3.2.6. Segment Routing For OMNI Link Selection . . . . . . . 26 70 3.2.7. Segment Routing Within the OMNI Link . . . . . . . . 27 71 3.3. OMNI Interface Characteristics . . . . . . . . . . . . . 29 72 3.4. OMNI Interface Initialization . . . . . . . . . . . . . . 31 73 3.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 31 74 3.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 32 75 3.4.3. AERO Bridge Behavior . . . . . . . . . . . . . . . . 32 76 3.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 32 77 3.5.1. OMNI ND Messages . . . . . . . . . . . . . . . . . . 34 78 3.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 36 79 3.5.3. OMNI Neighbor Window Synchronization . . . . . . . . 36 80 3.6. OMNI Interface Encapsulation and Re-encapsulation . . . . 37 81 3.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 37 82 3.8. OMNI Interface Data Origin Authentication . . . . . . . . 38 83 3.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 38 84 3.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 39 85 3.10.1. Client Forwarding Algorithm . . . . . . . . . . . . 40 86 3.10.2. Proxy/Server and Relay Forwarding Algorithm . . . . 42 87 3.10.3. Bridge Forwarding Algorithm . . . . . . . . . . . . 44 88 3.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 46 89 3.12. AERO Router Discovery, Prefix Delegation and 90 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 49 91 3.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 49 92 3.12.2. AERO Client Behavior . . . . . . . . . . . . . . . . 49 93 3.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 51 94 3.13. The AERO Proxy Function . . . . . . . . . . . . . . . . . 54 95 3.13.1. Detecting and Responding to Proxy/Server Failures . 57 96 3.13.2. Point-to-Multipoint Proxy/Server Coordination . . . 58 98 3.14. AERO Route Optimization . . . . . . . . . . . . . . . . . 59 99 3.14.1. Route Optimization Initiation . . . . . . . . . . . 60 100 3.14.2. Relaying the NS(AR) *NET Packet(s) . . . . . . . . . 61 101 3.14.3. Processing the NS(AR) and Sending the NA(AR) . . . . 61 102 3.14.4. Relaying the NA(AR) . . . . . . . . . . . . . . . . 62 103 3.14.5. Processing the NA(AR) . . . . . . . . . . . . . . . 62 104 3.14.6. Forwarding Packets to Route Optimized Targets . . . 63 105 3.15. Neighbor Unreachability Detection (NUD) . . . . . . . . . 66 106 3.16. Mobility Management and Quality of Service (QoS) . . . . 67 107 3.16.1. Mobility Update Messaging . . . . . . . . . . . . . 68 108 3.16.2. Announcing Link-Layer Address and/or QoS Preference 109 Changes . . . . . . . . . . . . . . . . . . . . . . 69 110 3.16.3. Bringing New Links Into Service . . . . . . . . . . 70 111 3.16.4. Deactivating Existing Links . . . . . . . . . . . . 70 112 3.16.5. Moving Between Proxy/Servers . . . . . . . . . . . . 70 113 3.17. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 72 114 3.17.1. Source-Specific Multicast (SSM) . . . . . . . . . . 72 115 3.17.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 73 116 3.17.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 74 117 3.18. Operation over Multiple OMNI Links . . . . . . . . . . . 74 118 3.19. DNS Considerations . . . . . . . . . . . . . . . . . . . 75 119 3.20. Transition/Coexistence Considerations . . . . . . . . . . 75 120 3.21. Detecting and Reacting to Proxy/Server and Bridge 121 Failures . . . . . . . . . . . . . . . . . . . . . . . . 76 122 3.22. AERO Clients on the Open Internet . . . . . . . . . . . . 76 123 3.23. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 79 124 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 79 125 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 126 6. Security Considerations . . . . . . . . . . . . . . . . . . . 80 127 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 128 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 129 8.1. Normative References . . . . . . . . . . . . . . . . . . 83 130 8.2. Informative References . . . . . . . . . . . . . . . . . 85 131 Appendix A. Non-Normative Considerations . . . . . . . . . . . . 91 132 A.1. Implementation Strategies for Route Optimization . . . . 91 133 A.2. Implicit Mobility Management . . . . . . . . . . . . . . 92 134 A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 92 135 A.4. AERO Critical Infrastructure Considerations . . . . . . . 93 136 A.5. AERO Server Failure Implications . . . . . . . . . . . . 93 137 A.6. AERO Client / Server Architecture . . . . . . . . . . . . 94 138 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 96 139 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 98 141 1. Introduction 143 Asymmetric Extended Route Optimization (AERO) fulfills the 144 requirements of Distributed Mobility Management (DMM) [RFC7333] and 145 route optimization [RFC5522] for aeronautical networking and other 146 network mobility use cases including intelligent transportation 147 systems and enterprise mobile device users. AERO is a secure 148 internetworking and mobility management service that employs the 149 Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] 150 Non-Broadcast, Multiple Access (NBMA) virtual link model. The OMNI 151 link is a virtual overlay configured over one or more underlying 152 Internetworks, and nodes on the link can exchange original IP packets 153 as single-hop neighbors. The OMNI Adaptation Layer (OAL) supports 154 end system multilink operation for increased reliability, bandwidth 155 optimization and traffic path selection while performing 156 fragmentation and reassembly to support Internetwork segment routing 157 and Maximum Transmission Unit (MTU) diversity. In terms of 158 precedence, readers may appreciate reading the AERO specification 159 first to gain an understanding of the overall architecture and 160 mobility services then return to the OMNI specification for a deeper 161 analysis of the NBMA link model. 163 The AERO service comprises Clients, Proxy/Servers and Relays that are 164 seen as OMNI link neighbors as well as Bridges that interconnect 165 diverse Internetworks as OMNI link segments through OAL forwarding at 166 a layer below IP. Each node's OMNI interface uses an IPv6 link-local 167 address format that supports operation of the IPv6 Neighbor Discovery 168 (ND) protocol [RFC4861] and links ND to IP forwarding. A node's OMNI 169 interface can be configured over multiple underlying interfaces, and 170 therefore appears as a single interface with multiple link-layer 171 addresses. Each link-layer address is subject to change due to 172 mobility and/or multilink fluctuations, and link-layer address 173 changes are signaled by ND messaging the same as for any IPv6 link. 175 AERO provides a secure cloud-based service where mobile node Clients 176 may use any Proxy/Server acting as a Mobility Anchor Point (MAP) and 177 fixed nodes may use any Relay on the link for efficient 178 communications. Fixed nodes forward original IP packets destined to 179 other AERO nodes via the nearest Relay, which forwards them through 180 the cloud. A mobile node's initial packets are forwarded through the 181 Proxy/Server, and direct routing is supported through route 182 optimization while packets are flowing. Both unicast and multicast 183 communications are supported, and mobile nodes may efficiently move 184 between locations while maintaining continuous communications with 185 correspondents and without changing their IP Address. 187 AERO Bridges peer with Proxy/Servers in a secured private BGP overlay 188 routing instance to provide a Segment Routing Topology (SRT) that 189 allows the OAL to span the underlying Internetworks of multiple 190 disjoint administrative domains as a single unified OMNI link at a 191 layer below IP. Each OMNI link instance is characterized by the set 192 of Mobility Service Prefixes (MSPs) common to all mobile nodes. 193 Relays provide an optimal route from (fixed) correspondent nodes on 194 the underlying Internetwork to (mobile or fixed) nodes on the OMNI 195 link. To the underlying Internetwork, the Relay is the source of a 196 route to the MSP; hence uplink traffic to the mobile node is 197 naturally routed to the nearest Relay. A Relay can be considered as 198 a simple case of a Proxy/Server that provides only forwarding and not 199 proxying services. 201 AERO can be used with OMNI links that span private-use Internetworks 202 and/or public Internetworks such as the global Internet. In the 203 latter case, some end systems may be located behind global Internet 204 Network Address Translators (NATs). A means for robust traversal of 205 NATs while avoiding "triangle routing" and Proxy/Server traffic 206 concentration is therefore provided. 208 AERO assumes the use of PIM Sparse Mode in support of multicast 209 communication. In support of Source Specific Multicast (SSM) when a 210 Mobile Node is the source, AERO route optimization ensures that a 211 shortest-path multicast tree is established with provisions for 212 mobility and multilink operation. In all other multicast scenarios 213 there are no AERO dependencies. 215 AERO was designed as a secure aeronautical internetworking service 216 for both manned and unmanned aircraft, where the aircraft is treated 217 as a mobile node that can connect an Internet of Things (IoT). AERO 218 is also applicable to a wide variety of other use cases. For 219 example, it can be used to coordinate the links of mobile nodes 220 (e.g., cellphones, tablets, laptop computers, etc.) that connect into 221 a home enterprise network via public access networks with VPN or non- 222 VPN services enabled according to the appropriate security model. 223 AERO can also be used to facilitate terrestrial vehicular and urban 224 air mobility (as well as pedestrian communication services) for 225 future intelligent transportation systems 226 [I-D.ietf-ipwave-vehicular-networking][I-D.templin-ipwave-uam-its]. 227 Other applicable use cases are also in scope. 229 Along with OMNI, AERO provides secured optimal routing support for 230 the "6M's" of modern Internetworking, including: 232 1. Multilink - a mobile node's ability to coordinate multiple 233 diverse underlying data links as a single logical unit (i.e., the 234 OMNI interface) to achieve the required communications 235 performance and reliability objectives. 237 2. Multinet - the ability to span the OMNI link over a segment 238 routing topology with multiple diverse network administrative 239 domains while maintaining seamless end-to-end communications 240 between mobile Clients and correspondents such as air traffic 241 controllers, fleet administrators, etc. 243 3. Mobility - a mobile node's ability to change network points of 244 attachment (e.g., moving between wireless base stations) which 245 may result in an underlying interface address change, but without 246 disruptions to ongoing communication sessions with peers over the 247 OMNI link. 249 4. Multicast - the ability to send a single network transmission 250 that reaches multiple nodes belonging to the same interest group, 251 but without disturbing other nodes not subscribed to the interest 252 group. 254 5. Multihop - a mobile node vehicle-to-vehicle relaying capability 255 useful when multiple forwarding hops between vehicles may be 256 necessary to "reach back" to an infrastructure access point 257 connection to the OMNI link. 259 6. MTU assurance - the ability to deliver packets of various robust 260 sizes between peers without loss due to a link size restriction, 261 and to dynamically adjust packets sizes to achieve the optimal 262 performance for each independent traffic flow. 264 The following numbered sections present the AERO specification. The 265 appendices at the end of the document are non-normative. 267 2. Terminology 269 The terminology in the normative references applies; especially, the 270 terminology in the OMNI specification [I-D.templin-6man-omni] is used 271 extensively throughout. The following terms are defined within the 272 scope of this document: 274 IPv6 Neighbor Discovery (ND) 275 a control message service for coordinating neighbor relationships 276 between nodes connected to a common link. AERO uses the IPv6 ND 277 messaging service specified in [RFC4861]. 279 IPv6 Prefix Delegation 280 a networking service for delegating IPv6 prefixes to nodes on the 281 link. The nominal service is DHCPv6 [RFC8415], however alternate 282 services (e.g., based on ND messaging) are also in scope. A 283 minimal form of prefix delegation known as "prefix registration" 284 can be used if the Client knows its prefix in advance and can 285 represent it in the IPv6 source address of an ND message. 287 Access Network (ANET) 288 a node's first-hop data link service network (e.g., a radio access 289 network, cellular service provider network, corporate enterprise 290 network, etc.) that often provides link-layer security services 291 such as IEEE 802.1X and physical-layer security (e.g., "protected 292 spectrum") to prevent unauthorized access internally and with 293 border network-layer security services such as firewalls and 294 proxys that prevent unauthorized outside access. 296 ANET interface 297 a node's attachment to a link in an ANET. 299 Internetwork (INET) 300 a connected IP network topology with a coherent routing and 301 addressing plan and that provides a transit backbone service for 302 ANET end systems. INETs also provide an underlay service over 303 which the AERO virtual link is configured. Example INETs include 304 corporate enterprise networks, aviation networks, and the public 305 Internet itself. When there is no administrative boundary between 306 an ANET and the INET, the ANET and INET are one and the same. 308 INET interface 309 a node's attachment to a link in an INET. 311 *NET 312 a "wildcard" term referring to either ANET or INET when it is not 313 necessary to draw a distinction between the two. 315 *NET interface 316 a node's attachment to a link in a *NET. 318 *NET Partition 319 frequently, *NETs such as large corporate enterprise networks are 320 sub-divided internally into separate isolated partitions (a 321 technique also known as "network segmentation"). Each partition 322 is fully connected internally but disconnected from other 323 partitions, and there is no requirement that separate partitions 324 maintain consistent Internet Protocol and/or addressing plans. 325 (Each *NET partition is seen as a separate OMNI link segment as 326 discussed below.) 328 *NET address 329 an IP address assigned to a node's interface connection to a *NET. 331 *NET encapsulation 332 the encapsulation of a packet in an outer header or headers that 333 can be routed within the scope of the local *NET partition. 335 OMNI link 336 the same as defined in [I-D.templin-6man-omni], and manifested by 337 IPv6 encapsulation [RFC2473]. The OMNI link spans underlying *NET 338 segments joined by virtual bridges in a spanning tree the same as 339 a bridged campus LAN. AERO nodes on the OMNI link appear as 340 single-hop neighbors at the network layer even though they may be 341 separated by multiple underlying *NET hops, and can use Segment 342 Routing [RFC8402] to cause packets to visit selected waypoints on 343 the link. 345 OMNI Interface 346 a node's attachment to an OMNI link. Since OMNI interface 347 addresses are managed for uniqueness, OMNI interfaces do not 348 require Duplicate Address Detection (DAD) and therefore set the 349 administrative variable 'DupAddrDetectTransmits' to zero 350 [RFC4862]. 352 OMNI Adaptation Layer (OAL) 353 an OMNI interface process whereby original IP packets admitted 354 into the interface are wrapped in a mid-layer IPv6 header and 355 subject to fragmentation and reassembly. The OAL is also 356 responsible for generating MTU-related control messages as 357 necessary, and for providing addressing context for spanning 358 multiple segments of a bridged OMNI link. 360 original IP packet 361 a whole IP packet or fragment admitted into the OMNI interface by 362 the network layer prior to OAL encapsulation and fragmentation, or 363 an IP packet delivered to the network layer by the OMNI interface 364 following OAL decapsulation and reassembly. 366 OAL packet 367 an original IP packet encapsulated in OAL headers and trailers 368 before OAL fragmentation, or following OAL reassembly. 370 OAL fragment 371 a portion of an OAL packet following fragmentation but prior to 372 *NET encapsulation, or following *NET encapsulation but prior to 373 OAL reassembly. 375 (OAL) atomic fragment 376 an OAL packet that does not require fragmentation is always 377 encapsulated as an "atomic fragment" and includes a Fragment 378 Header with Fragment Offset and More Fragments both set to 0, but 379 with a valid Identification value. 381 (OAL) carrier packet 382 an encapsulated OAL fragment following *NET encapsulation or prior 383 to *NET decapsulation. OAL sources and destinations exchange 384 carrier packets over underlying interfaces, and may be separated 385 by one or more OAL intermediate nodes. OAL intermediate nodes re- 386 encapsulate carrier packets during forwarding by removing the *NET 387 headers of the previous hop underlying network and replacing them 388 with new *NET headers for the next hop underlying network. 390 OAL source 391 an OMNI interface acts as an OAL source when it encapsulates 392 original IP packets to form OAL packets, then performs OAL 393 fragmentation and *NET encapsulation to create carrier packets. 395 OAL destination 396 an OMNI interface acts as an OAL destination when it decapsulates 397 carrier packets, then performs OAL reassembly and decapsulation to 398 derive the original IP packet. 400 OAL intermediate node 401 an OMNI interface acts as an OAL intermediate node when it removes 402 the *NET headers of carrier packets received on a first segment, 403 then re-encapsulates the carrier packets in new *NET headers and 404 forwards them into the next segment. OAL intermediate nodes 405 decrement the Hop Limit of the OAL IPv6 header during re- 406 encapsulation, and discard the packet if the Hop Limit reaches 0. 407 OAL intermediate nodes do not decrement the Hop Limit/TTL of the 408 original IP packet. 410 underlying interface 411 a *NET interface over which an OMNI interface is configured. 413 Mobility Service Prefix (MSP) 414 an aggregated IP Global Unicast Address (GUA) prefix (e.g., 415 2001:db8::/32, 192.0.2.0/24, etc.) assigned to the OMNI link and 416 from which more-specific Mobile Network Prefixes (MNPs) are 417 delegated. OMNI link administrators typically obtain MSPs from an 418 Internet address registry, however private-use prefixes can 419 alternatively be used subject to certain limitations (see: 420 [I-D.templin-6man-omni]). OMNI links that connect to the global 421 Internet advertise their MSPs to their interdomain routing peers. 423 Mobile Network Prefix (MNP) 424 a longer IP prefix delegated from an MSP (e.g., 425 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and delegated to an 426 AERO Client or Relay. 428 Mobile Network Prefix Link Local Address (MNP-LLA) 429 an IPv6 Link Local Address that embeds the most significant 64 430 bits of an MNP in the lower 64 bits of fe80::/64, as specified in 431 [I-D.templin-6man-omni]. 433 Mobile Network Prefix Unique Local Address (MNP-ULA) 434 an IPv6 Unique-Local Address derived from an MNP-LLA. 436 Administrative Link Local Address (ADM-LLA) 437 an IPv6 Link Local Address that embeds a 32-bit administratively- 438 assigned identification value in the lower 32 bits of fe80::/96, 439 as specified in [I-D.templin-6man-omni]. 441 Administrative Unique Local Address (ADM-ULA) 442 an IPv6 Unique-Local Address derived from an ADM-LLA. 444 AERO node 445 a node that is connected to an OMNI link and participates in the 446 AERO internetworking and mobility service. 448 AERO Client ("Client") 449 an AERO node that connects over one or more underlying interfaces 450 and requests MNP delegation/registration service from AERO Proxy/ 451 Servers. The Client assigns an MNP-LLA to the OMNI interface for 452 use in ND exchanges with other AERO nodes and forwards original IP 453 packets to correspondents according to OMNI interface neighbor 454 cache state. 456 AERO Proxy/Server ("Proxy/Server") 457 a dual-function node that provides a proxying service between AERO 458 Clients and external peers on its Client-facing ANET interfaces 459 (i.e., in the same fashion as for an enterprise network proxy) as 460 well as default forwarding and Mobility Anchor Point (MAP) 461 services for coordination with correspondents on its INET-facing 462 interfaces. (Proxy/Servers in the open INET instead configure 463 only an INET interface and no ANET interfaces.) The Proxy/Server 464 configures an OMNI interface and assigns an ADM-LLA to support the 465 operation of IPv6 ND services, while advertising all of its 466 associated MNPs via BGP peerings with Bridges. Note that the 467 Proxy and Server functions can be considered logically separable, 468 but since each Proxy/Server must be informed of all of the 469 Client's other multilink Proxy/Server affiliations the AERO 470 service is best supported when the two functions are coresident on 471 the same physical or logical platform. 473 AERO Relay ("Relay") 474 a Proxy/Server that provides forwarding services between nodes 475 reached via the OMNI link and correspondents on connected 476 downstream links. AERO Relays configure an OMNI interface and 477 assign an ADM-LLA the same as Proxy/Servers. AERO Relays also run 478 a dynamic routing protocol to discover any non-MNP IP GUA routes 479 in service on its connected downstream network links. In both 480 cases, the Relay advertises the MSP(s) to its downstream networks, 481 and distributes all of its associated non-MNP IP GUA routes via 482 BGP peerings with Bridges (i.e., the same as for Proxy/Servers). 484 AERO Bridge ("Bridge") 485 a node that provides OAL forwarding services (as well as a 486 security trust anchor) for nodes on an OMNI link. The Bridge 487 forwards carrier packets between OMNI link segments as OAL 488 intermediate nodes while decrementing the OAL IPv6 header Hop 489 Limit but without decrementing the network layer IP TTL/Hop Limit. 490 AERO Bridges peer with Proxy/Servers and other Bridges over 491 secured tunnels to discover the full set of MNPs for the link as 492 well as any non-MNP IP GUA routes that are reachable via Relays. 494 First-Hop Segment (FHS) Proxy/Server 495 a Proxy/Server for an underlying interface of the source Client 496 that forwards packets sent by the source Client over that 497 interface into the segment routing topology. 499 Last-Hop Segment (LHS) Proxy/Server 500 a Proxy/Server for an underlying interface of the target Client 501 that forwards packets received from the segment routing topology 502 to the target Client over that interface. 504 Segment Routing Topology (SRT) 505 a multinet forwarding region between the FHS Proxy/Server and LHS 506 Proxy/Server. FHS/LHS Proxy/Servers and SRT Bridges span the OMNI 507 link on behalf of source/target Client pairs. The SRT maintains a 508 spanning tree established through BGP peerings between Bridges and 509 Proxy/Servers. Each SRT segment includes Bridges in a "hub" and 510 Proxy/Servers in "spokes", while adjacent segments are 511 interconnected by Bridge-Bridge peerings. The BGP peerings are 512 configured over both secured and unsecured underlying network 513 paths such that a secured spanning tree is available for critical 514 control messages while other messages can use the unsecured 515 spanning tree. 517 link-layer address 518 an IP address used as an encapsulation header source or 519 destination address from the perspective of the OMNI interface. 520 When an upper layer protocol (e.g., UDP) is used as part of the 521 encapsulation, the port number is also considered as part of the 522 link-layer address. 524 network layer address 525 the source or destination address of an original IP packet 526 presented to the OMNI interface. 528 end user network (EUN) 529 an internal virtual or external edge IP network that an AERO 530 Client or Relay connects to the rest of the network via the OMNI 531 interface. The Client/Relay sees each EUN as a "downstream" 532 network, and sees the OMNI interface as the point of attachment to 533 the "upstream" network. 535 Mobile Node (MN) 536 an AERO Client and all of its downstream-attached networks that 537 move together as a single unit, i.e., an end system that connects 538 an Internet of Things. 540 Mobile Router (MR) 541 a MN's on-board router that forwards original IP packets between 542 any downstream-attached networks and the OMNI link. The MR is the 543 MN entity that hosts the AERO Client. 545 Route Optimization Source (ROS) 546 the AERO node nearest the source that initiates route 547 optimization. The ROS may be a FHS Proxy/Server or Relay for the 548 source, or may be the source Client itself. 550 Route Optimization responder (ROR) 551 the AERO node that responds to route optimization requests on 552 behalf of the target. The ROR may be an LHS Proxy/Server for a 553 target MNP Client or an LHS Relay for a non-MNP target. 555 MAP List 556 a geographically and/or topologically referenced list of addresses 557 of all Proxy/Servers within the same OMNI link. Each OMNI link 558 has its own MAP list. 560 Distributed Mobility Management (DMM) 561 a BGP-based overlay routing service coordinated by Proxy/Servers 562 and Bridges that tracks all Proxy/Server-to-Client associations. 564 Mobility Service (MS) 565 the collective set of all Proxy/Servers, Bridges and Relays that 566 provide the AERO Service to Clients. 568 Mobility Service Endpoint MSE) 569 an individual Proxy/Server, Bridge or Relay in the Mobility 570 Service. 572 Throughout the document, the simple terms "Client", "Proxy/Server", 573 "Bridge" and "Relay" refer to "AERO Client", "AERO Proxy/Server", 574 "AERO Bridge" and "AERO Relay", respectively. Capitalization is used 575 to distinguish these terms from other common Internetworking uses in 576 which they appear without capitalization. 578 The terminology of IPv6 ND [RFC4861] and DHCPv6 [RFC8415] (including 579 the names of node variables, messages and protocol constants) is used 580 throughout this document. The terms "All-Routers multicast", "All- 581 Nodes multicast", "Solicited-Node multicast" and "Subnet-Router 582 anycast" are defined in [RFC4291]. Also, the term "IP" is used to 583 generically refer to either Internet Protocol version, i.e., IPv4 584 [RFC0791] or IPv6 [RFC8200]. 586 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 587 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 588 "OPTIONAL" in this document are to be interpreted as described in BCP 589 14 [RFC2119][RFC8174] when, and only when, they appear in all 590 capitals, as shown here. 592 3. Asymmetric Extended Route Optimization (AERO) 594 The following sections specify the operation of IP over OMNI links 595 using the AERO service: 597 3.1. AERO Node Types 599 AERO Clients are Mobile Nodes (MNs) that configure OMNI interfaces 600 over underlying interfaces with addresses that may change when the 601 Client moves to a new network connection point. AERO Clients 602 register their Mobile Network Prefixes (MNPs) with the AERO service, 603 and distribute the MNPs to nodes on EUNs. AERO Bridges, Proxy/ 604 Servers and Relays are critical infrastructure elements in fixed 605 (i.e., non-mobile) INET deployments and hence have permanent and 606 unchanging INET addresses. Together, they constitute the AERO 607 service which provides an OMNI link virtual overlay for connecting 608 AERO Clients. 610 AERO Bridges (together with Proxy/Servers) provide the secured 611 backbone supporting infrastructure for a Segment Routing Topology 612 (SRT) that spans the OMNI link. Bridges forward carrier packets both 613 within the same SRT segment and between disjoint SRT segments based 614 on an IPv6 encapsulation mid-layer known as the OMNI Adaptation Layer 615 (OAL) [I-D.templin-6man-omni]. During forwarding, the inner IP layer 616 experiences a virtual bridging service since the inner IP TTL/Hop 617 Limit is not decremented. Each Bridge also peers with Proxy/Servers 618 and other Bridges in a dynamic routing protocol instance to provide a 619 Distributed Mobility Management (DMM) service for the list of active 620 MNPs (see Section 3.2.3). Bridges present the OMNI link as a set of 621 one or more Mobility Service Prefixes (MSPs) and configure secured 622 tunnels with Proxy/Servers, Relays and other Bridges; they further 623 maintain IP forwarding table entries for each MNP and any other 624 reachable non-MNP prefixes. 626 AERO Proxy/Servers in distributed SRT segments provide default 627 forwarding and mobility/multilink services for AERO Client Mobile 628 Nodes (MNs). Each Proxy/Server also peers with Bridges in a dynamic 629 routing protocol instance to advertise its list of associated MNPs 630 (see Section 3.2.3). Proxy/Servers facilitate prefix delegation/ 631 registration exchanges with Clients, where each delegated prefix 632 becomes an MNP taken from an MSP. Proxy/Servers forward carrier 633 packets between OMNI interface neighbors and track each Client's 634 mobility profiles. Proxy/Servers at ANET/INET boundaries provide a 635 conduit for ANET Clients to associate with peers reached through 636 external INETs. Proxy/Servers in the open INET support INET Clients 637 through authenticated IPv6 ND message exchanges. Source Clients 638 employ First-Hop Segment (FHS) Proxy/Servers to forward packets over 639 the SRT to Last-Hop Segment (LHS) Proxy/Servers which finally forward 640 to target Clients. 642 AERO Relays are Proxy/Servers that provide forwarding services to 643 exchange original IP packets between the OMNI interface and INET/EUN 644 interfaces. Relays are provisioned with MNPs the same as for an AERO 645 Client, and also run a dynamic routing protocol to discover any non- 646 MNP IP routes. The Relay advertises the MSP(s) to its connected 647 networks, and distributes all of its associated MNP and non-MNP 648 routes via BGP peerings with Bridges 650 3.2. The AERO Service over OMNI Links 652 3.2.1. AERO/OMNI Reference Model 654 Figure 1 presents the basic OMNI link reference model: 656 +----------------+ 657 | AERO Bridge B1 | 658 | Nbr: S1, S2, P1| 659 |(X1->S1; X2->S2)| 660 | MSP M1 | 661 +-------+--------+ 662 +--------------+ | +--------------+ 663 | AERO P/S S1 | | | AERO P/S S2 | 664 | Nbr: C1, B1 | | | Nbr: C2, B1 | 665 | default->B1 | | | default->B1 | 666 | X1->C1 | | | X2->C2 | 667 +-------+------+ | +------+-------+ 668 | OMNI link | | 669 X===+===+==================+===================+===+===X 670 | | 671 +-----+--------+ +--------+-----+ 672 |AERO Client C1| |AERO Client C2| 673 | Nbr: S1 | | Nbr: S2 | 674 | default->S1 | | default->S2 | 675 | MNP X1 | | MNP X2 | 676 +------+-------+ +-----+--------+ 677 | | 678 .-. .-. 679 ,-( _)-. ,-( _)-. 680 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 681 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 682 `-(______)-' +-------+ +-------+ `-(______)-' 684 Figure 1: AERO/OMNI Reference Model 686 In this model: 688 o the OMNI link is an overlay network service configured over one or 689 more underlying SRT segments which may be managed by different 690 administrative authorities and have incompatible protocols and/or 691 addressing plans. 693 o AERO Bridge B1 aggregates Mobility Service Prefix (MSP) M1, 694 discovers Mobile Network Prefixes (MNPs) X* and advertises the MSP 695 via BGP peerings over secured tunnels to Proxy/Servers (S1, S2). 696 Bridges provide the backbone for an SRT that spans the OMNI link. 698 o AERO Proxy/Servers S1 and S2 configure secured tunnels with Bridge 699 B1 and also provide mobility, multilink, multicast and default 700 router services for the MNPs of their associated Clients C1 and 701 C2. (Proxy/Servers that act as Relays can also advertise non-MNP 702 routes for non-mobile correspondent nodes the same as for MNP 703 Clients.) 705 o AERO Clients C1 and C2 associate with Proxy/Servers S1 and S2, 706 respectively. They receive MNP delegations X1 and X2, and also 707 act as default routers for their associated physical or internal 708 virtual EUNs. Simple hosts H1 and H2 attach to the EUNs served by 709 Clients C1 and C2, respectively. 711 An OMNI link configured over a single *NET appears as a single 712 unified link with a consistent underlying network addressing plan. 713 In that case, all nodes on the link can exchange carrier packets via 714 simple *NET encapsulation (i.e., following any necessary NAT 715 traversal), since the underlying *NET is connected. In common 716 practice, however, OMNI links are traversed by an SRT spanning tree, 717 where each segment is a distinct *NET potentially managed under a 718 different administrative authority (e.g., as for worldwide aviation 719 service providers such as ARINC, SITA, Inmarsat, etc.). Individual 720 *NETs may also themselves be partitioned internally, in which case 721 each internal partition is seen as a separate segment. 723 The addressing plan of each SRT segment is consistent internally but 724 will often bear no relation to the addressing plans of other 725 segments. Each segment is also likely to be separated from others by 726 network security devices (e.g., firewalls, proxys, packet filtering 727 gateways, etc.), and in many cases disjoint segments may not even 728 have any common physical link connections. Therefore, nodes can only 729 be assured of exchanging carrier packets directly with correspondents 730 in the same segment, and not with those in other segments. The only 731 means for joining the segments therefore is through inter-domain 732 peerings between AERO Bridges. 734 The same as for traditional campus LANs, the OMNI link SRT spans 735 multiple segments that can be joined into a single unified link using 736 the OMNI Adaptation Layer (OAL) [I-D.templin-6man-omni] which inserts 737 a mid-layer IPv6 encapsulation header that supports inter-segment 738 forwarding (i.e., bridging) without decrementing the network-layer 739 TTL/Hop Limit of the original IP packet. An example OMNI link SRT is 740 shown in Figure 2: 742 . . . . . . . . . . . . . . . . . . . . . . . 743 . . 744 . .-(::::::::) . 745 . .-(::::::::::::)-. +-+ . 746 . (:::: Segment A :::)--|B|---+ . 747 . `-(::::::::::::)-' +-+ | . 748 . `-(::::::)-' | . 749 . | . 750 . .-(::::::::) | . 751 . .-(::::::::::::)-. +-+ | . 752 . (:::: Segment B :::)--|B|---+ . 753 . `-(::::::::::::)-' +-+ | . 754 . `-(::::::)-' | . 755 . | . 756 . .-(::::::::) | . 757 . .-(::::::::::::)-. +-+ | . 758 . (:::: Segment C :::)--|B|---+ . 759 . `-(::::::::::::)-' +-+ | . 760 . `-(::::::)-' | . 761 . | . 762 . ..(etc).. x . 763 . . 764 . . 765 . <- Segment Routing Topology (SRT) -> . 766 . . . . . . . . . . . . . .. . . . . . . . . 768 Figure 2: OMNI Link Segment Routing Topology (SRT) 770 Bridges, Proxy/Servers and Relay OMNI interfaces are configured over 771 both secured tunnels and open INET underlying interfaces within their 772 respective SRT segments. Within each segment, Bridges configure 773 "hub-and-spokes" BGP peerings with Proxy/Server/Relays as "spokes". 774 Adjacent SRT segments are joined by Bridge-to-Bridge peerings to 775 collectively form a spanning tree over the entire SRT. The "secured" 776 spanning tree supports strong authentication for control plane 777 messages. The "unsecured" spanning tree conveys ordinary carrier 778 packets without security codes and that must be treated by 779 destinations according to data origin authentication procedures. 780 Route optimization can be employed to cause carrier packets to take 781 more direct paths between OMNI link neighbors without having to 782 follow strict SRT spanning tree paths. 784 3.2.2. Addressing and Node Identification 786 AERO nodes on OMNI links use the Link-Local Address (LLA) prefix 787 fe80::/64 [RFC4291] to assign LLAs used for network-layer addresses 788 in link-scoped IPv6 ND and data messages. AERO Clients use LLAs 789 constructed from MNPs (i.e., "MNP-LLAs") while other AERO nodes use 790 LLAs constructed from administrative identification values ("ADM- 791 LLAs") as specified in [I-D.templin-6man-omni]. Non-MNP routes are 792 also represented the same as for MNP-LLAs, but may include a prefix 793 that is not properly covered by the MSP. 795 AERO nodes also use the Unique Local Address (ULA) prefix fd00::/8 796 followed by a pseudo-random 40-bit OMNI domain identifier to form the 797 prefix [ULA]::/48, then include a 16-bit OMNI link identifier '*' to 798 form the prefix [ULA*]::/64 [RFC4291]. The AERO node then uses the 799 prefix [ULA*]::/64 to form "MNP-ULAs" or "ADM-ULA"s as specified in 800 [I-D.templin-6man-omni] to support OAL addressing. (The prefix 801 [ULA*]::/64 appearing alone and with no suffix represents "default".) 802 AERO Clients also use Temporary ULAs constructed per 803 [I-D.templin-6man-omni], where the addresses are typically used only 804 in initial control message exchanges until a stable MNP-LLA/ULA is 805 assigned. 807 AERO MSPs, MNPs and non-MNP routes are typically based on Global 808 Unicast Addresses (GUAs), but in some cases may be based on private- 809 use addresses. See [I-D.templin-6man-omni] for a full specification 810 of LLAs, ULAs and GUAs used by AERO nodes on OMNI links. 812 Finally, AERO Clients and Proxy/Servers configure node identification 813 values as specified in [I-D.templin-6man-omni]. 815 3.2.3. AERO Routing System 817 The AERO routing system comprises a private instance of the Border 818 Gateway Protocol (BGP) [RFC4271] that is coordinated between Bridges 819 and Proxy/Servers and does not interact with either the public 820 Internet BGP routing system or any underlying INET routing systems. 822 In a reference deployment, each Proxy/Server is configured as an 823 Autonomous System Border Router (ASBR) for a stub Autonomous System 824 (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within 825 the BGP instance, and each Proxy/Server further uses eBGP to peer 826 with one or more Bridges but does not peer with other Proxy/Servers. 827 Each SRT segment in the OMNI link must include one or more Bridges, 828 which peer with the Proxy/Servers within that segment. All Bridges 829 within the same segment are members of the same hub AS, and use iBGP 830 to maintain a consistent view of all active routes currently in 831 service. The Bridges of different segments peer with one another 832 using eBGP. 834 Bridges maintain forwarding table entries only for the MNP-ULAs 835 corresponding to MNP and non-MNP routes that are currently active, 836 and carrier packets destined to all other MNP-ULAs will correctly 837 incur Destination Unreachable messages due to the black-hole route. 839 In this way, Proxy/Servers and Relays have only partial topology 840 knowledge (i.e., they only maintain routing information for their 841 directly associated Clients and non-AERO links) and they forward all 842 other carrier packets to Bridges which have full topology knowledge. 844 Each OMNI link SRT segment assigns a unique ADM-ULA sub-prefix of 845 [ULA*]::/96. For example, a first segment could assign 846 [ULA*]::1000/116, a second could assign [ULA*]::2000/116, a third 847 could assign [ULA*]::3000/116, etc. Within each segment, each Proxy/ 848 Server configures an ADM-ULA within the segment's prefix, e.g., the 849 Proxy/Servers within [ULA*]::2000/116 could assign the ADM-ULAs 850 [ULA*]::2011/116, [ULA*]::2026/116, [ULA*]::2003/116, etc. 852 The administrative authorities for each segment must therefore 853 coordinate to assure mutually-exclusive ADM-ULA prefix assignments, 854 but internal provisioning of ADM-ULAs an independent local 855 consideration for each administrative authority. For each ADM-ULA 856 prefix, the Bridge(s) that connect that segment assign the all-zero's 857 address of the prefix as a Subnet Router Anycast address. For 858 example, the Subnet Router Anycast address for [ULA*]::1023/116 is 859 simply [ULA*]::1000. 861 ADM-ULA prefixes are statically represented in Bridge forwarding 862 tables. Bridges join multiple SRT segments into a unified OMNI link 863 over multiple diverse network administrative domains. They support a 864 bridging function by first establishing forwarding table entries for 865 their ADM-ULA prefixes either via standard BGP routing or static 866 routes. For example, if three Bridges ('A', 'B' and 'C') from 867 different segments serviced [ULA*]::1000/116, [ULA*]::2000/116 and 868 [ULA*]::3000/116 respectively, then the forwarding tables in each 869 Bridge are as follows: 871 A: [ULA*]::1000/116->local, [ULA*]::2000/116->B, [ULA*]::3000/116->C 873 B: [ULA*]::1000/116->A, [ULA*]::2000/116->local, [ULA*]::3000/116->C 875 C: [ULA*]::1000/116->A, [ULA*]::2000/116->B, [ULA*]::3000/116->local 877 These forwarding table entries are permanent and never change, since 878 they correspond to fixed infrastructure elements in their respective 879 segments. 881 MNP ULAs are instead dynamically advertised in the AERO routing 882 system by Proxy/Servers and Relays that provide service for their 883 corresponding MNPs. For example, if three Proxy/Servers ('D', 'E' 884 and 'F') service the MNPs 2001:db8:1000:2000::/56, 885 2001:db8:3000:4000::/56 and 2001:db8:5000:6000::/56 then the routing 886 system would include: 888 D: [ULA*]:2001:db8:1000:2000/120 890 E: [ULA*]:2001:db8:3000:4000/120 892 F: [ULA*]:2001:db8:5000:6000/120 894 A full discussion of the BGP-based routing system used by AERO is 895 found in [I-D.ietf-rtgwg-atn-bgp]. 897 3.2.4. OMNI Link Segment Routing 899 With the Client and SRT segment prefixes in place in Bridge 900 forwarding tables, the OMNI interface sends control and data carrier 901 packets toward AERO destination nodes located in different OMNI link 902 segments over the SRT spanning tree. The OMNI interface uses the 903 OMNI Adaptation Layer (OAL) encapsulation service 904 [I-D.templin-6man-omni], and includes an OMNI Routing Header (ORH) as 905 an extension to the OAL header. Each carrier packet includes at most 906 one ORH in compressed or uncompressed form, with the uncompressed 907 form shown in Figure 3: 909 0 1 2 3 910 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | omIndex | FMT | SRT | LHS (bits 0 -15) | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | LHS (bits 0 -15) | ~ 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 918 ~ Link Layer Address (L2ADDR) ~ 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Null Padding (if necessary) | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 ~ Destination Suffix ~ 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 Figure 3: OMNI Routing Header (ORH) Format 927 The ORH includes the following fields, in consecutive order: 929 o Next Header identifies the type of header immediately following 930 the ORH. 932 o Hdr Ext Len is the length of the Routing header in 8-octet units 933 (not including the first 8 octets). The field must encode a value 934 between 0 and 4 (all other values indicate a parameter problem). 936 o Routing Type is set to TBD1 (see IANA Considerations). 938 o Segments Left encodes the value 0 or 1 (all other values indicate 939 a parameter problem). 941 o omIndex - a 1-octet field consulted only when Segments Left is 0; 942 identifies a specific target Client underlying interface serviced 943 by the LHS Proxy-Server when there are multiple alternatives. 944 When FMT-Forward is clear, omIndex determines the interface for 945 forwarding the ORH packet following reassembly; when FMT-Forward 946 is set, omIndex determines the interface for forwarding the raw 947 carrier packets without first reassembling. When omIndex is set 948 to 0 (or when no ORH is present), the LHS Proxy/Server selects 949 among any of the Client's available underlying interfaces that it 950 services locally (i.e., and not those serviced by another Proxy/ 951 Server). 953 o FMT - a 3-bit "Forward/Mode/Trailer" code corresponding to the 954 included Link Layer Address as follows: 956 * When the most significant bit (i.e., "FMT-Forward") is clear, 957 the LHS Proxy/Server must reassemble. When FMT-Forward is set, 958 the LHS Proxy/Server must forward the fragments to the Client 959 (while changing the OAL destination address to the MNP-ULA of 960 the Client if necessary) without reassembling. 962 * When the next most significant bit (i.e., "FMT-Mode") is clear, 963 L2ADDR is the INET address of the LHS Proxy/Server and the 964 Client must be reached through the LHS Proxy/Server. When FMT- 965 Mode is set, the Client is eligible for route optimization over 966 the open INET where it may be located behind one or more NATs, 967 and L2ADDR is either the INET address of the LHS Proxy/Server 968 (when FMT-Forward is set) or the native INET address of the 969 Client itself (when FMT-Forward is clear). 971 * The least significant bit (i.e., "FMT-Type") is consulted only 972 when Hdr Ext Len is 1 and ignored otherwise. If FMT-Type is 973 clear, the remaining 10 ORH octets contain an LHS followed by 974 an IPv4 L2ADDR. If FMT-Type is set, the remainder instead 975 contains 2 null padding octets followed by an 8-octet (IPv6) 976 Destination Suffix. 978 o SRT - a 5-bit Segment Routing Topology prefix length consulted 979 only when Segments Left is 1, and encodes a value that (when added 980 to 96) determines the prefix length to apply to the ADM-ULA formed 981 from concatenating [ULA*]::/96 with the 32 bit LHS value (for 982 example, the value 16 corresponds to the prefix length 112). 984 o LHS - a 4-octet field present only when indicated by the ORH 985 length (see below) and consulted only when Segments Left is 1. 986 The field encodes the 32-bit ADM-ULA suffix of an LHS Proxy/Server 987 for the target. When SRT and LHS are both set to 0, the LHS 988 Proxy/Server must be reached directly via INET encapsulation 989 instead of over the spanning tree. When SRT is set to 0 and LHS 990 is non-zero, the prefix length is set to 128. SRT and LHS 991 determine the ADM-ULA of the LHS Proxy/Server over the spanning 992 tree. 994 o Link Layer Address (L2ADDR) - an IP encapsulation address present 995 only when indicated by the ORH length (see below) and consulted 996 only when Segments Left is 1. The ORH length also determines the 997 L2ADDR IP version since the field will always contain exactly 6 998 octets for UDP/IPv4 or 18 octets for UDP/IPv6. When present, 999 provides the link-layer address (i.e., the encapsulation address) 1000 of the LHS Proxy/Server or the target Client itself. The UDP Port 1001 Number appears in the first two octets and the IP address appears 1002 in the remaining octets. The Port Number and IP address are 1003 recorded in network byte order, and in ones-compliment 1004 "obfuscated" form per [RFC4380]. The OMNI interface forwarding 1005 algorithm uses L2ADDR as the INET encapsulation address for 1006 forwarding when SRT/LHS is located in the same OMNI link segment. 1007 If direct INET encapsulation is not permitted, L2ADDR is instead 1008 set to all-zeros and the packet must be forwarded to the LHS 1009 Proxy-Server via the spanning tree. 1011 o Null Padding - zero-valued octets added as necessary to pad the 1012 portion of the ORH included up to this point to an even 8-octet 1013 boundary. 1015 o Destination Suffix - a trailing 8-octet field present only when 1016 indicated by the ORH length (see below). When ORH length is 1, 1017 FMT-Type determines whether the option includes a Destination 1018 Suffix or an LHS/L2ADDR for IPv4 since there is only enough space 1019 available for one. When present, encodes the 64-bit MNP-ULA 1020 suffix for the target Client. 1022 The ORH Hdr Ext Len field value also serves as an implicit ORH 1023 "Type", with 5 distinct Types specified (i.e., ORH-0 through ORH-4). 1024 All ORH-* Types include the same 6-octet preamble beginning with Next 1025 Header up to and including omIndex, followed by a Type-specific 1026 remainder as follows: 1028 o ORH-0 - The preamble Hdr Ext Len and Segments Left must both be 0. 1029 Two null padding octets follow the preamble, and all other fields 1030 are omitted. 1032 o ORH-1 - The preamble Hdr Ext Len is set to 1. When FMT-Type is 1033 clear, the LHS and L2ADDR for IPv4 fields are included and the 1034 Destination Suffix is omitted. When FMT-Type is set, the LHS and 1035 L2ADDR fields are omitted, the Destination Suffix field is 1036 included and Segments Left must be 0. 1038 o ORH-2 - The preamble Hdr Ext Len is set to 2. The LHS, L2ADDR for 1039 IPv4 and Destination Suffix fields are all included. 1041 o ORH-3 - The preamble Hdr Ext Len is set to 3. The LHS and L2ADDR 1042 for IPv6 fields are included and the Destination Suffix field is 1043 omitted. 1045 o ORH-4 - The preamble Hdr Ext Len is set to 4. The LHS, L2ADDR for 1046 IPv6 and Destination Suffix fields are all included. 1048 AERO neighbors use OAL encapsulation and fragmentation to exchange 1049 OAL packets as specified in [I-D.templin-6man-omni]. When an AERO 1050 node's OMNI interface (acting as an OAL source) uses OAL 1051 encapsulation for an original IP packet with source address 1052 2001:db8:1:2::1 and destination address 2001:db8:1234:5678::1, it 1053 sets the OAL header source address to its own ULA (e.g., 1054 [ULA*]::2001:db8:1:2), sets the destination address to the MNP-ULA 1055 corresponding to the IP destination address (e.g., 1056 [ULA*]::2001:db8:1234:5678), sets the Traffic Class, Flow Label, Hop 1057 Limit and Payload Length as discussed in [I-D.templin-6man-omni], 1058 then finally selects an Identification and appends an OAL checksum. 1060 If the neighbor cache information indicates that the target is in a 1061 different segment, the OAL source next inserts an ORH immediately 1062 following the OAL header while including Destination Suffix for non- 1063 first-fragments only when necessary (in this case, the Destination 1064 Suffix is 2001:db8:1234:5678). Next, to direct the packet to a 1065 first-hop Proxy/Server or a Bridge, the source prepares an ORH with 1066 Segments Left set to 1 and with SRT/LHS/L2ADDR included, then 1067 overwrites the OAL header destination address with the LHS Subnet 1068 Router Anycast address (for example, for LHS 3000:4567 with SRT 16, 1069 the Subnet Router Anycast address is [ULA*]::3000:0000). To send the 1070 packet to the LHS Proxy/Server either directly or via the spanning 1071 tree, the OAL source instead includes an ORH (Type 0 or 1) with 1072 Segments Left set to 0 and LHS/L2ADDR omitted, and overwrites the OAL 1073 header destination address with either the LHS Proxy/Server ADM-ULA 1074 or the MNP-ULA of the Client itself. 1076 The OAL source then fragments the OAL packet, with each resulting OAL 1077 fragment including the OAL/ORH headers while only the first fragment 1078 includes the original IPv6 header. If FMT-Forward is set, the 1079 Identification used for fragmentation must be within the window for 1080 the Client and a Destination Suffix must be included with each non- 1081 first-fragment when necessary; otherwise the Identification must be 1082 within the window for the Client's Proxy/Server and no Destination 1083 Suffix is needed. (Note that if no actual fragmentation is required 1084 the OAL source still prepares the packet as an "atomic" fragment that 1085 includes a Fragment Header with Offset and More Fragments both set to 1086 0.) The OAL source finally encapsulates each resulting OAL fragment 1087 in an *NET header to form an OAL carrier packet, with source address 1088 set to its own *NET address (e.g., 192.0.2.100) and destination set 1089 to the *NET address of the last hop itself or the next hop in the 1090 spanning tree (e.g., 192.0.2.1). 1092 The carrier packet encapsulation format in the above example is shown 1093 in Figure 4: 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | *NET Header | 1097 | src = 192.0.2.100 | 1098 | dst = 192.0.2.1 | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | OAL IPv6 Header | 1101 | src = [ULA*]::2001:db8:1:2 | 1102 | dst= [ULA*]::3000:0000 | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | ORH (if necessary) | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | OAL Fragment Header | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Original IP Header | 1109 | (first-fragment only) | 1110 | src = 2001:db8:1:2::1 | 1111 | dst = 2001:db8:1234:5678::1 | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | | 1114 ~ ~ 1115 ~ Original Packet Body/Fragment ~ 1116 ~ ~ 1117 | | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 4: Carrier Packet Format 1122 In this format, the original IP header and packet body/fragment are 1123 from the original IP packet, the OAL header is an IPv6 header 1124 prepared according to [RFC2473], the ORH is a Routing Header 1125 extension of the OAL header, the Fragment Header identifies each 1126 fragment, and the INET header is prepared as discussed in 1127 Section 3.6. The OAL source then transmits the resulting carrier 1128 packets into the SRT spanning tree, where they are forwarded over 1129 possibly multiple OAL intermediate nodes until they arrive at the OAL 1130 destination. 1132 This gives rise to an SRT forwarding system that contains both Client 1133 MNP-ULA routes that may change dynamically due to regional node 1134 mobility and per-segment ADM-ULA routes that rarely if ever change. 1135 The spanning tree can therefore provide link-layer bridging by 1136 sending carrier packets over the spanning tree instead of network- 1137 layer routing according to MNP routes. As a result, opportunities 1138 for loss due to node mobility between different segments are 1139 mitigated. 1141 Note: The document recommends that AERO nodes transform ORHs with 1142 Segments Left set to 1 into ORH-0 or ORH-1 during forwarding. While 1143 this may yield encapsulation overhead savings in some cases, the AERO 1144 node may instead simply set Segments Left to 0 and leave the original 1145 ORH in place. The LHS Proxy/Server or target Client that processes 1146 the ORH will receive the same information in both cases. 1148 Note: When the OAL source sets a carrier packet OAL destination 1149 address to a target's MNP-ULA but does not assert a specific target 1150 underlying interface, it may omit the ORH whether forwarding to the 1151 LHS Proxy/Server or directly to the target itself. When the LHS 1152 Proxy/Server receives a carrier packet with OAL destination set to 1153 the target MNP-ULA but with no ORH, it forwards over any available 1154 underlying interface for the target that it services locally. 1156 Note: When the OAL source and destination are on the same INET 1157 segment, OAL header compression can be used to significantly reduce 1158 encapsulation overhead as discussed in [I-D.templin-6man-omni]. 1160 Note: Use of an IPv6 "minimal encapsulation" format (i.e., an IPv6 1161 variant of [RFC2004]) based on extensions to the ORH was considered 1162 and abandoned. In the approach, the ORH would be inserted as an 1163 extension header to the original IPv6 packet header. The IPv6 1164 destination address would then be written into the ORH, and the ULA 1165 corresponding to the destination would be overwritten in the IPv6 1166 destination address. This would seemingly convey enough forwarding 1167 information so that OAL encapsulation could be avoided. However, 1168 this "minimal encapsulation" IPv6 packet would then have a non-ULA 1169 source address and ULA destination address, an incorrect value in 1170 upper layer protocol checksums, and a Hop Limit that is decremented 1171 within the spanning tree when it should not be. The insertion and 1172 removal of the ORH would also entail rewriting the Payload Length and 1173 Next Header fields - again, invalidating upper layer checksums. 1174 These irregularities would result in implementation challenges and 1175 the potential for operational issues, e.g., since actionable ICMPv6 1176 error reports could not be delivered to the original source. In 1177 order to address the issues, still more information such as the 1178 original IPv6 source address could be written into the ORH. However, 1179 with the additional information the benefit of the "minimal 1180 encapsulation" savings quickly diminishes, and becomes overshadowed 1181 by the implementation and operational irregularities. 1183 3.2.5. Segment Routing Topologies (SRTs) 1185 The 64-bit sub-prefixes of [ULA]::/48 identify up to 2^16 distinct 1186 Segment Routing Topologies (SRTs). Each SRT is a mutually-exclusive 1187 OMNI link overlay instance using a distinct set of ULAs, and emulates 1188 a Virtual LAN (VLAN) service for the OMNI link. In some cases (e.g., 1189 when redundant topologies are needed for fault tolerance and 1190 reliability) it may be beneficial to deploy multiple SRTs that act as 1191 independent overlay instances. A communication failure in one 1192 instance therefore will not affect communications in other instances. 1194 Each SRT is identified by a distinct value in bits 48-63 of 1195 [ULA]::/48, i.e., as [ULA0]::/64, [ULA1]::/64, [ULA2]::/64, etc. 1196 Each OMNI interface is identified by a unique interface name (e.g., 1197 omni0, omni1, omni2, etc.) and assigns an anycast ADM-ULA 1198 corresponding to its SRT prefix length. The anycast ADM-ULA is used 1199 for OMNI interface determination in Safety-Based Multilink (SBM) as 1200 discussed in [I-D.templin-6man-omni]. Each OMNI interface further 1201 applies Performance-Based Multilink (PBM) internally. 1203 The Bridges and Proxy/Servers of each independent SRT engage in BGP 1204 peerings to form a spanning tree with the Bridges in non-leaf nodes 1205 and the Proxy/Servers in leaf nodes. The spanning tree is configured 1206 over both secured and unsecured underlying network paths. The 1207 secured spanning tree is used to convey secured control messages 1208 between FHS and LHS Proxy/Servers, while the unsecured spanning tree 1209 forwards data messages and/or unsecured control messages. 1211 Each SRT segment is identified by a unique ADM-ULA prefix used by all 1212 Proxy/Servers and Bridges in the segment. Each AERO node must 1213 therefore discover an SRT prefix that correspondents can use to 1214 determine the correct segment, and must publish the SRT prefix in 1215 IPv6 ND messages and carrier packet ORHs. 1217 3.2.6. Segment Routing For OMNI Link Selection 1219 Original IPv6 source can direct IPv6 packets to an AERO node by 1220 including a standard IPv6 Segment Routing Header (SRH) [RFC8754] with 1221 the anycast ADM-ULA for the selected OMNI link as either the IPv6 1222 destination or as an intermediate hop within the SRH. This allows 1223 the original source to determine the specific OMNI link SRT an 1224 original IPv6 packet will traverse when there may be multiple 1225 alternatives. 1227 When an AERO node processes the SRH and forwards the original IPv6 1228 packet to the correct OMNI interface, the OMNI interface writes the 1229 next IPv6 address from the SRH into the IPv6 destination address and 1230 decrements Segments Left. If decrementing would cause Segments Left 1231 to become 0, the OMNI interface deletes the SRH before forwarding. 1232 This form of Segment Routing supports Safety-Based Multilink (SBM). 1234 3.2.7. Segment Routing Within the OMNI Link 1236 OAL sources can insert an ORH for Segment Routing within the same 1237 OMNI link to influence the paths of carrier packets sent to OAL 1238 destinations in remote SRT segments without requiring all carrier 1239 packets to traverse strict SRT spanning tree paths. (OAL sources can 1240 also insert an ORH in carrier packets sent to OAL destinations in the 1241 local segment if additional last-hop forwarding information is 1242 required.) 1244 When an AERO node's OMNI interface has an original IP packet to send 1245 to a target discovered through route optimization located in the same 1246 SRT segment, it acts as an OAL source to perform OAL encapsulation 1247 and fragmentation. The node then uses L2ADDR for INET encapsulation 1248 while including an ORH-0 when sending the resulting carrier packets 1249 to the ADM-ULA of the LHS Proxy/Server, or optionally omitting the 1250 ORH-0 when sending to the MNP-ULA of the target Client itself. When 1251 the node sends carrier packets with an ORH-0 to the LHS Proxy/Server, 1252 it sets the OAL destination to the ADM-ULA of the Proxy/Server if the 1253 Proxy/Server is responsible for reassembly; otherwise, it sets the 1254 OAL destination to the MNP-ULA of the target Client to cause the 1255 Proxy/Server to forward without reassembling. The node also sets 1256 omIndex to select a specific target Client underlying interface, or 1257 sets omIndex to 0 when no preference is selected. 1259 When an AERO node's OMNI interface has an original IP packet to send 1260 to a route optimization target located in a remote OMNI link segment, 1261 it acts as an OAL source the same as above but also includes an 1262 appropriate ORH type with Segments Left set to 1 and with SRT/LHS/ 1263 L2ADDR information while setting the OAL destination to the Subnet 1264 Router Anycast address for the LHS OMNI link segment. (The OAL 1265 source can alternatively include an ORH with Segments Left set to 0 1266 while setting the OAL destination to the ADM-ULA of the LHS Proxy/ 1267 Server, but this would cause the carrier packets to follow strict 1268 spanning tree paths.) The OMNI interface then forwards the resulting 1269 carrier packets into the spanning tree. 1271 When a Bridge receives a carrier packet destined to its Subnet Router 1272 Anycast address with any ORH type with Segments Left set to 1 and 1273 with SRT/LHS/L2ADDR values corresponding to the local segment, it 1274 examines FMT-Mode to determine whether the target Client can accept 1275 packets directly (i.e., following any NAT traversal procedures 1276 necessary) while bypassing the LHS Proxy/Server. If the Client can 1277 be reached directly and NAT traversal has converged, the Bridge then 1278 writes the MNP-ULA (found in the inner IPv6 header for first 1279 fragments or the ORH Destination Suffix for non-first fragments) into 1280 the OAL destination address, decrements the OAL IPv6 header Hop Limit 1281 (and discards the packet if Hop Limit reaches 0), removes the ORH, 1282 re-encapsulates the carrier packet according to L2ADDR then forwards 1283 the carrier packet directly to the target Client. If the Client 1284 cannot be reached directly (or if NAT traversal has not yet 1285 converged), the Bridge instead transforms the ORH into an ORH-0, re- 1286 encapsulates the packet according to L2ADDR, changes the OAL 1287 destination to the ADM-ULA of the LHS Proxy/Server if FMT-Forward is 1288 clear or the MNP-ULA of the Client if FMT-Forward is set and forwards 1289 the carrier packet to the LHS Proxy/Server. 1291 When a Bridge receives a carrier packet destined to its Subnet Router 1292 Anycast address with any ORH type with Segments Left set to 1 and 1293 L2ADDR set to 0, the Bridge instead forwards the packet toward the 1294 LHS Proxy/Server via the spanning tree. The Bridge changes the OAL 1295 destination to the ADM-ULA of the LHS Proxy/Server, transforms the 1296 ORH into an ORH-0 (or an ORH-1 with FMT-Type set and Segments Left 1297 0), then forwards the packet to the next hop in the spanning tree. 1298 The Bridge may also elect to forward via the spanning tree as above 1299 even when it receives a carrier packet with an ORH that includes a 1300 valid L2ADDR Port Number and IP address, however this may result in a 1301 longer path than necessary. If the carrier packet arrived via the 1302 secured spanning tree, the Bridge forwards to the next hop also via 1303 the secured spanning tree. If the carrier packet arrived via the 1304 unsecured spanning tree, the Bridge forwards to the next hop also via 1305 the unsecured spanning tree. 1307 When an LHS Proxy/Server receives carrier packets with any ORH type 1308 with Segments Left set to 0 and with OAL destination set to its own 1309 ADM-ULA, it proceeds according to FMT-Forward and omIndex. If FMT- 1310 Forward is set, the LHS Proxy/Server changes the OAL destination to 1311 the MNP-ULA of the target Client found in the IPv6 header for first 1312 fragments or in the ORH Destination Suffix for non-first-fragments, 1313 removes the ORH and forwards to the target Client interface 1314 identified by omIndex. If FMT-Forward is clear, the LHS Proxy/Server 1315 instead reassembles then re-encapsulates while refragmenting if 1316 necessary, removes the ORH and forwards to the target Client 1317 according to omIndex. 1319 When an LHS Proxy/Server receives carrier packets with any ORH type 1320 with Segments Left set to 0 and with OAL destination set to the MNP- 1321 ULA of the target Client, it removes the ORH and forwards to the 1322 target Client according to omIndex. During forwarding, the LHS 1323 Proxy/Server must first verify that the omIndex corresponds to a 1324 target underlying interface that it services locally and must not 1325 forward to other target underlying interfaces. If omIndex is 0 (or 1326 if no ORH is included) the LHS Proxy/Server instead selects among any 1327 of the target underlying interfaces it services. 1329 When a target Client receives carrier packets with OAL destination 1330 set to is MNP-ULA, it reassembles to obtain the OAL packet then 1331 decapsulates and delivers the original IP packet to upper layers. 1333 Note: Special handling procedures are employed for the exchange of 1334 IPv6 ND messages used to establish neighbor cache state as discussed 1335 in Section 3.14. The procedures call for hop-by-hop authentication 1336 and neighbor cache state establishment based on the encapsulation 1337 ULA, with next-hop determination based on the IPv6 ND message LLA. 1339 3.3. OMNI Interface Characteristics 1341 OMNI interfaces are virtual interfaces configured over one or more 1342 underlying interfaces classified as follows: 1344 o INET interfaces connect to an INET either natively or through one 1345 or more NATs. Native INET interfaces have global IP addresses 1346 that are reachable from any INET correspondent. The INET-facing 1347 interfaces of Proxy/Servers are native interfaces, as are Relay 1348 and Bridge interfaces. NATed INET interfaces connect to a private 1349 network behind one or more NATs that provide INET access. Clients 1350 that are behind a NAT are required to send periodic keepalive 1351 messages to keep NAT state alive when there are no carrier packets 1352 flowing. 1354 o ANET interfaces connect to an ANET that is separated from the open 1355 INET by an FHS Proxy/Server. Clients can issue control messages 1356 over the ANET without including an authentication signature since 1357 the ANET is secured at the network layer or below. Proxy/Servers 1358 can actively issue control messages over the INET on behalf of 1359 ANET Clients to reduce ANET congestion. 1361 o VPNed interfaces use security encapsulation over the INET to a 1362 Virtual Private Network (VPN) server that also acts as an FHS 1363 Proxy/Server. Other than the link-layer encapsulation format, 1364 VPNed interfaces behave the same as Direct interfaces. 1366 o Direct (i.e., single-hop point-to-point) interfaces connect a 1367 Client directly to an FHS Proxy/Server without crossing any ANET/ 1368 INET paths. An example is a line-of-sight link between a remote 1369 pilot and an unmanned aircraft. The same Client considerations 1370 apply as for VPNed interfaces. 1372 OMNI interfaces use OAL encapsulation and fragmentation as discussed 1373 in Section 3.2.4. OMNI interfaces use *NET encapsulation (see: 1374 Section 3.6) to exchange carrier packets with OMNI link neighbors 1375 over INET or VPNed interfaces as well as over ANET interfaces for 1376 which the Client and FHS Proxy/Server may be multiple IP hops away. 1377 OMNI interfaces do not use link-layer encapsulation over Direct 1378 underlying interfaces or ANET interfaces when the Client and FHS 1379 Proxy/Server are known to be on the same underlying link. 1381 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 1382 state the same as for any interface. OMNI interfaces use ND messages 1383 including Router Solicitation (RS), Router Advertisement (RA), 1384 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for 1385 neighbor cache management. In environments where spoofing may be a 1386 threat, OMNI neighbors should employ OAL Identification window 1387 synchronization in their ND message exchanges. 1389 OMNI interfaces send ND messages with an OMNI option formatted as 1390 specified in [I-D.templin-6man-omni]. The OMNI option includes 1391 prefix registration information, Interface Attributes containing link 1392 information parameters for the OMNI interface's underlying interfaces 1393 and any other per-neighbor information. Each OMNI option may include 1394 multiple Interface Attributes sub-options identified by omIndex 1395 values. 1397 A Client's OMNI interface may be configured over multiple underlying 1398 interfaces. For example, common mobile handheld devices have both 1399 wireless local area network ("WLAN") and cellular wireless links. 1400 These links are often used "one at a time" with low-cost WLAN 1401 preferred and highly-available cellular wireless as a standby, but a 1402 simultaneous-use capability could provide benefits. In a more 1403 complex example, aircraft frequently have many wireless data link 1404 types (e.g. satellite-based, cellular, terrestrial, air-to-air 1405 directional, etc.) with diverse performance and cost properties. 1407 If a Client's multiple underlying interfaces are used "one at a time" 1408 (i.e., all other interfaces are in standby mode while one interface 1409 is active), then successive ND messages all include OMNI option 1410 Interface Attributes sub-options with the same underlying interface 1411 index. In that case, the Client would appear to have a single 1412 underlying interface but with a dynamically changing link-layer 1413 address. 1415 If the Client has multiple active underlying interfaces, then from 1416 the perspective of ND it would appear to have multiple link-layer 1417 addresses. In that case, ND message OMNI options MAY include 1418 Interface Attributes sub-options with different underlying interface 1419 indexes. Every ND message need not include Interface Attributes for 1420 all underlying interfaces; for any attributes not included, the 1421 neighbor considers the status as unchanged. 1423 Bridge and Proxy/Server OMNI interfaces are configured over 1424 underlying interfaces that provide both secured tunnels for carrying 1425 IPv6 ND and BGP protocol control plane messages and open INET access 1426 for carrying unsecured messages. The OMNI interface configures both 1427 an ADM-LLA and its corresponding ADM-ULA, and acts as an OAL source 1428 to encapsulate and fragment original IP packets while presenting the 1429 resulting carrier packets over the secured or unsecured underlying 1430 paths. Note that Bridge and Proxy/Server BGP protocol TCP sessions 1431 are run directly over the OMNI interface and use ADM-ULA source and 1432 destination addresses. The OMNI interface employs the OAL to 1433 encapsulate the original IP packets for these sessions as carrier 1434 packets (i.e., even though the OAL header may use the same ADM-ULAs 1435 as the original IP header) and forwards them over the secured 1436 underlying path. 1438 3.4. OMNI Interface Initialization 1440 AERO Proxy/Servers and Clients configure OMNI interfaces as their 1441 point of attachment to the OMNI link. AERO nodes assign the MSPs for 1442 the link to their OMNI interfaces (i.e., as a "route-to-interface") 1443 to ensure that original IP packets with destination addresses covered 1444 by an MNP not explicitly associated with another interface are 1445 directed to an OMNI interface. 1447 OMNI interface initialization procedures for Proxy/Servers, Clients 1448 and Bridges are discussed in the following sections. 1450 3.4.1. AERO Proxy/Server and Relay Behavior 1452 When a Proxy/Server enables an OMNI interface, it assigns an 1453 ADM-{LLA,ULA} appropriate for the given OMNI link SRT segment. The 1454 Proxy/Server also configures secured tunnels with one or more 1455 neighboring Bridges and engages in a BGP routing protocol session 1456 with each Bridge. 1458 The OMNI interface provides a single interface abstraction to the IP 1459 layer, but internally includes an NBMA nexus for sending carrier 1460 packets to OMNI interface neighbors over underlying INET interfaces 1461 and secured tunnels. The Proxy/Server further configures a service 1462 to facilitate ND exchanges with AERO Clients and manages per-Client 1463 neighbor cache entries and IP forwarding table entries based on 1464 control message exchanges. 1466 Relays are simply Proxy/Servers that run a dynamic routing protocol 1467 to redistribute routes between the OMNI interface and INET/EUN 1468 interfaces (see: Section 3.2.3). The Relay provisions MNPs to 1469 networks on the INET/EUN interfaces (i.e., the same as a Client would 1470 do) and advertises the MSP(s) for the OMNI link over the INET/EUN 1471 interfaces. The Relay further provides an attachment point of the 1472 OMNI link to a non-MNP-based global topology. 1474 3.4.2. AERO Client Behavior 1476 When a Client enables an OMNI interface, it assigns either an 1477 MNP-{LLA, ULA} or a Temporary ULA and sends RS messages with ND 1478 parameters over its underlying interfaces to an FHS Proxy/Server, 1479 which returns an RA message with corresponding parameters. The RS/RA 1480 messages may pass through one or more NATs in the case of a Client's 1481 INET interface. (Note: if the Client used a Temporary ULA in its 1482 initial RS message, it will discover an MNP-{LLA, ULA} in the 1483 corresponding RA that it receives from the FHS Proxy/Server and begin 1484 using these new addresses. If the Client is operating outside the 1485 context of AERO infrastructure such as in a Mobile Ad-hoc Network 1486 (MANET), however, it may continue using Temporary ULAs for Client-to- 1487 Client communications until it encounters an infrastructure element 1488 that can provide an MNP.) 1490 3.4.3. AERO Bridge Behavior 1492 AERO Bridges configure an OMNI interface and assign the ADM-ULA 1493 Subnet Router Anycast address for each OMNI link SRT segment they 1494 connect to. Bridges configure secured tunnels with Proxy/Servers in 1495 the same SRT segment and other Bridges in the same (or an adjacent) 1496 SRT segment. Bridges then engage in a BGP routing protocol session 1497 with neighbors over the secured spanning tree (see: Section 3.2.3). 1499 3.5. OMNI Interface Neighbor Cache Maintenance 1501 Each OMNI interface maintains a conceptual neighbor cache that 1502 includes a Neighbor Cache Entry (NCE) for each of its active 1503 neighbors on the OMNI link per [RFC4861]. Each route optimization 1504 source NCE is indexed by the LLA of the neighbor, while the OAL 1505 encapsulation ULA determines the context for Identification 1506 verification. In addition to ordinary neighbor cache entries, proxy 1507 neighbor cache entries are created and maintained by AERO Proxy/ 1508 Servers when they proxy Client ND message exchanges [RFC4389]. AERO 1509 Proxy/Servers maintain proxy neighbor cache entries for each of their 1510 associated Clients. 1512 To the list of NCE states in Section 7.3.2 of [RFC4861], Proxy/Server 1513 OMNI interfaces add an additional state DEPARTED that applies to 1514 Clients that have recently departed. The interface sets a 1515 "DepartTime" variable for the NCE to "DEPART_TIME" seconds. 1516 DepartTime is decremented unless a new ND message causes the state to 1517 return to REACHABLE. While a NCE is in the DEPARTED state, the 1518 Proxy/Server forwards carrier packets destined to the target Client 1519 to the Client's new location instead. When DepartTime decrements to 1520 0, the NCE is deleted. It is RECOMMENDED that DEPART_TIME be set to 1521 the default constant value REACHABLE_TIME plus 10 seconds (40 seconds 1522 by default) to allow a window for carrier packets in flight to be 1523 delivered while stale route optimization state may be present. 1525 Proxy/Servers can act as RORs on behalf of their associated Clients 1526 according to the Proxy Neighbor Advertisement specification in 1527 Section 7.2.8 of [RFC4861]. When a Proxy/Server ROR receives an 1528 authentic NS message used for route optimization, it first searches 1529 for a NCE for the target Client and accepts the message only if there 1530 is an entry. The Proxy/Server then returns a solicited NA message 1531 while creating or updating a "Report List" entry in the target 1532 Client's NCE that caches both the LLA and ULA of ROS with a 1533 "ReportTime" variable set to REPORT_TIME seconds. The ROR resets 1534 ReportTime when it receives a new authentic NS message, and otherwise 1535 decrements ReportTime while no authentic NS messages have been 1536 received. It is RECOMMENDED that REPORT_TIME be set to the default 1537 constant value REACHABLE_TIME plus 10 seconds (40 seconds by default) 1538 to allow a window for route optimization to converge before 1539 ReportTime decrements below REACHABLE_TIME. 1541 When the ROS receives a solicited NA message response to its NS 1542 message used for route optimization, it creates or updates a NCE for 1543 the target network-layer and link-layer addresses. The ROS then 1544 (re)sets ReachableTime for the NCE to REACHABLE_TIME seconds and 1545 performs reachability tests over specific underlying interface pairs 1546 to determine paths for forwarding carrier packets directly to the 1547 target. The ROS otherwise decrements ReachableTime while no further 1548 solicited NA messages arrive. It is RECOMMENDED that REACHABLE_TIME 1549 be set to the default constant value 30 seconds as specified in 1550 [RFC4861]. 1552 AERO nodes also use the value MAX_UNICAST_SOLICIT to limit the number 1553 of NS messages sent when a correspondent may have gone unreachable, 1554 the value MAX_RTR_SOLICITATIONS to limit the number of RS messages 1555 sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT 1556 to limit the number of unsolicited NAs that can be sent based on a 1557 single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT, 1558 MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the 1559 same as specified in [RFC4861]. 1561 Different values for DEPART_TIME, REPORT_TIME, REACHABLE_TIME, 1562 MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and 1563 MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if 1564 different values are chosen, all nodes on the link MUST consistently 1565 configure the same values. Most importantly, DEPART_TIME and 1566 REPORT_TIME SHOULD be set to a value that is sufficiently longer than 1567 REACHABLE_TIME to avoid packet loss due to stale route optimization 1568 state. 1570 3.5.1. OMNI ND Messages 1572 OMNI interfaces prepare IPv6 ND messages the same as for standard 1573 IPv6 ND, but also include a new option type termed the OMNI option 1574 [I-D.templin-6man-omni]. OMNI interfaces prepare IPv6 ND messages 1575 the same as for standard IPv6 ND, and include one or more OMNI 1576 options and any other options then completely populate all option 1577 information. If the OMNI interface includes an authentication 1578 signature, it sets the IPv6 ND message Checksum field to 0 and 1579 calculates the authentication signature over the entire length of the 1580 message (beginning with a pseudo-header of the IPv6 header) but does 1581 not then proceed to calculate the IPv6 ND message checksum itself. 1582 If the OMNI interface forwards the message to a next hop over the 1583 secured spanning tree path, it omits both the authentication 1584 signature or checksum since lower layers already ensure 1585 authentication and integrity. In all other cases, the OMNI interface 1586 calculates the standard IPv6 ND message checksum and writes the value 1587 in the Checksum field. OMNI interfaces verify authentication and 1588 integrity of each IPv6 ND message received according to the specific 1589 check(s) included, and process the message further only following 1590 verification. 1592 OMNI options include per-neighbor information such as Interface 1593 Attributes that provide link-layer address and traffic selector 1594 information for the neighbor's underlying interfaces. This 1595 information is stored in the neighbor cache and provides the basis 1596 for the forwarding algorithm specified in Section 3.10. The 1597 information is cumulative and reflects the union of the OMNI 1598 information from the most recent ND messages received from the 1599 neighbor; it is therefore not required that each ND message contain 1600 all neighbor information. 1602 The OMNI option Interface Attributes for each underlying interface 1603 includes a two-part "Link-Layer Address" consisting of an INET 1604 encapsulation address determined by the FMT and L2ADDR fields and an 1605 ADM-ULA determined by the SRT and LHS fields. Underlying interfaces 1606 are further selected based on their associated traffic selectors. 1608 The OMNI option is distinct from any Source/Target Link-Layer Address 1609 Options (S/TLLAOs) that may appear in an ND message according to the 1610 appropriate IPv6 over specific link layer specification (e.g., 1611 [RFC2464]). If both an OMNI option and S/TLLAO appear, the former 1612 pertains to encapsulation addresses while the latter pertains to the 1613 native L2 address format of the underlying media 1615 OMNI interface IPv6 ND messages may also include other IPv6 ND 1616 options. In particular, solicitation messages may include Nonce and/ 1617 or Timestamp options if required for verification of advertisement 1618 replies. If an OMNI ND solicitation message includes a Nonce option, 1619 the advertisement reply must echo the same Nonce. If an OMNI ND 1620 solicitation message includes a Timestamp option, the advertisement 1621 reply should also include a Timestamp option. 1623 AERO Clients send RS messages to the All-Routers multicast address 1624 while using unicast link-layer addresses. AERO Proxy/Servers respond 1625 by returning unicast RA messages. During the RS/RA exchange, AERO 1626 Clients and Servers include state synchronization parameters to 1627 establish Identification windows and other state. 1629 AERO nodes use NS/NA messages for the following purposes: 1631 o NS/NA(AR) messages are used for address resolution only. The ROS 1632 sends an NS(AR) to the solicited-node multicast address of the 1633 target, and an ROR in the network with addressing information for 1634 the target returns a unicast NA(AR). The NA(AR) contains 1635 authentic and current target address resolution information, but 1636 only an implicit third-party assertion of target reachability. 1637 NS/NA(AR) messages must be secured. 1639 o NS/NA(WIN) messages are used for establishing and maintaining 1640 window synchronization state (and/or any other state such as 1641 Interface Attributes). The source sends an NS(WIN) to the unicast 1642 address of the target, and the target returns a unicast NA(WIN). 1643 The NS/NA(WIN) exchange synchronizes the sequence number windows 1644 for Identification values the neighbors will include in subsequent 1645 carrier packets, and asserts reachability for the target without 1646 necessarily testing a specific underlying interface pair. NS/ 1647 NA(WIN) messages must be secured. 1649 o NS/NA(NUD) messages are used for determining target reachability. 1650 The source sends an NS(NUD) to the unicast address of the target 1651 while naming a specific underlying interface pair, and the target 1652 returns a unicast NA(NUD). NS/NA(NUD) messages that use an in- 1653 window sequence number and do not update any other state need not 1654 be secured but should include an IPv6 ND message checksum. NS/ 1655 NA(NUD) messages may also be used in combination with window 1656 synchronization (i.e., NUD+WIN), in which case the messages must 1657 be secured. 1659 o Unsolicited NA (uNA) messages are used to signal addressing and/or 1660 other neighbor state changes (e.g., address changes due to 1661 mobility, signal degradation, traffic selector updates, etc.). uNA 1662 messages that include state update information must be secured. 1664 o NS/NA(DAD) messages are not used in AERO, since Duplicate Address 1665 Detection is not required. 1667 Additionally, nodes may send NA/RA messages with the OMNI option PNG 1668 flag set to receive a solicited NA response from the neighbor. The 1669 solicited NA response MUST set the ACK flag (without also setting the 1670 SYN or PNG flags) and include the Identification used in the PNG 1671 message in the Acknowledgement. 1673 3.5.2. OMNI Neighbor Advertisement Message Flags 1675 As discussed in Section 4.4 of [RFC4861] NA messages include three 1676 flag bits R, S and O. OMNI interface NA messages treat the flags as 1677 follows: 1679 o R: The R ("Router") flag is set to 1 in the NA messages sent by 1680 all AERO/OMNI node types. Simple hosts that would set R to 0 do 1681 not occur on the OMNI link itself, but may occur on the downstream 1682 links of Clients and Relays. 1684 o S: The S ("Solicited") flag is set exactly as specified in 1685 Section 4.4. of [RFC4861], i.e., it is set to 1 for Solicited NAs 1686 and set to 0 for uNAs (both unicast and multicast). 1688 o O: The O ("Override") flag is set to 0 for solicited NAs returned 1689 by a Proxy/Server ROR and set to 1 for all other solicited and 1690 unsolicited NAs. For further study is whether solicited NAs for 1691 anycast targets apply for OMNI links. Since MNP-LLAs must be 1692 uniquely assigned to Clients to support correct ND protocol 1693 operation, however, no role is currently seen for assigning the 1694 same MNP-LLA to multiple Clients. 1696 3.5.3. OMNI Neighbor Window Synchronization 1698 In secured environments (e.g., such as between nodes on the same 1699 secured ANET), OMNI interface neighbors can exchange OAL packets 1700 using randomly-initialized and monotonically-increasing 1701 Identification values (modulo 2*32) without window synchronization. 1702 In environments where spoofing is considered a threat, OMNI interface 1703 neighbors instead invoke window synchronization in ND message 1704 exchanges to maintain send/receive window state in their respective 1705 neighbor cache entries as specified in [I-D.templin-6man-omni]. 1707 In the asymmetric window synchronization case, the initial ND message 1708 exchange establishes only the initiator's send window and the 1709 responder's receive window such that a corresponding exchange would 1710 be needed to establish the reverse direction. In the symmetric case, 1711 the initiator and responder engage in a three-way handshake to 1712 symmetrically establish the send/receive windows of both parties. 1714 3.6. OMNI Interface Encapsulation and Re-encapsulation 1716 The OMNI interface admits original IP packets then acts as an OAL 1717 source to perform OAL encapsulation and fragmentation as specified in 1718 [I-D.templin-6man-omni] while including an ORH if necessary as 1719 specified in Section 3.2.4. OAL encapsulation produces OAL packets 1720 subject to fragmentation, with the resulting fragments encapsulated 1721 in *NET headers as carrier packets. 1723 For carrier packets undergoing re-encapsulation at an OAL 1724 intermediate node, the OMNI interface decrements the OAL IPv6 header 1725 Hop Limit and discards the carrier packet if the Hop Limit reaches 0. 1726 The intermediate node next removes the *NET encapsulation headers 1727 from the first segment and re-encapsulates the packet in new *NET 1728 encapsulation headers for the next segment. 1730 When an FHS Proxy/Server re-encapsulates a carrier packet received 1731 from a Client that includes an OAL but no ORH, it inserts an ORH 1732 immediately following the OAL header and adjusts the OAL payload 1733 length and destination address field. The ORH may be removed by an 1734 LHS Bridge or Proxy/Server, but its insertion and removal will not 1735 interfere with reassembly at the final destination. For this reason, 1736 Clients must reserve 40 bytes for a maximum-length ORH when they 1737 perform OAL encapsulation (see: Section 3.9). 1739 3.7. OMNI Interface Decapsulation 1741 OMNI interfaces (acting as OAL destinations) decapsulate and 1742 reassemble OAL packets into original IP packets destined either to 1743 the AERO node itself or to a destination reached via an interface 1744 other than the OMNI interface the original IP packet was received on. 1745 When carrier packets containing OAL fragments addressed to itself 1746 arrive, the OMNI interface discards the NET encapsulation headers and 1747 reassembles as discussed in Section 3.9. 1749 3.8. OMNI Interface Data Origin Authentication 1751 AERO nodes employ simple data origin authentication procedures. In 1752 particular: 1754 o AERO Bridges and Proxy/Servers accept carrier packets received 1755 from secured underlying interfaces. 1757 o AERO Proxy/Servers and Clients accept carrier packets and original 1758 IP packets that originate from within the same secured ANET. 1760 o AERO Clients and Relays accept original IP packets from downstream 1761 network correspondents based on ingress filtering. 1763 o AERO Clients, Relays and Proxy/Servers verify carrier packet UDP/ 1764 IP encapsulation addresses according to [I-D.templin-6man-omni]. 1766 o AERO nodes accept carrier packets addressed to themselves with 1767 Identification values within the current window for the OAL source 1768 neighbor (when window synchronization is used) and drop any 1769 carrier packets with out-of-window Identification values. (AERO 1770 nodes may forward carrier packets not addressed to themselves 1771 without verifying the Identification value.) 1773 AERO nodes silently drop any packets that do not satisfy the above 1774 data origin authentication procedures. Further security 1775 considerations are discussed in Section 6. 1777 3.9. OMNI Interface MTU 1779 The OMNI interface observes the link nature of tunnels, including the 1780 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 1781 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 1782 The OMNI interface employs an OMNI Adaptation Layer (OAL) that 1783 accommodates multiple underlying links with diverse MTUs while 1784 observing both a minimum and per-path Maximum Payload Size (MPS). 1785 The functions of the OAL and the OMNI interface MTU/MRU/MPS are 1786 specified in [I-D.templin-6man-omni] with MTU/MRU both set to the 1787 constant value 9180 bytes, with minimum MPS set to 400 bytes, and 1788 with per-path MPS set to potentially larger values depending on the 1789 underlying path. 1791 When the network layer presents an original IP packet to the OMNI 1792 interface, the OAL source encapsulates and fragments the original IP 1793 packet if necessary. When the network layer presents the OMNI 1794 interface with multiple original IP packets bound to the same OAL 1795 destination, the OAL source can concatenate them together into a 1796 single OAL super-packet as discussed in [I-D.templin-6man-omni]. The 1797 OAL source then fragments the OAL packet if necessary according to 1798 the minimum/path MPS such that the OAL headers appear in each 1799 fragment while the original IP packet header appears only in the 1800 first fragment. The OAL source then encapsulates each OAL fragment 1801 in *NET headers for transmission as carrier packets over an 1802 underlying interface connected to either a physical link (such as 1803 Ethernet, WiFi and the like) or a virtual link such as an Internet or 1804 higher-layer tunnel (see the definition of link in [RFC8200]). 1806 Note: A Client that does not (yet) have neighbor cache state for a 1807 target may omit the ORH in carrier packets with the understanding 1808 that a Proxy/Server may insert an ORH on its behalf. For this 1809 reason, Clients reserve 40 bytes for the largest possible ORH in 1810 their OAL fragment size calculations. 1812 Note: Although the ORH may be removed or replaced by a Bridge or 1813 Proxy/Server on the path (see: Section 3.10.3), this does not 1814 interfere with the destination's ability to reassemble since the ORH 1815 is not included in the fragmentable part and its removal/ 1816 transformation does not invalidate fragment header information. 1818 3.10. OMNI Interface Forwarding Algorithm 1820 Original IP packets enter a node's OMNI interface either from the 1821 network layer (i.e., from a local application or the IP forwarding 1822 system) while carrier packets enter from the link layer (i.e., from 1823 an OMNI interface neighbor). All original IP packets and carrier 1824 packets entering a node's OMNI interface first undergo data origin 1825 authentication as discussed in Section 3.8. Those that satisfy data 1826 origin authentication are processed further, while all others are 1827 dropped silently. 1829 Original IP packets that enter the OMNI interface from the network 1830 layer are forwarded to an OMNI interface neighbor using OAL 1831 encapsulation and fragmentation to produce carrier packets for 1832 transmission over underlying interfaces. (If routing indicates that 1833 the original IP packet should instead be forwarded back to the 1834 network layer, the packet is dropped to avoid looping). Carrier 1835 packets that enter the OMNI interface from the link layer are either 1836 re-encapsulated and re-admitted into the OMNI link, or reassembled 1837 and forwarded to the network layer where they are subject to either 1838 local delivery or IP forwarding. In all cases, the OAL MUST NOT 1839 decrement the network layer TTL/Hop-count since its forwarding 1840 actions occur below the network layer. 1842 OMNI interfaces may have multiple underlying interfaces and/or 1843 neighbor cache entries for neighbors with multiple underlying 1844 interfaces (see Section 3.3). The OAL uses Interface Attributes 1845 traffic selectors (e.g., port number, flow specification, etc.) to 1846 select an outbound underlying interface for each OAL packet based on 1847 the node's own interface attributes, and also to select a destination 1848 link-layer address based on the neighbor's underlying interface 1849 attributes. AERO implementations SHOULD permit network management to 1850 dynamically adjust traffic selector values at runtime. 1852 If an OAL packet matches the traffic selectors of multiple outgoing 1853 interfaces and/or neighbor interfaces, the OMNI interface replicates 1854 the packet and sends one copy via each of the (outgoing / neighbor) 1855 interface pairs; otherwise, it sends a single copy of the OAL packet 1856 via an interface with the best matching traffic selector. (While not 1857 strictly required, the likelihood of successful reassembly may 1858 improve when the OMNI interface sends all fragments of the same 1859 fragmented OAL packet consecutively over the same underlying 1860 interface pair to avoid complicating factors such as delay variance 1861 and reordering.) AERO nodes keep track of which underlying 1862 interfaces are currently "reachable" or "unreachable", and only use 1863 "reachable" interfaces for forwarding purposes. 1865 The following sections discuss the OMNI interface forwarding 1866 algorithms for Clients, Proxy/Servers and Bridges. In the following 1867 discussion, an original IP packet's destination address is said to 1868 "match" if it is the same as a cached address, or if it is covered by 1869 a cached prefix (which may be encoded in an MNP-LLA). 1871 3.10.1. Client Forwarding Algorithm 1873 When an original IP packet enters a Client's OMNI interface from the 1874 network layer the Client searches for a NCE that matches the 1875 destination. If there is a match, the Client selects one or more 1876 "reachable" neighbor interfaces in the entry for forwarding purposes. 1877 If there is no NCE, the Client instead either enqueues the original 1878 IP packet and invokes route optimization or forwards the original IP 1879 packet toward a Proxy/Server. The Client (acting as an OAL source) 1880 performs OAL encapsulation and sets the OAL destination address to 1881 the MNP-ULA of the target if there is a matching NCE; otherwise, it 1882 sets the OAL destination to the ADM-ULA of the Proxy/Server. If the 1883 Client has multiple original IP packets to send to the same neighbor, 1884 it can concatenate them in a single super-packet 1885 [I-D.templin-6man-omni]. The OAL source then performs fragmentation 1886 to create OAL fragments (see: Section 3.9), appends any *NET 1887 encapsulation, and sends the resulting carrier packets over 1888 underlying interfaces to the neighbor acting as an OAL destination. 1890 If the neighbor interface selected for forwarding is located on the 1891 same OMNI link segment and not behind a NAT, the Client forwards the 1892 carrier packets directly according to the L2ADDR information for the 1893 neighbor. If the neighbor interface is behind a NAT on the same OMNI 1894 link segment, the Client instead forwards the initial carrier packets 1895 to the LHS Proxy/Server (while inserting an ORH-0 if necessary) and 1896 initiates NAT traversal procedures. If the Client's intended source 1897 underlying interface is also behind a NAT and located on the same 1898 OMNI link segment, it sends a "direct bubble" over the interface per 1899 [RFC6081][RFC4380] to the L2ADDR found in the neighbor cache in order 1900 to establish state in its own NAT by generating traffic toward the 1901 neighbor (note that no response to the bubble is expected). 1903 The Client next sends an NS(NUD) message toward the MNP-ULA of the 1904 neighbor via the LHS Proxy/Server as discussed in Section 3.15. If 1905 the Client receives an NA(NUD) from the neighbor over the underlying 1906 interface, it marks the neighbor interface as "trusted" and sends 1907 future carrier packets directly to the L2ADDR information for the 1908 neighbor instead of indirectly via the LHS Proxy/Server. The Client 1909 must honor the neighbor cache maintenance procedure by sending 1910 additional direct bubbles and/or NS/NA(NUD) messages as discussed in 1911 [RFC6081][RFC4380] in order to keep NAT state alive as long as 1912 carrier packets are still flowing. 1914 When a carrier packet enters a Client's OMNI interface from the link- 1915 layer, if the OAL destination matches one of the Client's ULAs the 1916 Client (acting as an OAL destination) verifies that the 1917 Identification is in-window for this OAL source, then reassembles and 1918 decapsulates as necessary and delivers the original IP packet to the 1919 network layer. Otherwise, the Client drops the original IP packet 1920 and MAY return a network-layer ICMP Destination Unreachable message 1921 subject to rate limiting (see: Section 3.11). 1923 Note: Clients and their FHS Proxy/Server (and other Client) peers can 1924 exchange original IP packets over ANET underlying interfaces without 1925 invoking the OAL, since the ANET is secured at the link and physical 1926 layers. By forwarding original IP packets without invoking the OAL, 1927 however, the ANET peers can engage only in classical path MTU 1928 discovery since the packets are subject to loss and/or corruption due 1929 to the various per-link MTU limitations that may occur within the 1930 ANET. Moreover, the original IP packets do not include either the 1931 OAL integrity check or per-packet Identification values that can be 1932 used for data origin authentication and link-layer retransmissions. 1933 The tradeoff therefore involves an assessment of the per-packet 1934 encapsulation overhead saved by bypassing the OAL vs. inheritance of 1935 classical network "brittleness". (Note however that ANET peers can 1936 send small original IP packets without invoking the OAL, while 1937 invoking the OAL for larger packets. This presents the beneficial 1938 aspects of both small packet efficiency and large packet robustness, 1939 with delay variance and reordering as possible side effects.) 1941 3.10.2. Proxy/Server and Relay Forwarding Algorithm 1943 When the Proxy/Server receives an original IP packet from the network 1944 layer, it drops the packet if routing indicates that it should be 1945 forwarded back to the network layer to avoid looping. Otherwise, the 1946 Proxy/Server regards the original IP packet the same as if it had 1947 arrived as carrier packets with OAL destination set to its own ADM- 1948 ULA. When the Proxy/Server receives carrier packets on underlying 1949 interfaces with OAL destination set to its own ADM-ULA, it performs 1950 OAL reassembly if necessary to obtain the original IP packet. 1952 The Proxy/Server next searches for a NCE that matches the original IP 1953 destination and proceeds as follows: 1955 o if the original IP packet destination matches a NCE, the Proxy/ 1956 Sever uses one or more "reachable" neighbor interfaces in the 1957 entry for packet forwarding using OAL encapsulation and 1958 fragmentation according to the cached link-layer address 1959 information. If the neighbor interface is in a different OMNI 1960 link segment, the Proxy/Server performs OAL encapsulation and 1961 fragmentation, inserts an ORH and forwards the resulting carrier 1962 packets via the spanning tree to a Bridge; otherwise, it forwards 1963 the carrier packets directly to the neighbor. If the neighbor is 1964 behind a NAT, the Proxy/Server instead forwards initial carrier 1965 packets via a Bridge while sending an NS(NUD) to the neighbor. 1966 When the Proxy/Server receives the NA(NUD), it can begin 1967 forwarding carrier packets directly to the neighbor the same as 1968 discussed in Section 3.10.1 while sending additional NS(NUD) 1969 messages as necessary to maintain NAT state. Note that no direct 1970 bubbles are necessary since the Proxy/Server is by definition not 1971 located behind a NAT. 1973 o else, if the original IP destination matches a non-MNP route in 1974 the IP forwarding table or an ADM-LLA assigned to the Proxy/ 1975 Server's OMNI interface, the Proxy/Server acting as a Relay 1976 presents the original IP packet to the network layer for local 1977 delivery or IP forwarding. 1979 o else, the Proxy/Server initiates address resolution as discussed 1980 in Section 3.14, while retaining initial original IP packets in a 1981 small queue awaiting address resolution completion. 1983 When the Proxy/Server receives a carrier packet with OAL destination 1984 set to an MNP-ULA that does not match the MSP, it accepts the carrier 1985 packet only if data origin authentication succeeds and if there is a 1986 network layer routing table entry for a GUA route that matches the 1987 MNP-ULA. If there is no route, the Proxy/Server drops the carrier 1988 packet; otherwise, it reassembles and decapsulates to obtain the 1989 original IP packet and acts as a Relay to present it to the network 1990 layer where it will be delivered according to standard IP forwarding. 1992 When a Proxy/Server receives a carrier packet from one of its Client 1993 neighbors with OAL destination set to another node, it forwards the 1994 packets via a matching NCE or via the spanning tree if there is no 1995 matching entry. When the Proxy/Server receives a carrier packet with 1996 OAL destination set to the MNP-ULA of one of its Client neighbors 1997 established through RS/RA exchanges, it accepts the carrier packet 1998 only if data origin authentication succeeds. If the NCE state is 1999 DEPARTED, the Proxy/Server inserts an ORH that encodes the MNP-ULA 2000 destination suffix and changes the OAL destination address to the 2001 ADM-ULA of the new Proxy/Server, then re-encapsulates the carrier 2002 packet and forwards it to a Bridge which will eventually deliver it 2003 to the new Proxy/Server. 2005 If the neighbor cache state for the MNP-ULA is REACHABLE, the Proxy/ 2006 Server forwards the carrier packets to the Client which then must 2007 reassemble. (Note that the Proxy/Server does not reassemble carrier 2008 packets not explicitly addressed to its own ADM-ULA, since some of 2009 the carrier packets of the same original IP packet could be forwarded 2010 through a different Proxy/Server.) In that case, the Client may 2011 receive fragments that are smaller than its link MTU but that can 2012 still be reassembled. 2014 Note: Proxy/Servers may receive carrier packets with ORHs that 2015 include additional forwarding information. Proxy/Servers use the 2016 forwarding information to determine the correct interface for 2017 forwarding to the target Client, then remove the ORH and forward the 2018 carrier packet. If the ORH information instead indicates that the 2019 Proxy/Server is responsible for reassembly, the Proxy/Server 2020 reassembles first before re-encapsulating (and possibly also re- 2021 fragmenting) then forwards to the target Client. For a full 2022 discussion of cases when the Proxy/Server may receive carrier packets 2023 with ORHs, see: Section 3.14.6. 2025 Note: Clients and their FHS Proxy/Server peers can exchange original 2026 IP packets over ANET underlying interfaces without invoking the OAL, 2027 since the ANET is secured at the link and physical layers. By 2028 forwarding original IP packets without invoking the OAL, however, the 2029 Client and Proxy/Server can engage only in classical path MTU 2030 discovery since the packets are subject to loss and/or corruption due 2031 to the various per-link MTU limitations that may occur within the 2032 ANET. Moreover, the original IP packets do not include either the 2033 OAL integrity check or per-packet Identification values that can be 2034 used for data origin authentication and link-layer retransmissions. 2035 The tradeoff therefore involves an assessment of the per-packet 2036 encapsulation overhead saved by bypassing the OAL vs. inheritance of 2037 classical network "brittleness". (Note however that ANET peers can 2038 send small original IP packets without invoking the OAL, while 2039 invoking the OAL for larger packets. This presents the beneficial 2040 aspects of both small packet efficiency and large packet robustness.) 2042 Note: When a Proxy/Server receives a (non-OAL) original IP packet 2043 from an ANET Client, or a carrier packet with OAL destination set to 2044 its own ADM-ULA from any Client, the Proxy/Server reassembles if 2045 necessary then performs ROS functions on behalf of the Client. The 2046 Client may at some later time begin sending carrier packets to the 2047 OAL address of the actual target instead of the Proxy/Server, at 2048 which point it may begin functioning as an ROS on its own behalf and 2049 thereby "override" the Proxy/Server's ROS role. 2051 Note; Proxy/Servers drop any original IP packets (received either 2052 directly from an ANET Client or following reassembly of carrier 2053 packets received from an ANET/INET Client) with a destination that 2054 corresponds to the Client's delegated MNP. Similarly, Proxy/Servers 2055 drop any carrier packet received with both a source and destination 2056 that correspond to the Client's delegated MNP. These checks are 2057 necessary to prevent Clients from either accidentally or 2058 intentionally establishing endless loops that could congest Proxy/ 2059 Servers and/or ANET/INET links. 2061 Note: Proxy/Servers forward secure control plane carrier packets via 2062 the SRT secured spanning tree and forwards other carrier packets via 2063 the unsecured spanning tree. When a Proxy/Server receives a carrier 2064 packet from the secured spanning tree, it considers the message as 2065 authentic without having to verify upper layer authentication 2066 signatures. When a Proxy/Server receives a carrier packet from the 2067 unsecured spanning tree, it verifies any upper layer authentication 2068 signatures and/or forwards the unsecured message toward the 2069 destination which must apply data origin authentication. 2071 Note: If the Proxy/Server has multiple original IP packets to send to 2072 the same neighbor, it can concatenate them in a single OAL super- 2073 packet [I-D.templin-6man-omni]. 2075 3.10.3. Bridge Forwarding Algorithm 2077 Bridges forward carrier packets while decrementing the OAL header Hop 2078 Count but not the original IP header Hop Count/TTL. Bridges convey 2079 carrier packets that encapsulate IPv6 ND control messages or routing 2080 protocol control messages via the secured spanning tree, and may 2081 convey carrier packets that encapsulate ordinary data via the 2082 unsecured spanning tree. When the Bridge receives a carrier packet, 2083 it removes the outer *NET header and searches for a forwarding table 2084 entry that matches the OAL destination address. The Bridge then 2085 processes the packet as follows: 2087 o if the carrier packet destination matches its ADM-ULA or the 2088 corresponding ADM-ULA Subnet Router Anycast address and the OAL 2089 header is followed by an ORH, the Bridge reassembles if necessary 2090 then sets aside the ORH and processes the carrier packet locally 2091 before forwarding. If the OAL packet contains an NA(NUD) message, 2092 the Bridge writes FMT/SRT/LHS/L2ADDR information for its own INET 2093 interface over the OMNI option Interface Attributes sub-option 2094 supplied by the NA(NUD) message source. The Bridge next examines 2095 the ORH, and if FMT-Mode indicates the destination is a Client on 2096 the open *NET (or, a Client behind a NAT for which NAT traversal 2097 procedures have already converged) the Bridge writes the MNP-ULA 2098 formed from the ORH Destination Suffix into the OAL destination. 2099 The Bridge then removes the ORH and forwards the packet using 2100 encapsulation based on L2ADDR. If the LHS Proxy/Server will 2101 forward to the Client without reassembly, the Bridge writes the 2102 MNP-ULA into the OAL destination then replaces the ORH with an 2103 ORH-0 and forwards the carrier packet to the LHS Proxy/Server 2104 while also invoking NAT traversal procedures if necessary (noting 2105 that no direct bubbles are necessary since only the target Client 2106 and not the Bridge is behind a NAT). If the LHS Proxy/Server must 2107 perform reassembly before forwarding to the Client, the Bridge 2108 instead writes the ADM-ULA formed from the ORH SRT/LHS into the 2109 OAL destination address, replaces the ORH with an ORH-0 and 2110 forwards the carrier packet to the LHS Proxy/Server. 2112 o else, if the carrier packet destination matches its ADM-ULA or the 2113 corresponding ADM-ULA Subnet Router Anycast address and the OAL 2114 header is not followed by an ORH with Segments Left set to 1, the 2115 Bridge submits the packet for reassembly. When reassembly is 2116 complete, the Bridge submits the original IP packet to the network 2117 layer to support local applications such as BGP routing protocol 2118 sessions. 2120 o else, if the carrier packet destination matches a forwarding table 2121 entry the Bridge forwards the carrier packet to the next hop. (If 2122 the destination matches an MSP without matching an MNP, however, 2123 the Bridge instead drops the packet and returns a Destination 2124 Unreachable message subject to rate limiting - see: Section 3.11). 2126 o else, the Bridge drops the packet and returns an Destination 2127 Unreachable as above. 2129 The Bridge decrements the OAL IPv6 header Hop Limit when it forwards 2130 the carrier packet and drops the packet if the Hop Limit reaches 0. 2131 Therefore, only the Hop Limit in the OAL header is decremented and 2132 not the TTL/Hop Limit in the original IP packet header. Bridges do 2133 not insert OAL/ORH headers themselves; instead, they simply forward 2134 carrier packets based on their destination addresses while also 2135 possibly transforming larger ORHs into an ORH-0 (or removing the ORH 2136 altogether). 2138 Bridges forward carrier packets received from a first segment via the 2139 SRT secured spanning tree to the next segment also via the secured 2140 spanning tree. Bridges forward carrier packets received from a first 2141 segment via the unsecured spanning tree to the next segment also via 2142 the unsecured spanning tree. Bridges use a single IPv6 routing table 2143 that always determines the same next hop for a given OAL destination, 2144 where the secured/unsecured spanning tree is determined through the 2145 selection of the underlying interface to be used for transmission 2146 (i.e., a secured tunnel or an open INET interface). 2148 3.11. OMNI Interface Error Handling 2150 When an AERO node admits an original IP packet into the OMNI 2151 interface, it may receive link-layer or network-layer error 2152 indications. The AERO node may also receive OMNI link error 2153 indications in OAL-encapsulated uNA messages that include 2154 authentication signatures. 2156 A link-layer error indication is an ICMP error message generated by a 2157 router in the INET on the path to the neighbor or by the neighbor 2158 itself. The message includes an IP header with the address of the 2159 node that generated the error as the source address and with the 2160 link-layer address of the AERO node as the destination address. 2162 The IP header is followed by an ICMP header that includes an error 2163 Type, Code and Checksum. Valid type values include "Destination 2164 Unreachable", "Time Exceeded" and "Parameter Problem" 2165 [RFC0792][RFC4443]. (OMNI interfaces ignore link-layer IPv4 2166 "Fragmentation Needed" and IPv6 "Packet Too Big" messages for carrier 2167 packets that are no larger than the minimum/path MPS as discussed in 2168 Section 3.9, however these messages may provide useful hints of probe 2169 failures during path MPS probing.) 2171 The ICMP header is followed by the leading portion of the carrier 2172 packet that generated the error, also known as the "packet-in-error". 2173 For ICMPv6, [RFC4443] specifies that the packet-in-error includes: 2174 "As much of invoking packet as possible without the ICMPv6 packet 2175 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 2176 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 2177 "Internet Header + 64 bits of Original Data Datagram", however 2178 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 2179 ICMP datagram SHOULD contain as much of the original datagram as 2180 possible without the length of the ICMP datagram exceeding 576 2181 bytes". 2183 The link-layer error message format is shown in Figure 5: 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 ~ ~ 2187 | IP Header of link layer | 2188 | error message | 2189 ~ ~ 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | ICMP Header | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2193 ~ ~ P 2194 | carrier packet *NET and OAL | a 2195 | encapsulation headers | c 2196 ~ ~ k 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 2198 ~ ~ t 2199 | original IP packet headers | 2200 | (first-fragment only) | i 2201 ~ ~ n 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 ~ ~ e 2204 | Portion of the body of | r 2205 | the original IP packet | r 2206 | (all fragments) | o 2207 ~ ~ r 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 2210 Figure 5: OMNI Interface Link-Layer Error Message Format 2212 The AERO node rules for processing these link-layer error messages 2213 are as follows: 2215 o When an AERO node receives a link-layer Parameter Problem message, 2216 it processes the message the same as described as for ordinary 2217 ICMP errors in the normative references [RFC0792][RFC4443]. 2219 o When an AERO node receives persistent link-layer Time Exceeded 2220 messages, the IP ID field may be wrapping before earlier fragments 2221 awaiting reassembly have been processed. In that case, the node 2222 should begin including integrity checks and/or institute rate 2223 limits for subsequent packets. 2225 o When an AERO node receives persistent link-layer Destination 2226 Unreachable messages in response to carrier packets that it sends 2227 to one of its neighbor correspondents, the node should process the 2228 message as an indication that a path may be failing, and 2229 optionally initiate NUD over that path. If it receives 2230 Destination Unreachable messages over multiple paths, the node 2231 should allow future carrier packets destined to the correspondent 2232 to flow through a default route and re-initiate route 2233 optimization. 2235 o When an AERO Client receives persistent link-layer Destination 2236 Unreachable messages in response to carrier packets that it sends 2237 to one of its neighbor Proxy/Servers, the Client should mark the 2238 path as unusable and use another path. If it receives Destination 2239 Unreachable messages on many or all paths, the Client should 2240 associate with a new Proxy/Server and release its association with 2241 the old Proxy/Server as specified in Section 3.16.5. 2243 o When an AERO Proxy/Server receives persistent link-layer 2244 Destination Unreachable messages in response to carrier packets 2245 that it sends to one of its neighbor Clients, the Proxy/Server 2246 should mark the underlying path as unusable and use another 2247 underlying path. 2249 o When an AERO Proxy/Server receives link-layer Destination 2250 Unreachable messages in response to a carrier packet that it sends 2251 to one of its permanent neighbors, it treats the messages as an 2252 indication that the path to the neighbor may be failing. However, 2253 the dynamic routing protocol should soon reconverge and correct 2254 the temporary outage. 2256 When an AERO Bridge receives a carrier packet for which the network- 2257 layer destination address is covered by an MSP, the Bridge drops the 2258 packet if there is no more-specific routing information for the 2259 destination and returns an OMNI interface Destination Unreachable 2260 message subject to rate limiting. 2262 When an AERO node receives a carrier packet for which reassembly is 2263 currently congested, it returns an OMNI interface Packet Too Big 2264 (PTB) message as discussed in [I-D.templin-6man-omni] (note that the 2265 PTB messages could indicate either "hard" or "soft" errors). 2267 AERO nodes include ICMPv6 error messages intended for the OAL source 2268 as sub-options in the OMNI option of secured uNA messages. When the 2269 OAL source receives the uNA message, it can extract the ICMPv6 error 2270 message enclosed in the OMNI option and either process it locally or 2271 translate it into a network-layer error to return to the original 2272 source. 2274 3.12. AERO Router Discovery, Prefix Delegation and Autoconfiguration 2276 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 2277 coordinated as discussed in the following Sections. 2279 3.12.1. AERO Service Model 2281 Each AERO Proxy/Server on the OMNI link is configured to facilitate 2282 Client prefix delegation/registration requests. Each Proxy/Server is 2283 provisioned with a database of MNP-to-Client ID mappings for all 2284 Clients enrolled in the AERO service, as well as any information 2285 necessary to authenticate each Client. The Client database is 2286 maintained by a central administrative authority for the OMNI link 2287 and securely distributed to all Proxy/Servers, e.g., via the 2288 Lightweight Directory Access Protocol (LDAP) [RFC4511], via static 2289 configuration, etc. Clients receive the same service regardless of 2290 the Proxy/Servers they select. 2292 AERO Clients and Proxy/Servers use ND messages to maintain neighbor 2293 cache entries. AERO Proxy/Servers configure their OMNI interfaces as 2294 advertising NBMA interfaces, and therefore send unicast RA messages 2295 with a short Router Lifetime value (e.g., ReachableTime seconds) in 2296 response to a Client's RS message. Thereafter, Clients send 2297 additional RS messages to keep Proxy/Server state alive. 2299 AERO Clients and Proxy/Servers include prefix delegation and/or 2300 registration parameters in RS/RA messages (see 2301 [I-D.templin-6man-omni]). The ND messages are exchanged between 2302 Client and FHS Proxy/Servers according to the prefix management 2303 schedule required by the service. If the Client knows its MNP in 2304 advance, it can employ prefix registration by including its MNP-LLA 2305 as the source address of an RS message and with an OMNI option with 2306 valid prefix registration information for the MNP. If the Proxy/ 2307 Server accepts the Client's MNP assertion, it injects the MNP into 2308 the routing system and establishes the necessary neighbor cache 2309 state. If the Client does not have a pre-assigned MNP, it can 2310 instead employ prefix delegation by including the unspecified address 2311 (::) as the source address of an RS message and with an OMNI option 2312 with prefix delegation parameters to request an MNP. 2314 The following sections specify the Client and Proxy/Server behavior. 2316 3.12.2. AERO Client Behavior 2318 AERO Clients discover the addresses of candidate FHS Proxy/Servers in 2319 a similar manner as described in [RFC5214]. Discovery methods 2320 include static configuration (e.g., from a flat-file map of Proxy/ 2321 Server addresses and locations), or through an automated means such 2322 as Domain Name System (DNS) name resolution [RFC1035]. 2323 Alternatively, the Client can discover Proxy/Server addresses through 2324 a layer 2 data link login exchange, or through a unicast RA response 2325 to a multicast/anycast RS as described below. In the absence of 2326 other information, the Client can resolve the DNS Fully-Qualified 2327 Domain Name (FQDN) "linkupnetworks.[domainname]" where 2328 "linkupnetworks" is a constant text string and "[domainname]" is a 2329 DNS suffix for the OMNI link (e.g., "example.com"). 2331 To associate with a FHS Proxy/Server over an underlying interface, 2332 the Client acts as a requesting router to request MNPs by preparing 2333 an RS message with prefix management parameters. If the Client 2334 already knows the Proxy/Server's ADM-LLA, it includes the LLA as the 2335 network-layer destination address; otherwise, the Client includes the 2336 (link-local) All-Routers multicast as the network-layer destination. 2337 If the Client already knows its own MNP-LLA, it can use the MNP-LLA 2338 as the network-layer source address and include an OMNI option with 2339 prefix registration information. Otherwise, the Client uses the 2340 unspecified address (::) as the network-layer source address and 2341 includes prefix delegation parameters in the OMNI option (see: 2342 [I-D.templin-6man-omni]). 2344 The Client next includes Interface Attributes corresponding to the 2345 underlying interface over which it will send the RS message, and MAY 2346 include additional Interface Attributes specific to other underlying 2347 interfaces. Next, the Client submits the RS for OAL encapsulation 2348 and fragmentation if necessary with its own MNP-ULA and the Proxy/ 2349 Server's ADM-ULA or (site-scoped) All-Routers multicast as the OAL 2350 addresses while selecting an Identification value and invoking window 2351 synchronization as specified in [I-D.templin-6man-omni]. 2353 The Client then sends the RS (either directly via Direct interfaces, 2354 via a VPN for VPNed interfaces, via an access router for ANET 2355 interfaces or via INET encapsulation for INET interfaces) then waits 2356 up to RetransTimer milliseconds for an RA message reply (see 2357 Section 3.12.3) (retrying up to MAX_RTR_SOLICITATIONS). If the 2358 Client receives no RAs, or if it receives an RA with Router Lifetime 2359 set to 0, the Client SHOULD abandon attempts through the first 2360 candidate FHS Proxy/Server and try another Proxy/Server. Otherwise, 2361 the Client processes the prefix information found in the RA message. 2363 When the Client processes an RA, it first performs OAL reassembly and 2364 decapsulation if necessary then creates a NCE with the Proxy/Server's 2365 ADM-LLA as the network-layer address and the Proxy/Server's 2366 encapsulation and/or link-layer addresses as the link-layer address. 2367 The Client next records the RA Router Lifetime field value in the NCE 2368 as the time for which the Proxy/Server has committed to maintaining 2369 the MNP in the routing system via this underlying interface, and 2370 caches the other RA configuration information including Cur Hop 2371 Limit, M and O flags, Reachable Time and Retrans Timer. The Client 2372 then autoconfigures MNP-LLAs for any delegated MNPs and assigns them 2373 to the OMNI interface. The Client also caches any MSPs included in 2374 Route Information Options (RIOs) [RFC4191] as MSPs to associate with 2375 the OMNI link, and assigns the MTU value in the MTU option to the 2376 underlying interface. 2378 The Client then registers its additional underlying interfaces with 2379 FHS Proxy/Servers for those interfaces discovered by sending RS 2380 messages via each additional interface as described above. The RS 2381 messages include the same parameters as for the initial RS/RA 2382 exchange, but with destination address set to the Proxy/Server's ADM- 2383 LLA. The Client finally sub-delegates the MNPs to its attached EUNs 2384 and/or the Client's own internal virtual interfaces as described in 2385 [I-D.templin-v6ops-pdhost] to support the Client's downstream 2386 attached "Internet of Things (IoT)". The Client then sends 2387 additional RS messages over each underlying interface before the 2388 Router Lifetime received for that interface expires. 2390 After the Client registers its underlying interfaces, it may wish to 2391 change one or more registrations, e.g., if an interface changes 2392 address or becomes unavailable, if traffic selectors change, etc. To 2393 do so, the Client prepares an RS message to send over any available 2394 underlying interface as above. The RS includes an OMNI option with 2395 prefix registration/delegation information, with Interface Attributes 2396 specific to the selected underlying interface, and with any 2397 additional Interface Attributes specific to other underlying 2398 interfaces. When the Client receives the Proxy/Server's RA response, 2399 it has assurance that the Proxy/Server has been updated with the new 2400 information. 2402 If the Client wishes to discontinue use of a Proxy/Server it issues 2403 an RS message over any underlying interface with an OMNI option with 2404 a prefix release indication. When the Proxy/Server processes the 2405 message, it releases the MNP, sets the NCE state for the Client to 2406 DEPARTED and returns an RA reply with Router Lifetime set to 0. 2407 After a short delay (e.g., 2 seconds), the Proxy/Server withdraws the 2408 MNP from the routing system. 2410 3.12.3. AERO Proxy/Server Behavior 2412 AERO Proxy/Servers act as both IP routers and ND proxies, and support 2413 a prefix delegation/registration service for Clients. Proxy/Servers 2414 arrange to add their ADM-LLAs to a static map of Proxy/Server 2415 addresses for the link and/or the DNS resource records for the FQDN 2416 "linkupnetworks.[domainname]" before entering service. The static 2417 map and/or DNS resource records should be arranged such that Clients 2418 can discover the addresses of Proxy/Servers that are geographically 2419 and/or topologically "close" to their underlying network connections. 2421 When an FHS Proxy/Server receives a prospective Client's RS message 2422 on its OMNI interface, it SHOULD return an immediate RA reply with 2423 Router Lifetime set to 0 if it is currently too busy or otherwise 2424 unable to service the Client. Otherwise, the Proxy/Server performs 2425 OAL reassembly and decapsulation if necessary, then authenticates the 2426 RS message and processes the prefix delegation/registration 2427 parameters. The Proxy/Server first determines the correct MNPs to 2428 provide to the Client by processing the MNP-LLA prefix parameters 2429 and/or the DHCPv6 OMNI sub-option. When the Proxy/Server returns the 2430 MNPs, it also creates a forwarding table entry for the MNP-ULA 2431 corresponding to each MNP so that the MNPs are propagated into the 2432 routing system (see: Section 3.2.3). For IPv6, the Proxy/Server 2433 creates an IPv6 forwarding table entry for each MNP. For IPv4, the 2434 Proxy/Server creates an IPv6 forwarding table entry with the 2435 IPv4-compatibility MNP-ULA prefix corresponding to the IPv4 address. 2437 The Proxy/Server next creates a NCE for the Client using the base 2438 MNP-LLA as the network-layer address. Next, the Proxy/Server updates 2439 the NCE by recording the information in each Interface Attributes 2440 sub-option in the RS OMNI option. The Proxy/Server also records the 2441 actual OAL/*NET addresses and RS message window synchronization 2442 parameters (if any) in the NCE. 2444 Next, the Proxy/Server prepares an RA message using its ADM-LLA as 2445 the network-layer source address and the network-layer source address 2446 of the RS message as the network-layer destination address. The 2447 Proxy/Server sets the Router Lifetime to the time for which it will 2448 maintain both this underlying interface individually and the NCE as a 2449 whole. The Proxy/Server also sets Cur Hop Limit, M and O flags, 2450 Reachable Time and Retrans Timer to values appropriate for the OMNI 2451 link. The Proxy/Server includes the MNPs, any other prefix 2452 management parameters and an OMNI option with no Interface Attributes 2453 but with an Origin Indication sub-option per [I-D.templin-6man-omni] 2454 with the mapped and obfuscated Port Number and IP address 2455 corresponding to the Client's own INET address in the case of INET 2456 Clients or to the Proxy/Server's INET-facing address for all other 2457 Clients. The Proxy/Server should also include an Interface 2458 Attributes sub-option in the OMNI option with FMT/SRT/LHS information 2459 for its INET interface. The Proxy/Server then includes one or more 2460 RIOs that encode the MSPs for the OMNI link, plus an MTU option (see 2461 Section 3.9). The Proxy/Server finally forwards the message to the 2462 Client using OAL encapsulation/fragmentation if necessary while 2463 including an acknowledgement if the RS invoked window 2464 synchronization. 2466 After the initial RS/RA exchange, the Proxy/Server maintains a 2467 ReachableTime timer for each of the Client's underlying interfaces 2468 individually (and for the Client's NCE collectively) set to expire 2469 after ReachableTime seconds. If the Client (or Proxy) issues 2470 additional RS messages, the Proxy/Server sends an RA response and 2471 resets ReachableTime. If the Proxy/Server receives an ND message 2472 with a prefix release indication it sets the Client's NCE to the 2473 DEPARTED state and withdraws the MNP from the routing system after a 2474 short delay (e.g., 2 seconds). If ReachableTime expires before a new 2475 RS is received on an individual underlying interface, the Proxy/ 2476 Server marks the interface as DOWN. If ReachableTime expires before 2477 any new RS is received on any individual underlying interface, the 2478 Proxy/Server sets the NCE state to STALE and sets a 10 second timer. 2479 If the Proxy/Server has not received a new RS or ND message with a 2480 prefix release indication before the 10 second timer expires, it 2481 deletes the NCE and withdraws the MNP from the routing system. 2483 The Proxy/Server processes any ND messages pertaining to the Client 2484 and returns an NA/RA reply in response to solicitations. The Proxy/ 2485 Server may also issue unsolicited RA messages, e.g., with reconfigure 2486 parameters to cause the Client to renegotiate its prefix delegation/ 2487 registrations, with Router Lifetime set to 0 if it can no longer 2488 service this Client, etc. Finally, If the NCE is in the DEPARTED 2489 state, the Proxy/Server deletes the entry after DepartTime expires. 2491 Note: Clients SHOULD notify former Proxy/Servers of their departures, 2492 but Proxy/Servers are responsible for expiring neighbor cache entries 2493 and withdrawing routes even if no departure notification is received 2494 (e.g., if the Client leaves the network unexpectedly). Proxy/Servers 2495 SHOULD therefore set Router Lifetime to ReachableTime seconds in 2496 solicited RA messages to minimize persistent stale cache information 2497 in the absence of Client departure notifications. A short Router 2498 Lifetime also ensures that proactive RS/RA messaging between Clients 2499 and Proxy/Servers will keep any NAT state alive (see above). 2501 Note: All Proxy/Servers on an OMNI link MUST advertise consistent 2502 values in the RA Cur Hop Limit, M and O flags, Reachable Time and 2503 Retrans Timer fields the same as for any link, since unpredictable 2504 behavior could result if different Proxy/Servers on the same link 2505 advertised different values. 2507 3.12.3.1. DHCPv6-Based Prefix Registration 2509 When a Client is not pre-provisioned with an MNP-LLA, it will need 2510 for the FHS Proxy/Server to select one or more MNPs on its behalf and 2511 set up the correct state in the AERO routing service. (A Client with 2512 a pre-provisioned MNP may also request the Proxy/Server to select 2513 additional MNPs.) The DHCPv6 service [RFC8415] is used to support 2514 this requirement. 2516 When a Client needs to have the FHS Proxy/Server select MNPs, it 2517 sends an RS message with source address set to the unspecified 2518 address (::) and with an OMNI option that includes a DHCPv6 message 2519 sub-option with DHCPv6 Prefix Delegation (DHCPv6-PD) parameters. 2520 When the Proxy/Server receives the RS message, it extracts the 2521 DHCPv6-PD message from the OMNI option. 2523 The Proxy/Server then acts as a "Proxy DHCPv6 Client" in a message 2524 exchange with the locally-resident DHCPv6 server, which delegates 2525 MNPs and returns a DHCPv6-PD Reply message. (If the Proxy/Server 2526 wishes to defer creation of MN state until the DHCPv6-PD Reply is 2527 received, it can instead act as a Lightweight DHCPv6 Relay Agent per 2528 [RFC6221] by encapsulating the DHCPv6-PD message in a Relay-forward/ 2529 reply exchange with Relay Message and Interface ID options.) 2531 When the Proxy/Server receives the DHCPv6-PD Reply, it adds a route 2532 to the routing system and creates an MNP-LLA based on the delegated 2533 MNP. The Proxy/Server then sends an RA back to the Client with the 2534 (newly-created) MNP-LLA as the destination address and with the 2535 DHCPv6-PD Reply message coded in the OMNI option. When the Client 2536 receives the RA, it creates a default route, assigns the Subnet 2537 Router Anycast address and sets its MNP-LLA based on the delegated 2538 MNP. 2540 Note: See [I-D.templin-6man-omni] for an MNP delegation alternative 2541 that avoids including a DHCPv6 message sub-option in the RS. Namely, 2542 when the Client requests a single MNP it can set the RS source to the 2543 unspecified address (::) and include a Node Identification sub-option 2544 and Preflen in the OMNI option (but with no DHCPv6 message sub- 2545 option). When the Proxy/Server receives the RS message, it forwards 2546 a self-generated DHCPv6 Solicit message to the DHCPv6 server on 2547 behalf of the Client. When the Proxy/Server receives the DHCPv6 2548 Reply, it prepares an RA message with an OMNI option with Preflen 2549 information (but with no DHCPv6 message sub-option), then places the 2550 (newly-created) MNP-LLA in the RA destination address and returns the 2551 message to the Client. 2553 3.13. The AERO Proxy Function 2555 Clients connect to the OMNI link via FHS Proxy/Servers, with one or 2556 more FHS Proxy/Servers for each underlying interface. Each of the 2557 Client's FHS Proxy/Servers must be informed of all of the Client's 2558 additional underlying interfaces. For Clients on Direct and VPNed 2559 underlying interfaces the Proxy/Server "A" for that interface is 2560 directly connected, for Clients on ANET underlying interfaces Proxy/ 2561 Server "A" is located on the ANET/INET boundary, and for Clients on 2562 INET underlying interfaces Proxy/Server "A" is located somewhere in 2563 the connected Internetwork. When the Client registers with Proxy/ 2564 Server "A", it must also report the registration to any other Proxy/ 2565 Servers for other underlying interfaces "B", "C", "D", etc. for which 2566 an underlying interface relationship has already been established. 2567 The Proxy/Server satisfies these requirements as follows: 2569 o when FHS Proxy/Server "A" receives a Client RS message, it first 2570 verifies that the OAL Identification is within the window for the 2571 NCE that matches the MNP-ULA for this Client neighbor and 2572 authenticates the message. (If no NCE was found, Proxy/Server "A 2573 instead creates one in the STALE state and returns an RA message 2574 with an authentication signature and any window synchronization 2575 parameters.) Proxy/Server "A" then examines the network-layer 2576 destination address. If the destination address is the ADM-LLA of 2577 a different Proxy/Server "B" (or, if the OMNI option included an 2578 MS-Register sub-option with the ADM-LLAs of one or more different 2579 "LHS" Proxy/Servers "B", "C", "D", etc.), Proxy/Server "A" 2580 prepares a separate proxyed version of the RS message with an OAL 2581 header with source set to its own ADM-ULA and destination set to 2582 the LHS Proxy/Server's ADM-ULA. Proxy/Server "A" also overwrites 2583 the OMNI header Interface Attributes option supplied by the Client 2584 with its own FMT/SRT/LHS/L2ADDR information. Proxy/Server "A" 2585 then sets the S/T-omIndex to the value for this Client underlying 2586 interface, then forwards the message into the OMNI link secured 2587 spanning tree. 2589 o when LHS Proxy/Server "B" receives the RS, it authenticates the 2590 message then creates or updates a NCE for the Client with FHS 2591 Proxy/Server "A"'s Interface Attributes as the link-layer address 2592 information for this S/T-omIndex and caches any window 2593 synchronization parameters supplied by the Client. LHS Proxy/ 2594 Server "B" then prepares an RA message with source set to its own 2595 LLA and destination set to the Client's MNP-LLA, and with any 2596 window synchronization acknowledgements. Proxy/Server "B" then 2597 encapsulates the RA in an OAL header with source set to its own 2598 ADM-ULA and destination set to the ADM-ULA of Proxy/Server "A, 2599 performs fragmentation if necessary, then sends the resulting 2600 carrier packets into the secured spanning tree. 2602 o when Proxy/Server "A" reassembles the RA, it locates the Client 2603 NCE based on the RA destination LLA. Proxy/Server "A" then re- 2604 encapsulates the RA message with OAL source set to its own ADM-ULA 2605 and OAL destination set to the MNP-ULA of the Client, includes an 2606 authentication signature if necessary, fragments if necessary and 2607 returns the fragments to the Client. 2609 o The Client repeats this process over each of its additional 2610 underlying interfaces while treating each Proxy/Server "B", "C", 2611 "D" as an FHS while providing MS-Register information for other 2612 Proxy/Servers as an LHS. 2614 After the initial RS/RA exchanges each Proxy/Server forwards any of 2615 the Client's carrier packets with OAL destinations for which there is 2616 no matching NCE to a Bridge using OAL encapsulation with its own ADM- 2617 ULA as the source and the destination determined by the ORH supplied 2618 by the Client. The Proxy/Server instead forwards any carrier packets 2619 destined to a neighbor cache target directly to the target according 2620 to the OAL/link-layer information - the process of establishing 2621 neighbor cache entries is specified in Section 3.14. 2623 While the Client is still associated with each Proxy/Server "A", "A" 2624 can send NS, RS and/or unsolicited NA messages to update the neighbor 2625 cache entries of other AERO nodes on behalf of the Client and/or to 2626 convey Interface Attributes updates. This allows for higher- 2627 frequency Proxy-initiated RS/RA messaging over well-connected INET 2628 infrastructure supplemented by lower-frequency Client-initiated RS/RA 2629 messaging over constrained ANET data links. 2631 If any Proxy/Server "B", "C", "D" ceases to send solicited RAs, 2632 Proxy/Server "A" sends unsolicited RAs to the Client with destination 2633 set to (link-local) All-Nodes multicast and with Router Lifetime set 2634 to zero to inform Clients that a Proxy/Server has failed. Although 2635 Proxy/Server "A" can engage in ND exchanges on behalf of the Client, 2636 the Client can also send ND messages on its own behalf, e.g., if it 2637 is in a better position than "A" to convey Interface Attribute 2638 changes, etc. The ND messages sent by the Client include the 2639 Client's MNP-LLA as the source in order to differentiate them from 2640 the ND messages sent by Proxy/Server "A". 2642 If the Client becomes unreachable over all underlying interface it 2643 serves, Proxy/Server "A" sets the NCE state to DEPARTED and retains 2644 the entry for DepartTime seconds. While the state is DEPARTED, 2645 Proxy/Server "A" forwards any carrier packets destined to the Client 2646 to a Bridge via OAL/ORH encapsulation. When DepartTime expires, 2647 Proxy/Server "A" deletes the NCE and discards any further carrier 2648 packets destined to the former Client. 2650 In some ANETs that employ a Proxy/Server, the Client's MNP can be 2651 injected into the ANET routing system. In that case, the Client can 2652 send original IP packets without invoking the OAL so that the ANET 2653 routing system transports the original IP packets to the Proxy. This 2654 can be very beneficial, e.g., if the Client connects to the ANET via 2655 low-end data links such as some aviation wireless links. 2657 If the ANET first-hop access router is on the same underlying link as 2658 the Client and recognizes the AERO/OMNI protocol, the Client can 2659 avoid OAL encapsulation for both its control and data messages. When 2660 the Client connects to the link, it can send an unencapsulated RS 2661 message with source address set to its own MNP-LLA (or to a Temporary 2662 LLA), and with destination address set to the ADM-LLA of the Client's 2663 selected Proxy/Server or to (link-local) All-Routers multicast. The 2664 Client includes an OMNI option formatted as specified in 2665 [I-D.templin-6man-omni]. The Client then sends the unencapsulated RS 2666 message, which will be intercepted by the AERO-Aware access router. 2668 The ANET access router then performs OAL encapsulation on the RS 2669 message and forwards it to a Proxy/Server at the ANET/INET boundary. 2670 When the access router and Proxy/Server are one and the same node, 2671 the Proxy/Server would share and underlying link with the Client but 2672 its message exchanges with outside correspondents would need to pass 2673 through a security gateway at the ANET/INET border. The method for 2674 deploying access routers and Proxys (i.e. as a single node or 2675 multiple nodes) is an ANET-local administrative consideration. 2677 Note: When a Proxy/Server alters the IPv6 ND message contents before 2678 forwarding (e.g., such as altering the OMNI option contents), the 2679 IPv6 ND message checksum and/or authentication signature are 2680 invalidated. If the Proxy/Server forwards the message over the 2681 secured spanning tree, however, it need not re-calculate the 2682 checksum/signature since they will not be examined by the next hop. 2684 Note: The Proxy/Server can apply packing as discussed in 2685 [I-D.templin-6man-omni] if an opportunity arises to concatenate 2686 multiple original IP packets destined to the same neighbor. 2688 3.13.1. Detecting and Responding to Proxy/Server Failures 2690 In environments where fast recovery from Proxy/Server failure is 2691 required, Proxy/Server "A" SHOULD use proactive Neighbor 2692 Unreachability Detection (NUD) to track each peer Proxy/Server "B" 2693 reachability in a similar fashion as for Bidirectional Forwarding 2694 Detection (BFD) [RFC5880]. Proxy/Server "A" can then quickly detect 2695 and react to failures so that cached information is re-established 2696 through alternate paths. The NUD control messaging is carried only 2697 over well-connected ground domain networks (i.e., and not low-end 2698 aeronautical radio links) and can therefore be tuned for rapid 2699 response. 2701 Proxy/Server "A" performs proactive NUD with peer Proxy/Server "B" 2702 for which there are currently active Clients by sending continuous NS 2703 messages in rapid succession, e.g., one message per second. Proxy/ 2704 Server "A" sends the NS message via the spanning tree with its own 2705 ADM-LLA as the source and the ADM-LLA of the peer Proxy/Server "B" as 2706 the destination. When Proxy/Server "A" is also sending RS messages 2707 to the peer Proxy/Server "B" on behalf of ANET Clients, the resulting 2708 RA responses can be considered as equivalent hints of forward 2709 progress. This means that Proxy/Server "B" need not also send a 2710 periodic NS if it has already sent an RS within the same period. If 2711 the peer Proxy/Server "B" fails (i.e., if "A" ceases to receive 2712 advertisements), Proxy/Server "A" can quickly inform Clients by 2713 sending multicast RA messages on the ANET interface. 2715 Proxy/Server "A" sends RA messages on the ANET interface with source 2716 address set to Proxy/Server "B"'s address, destination address set to 2717 (link-local) All-Nodes multicast, and Router Lifetime set to 0. 2718 Proxy/Server "A" SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages 2719 separated by small delays [RFC4861]. Any Clients on the ANET that 2720 had been using the failed Proxy/Server "B" will receive the RA 2721 messages and associate with a new Proxy/Server. 2723 3.13.2. Point-to-Multipoint Proxy/Server Coordination 2725 In environments where Client messaging over ANETs is bandwidth- 2726 limited and/or expensive, Clients can enlist the services of Proxy/ 2727 Server "A" to coordinate with multiple Proxy/Servers "B", "C", "D" 2728 etc. in a single RS/RA message exchange. The Client can send a 2729 single RS message to (link-local) All-Routers multicast that includes 2730 the ID's of multiple Proxy/Servers in MS-Register sub-options of the 2731 OMNI option. 2733 When Proxy/Server "A" receives the RS and processes the OMNI option, 2734 it sends a separate RS to each MS-Register Proxy/Server ID. When 2735 Proxy/Server "A" receives an RA, it can optionally return an 2736 immediate "singleton" RA to the Client or record the Proxy/Server's 2737 ID for inclusion in a pending "aggregate" RA message. Proxy/Server 2738 "A" can then return aggregate RA messages to the Client including 2739 multiple Proxy/Server IDs in order to conserve bandwidth. Each RA 2740 includes a proper subset of the Proxy/Server IDs from the original RS 2741 message, and Proxy/Server "A" must ensure that the message contents 2742 of each RA are consistent with the information received from the 2743 (aggregated) additional Proxy/Servers. 2745 Clients can thereafter employ efficient point-to-multipoint Proxy/ 2746 Server coordination under the assistance of Proxy/Server "A" to 2747 reduce the number of messages sent over the ANET while enlisting the 2748 support of multiple Proxy/Servers for fault tolerance. Clients can 2749 further include MS-Release sub-options in IPv6 ND messages to request 2750 Proxy/Server "A" to release from former Proxy/Servers via the 2751 procedures discussed in Section 3.16.5. 2753 When the Client sends an RS with window synchronization parameters 2754 and with multiple MS-Register Proxy/Server IDs, Proxy/Server "A" may 2755 receive multiple RAs - each with their own window synchronization 2756 parameters. Proxy/Server "A" must then immediately forward these RAs 2757 to the Client as singletons instead of including them in an 2758 aggregate, and the Client will use each RA to establish a separate 2759 NCE and window for each individual Proxy/Server. 2761 The OMNI interface specification [I-D.templin-6man-omni] provides 2762 further discussion of the RS/RA messaging involved in point-to- 2763 multipoint coordination. 2765 3.14. AERO Route Optimization 2767 AERO nodes invoke route optimization when they need to forward 2768 packets to new target destinations. Route optimization is based on 2769 IPv6 ND Address Resolution messaging between a Route Optimization 2770 Source (ROS) and Route Optimization Responder (ROR). Route 2771 optimization is initiated by the first eligible ROS closest to the 2772 source as follows: 2774 o For Clients on VPNed and Direct interfaces, the Client's FHS 2775 Proxy/Server is the ROS. 2777 o For Clients on ANET interfaces, either the Client or the FHS 2778 Proxy/Server may be the ROS. 2780 o For Clients on INET interfaces, the Client itself is the ROS. 2782 o For correspondent nodes on INET/EUN interfaces serviced by a 2783 Relay, the Relay is the ROS. 2785 The route optimization procedure is conducted between the ROS and an 2786 LHS Proxy/Server/Relay for the target selected by routing as the ROR. 2787 In this arrangement, the ROS is always the Client or Proxy/Server/ 2788 Relay nearest the source over the selected source underlying 2789 interface, while the ROR is always an LHS Proxy/Server/Relay for the 2790 target regardless of the target underlying interface. 2792 The AERO routing system directs a route optimization solicitation 2793 sent by the ROS to the nearest available ROR, which returns a route 2794 optimization reply. The exact ROR selected is unimportant; all that 2795 matters is that the route optimization information returned must be 2796 current and authentic. The ROS is responsible for periodically 2797 refreshing the route optimization, and the ROR is responsible for 2798 quickly informing the ROS of any changes. 2800 The procedures are specified in the following sections. 2802 3.14.1. Route Optimization Initiation 2804 When an original IP packet from a source node destined to a target 2805 node arrives, the ROS checks for a NCE with an MNP-LLA that matches 2806 the target destination. If there is a NCE in the REACHABLE state, 2807 the ROS invokes the OAL and forwards the resulting carrier packets 2808 according to the cached state then returns from processing. 2809 Otherwise, if there is no NCE the ROS creates one in the INCOMPLETE 2810 state. 2812 The ROS next places the original IP packet on a short queue then 2813 sends an NS message for Address Resolution (NS(AR)) to receive a 2814 solicited NA(AR) message from an ROR. The NS(AR) message must be 2815 sent securely, and includes: 2817 o the LLA of the ROS as the source address. 2819 o the MNP-LLA corresponding to the original IP packet's destination 2820 as the Target Address, e.g., for 2001:db8:1:2::10:2000 the Target 2821 Address is fe80::2001:db8:1:2. 2823 o the Solicited-Node multicast address [RFC4291] formed from the 2824 lower 24 bits of the original IP packet's destination as the 2825 destination address, e.g., for 2001:db8:1:2::10:2000 the NS(AR) 2826 destination address is ff02:0:0:0:0:1:ff10:2000. 2828 The NS(AR) message also includes an OMNI option with an Interface 2829 Attributes entry for the underlying interface, with S/T-omIndex set 2830 to the underlying interface index and with Preflen set to the prefix 2831 length associated with the NS(AR) source. The ROS then selects an 2832 Identification value submits the NS(AR) message for OAL encapsulation 2833 with OAL source set to its own ULA and OAL destination set to the ULA 2834 corresponding to the target. (The ROS does not include any window 2835 synchronization parameters, since it will never exchange other 2836 carrier packet types directly with the ROR). 2838 The ROS then sends the resulting carrier packet(s) into the SRT 2839 secured spanning tree without decrementing the network-layer TTL/Hop 2840 Limit field. (When the ROS is an INET Client, it instead sends the 2841 resulting carrier packets to the ADM-ULA of one of its current Proxy/ 2842 Servers. The Proxy/Server reassembles if necessary, verifies the 2843 NS(AR) signature, then re-encapsulates with the OAL source set to its 2844 own ADM-ULA and OAL destination set to the ULA corresponding to the 2845 target. The Proxy/Server then fragments if necessary and sends the 2846 resulting carrier packets into the secured spanning tree on behalf of 2847 the Client.) 2849 3.14.2. Relaying the NS(AR) *NET Packet(s) 2851 When the Bridge receives the carrier packet(s) containing the RS from 2852 the ROS, it discards the *NET headers and determines the next hop by 2853 consulting its standard IPv6 forwarding table for the OAL header 2854 destination address. The Bridge then decrements the OAL header Hop- 2855 Limit, then re-encapsulates and forwards the carrier packet(s) via 2856 the secured spanning tree the same as for any IPv6 router, where it 2857 may traverse multiple OMNI link segments. The final-hop Bridge will 2858 deliver the carrier packet(s) via the secured spanning tree to a 2859 Proxy/Server or Relay that services the target. 2861 3.14.3. Processing the NS(AR) and Sending the NA(AR) 2863 When an LHS Proxy/Server (or Relay) for the target receives the 2864 secured carrier packet(s), it reassembles if necessary then examines 2865 the NS(AR) target to determine whether it has a matching NCE and/or 2866 non-MNP route. If there is no match, the Proxy/Server drops the 2867 message. Otherwise, the LHS Proxy/Server/Relay continues processing 2868 as follows: 2870 o if the NS(AR) target matches a Client NCE in the DEPARTED state, 2871 the Proxy/Server re-encapsulates while setting the OAL source to 2872 the ULA of the ROS and OAL destination address to the ADM-ULA of 2873 the Client's new Proxy/Server. The (old) Proxy/Server then 2874 fragments if necessary and forwards the resulting carrier 2875 packet(s) over the secured spanning tree then returns from 2876 processing. 2878 o If the NS(AR) target matches the MNP-LLA of a Client NCE in the 2879 REACHABLE state, the Proxy/Server makes note of whether the NS 2880 (AR) arrived from the secured or unsecured spanning tree then acts 2881 as an ROR to provide route optimization information on behalf of 2882 the Client. (Note that if the message arrived via the secured 2883 spanning tree the ROR need not perform further authentication, but 2884 if it arrived over an open INET underlying interface it must 2885 verify the message authentication signature before accepting.) 2887 o If the NS(AR) target matches one of its non-MNP routes, the Relay 2888 acts as both an ROR and a route optimization target, since the 2889 Relay forwards IP packets toward the (fixed network) target at the 2890 network layer. 2892 The ROR next checks the target NCE for a Report List entry that 2893 matches the NS(AR) source LLA/ULA of the ROS. If there is a Report 2894 List entry, the ROR refreshes ReportTime for this ROR; otherwise, the 2895 ROR creates a new entry for the ROS and records both the LLA and ULA. 2897 The ROR then prepares a (solicited) NA(AR) message to return to the 2898 ROS with the source address set to its own ADM-LLA, the destination 2899 address set to the NS(AR) LLA source address and the Target Address 2900 set to the target Client's MNP-LLA. The ROR then includes an OMNI 2901 option with Preflen set to the prefix length associated with the 2902 NA(AR) source address. The ROR next includes Interface Attributes in 2903 the OMNI option for all of the target's underlying interfaces with 2904 current information for each interface. 2906 For each Interface Attributes sub-option, the ROR sets the L2ADDR 2907 according to its own INET address for VPNed, Direct or ANET 2908 interfaces, to its own INET address for NATed Client interfaces, or 2909 to the Client's INET address for native Client interfaces. The ROR 2910 then includes the lower 32 bits of the Proxy/Server's ADM-ULA as the 2911 LHS, encodes the ADM-ULA SRT prefix length in the SRT field and sets 2912 FMT as specified in Section 3.3. 2914 The ROR then sets the NA(AR) message R flag to 1 (as a router) and S 2915 flag to 1 (as a response to a solicitation) and sets the O flag to 0 2916 (as a proxy) and sets the OMNI header S/T-omIndex to 0. The ROR 2917 finally submits the NA(AR) for OAL encapsulation with source set to 2918 its own ULA and destination set to the same ULA that appeared in the 2919 NS(AR) OAL source, then performs OAL encapsulation and fragmentation 2920 using the same Identification value that appeared in the NS(AR) and 2921 finally forwards the resulting (*NET-encapsulated) carrier packets 2922 via the secured spanning tree without decrementing the network-layer 2923 TTL/Hop Limit field. 2925 3.14.4. Relaying the NA(AR) 2927 When the Bridge receives NA(AR) carrier packets from the ROR, it 2928 discards the *NET header and determines the next hop by consulting 2929 its standard IPv6 forwarding table for the OAL header destination 2930 address. The Bridge then decrements the OAL header Hop-Limit, re- 2931 encapsulates the carrier packet and forwards it via the SRT secured 2932 spanning tree the same as for any IPv6 router, where it may traverse 2933 multiple OMNI link segments. The final-hop Bridge will deliver the 2934 carrier packet via the secured spanning tree to a Proxy/Server for 2935 the ROS. 2937 3.14.5. Processing the NA(AR) 2939 When the ROS receives the NA(AR) message from the ROR, it first 2940 searches for a NCE that matches the NA(AR) target address. The ROS 2941 then processes the message the same as for standard IPv6 Address 2942 Resolution [RFC4861]. In the process, it caches all OMNI option 2943 information in the target NCE (including all Interface Attributes), 2944 and caches the NA(AR) ADM-{LLA,ULA} source addresses as the addresses 2945 of the ROR. If the ROS receives additional NA(AR) or uNA messages 2946 for this target Client with the same ADM-LLA source address but a 2947 different ADM-ULA source address, it caches the new MSID as the new 2948 ADM-{LLA,ULA} and deprecates the former ADM-{LLA,ULA}. 2950 When the ROS is a Client, the solicited NA(AR) message will first be 2951 delivered via the SRT secured spanning tree to the Proxy/Server that 2952 forwarded the NS(AR), which reassembles if necessary. The Proxy/ 2953 Server then forwards the message to the Client while re-encapsulating 2954 and re-fragmenting if necessary. If the Client is on an ANET, ANET 2955 physical security and protected spectrum ensures security for the 2956 unmodified NA(AR); if the Client is on the open INET the Proxy/Server 2957 must instead insert an authentication signature. The Proxy/Server 2958 uses its own ADM-ULA as the OAL source and the MNP-ULA of the Client 2959 as the OAL destination. 2961 3.14.6. Forwarding Packets to Route Optimized Targets 2963 After the ROS receives the route optimization NA(AR) and updates the 2964 target NCE, it sends additional NS(AR) messages to the ADM-ULA of the 2965 ROR to refresh the NCE ReachableTime before expiration as long as 2966 there is continued interest in this target. While the NCE remains 2967 REACHABLE, the ROS can forward packets along the best underlying 2968 interface paths based on the target's Interface Attributes. The ROS 2969 selects target underlying interfaces according to traffic selectors 2970 and/or any other traffic discriminators, however each underlying 2971 interface selected must first establish window synchronization state 2972 if necessary. 2974 To establish window synchronization state, the ROS performs a secured 2975 unicast NS/NA(WIN) exchange with window synchronization parameters 2976 according to the Interface Attributes FMT code. If FMT-Forward is 2977 set, the ROS prepares an NS(WIN) with its own LLA as the source and 2978 the MNP-LLA of the target Client as the destination; otherwise, it 2979 sets the ADM-LLA of the LHS Proxy/Server as the destination. The ROS 2980 then encapsulates the NS(WIN) in an OAL header with its own ULA as 2981 the source. If the ROS is the Client, it sets the OAL destination to 2982 the ADM-ULA of its FHS Proxy/Server, includes an authentication 2983 signature if necessary, and includes an ORH-1 with FMT-Type clear for 2984 the first fragment. The Client sets the ORH Segments Left to 1 and 2985 includes valid SRT/LHS information for the LHS Proxy/Server with 2986 L2ADDR set to 0, then forwards the NS(WIN) to its FHS Proxy/Server 2987 which must reassemble and verify the authentication signature if 2988 necessary. The FHS Proxy/Server then re-encapsulates, re-fragments 2989 and forwards the NS(WIN) carrier packets into the secured spanning 2990 tree with its own ADM-ULA as the OAL source and the ADM-ULA of the 2991 LHS Proxy/Server as the OAL destination while replacing the ORH-1 2992 with an ORH-0. (If the ROS was the FHS Proxy/Server itself, it 2993 instead includes an ORH-0, and forwards the carrier packets into the 2994 secured spanning tree.) 2996 When an LHS Proxy/Server receives the NS(WIN) it first reassembles if 2997 necessary. If the NS(WIN) destination is its own ADM-LLA, the LHS 2998 Proxy/Server creates an NCE based on the NS(WIN) source LLA, caches 2999 the window synchronization information, and prepares an NA(WIN) while 3000 using its own ADM-LLA as the source and the ROS LLA as the 3001 destination. The LHS Proxy/Server then encapsulates the NA(WIN) in 3002 an OAL header with source set to its own ADM-ULA and destination set 3003 to the NS(WIN) OAL source. The LHS Proxy/Server then fragments if 3004 necessary includes an ORH-0 with omIndex set to the S/T-omIndex value 3005 found in the NS(WIN) OMNI option, then forwards the resulting carrier 3006 packets into the secured spanning tree which will deliver them to the 3007 ROS Proxy/Server. 3009 If the NS(WIN) destination is the MNP-LLA of the target Client, the 3010 LHS Proxy/Server instead re-encapsulates using the same OAL source 3011 and the MNP-ULA of the target as the OAL destination and includes an 3012 authentication signature if necessary while removing the ORH-0. The 3013 LHS Proxy/Server then forwards the NS(WIN) to the target over the 3014 underlying interface identified by the ORH-0 omIndex (or, over any 3015 underlying interface if omIndex is 0). When the target receives the 3016 NS(WIN), it verifies the authentication signature if necessary then 3017 creates an NCE for the ROS LLA, caches the window synchronization 3018 information and prepares an NA(WIN) to return to the ROS with its 3019 MNP-LLA as the source and the LLA of the ROS as the destination, and 3020 with an authentication signature if necessary. The target Client 3021 then encapsulates the NA(WIN) in an OAL header with its own MNP-ULA 3022 as the source, the ADM-ULA of the LHS Proxy/Server as the 3023 destination, and with an ORH-1 with SRT/LHS information copied from 3024 the ADM-ULA of the FHS Proxy/Server found in the NS(WIN) OAL source 3025 address. The target Client then sets the ORH-1 omIndex to the S/ 3026 T-omIndex value found in the NS(WIN) OMNI option, then forwards the 3027 message to the LHS Proxy/Server. 3029 When the LHS Proxy/Server receives the message, it reassembles if 3030 necessary, verifies the authentication signature if necessary then 3031 re-encapsulates using its own ADM-ULA as the source and the ADM-ULA 3032 of the FHS Proxy/Server as the destination The LHS Proxy/Server then 3033 re-fragments and forwards the NS(WIN) carrier packets into the 3034 spanning tree while replacing the ORH-1 with an ORH-0. When the FHS 3035 Proxy/Server receives the NA(WIN), it reassembles if necessary then 3036 updates the target NCE based on the message contents if the Proxy/ 3037 Server itself is the ROS. If the NS(WIN) source was the ADM-LLA of 3038 the LHS Proxy/Server, the ROS must create and maintain a NCE for the 3039 LHS Proxy/Server which it must regard as a companion to the existing 3040 MNP-LLA NCE for the target Client. (The NCE for the LHS Proxy/Server 3041 can also be shared by multiple target Client NCEs if the ROS 3042 communicates with multiple active targets located behind the same LHS 3043 Proxy/Server.) If the Client is the ROS, the FHS Proxy/Server 3044 instead inserts an authentication signature if necessary, removes the 3045 ORH-0 then re-encapsulates and re-fragments if necessary while 3046 changing the OAL destination to the MNP-ULA of the Client. The FHS 3047 Proxy/Server then forwards the NA(WIN) to the Client over the 3048 underlying interface identified by the ORH-0 omIndex which then 3049 updates its own NCE based on the target Client MNP-LLA or LHS Proxy/ 3050 Server ADM-LLA. The ROS (whether the Proxy/Server or the Client 3051 itself) finally arranges to return an acknowledgement if requested by 3052 the NA(WIN). 3054 After window synchronization state has been established, the ROS can 3055 begin forwarding carrier packets as specified in Section 3.2.7 while 3056 performing additional NS/NA(WIN) exchanges as above to update window 3057 state and/or test reachability. These forwarding procedures apply to 3058 the case where the selected target interface SRT/LHS codes indicate 3059 that the interface is located in a foreign OMNI link segment. In 3060 that case, the ROS must include ORHs and send the resulting carrier 3061 packets into the spanning tree. 3063 If the SRT/LHS codes indicate that the interface is in the local OMNI 3064 link segment, the ROS can instead forward carrier packets directly to 3065 the LHS Proxy/Server using the L2ADDR for encapsulation, or even to 3066 the target Client itself while invoking NAT traversal if necessary. 3067 When the ROS sends packets directly to the LHS Proxy/Server, it 3068 includes an ORH-0 if necessary to inform the Proxy/Server as to 3069 whether it must reassemble and/or the correct target Client interface 3070 for (re)forwarding. If the LHS Proxy/Server is required to 3071 reassemble, the ROS sets the OAL destination to the ADM-ULA of the 3072 LHS Proxy/Server; otherwise, it sets the OAL destination to the MNP- 3073 ULA of the target Client itself. When the ROS sends packets directly 3074 to the target Client, it need not include an ORH. The LHS Proxy/ 3075 Server (or target Client) then saves the L2ADDR and full OAL 3076 addresses in the ROS NCE, and the ROS can begin applying OAL header 3077 compression in subsequent carrier packets as specified in 3078 [I-D.templin-6man-omni] since the OAL header is not examined by any 3079 forwarding nodes in the path. 3081 While the ROS continues to actively forward packets to the target 3082 Client, it is responsible for updating window synchronization state 3083 and per-interface reachability before expiration. Window 3084 synchronization state is shared by all underlying interfaces in the 3085 ROS' NCE that use the same destination LLA so that a single NS/ 3086 NA(NUD) exchange applies for all interfaces regardless of the 3087 (single) interface used to conduct the exchange. However, the window 3088 synchronization exchange only confirms target Client reachability 3089 over the specific interface used to conduct the exchange. 3090 Reachability for other underlying interfaces that share the same 3091 window synchronization state must be determined individually using 3092 NS/NA(NUD) messages which need not be secured as long as they use in- 3093 window Identifications and do not update other state information. 3095 3.15. Neighbor Unreachability Detection (NUD) 3097 AERO nodes perform Neighbor Unreachability Detection (NUD) per 3098 [RFC4861] either reactively in response to persistent link-layer 3099 errors (see Section 3.11) or proactively to confirm reachability. 3100 The NUD algorithm is based on periodic control message exchanges and 3101 may further be seeded by ND hints of forward progress, but care must 3102 be taken to avoid inferring reachability based on spoofed 3103 information. For example, IPv6 ND message exchanges that include 3104 authentication codes and/or in-window Identifications may be 3105 considered as acceptable hints of forward progress, while spurious 3106 random carrier packets should be ignored. 3108 AERO nodes can perform NS/NA(NUD) exchanges over the OMNI link 3109 secured spanning tree (i.e. the same as described above for NS/ 3110 NA(WIN)) to test reachability without risk of DoS attacks from nodes 3111 pretending to be a neighbor. These NS/NA(NUD) messages use the 3112 unicast LLAs and ULAs of the parties involved in the NUD test the 3113 same as for standard IPv6 ND over the secured spanning tree. When 3114 only reachability information is required without updating any other 3115 NCE state, AERO nodes can instead perform NS/NA(NUD) exchanges 3116 directly between neighbors without employing the secured spanning 3117 tree as long as they include in-window Identifications and an 3118 authentication signature or checksum. 3120 When an ROR directs an ROS to a target neighbor with one or more 3121 link-layer addresses, the ROS probes each unsecured target underlying 3122 interface either proactively or on-demand of carrier packets directed 3123 to the path by multilink forwarding to maintain the interface's state 3124 as reachable. Probing is performed through NS(NUD) messages over the 3125 SRT secured or unsecured spanning tree, or through NS(NUD) messages 3126 sent directly to an underlying interface of the target itself. While 3127 testing a target underlying interface, the ROS can optionally 3128 continue to forward carrier packets via alternate interfaces and/or 3129 maintain a small queue of carrier packets until target reachability 3130 is confirmed. 3132 NS(NUD) messages are encapsulated, fragmented and transmitted as 3133 carrier packets the same as for ordinary original IP data packets, 3134 however the encapsulated destinations are the LLA of the ROS and 3135 either the ADM-LLA of the LHS Proxy/Server or the MNP-LLA of the 3136 target itself. The ROS encapsulates the NS(NUD) message the same as 3137 described in Section 3.2.7, however Destination Suffixes (if present) 3138 are set according to the LLA destination (i.e., and not a ULA/GUA 3139 destination). The ROS sets the NS(NUD) OMNI header S/T-omIndex to 3140 identify the underlying interface used for forwarding (or to 0 if any 3141 underlying interface can be used). The ROS also includes an ORH with 3142 FMT/SRT/LHS/LLADDR information the same as for ordinary data packets, 3143 but does not include an authentication signature. The ROS then 3144 fragments the OAL packet and forwards the resulting carrier packets 3145 into the unsecured spanning tree or directly to the target (or LHS 3146 Proxy/Server) if it is in the local segment. 3148 When the target (or LHS Proxy/Server) receives the NS(NUD) carrier 3149 packets, it verifies that it has a NCE for this ROS and that the 3150 Identification is in-window, then submits the carrier packets for 3151 reassembly. The node then verifies the authentication signature or 3152 checksum, then searches for Interface Attributes in its NCE for the 3153 ROS that match the NS(NUD) S/T-omIndex and uses the FMT/SRT/LHS/ 3154 L2ADDR information to prepare an ORH for the NA(NUD) reply. The node 3155 then prepares the NA(NUD) with the source and destination LLAs 3156 reversed, encapsulates and sets the OAL source and destination, sets 3157 the NA(NUD) S/T-omIndex to the index of the underlying interface the 3158 NS(NUD) arrived on and sets the Target Address to the same value 3159 included in the NS(NUD). The target next sets the R flag to 1, the S 3160 flag to 1 and the O flag to 1, then selects an in-window 3161 Identification for the ROS and performs fragmentation. The node then 3162 forwards the carrier packets into the unsecured spanning tree, 3163 directly to the ROS if it is in the local segment or directly to a 3164 Bridge in the local segment. 3166 When the ROS receives the NA(NUD), it marks the target underlying 3167 interface tested as "reachable". Note that underlying interface 3168 states are maintained independently of the overall NCE REACHABLE 3169 state, and that a single NCE may have multiple target underlying 3170 interfaces in various states "reachable" and otherwise while the NCE 3171 state as a whole remains REACHABLE. 3173 Note also that the exchange of NS/NA(NUD) messages has the useful 3174 side-benefit of opening holes in NATs that may be useful for NAT 3175 traversal. 3177 3.16. Mobility Management and Quality of Service (QoS) 3179 AERO is a Distributed Mobility Management (DMM) service. Each Proxy/ 3180 Server is responsible for only a subset of the Clients on the OMNI 3181 link, as opposed to a Centralized Mobility Management (CMM) service 3182 where there is a single network mobility collective entity for all 3183 Clients. Clients coordinate with their associated Proxy/Servers via 3184 RS/RA exchanges to maintain the DMM profile, and the AERO routing 3185 system tracks all current Client/Proxy/Server peering relationships. 3187 Proxy/Servers provide default routing and mobility/multilink services 3188 for their dependent Clients. Clients are responsible for maintaining 3189 neighbor relationships with their Proxy/Servers through periodic RS/ 3190 RA exchanges, which also serves to confirm neighbor reachability. 3191 When a Client's underlying Interface Attributes change, the Client is 3192 responsible for updating the Proxy/Server with this new information. 3193 Note that when there is a Proxy/Server in the path, the Proxy 3194 function can also perform some RS/RA exchanges on the Client's 3195 behalf. 3197 Mobility management messaging is based on the transmission and 3198 reception of unsolicited Neighbor Advertisement (uNA) messages. Each 3199 uNA message sets the IPv6 source address to the LLA of the ROR and 3200 the destination address to the unicast LLA of the ROS. 3202 Mobility management considerations are specified in the following 3203 sections. 3205 3.16.1. Mobility Update Messaging 3207 RORs accommodate Client mobility and/or multilink change events by 3208 sending secured uNA messages to each ROS in the target Client's 3209 Report List. When an ROR sends a uNA message, it sets the IPv6 3210 source address to the its own LLA, sets the destination address to 3211 the ROS LLA (i.e., an MNP-LLA if the ROS is a Client and an ADM-LLA 3212 if the ROS is a Proxy/Server) and sets the Target Address to the 3213 Client's MNP-LLA. The ROR also includes an OMNI option with Preflen 3214 set to the prefix length associated with the Client's MNP-LLA, with 3215 Interface Attributes for the target Client's underlying interfaces 3216 and with the OMNI header S/T-omIndex set to 0. The ROR then sets the 3217 uNA R flag to 1, S flag to 0 and O flag to 1, then encapsulates the 3218 message in an OAL header with source set to its own ADM-ULA and 3219 destination set to the ROS ULA (i.e., the ADM-ULA of the ROS Proxy/ 3220 Server) and sends the message into the secured spanning tree. 3222 As discussed in Section 7.2.6 of [RFC4861], the transmission and 3223 reception of uNA messages is unreliable but provides a useful 3224 optimization. In well-connected Internetworks with robust data links 3225 uNA messages will be delivered with high probability, but in any case 3226 the Proxy/Server can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT 3227 uNAs to each ROS to increase the likelihood that at least one will be 3228 received. Alternatively, the Proxy/Server can set the PNG flag in 3229 the uNA OMNI option header to request a solicited NA acknowledgement 3230 as specified in [I-D.templin-6man-omni]. 3232 When the ROS Proxy/Server receives a uNA message prepared as above, 3233 it ignores the message if the destination is not its own ADM-ULA or 3234 the MNP-ULA of the ROS Client. In the former case, it uses the 3235 included OMNI option information to update its NCE for the target, 3236 but does not reset ReachableTime since the receipt of an unsolicited 3237 NA message from the ROR does not provide confirmation that any 3238 forward paths to the target Client are working. If the destination 3239 was the MNP-ULA of the ROS Client, the ROS Proxy/Server instead re- 3240 encapsulates with the OAL source set to its own ADM-ULA, OAL 3241 destination set to the MNP-ULA of the ROS Client with an 3242 authentication signature if necessary, and with an in-window 3243 Identification for this Client. Finally, if the uNA message PNG flag 3244 was set, the ROS returns a solicited NA acknowledgement as specified 3245 in [I-D.templin-6man-omni]. 3247 In addition to sending uNA messages to the current set of ROSs for 3248 the target Client, the ROR also sends uNAs to the MNP-ULA associated 3249 with the link-layer address for any underlying interface for which 3250 the link-layer address has changed. These uNA messages update an old 3251 Proxy/Server that cannot easily detect (e.g., without active probing) 3252 when a formerly-active Client has departed. When the ROR sends the 3253 uNA, it sets the IPv6 source address to its LLA, sets the destination 3254 address to the old Proxy/Server's ADM-LLA, and sets the Target 3255 Address to the Client's MNP-LLA. The ROR also includes an OMNI 3256 option with Preflen set to the prefix length associated with the 3257 Client's MNP-LLA, with Interface Attributes for the changed 3258 underlying interface, and with the OMNI header S/T-omIndex set to 0. 3259 The ROR then sets the uNA R flag to 1, S flag to 0 and O flag to 1, 3260 then encapsulates the message in an OAL header with source set to its 3261 own ULA and destination set to the ADM-ULA of the old Proxy/Server 3262 and sends the message into the secured spanning tree. 3264 3.16.2. Announcing Link-Layer Address and/or QoS Preference Changes 3266 When a Client needs to change its underlying Interface Attributes 3267 (e.g., due to a mobility event), the Client requests one of its 3268 Proxy/Servers to send uNA or RS messages to all of its other Proxy/ 3269 Servers via the secured spanning tree with an OMNI option that 3270 includes Interface Attributes with the new link quality and address 3271 information. 3273 Up to MAX_RTR_SOLICITATIONS RS messages MAY be sent in parallel with 3274 sending carrier packets containing user data in case one or more RAs 3275 are lost. If all RAs are lost, the Client SHOULD re-associate with a 3276 new Proxy/Server. 3278 When the Proxy/Server receives the Client's changes, it sends uNA 3279 messages to all nodes in the Report List the same as described in the 3280 previous section. 3282 3.16.3. Bringing New Links Into Service 3284 When a Client needs to bring new underlying interfaces into service 3285 (e.g., when it activates a new data link), it sends an RS message to 3286 the Proxy/Server via the underlying interface with an OMNI option 3287 that includes Interface Attributes with appropriate link quality 3288 values and with link-layer address information for the new link. 3290 3.16.4. Deactivating Existing Links 3292 When a Client needs to deactivate an existing underlying interface, 3293 it sends an RS or uNA message to its Proxy/Server with an OMNI option 3294 with appropriate Interface Attribute values - in particular, the link 3295 quality value 0 assures that neighbors will cease to use the link. 3297 If the Client needs to send RS/uNA messages over an underlying 3298 interface other than the one being deactivated, it MUST include 3299 Interface Attributes with appropriate link quality values for any 3300 underlying interfaces being deactivated. 3302 Note that when a Client deactivates an underlying interface, 3303 neighbors that have received the RS/uNA messages need not purge all 3304 references for the underlying interface from their neighbor cache 3305 entries. The Client may reactivate or reuse the underlying interface 3306 and/or its omIndex at a later point in time, when it will send RS/uNA 3307 messages with fresh Interface Attributes to update any neighbors. 3309 3.16.5. Moving Between Proxy/Servers 3311 The Client performs the procedures specified in Section 3.12.2 when 3312 it first associates with a new FHS Proxy/Server or renews its 3313 association with an existing Proxy/Server. The Client also includes 3314 MS-Release identifiers in the RS message OMNI option per 3315 [I-D.templin-6man-omni] if it wants the new Proxy/Server to notify 3316 any old Proxy/Servers from which the Client is departing. 3318 When the new FHS Proxy/Server receives the Client's RS message, it 3319 returns an RA as specified in Section 3.12.3 and sends RS messages to 3320 any old Proxy/Servers listed in OMNI option MS-Release identifiers. 3321 When the new Proxy/Server sends an RS message, it sets the source to 3322 the MNP-LLA of the Client and sets the destination to the ADM-LLA of 3323 the old Proxy/Server. The new Proxy/Server also includes an OMNI 3324 option with Preflen set to the prefix length associated with the 3325 Client's MNP-LLA, with Interface Attributes for its own underlying 3326 interface, and with the OMNI header S/T-omIndex set to 0. The new 3327 Proxy/Server then encapsulates the message in an OAL header with 3328 source set to its own ADM-ULA and destination set to the ADM-ULA of 3329 the old Proxy/Server and sends the message into the secured spanning 3330 tree. 3332 When an old Proxy/Server receives the RS, it notices that the message 3333 appears to have originated from the Client's MNP-LLA but that the S/ 3334 T-omIndex is 0. The old Proxy/Server then changes the Client's NCE 3335 state to DEPARTED, sets the link-layer address of the Client to the 3336 new Proxy/Server's ADM-ULA, and resets DepartTime. The old Proxy/ 3337 Server then returns an RA message via the secured spanning tree by 3338 reversing the LLA and ULA addresses found in the RS message. After a 3339 short delay (e.g., 2 seconds) the old Proxy/Server withdraws the 3340 Client's MNP from the routing system. After DepartTime expires, the 3341 old Proxy/Server deletes the Client's NCE. 3343 The old Proxy/Server also iteratively sends uNA messages to each ROS 3344 in the Client's Report List with OAL source address set to the ADM- 3345 ULA of the new Proxy/Server and OAL destination address set to the 3346 ULA of the ROS. When the ROS receives the uNA, it examines the LLA 3347 source address to identify the old Proxy/Server and the uNA Target 3348 Address to locate the target Client's NCE. The ROS then caches the 3349 MSID found in the ULA source address as the ADM-{LLA/ULA} for the new 3350 Proxy/Server for this target NCE and marks the entry as STALE. While 3351 in the STALE state, the ROS allows new carrier packets to flow 3352 according to any alternate reachable underlying interfaces and sends 3353 new NS(AR) messages using its own ULA as the OAL source and the ADM- 3354 ULA of the new Proxy/Server as the OAL destination address to elicit 3355 NA(AR) messages that reset the NCE state to REACHABLE. 3357 Clients SHOULD NOT move rapidly between Proxy/Servers in order to 3358 avoid causing excessive oscillations in the AERO routing system. 3359 Examples of when a Client might wish to change to a different Proxy/ 3360 Server include a Proxy/Server that has gone unreachable, topological 3361 movements of significant distance, movement to a new geographic 3362 region, movement to a new OMNI link segment, etc. 3364 When a Client moves to a new Proxy/Server, some of the carrier 3365 packets of a multiple fragment OAL packet may have already arrived at 3366 the old Proxy/Server while others are en route to the new Proxy/ 3367 Server, however no special attention in the reassembly algorithm is 3368 necessary since all carrier packets will eventually arrive at the 3369 Client which can then reassemble. However, any carrier packets that 3370 are somehow lost can often be recovered through retransmissions. 3372 3.17. Multicast 3374 The AERO Client provides an IGMP (IPv4) [RFC2236] or MLD (IPv6) 3375 [RFC3810] proxy service for its EUNs and/or hosted applications 3376 [RFC4605]. Proxy/Servers act as a Protocol Independent Multicast - 3377 Sparse-Mode (PIM-SM, or simply "PIM") Designated Router (DR) 3378 [RFC7761]. AERO Relays also act as PIM routers (i.e., the same as 3379 AERO Proxys/Servers) on behalf of nodes on INET/EUN networks. 3381 Clients on ANET underlying interfaces for which the ANET has deployed 3382 native multicast services forward IGMP/MLD messages into the ANET. 3383 The IGMP/MLD messages may be further forwarded by a first-hop ANET 3384 access router acting as an IGMP/MLD-snooping switch [RFC4541], then 3385 ultimately delivered to an ANET FHS Proxy/Server. 3387 Clients on ANET underlying interfaces without native multicast 3388 services instead send NS(AR) messages to cause their FHS Proxy/Server 3389 to act as an ROS and forward the message to an LHS Proxy/Server ROR. 3390 Clients on INET interfaces act as an ROS on their own behalf and 3391 forward NS(AR) messages directly to the LHS Proxy/Server ROR (i.e., 3392 via the FHS Proxy/Server as a proxy). When the Client receives an 3393 NA(AR) response, it initiates PIM protocol messaging according to the 3394 Source-Specific Multicast (SSM) and Any-Source Multicast (ASM) 3395 operational modes as discussed in the following sections. 3397 3.17.1. Source-Specific Multicast (SSM) 3399 When an ROS "X" (i.e., either a ROS Client or its FHS Proxy Server) 3400 acting as PIM router receives a Join/Prune message from a node on its 3401 downstream interfaces containing one or more ((S)ource, (G)roup) 3402 pairs, it updates its Multicast Routing Information Base (MRIB) 3403 accordingly. For each S belonging to a prefix reachable via X's non- 3404 OMNI interfaces, X then forwards the (S, G) Join/Prune to any PIM 3405 routers on those interfaces per [RFC7761]. 3407 For each S belonging to a prefix reachable via X's OMNI interface, X 3408 sends an NS(AR) message (see: Section 3.14) using its own LLA as the 3409 source address and the LLA of S as the destination address. X then 3410 encapsulates the NS(AR) in an OAL header with source address set to 3411 the ULA of X and destination address set to the solicited node 3412 multicast address for S, then forwards the message into the secured 3413 spanning tree, which delivers it to ROR "Y" that services S. The 3414 resulting NA(AR) will return the LLA for the prefix that matches S as 3415 the network-layer source address and with an OMNI option with 3416 interface attributes for any underlying interfaces that are currently 3417 servicing S. 3419 When X processes the NA(AR) it selects one or more underlying 3420 interfaces for S and performs an NS/NA(WIN) exchange while including 3421 a PIM Join/Prune message for each multicast group of interest in the 3422 OMNI option. If S is located behind any Proxys "Z"*, each Z* then 3423 updates its MRIB accordingly and maintains the LLA of X as the next 3424 hop in the reverse path. Since the Bridges do not examine network 3425 layer control messages, this means that the (reverse) multicast tree 3426 path is simply from each Z* (and/or S) to X with no other multicast- 3427 aware routers in the path. 3429 Following the initial combined Join/Prune and NS/NA messaging, X 3430 maintains a NCE for each S the same as if X was sending unicast data 3431 traffic to S. In particular, X performs additional NS/NA exchanges 3432 to keep the NCE alive for up to t_periodic seconds [RFC7761]. If no 3433 new Joins are received within t_periodic seconds, X allows the NCE to 3434 expire. Finally, if X receives any additional Join/Prune messages 3435 for (S,G) it forwards the messages over the secured spanning tree. 3437 At some later time, Client C that holds an MNP for source S may 3438 depart from a first Proxy/Server Z1 and/or connect via a new Proxy/ 3439 Server Z2. In that case, Y sends a uNA message to X the same as 3440 specified for unicast mobility in Section 3.16. When X receives the 3441 uNA message, it updates its NCE for the LLA for source S and sends 3442 new Join messages to any new Proxys Z2. There is no requirement to 3443 send any Prune messages to old Proxy/Server Z1 since source S will no 3444 longer source any multicast data traffic via Z1. Instead, the 3445 multicast state for (S,G) in Proxy/Server Z1 will soon time out since 3446 no new Joins will arrive. 3448 After some later time, C may move to a new Proxy/Server Y2 and depart 3449 from old Sever Y1. In that case, Y1 sends Join messages for any of 3450 C's active (S,G) groups to Y2 while including its own LLA as the 3451 source address. This causes Y2 to include Y1 in the multicast 3452 forwarding tree during the interim time that Y1's NCE for C is in the 3453 DEPARTED state. At the same time, Y1 sends a uNA message to X with 3454 an OMNI option with S/T-omIndex set to 0 and a release indication to 3455 cause X to release its NCE for S. X then sends a new Join message to 3456 S via the secured spanning tree and re-initiates route optimization 3457 the same as if it were receiving a fresh Join message from a node on 3458 a downstream link. 3460 3.17.2. Any-Source Multicast (ASM) 3462 When an ROS X acting as a PIM router receives a Join/Prune from a 3463 node on its downstream interfaces containing one or more (*,G) pairs, 3464 it updates its Multicast Routing Information Base (MRIB) accordingly. 3465 X then forwards a copy of the message within the OMNI option of an 3466 NS(WIN) message to the Rendezvous Point (RP) R for each G over the 3467 secured spanning tree. X uses its own LLA as the source address and 3468 the LLA for R as the destination address, then encapsulates the 3469 NS(WIN) message in an OAL header with source address set to the ULA 3470 of X and destination address set to the ULA of R's Proxy/Server then 3471 sends the message into the secured spanning tree. 3473 For each source S that sends multicast traffic to group G via R, the 3474 Proxy/Server Z* for the Client that aggregates S encapsulates the 3475 original IP packets in PIM Register messages and forwards them to R 3476 via the secured spanning tree, which may then elect to send a PIM 3477 Join to Z*. This will result in an (S,G) tree rooted at Z* with R as 3478 the next hop so that R will begin to receive two copies of the 3479 original IP packet; one native copy from the (S, G) tree and a second 3480 copy from the pre-existing (*, G) tree that still uses PIM Register 3481 encapsulation. R can then issue a PIM Register-stop message to 3482 suppress the Register-encapsulated stream. At some later time, if C 3483 moves to a new Proxy/Server Z*, it resumes sending original IP 3484 packets via PIM Register encapsulation via the new Z*. 3486 At the same time, as multicast listeners discover individual S's for 3487 a given G, they can initiate an (S,G) Join for each S under the same 3488 procedures discussed in Section 3.17.1. Once the (S,G) tree is 3489 established, the listeners can send (S, G) Prune messages to R so 3490 that multicast original IP packets for group G sourced by S will only 3491 be delivered via the (S, G) tree and not from the (*, G) tree rooted 3492 at R. All mobility considerations discussed for SSM apply. 3494 3.17.3. Bi-Directional PIM (BIDIR-PIM) 3496 Bi-Directional PIM (BIDIR-PIM) [RFC5015] provides an alternate 3497 approach to ASM that treats the Rendezvous Point (RP) as a Designated 3498 Forwarder (DF). Further considerations for BIDIR-PIM are out of 3499 scope. 3501 3.18. Operation over Multiple OMNI Links 3503 An AERO Client can connect to multiple OMNI links the same as for any 3504 data link service. In that case, the Client maintains a distinct 3505 OMNI interface for each link, e.g., 'omni0' for the first link, 3506 'omni1' for the second, 'omni2' for the third, etc. Each OMNI link 3507 would include its own distinct set of Bridges and Proxy/Servers, 3508 thereby providing redundancy in case of failures. 3510 Each OMNI link could utilize the same or different ANET connections. 3511 The links can be distinguished at the link-layer via the SRT prefix 3512 in a similar fashion as for Virtual Local Area Network (VLAN) tagging 3513 (e.g., IEEE 802.1Q) and/or through assignment of distinct sets of 3514 MSPs on each link. This gives rise to the opportunity for supporting 3515 multiple redundant networked paths, with each VLAN distinguished by a 3516 different SRT "color" (see: Section 3.2.5). 3518 The Client's IP layer can select the outgoing OMNI interface 3519 appropriate for a given traffic profile while (in the reverse 3520 direction) correspondent nodes must have some way of steering their 3521 original IP packets destined to a target via the correct OMNI link. 3523 In a first alternative, if each OMNI link services different MSPs, 3524 then the Client can receive a distinct MNP from each of the links. 3525 IP routing will therefore assure that the correct OMNI link is used 3526 for both outbound and inbound traffic. This can be accomplished 3527 using existing technologies and approaches, and without requiring any 3528 special supporting code in correspondent nodes or Bridges. 3530 In a second alternative, if each OMNI link services the same MSP(s) 3531 then each link could assign a distinct "OMNI link Anycast" address 3532 that is configured by all Bridges on the link. Correspondent nodes 3533 can then perform Segment Routing to select the correct SRT, which 3534 will then direct the original IP packet over multiple hops to the 3535 target. 3537 3.19. DNS Considerations 3539 AERO Client MNs and INET correspondent nodes consult the Domain Name 3540 System (DNS) the same as for any Internetworking node. When 3541 correspondent nodes and Client MNs use different IP protocol versions 3542 (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain 3543 A records for IPv4 address mappings to MNs which must then be 3544 populated in Relay NAT64 mapping caches. In that way, an IPv4 3545 correspondent node can send original IPv4 packets to the IPv4 address 3546 mapping of the target MN, and the Relay will translate the IPv4 3547 header and destination address into an IPv6 header and IPv6 3548 destination address of the MN. 3550 When an AERO Client registers with an AERO Proxy/Server, the Proxy/ 3551 Server can return the address(es) of DNS servers in RDNSS options 3552 [RFC6106]. The DNS server provides the IP addresses of other MNs and 3553 correspondent nodes in AAAA records for IPv6 or A records for IPv4. 3555 3.20. Transition/Coexistence Considerations 3557 OAL encapsulation ensures that dissimilar INET partitions can be 3558 joined into a single unified OMNI link, even though the partitions 3559 themselves may have differing protocol versions and/or incompatible 3560 addressing plans. However, a commonality can be achieved by 3561 incrementally distributing globally routable (i.e., native) IP 3562 prefixes to eventually reach all nodes (both mobile and fixed) in all 3563 OMNI link segments. This can be accomplished by incrementally 3564 deploying AERO Bridges on each INET partition, with each Bridge 3565 distributing its MNPs and/or discovering non-MNP IP GUA prefixes on 3566 its INET links. 3568 This gives rise to the opportunity to eventually distribute native IP 3569 addresses to all nodes, and to present a unified OMNI link view even 3570 if the INET partitions remain in their current protocol and 3571 addressing plans. In that way, the OMNI link can serve the dual 3572 purpose of providing a mobility/multilink service and a transition/ 3573 coexistence service. Or, if an INET partition is transitioned to a 3574 native IP protocol version and addressing scheme that is compatible 3575 with the OMNI link MNP-based addressing scheme, the partition and 3576 OMNI link can be joined by Bridges. 3578 Relays that connect INETs/EUNs with dissimilar IP protocol versions 3579 may need to employ a network address and protocol translation 3580 function such as NAT64 [RFC6146]. 3582 3.21. Detecting and Reacting to Proxy/Server and Bridge Failures 3584 In environments where rapid failure recovery is required, Proxy/ 3585 Servers and Bridges SHOULD use Bidirectional Forwarding Detection 3586 (BFD) [RFC5880]. Nodes that use BFD can quickly detect and react to 3587 failures so that cached information is re-established through 3588 alternate nodes. BFD control messaging is carried only over well- 3589 connected ground domain networks (i.e., and not low-end radio links) 3590 and can therefore be tuned for rapid response. 3592 Proxy/Servers and Bridges maintain BFD sessions in parallel with 3593 their BGP peerings. If a Proxy/Server or Bridge fails, BGP peers 3594 will quickly re-establish routes through alternate paths the same as 3595 for common BGP deployments. Similarly, Proxys maintain BFD sessions 3596 with their associated Bridges even though they do not establish BGP 3597 peerings with them. 3599 3.22. AERO Clients on the Open Internet 3601 AERO Clients that connect to the open Internet via INET interfaces 3602 can establish a VPN or direct link to securely connect to a FHS 3603 Proxy/Server in a "tethered" arrangement with all of the Client's 3604 traffic transiting the Proxy/Server which acts as a router. 3605 Alternatively, the Client can associate with an INET FHS Proxy/Server 3606 using UDP/IP encapsulation and control message securing services as 3607 discussed in the following sections. 3609 When a Client's OMNI interface enables an INET underlying interface, 3610 it first examines the INET address. For IPv4, the Client assumes it 3611 is on the open Internet if the INET address is not a special-use IPv4 3612 address per [RFC3330]. Similarly for IPv6, the Client assumes it is 3613 on the open Internet if the INET address is a Global Unicast Address 3614 (GUA) [RFC4291]. Otherwise, the Client should assume it is behind 3615 one or several NATs. 3617 The Client then prepares an RS message with IPv6 source address set 3618 to its MNP-LLA, with IPv6 destination set to (link-local) All-Routers 3619 multicast and with an OMNI option with underlying interface 3620 attributes. If the Client believes that it is on the open Internet, 3621 it SHOULD include an L2ADDR in the Interface Attributes sub-option 3622 corresponding to the underlying interface; otherwise, it MAY set 3623 L2ADDR to 0. If the underlying address is IPv4, the Client includes 3624 the Port Number and IPv4 address written in obfuscated form [RFC4380] 3625 as discussed in Section 3.3. If the underlying interface address is 3626 IPv6, the Client instead includes the Port Number and IPv6 address in 3627 obfuscated form. The Client finally includes an authentication 3628 signature per [I-D.templin-6man-omni] to provide message 3629 authentication, selects an Identification value and window 3630 synchronization parameters, and submits the RS for OAL encapsulation. 3631 The Client then encapsulates the OAL fragment in UDP/IP headers to 3632 form a carrier packet, sets the UDP/IP source to its INET address and 3633 UDP port, sets the UDP/IP destination to the FHS Proxy/Server's INET 3634 address and the AERO service port number (8060), then sends the 3635 carrier packet to the Proxy/Server. 3637 When the FHS Proxy/Server receives the RS, it discards the OAL 3638 encapsulation, authenticates the RS message, creates a NCE and 3639 registers the Client's MNP, window synchronization state and INET 3640 interface information according to the OMNI option parameters. If 3641 the RS message OMNI option includes Interface Attributes with an 3642 L2ADDR, the Proxy/Server compares the encapsulation IP address and 3643 UDP port number with the (unobfuscated) values. If the values are 3644 the same, the Proxy/Server caches the Client's information as "INET" 3645 addresses meaning that the Client is likely to accept direct messages 3646 without requiring NAT traversal exchanges. If the values are 3647 different (or, if the OMNI option did not include an L2ADDR) the 3648 Proxy/Server instead caches the Client's information as "mapped" 3649 addresses meaning that NAT traversal exchanges may be necessary. 3651 The FHS Proxy/Server then prepares an RA message with IPv6 source and 3652 destination set corresponding to the addresses in the RS, and with an 3653 OMNI option with an Origin Indication sub-option per 3654 [I-D.templin-6man-omni] with the mapped and obfuscated Port Number 3655 and IP address observed in the encapsulation headers. The Proxy/ 3656 Server also includes an Interface Attributes sub-option for its 3657 underlying interface with FMT/SRT/LHS information appropriate for its 3658 INET interface, and with an authentication signature sub-option per 3660 [I-D.templin-6man-omni] and/or a symmetric window synchronization/ 3661 acknowledgement if necessary. The Proxy/Server then performs OAL 3662 encapsulation and fragmentation if necessary and encapsulates each 3663 fragment in UDP/IP headers with addresses set per the L2ADDR 3664 information in the NCE for the Client. 3666 When the Client receives the RA, it authenticates the message then 3667 process the window synchronization/acknowledgement and compares the 3668 mapped Port Number and IP address from the Origin Indication sub- 3669 option with its own address. If the addresses are the same, the 3670 Client assumes the open Internet / Cone NAT principle; if the 3671 addresses are different, the Client instead assumes that further 3672 qualification procedures are necessary to detect the type of NAT and 3673 proceeds according to standard procedures [RFC6081][RFC4380]. The 3674 Client also caches the RA Interface Attributes FMT/SRT/LHS 3675 information to discover the Proxy/Server's spanning tree orientation. 3676 The Client finally arranges to return an explicit/implicit 3677 acknowledgement, and sends periodic RS messages to receive fresh RA 3678 messages before the Router Lifetime received on each INET interface 3679 expires. 3681 When the Client sends messages to target IP addresses, it also 3682 invokes route optimization per Section 3.14. For route optimized 3683 targets in the same OMNI link segment, if the target's L2ADDR is on 3684 the open INET, the Client forwards carrier packets directly to the 3685 target INET address. If the target is behind a NAT, the Client first 3686 establishes NAT state for the L2ADDR using the "direct bubble" and 3687 NUD mechanisms discussed in Section 3.10.1. The Client continues to 3688 send carrier packets via its Proxy/Server until NAT state is 3689 populated, then begins forwarding carrier packets via the direct path 3690 through the NAT to the target. For targets in different OMNI link 3691 segments, the Client uses OAL/ORH encapsulation and forwards carrier 3692 packets to the Bridge that returned the NA(AR) message. 3694 The Client can send original IP packets to route-optimized neighbors 3695 in the same OMNI link segment no larger than the minimum/path MPS in 3696 one piece and with OAL encapsulation as atomic fragments. For larger 3697 original IP packets, the Client applies OAL encapsulation then 3698 fragments if necessary according to Section 3.9, with OAL header with 3699 source set to its own MNP-ULA and destination set to the MNP-ULA of 3700 the target, and with an in-window Identification value. The Client 3701 then encapsulates each resulting carrier packet in UDP/IP *NET 3702 headers and sends them to the next hop. 3704 Note: The NAT traversal procedures specified in this document are 3705 applicable for Cone, Address-Restricted and Port-Restricted NATs 3706 only. While future updates to this document may specify procedures 3707 for other NAT variations (e.g., hairpinning and various forms of 3708 Symmetric NATs), it should be noted that continuous communications 3709 are always possible through forwarding via a Proxy/Server even if NAT 3710 traversal is not employed. 3712 3.23. Time-Varying MNPs 3714 In some use cases, it is desirable, beneficial and efficient for the 3715 Client to receive a constant MNP that travels with the Client 3716 wherever it moves. For example, this would allow air traffic 3717 controllers to easily track aircraft, etc. In other cases, however 3718 (e.g., intelligent transportation systems), the MN may be willing to 3719 sacrifice a modicum of efficiency in order to have time-varying MNPs 3720 that can be changed every so often to defeat adversarial tracking. 3722 The DHCPv6 service offers a way for Clients that desire time-varying 3723 MNPs to obtain short-lived prefixes (e.g., on the order of a small 3724 number of minutes). In that case, the identity of the Client would 3725 not be bound to the MNP but rather to a Node Identification value 3726 (see: [I-D.templin-6man-omni]) to be used as the Client ID seed for 3727 MNP prefix delegation. The Client would then be obligated to 3728 renumber its internal networks whenever its MNP (and therefore also 3729 its MNP-LLA) changes. This should not present a challenge for 3730 Clients with automated network renumbering services, however presents 3731 limits for the durations of ongoing sessions that would prefer to use 3732 a constant address. 3734 4. Implementation Status 3736 An early AERO implementation based on OpenVPN (https://openvpn.net/) 3737 was announced on the v6ops mailing list on January 10, 2018 and an 3738 initial public release of the AERO proof-of-concept source code was 3739 announced on the intarea mailing list on August 21, 2015. 3741 AERO Release-3.2 was tagged on March 30, 2021, and is undergoing 3742 internal testing. Additional internal releases expected within the 3743 coming months, with first public release expected end of 1H2021. 3745 Many AERO/OMNI functions are implemented and undergoing final 3746 integration. OAL fragmentation/reassembly buffer management code has 3747 been cleared for public release and will be presented at the June 3748 2021 ICAO mobility subgroup meeting. 3750 5. IANA Considerations 3752 The IANA is instructed to assign a new type value TBD1 in the IPv6 3753 Routing Types registry (IANA registration procedure is IETF Review or 3754 IESG Approval). 3756 The IANA has assigned the UDP port number "8060" for an earlier 3757 experimental first version of AERO [RFC6706]. This document together 3758 with [I-D.templin-6man-omni] reclaims UDP port number "8060" for 3759 'aero' as the service port for UDP/IP encapsulation. This document 3760 makes no request of IANA, since [I-D.templin-6man-omni] already 3761 provides instructions. (Note: although [RFC6706] was not widely 3762 implemented or deployed, it need not be obsoleted since its messages 3763 use the invalid ICMPv6 message type number '0' which implementations 3764 of this specification can easily distinguish and ignore.) 3766 No further IANA actions are required. 3768 6. Security Considerations 3770 AERO Bridges configure secured tunnels with AERO Proxy/Servers and 3771 Relays within their local OMNI link segments. Applicable secured 3772 tunnel alternatives include IPsec [RFC4301], TLS/SSL [RFC8446], DTLS 3773 [RFC6347], WireGuard [WG], etc. The AERO Bridges of all OMNI link 3774 segments in turn configure secured tunnels for their neighboring AERO 3775 Bridges in a secured spanning tree topology. Therefore, control 3776 messages exchanged between any pair of OMNI link neighbors over the 3777 secured spanning tree are already protected. 3779 To prevent spoofing vectors, Proxy/Servers MUST discard without 3780 responding to any unsecured NS(AR) messages. Also, Proxy/Servers 3781 MUST discard without forwarding any original IP packets received from 3782 one of their own Clients (whether directly or following OAL 3783 reassembly) with a source address that does not match the Client's 3784 MNP and/or a destination address that does match the Client's MNP. 3785 Finally, Proxy/Servers MUST discard without forwarding any carrier 3786 packets with an OAL source and destination that both match the same 3787 MNP (i.e., after consulting the ORH if present). 3789 For INET partitions that require strong security in the data plane, 3790 two options for securing communications include 1) disable route 3791 optimization so that all traffic is conveyed over secured tunnels, or 3792 2) enable on-demand secure tunnel creation between Client neighbors. 3793 Option 1) would result in longer routes than necessary and impose 3794 traffic concentration on critical infrastructure elements. Option 2) 3795 could be coordinated between Clients using NS/NA messages with OMNI 3796 Host Identity Protocol (HIP) "Initiator/Responder" message sub- 3797 options [RFC7401][I-D.templin-6man-omni] to create a secured tunnel 3798 on-demand. 3800 AERO Clients that connect to secured ANETs need not apply security to 3801 their ND messages, since the messages will be authenticated and 3802 forwarded by a perimeter Proxy/Server that applies security on its 3803 INET-facing interface as part of the spanning tree (see above). AERO 3804 Clients connected to the open INET can use network and/or transport 3805 layer security services such as VPNs or can by some other means 3806 establish a direct link to a Proxy/Server. When a VPN or direct link 3807 may be impractical, however, INET Clients and Proxy/Servers SHOULD 3808 include and verify authentication signatures for their IPv6 ND 3809 messages as specified in [I-D.templin-6man-omni]. 3811 Application endpoints SHOULD use transport-layer (or higher-layer) 3812 security services such as TLS/SSL, DTLS or SSH [RFC4251] to assure 3813 the same level of protection as for critical secured Internet 3814 services. AERO Clients that require host-based VPN services SHOULD 3815 use network and/or transport layer security services such as IPsec, 3816 TLS/SSL, DTLS, etc. AERO Proxys and Proxy/Servers can also provide a 3817 network-based VPN service on behalf of the Client, e.g., if the 3818 Client is located within a secured enclave and cannot establish a VPN 3819 on its own behalf. 3821 AERO Proxy/Servers and Bridges present targets for traffic 3822 amplification Denial of Service (DoS) attacks. This concern is no 3823 different than for widely-deployed VPN security gateways in the 3824 Internet, where attackers could send spoofed packets to the gateways 3825 at high data rates. This can be mitigated through the AERO/OMNI data 3826 origin authentication procedures, as well as connecting Proxy/Servers 3827 and Bridges over dedicated links with no connections to the Internet 3828 and/or when connections to the Internet are only permitted through 3829 well-managed firewalls. Traffic amplification DoS attacks can also 3830 target an AERO Client's low data rate links. This is a concern not 3831 only for Clients located on the open Internet but also for Clients in 3832 secured enclaves. AERO Proxy/Servers and Proxys can institute rate 3833 limits that protect Clients from receiving packet floods that could 3834 DoS low data rate links. 3836 AERO Relays must implement ingress filtering to avoid a spoofing 3837 attack in which spurious messages with ULA addresses are injected 3838 into an OMNI link from an outside attacker. AERO Clients MUST ensure 3839 that their connectivity is not used by unauthorized nodes on their 3840 EUNs to gain access to a protected network, i.e., AERO Clients that 3841 act as routers MUST NOT provide routing services for unauthorized 3842 nodes. (This concern is no different than for ordinary hosts that 3843 receive an IP address delegation but then "share" the address with 3844 other nodes via some form of Internet connection sharing such as 3845 tethering.) 3847 The MAP list MUST be well-managed and secured from unauthorized 3848 tampering, even though the list contains only public information. 3849 The MAP list can be conveyed to the Client in a similar fashion as in 3850 [RFC5214] (e.g., through layer 2 data link login messaging, secure 3851 upload of a static file, DNS lookups, etc.). 3853 The AERO service for open INET Clients depends on a public key 3854 distribution service in which Client public keys and identities are 3855 maintained in a shared database accessible to all open INET Proxy/ 3856 Servers. Similarly, each Client must be able to determine the public 3857 key of each Proxy/Server, e.g. by consulting an online database. 3858 When AERO nodes register their public keys indexed by a unique Host 3859 Identity Tag (HIT) [RFC7401] in a distributed database such as the 3860 DNS, and use the HIT as an identity for applying IPv6 ND message 3861 authentication signatures, a means for determining public key 3862 attestation is available. 3864 Security considerations for IPv6 fragmentation and reassembly are 3865 discussed in [I-D.templin-6man-omni]. In environments where spoofing 3866 is considered a threat, OMNI nodes SHOULD employ Identification 3867 window synchronization and OAL destinations SHOULD configure an (end- 3868 system-based) firewall. 3870 SRH authentication facilities are specified in [RFC8754]. Security 3871 considerations for accepting link-layer ICMP messages and reflected 3872 packets are discussed throughout the document. 3874 7. Acknowledgements 3876 Discussions in the IETF, aviation standards communities and private 3877 exchanges helped shape some of the concepts in this work. 3878 Individuals who contributed insights include Mikael Abrahamsson, Mark 3879 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 3880 Wojciech Dec, Pavel Drasil, Ralph Droms, Adrian Farrel, Nick Green, 3881 Sri Gundavelli, Brian Haberman, Bernhard Haindl, Joel Halpern, Tom 3882 Herbert, Sascha Hlusiak, Lee Howard, Zdenek Jaron, Andre Kostur, 3883 Hubert Kuenig, Ted Lemon, Andy Malis, Satoru Matsushima, Tomek 3884 Mrugalski, Madhu Niraula, Alexandru Petrescu, Behcet Saikaya, Michal 3885 Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, Lloyd 3886 Wood and James Woodyatt. Members of the IESG also provided valuable 3887 input during their review process that greatly improved the document. 3888 Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman 3889 for their shepherding guidance during the publication of the AERO 3890 first edition. 3892 This work has further been encouraged and supported by Boeing 3893 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 3894 Brodie, John Bush, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, 3895 Claudiu Danilov, Don Dillenburg, Joe Dudkowski, Wen Fang, Samad 3896 Farooqui, Anthony Gregory, Jeff Holland, Seth Jahne, Brian Jaury, 3897 Greg Kimberly, Ed King, Madhuri Madhava Badgandi, Laurel Matthew, 3898 Gene MacLean III, Kyle Mikos, Rob Muszkiewicz, Sean O'Sullivan, Vijay 3899 Rajagopalan, Greg Saccone, Rod Santiago, Kent Shuey, Brian Skeen, 3900 Mike Slane, Carrie Spiker, Katie Tran, Brendan Williams, Amelia 3901 Wilson, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 3902 Boeing mobility, networking and autonomy teams. Kyle Bae, Wayne 3903 Benson, Madhuri Madhava Badgandi, Vijayasarathy Rajagopalan, Katie 3904 Tran and Eric Yeh are especially acknowledged for implementing the 3905 AERO functions as extensions to the public domain OpenVPN 3906 distribution. Chuck Klabunde is honored and remembered for his early 3907 leadership, and we mourn his untimely loss. 3909 Earlier works on NBMA tunneling approaches are found in 3910 [RFC2529][RFC5214][RFC5569]. 3912 Many of the constructs presented in this second edition of AERO are 3913 based on the author's earlier works, including: 3915 o The Internet Routing Overlay Network (IRON) 3916 [RFC6179][I-D.templin-ironbis] 3918 o Virtual Enterprise Traversal (VET) 3919 [RFC5558][I-D.templin-intarea-vet] 3921 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 3922 [RFC5320][I-D.templin-intarea-seal] 3924 o AERO, First Edition [RFC6706] 3926 Note that these works cite numerous earlier efforts that are not also 3927 cited here due to space limitations. The authors of those earlier 3928 works are acknowledged for their insights. 3930 This work is aligned with the NASA Safe Autonomous Systems Operation 3931 (SASO) program under NASA contract number NNA16BD84C. 3933 This work is aligned with the FAA as per the SE2025 contract number 3934 DTFAWA-15-D-00030. 3936 This work is aligned with the Boeing Commercial Airplanes (BCA) 3937 Internet of Things (IoT) and autonomy programs. 3939 This work is aligned with the Boeing Information Technology (BIT) 3940 MobileNet program. 3942 8. References 3944 8.1. Normative References 3946 [I-D.templin-6man-omni] 3947 Templin, F. L. and T. Whyman, "Transmission of IP Packets 3948 over Overlay Multilink Network (OMNI) Interfaces", draft- 3949 templin-6man-omni-03 (work in progress), April 2021. 3951 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3952 DOI 10.17487/RFC0791, September 1981, 3953 . 3955 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3956 RFC 792, DOI 10.17487/RFC0792, September 1981, 3957 . 3959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3960 Requirement Levels", BCP 14, RFC 2119, 3961 DOI 10.17487/RFC2119, March 1997, 3962 . 3964 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3965 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 3966 December 1998, . 3968 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 3969 "SEcure Neighbor Discovery (SEND)", RFC 3971, 3970 DOI 10.17487/RFC3971, March 2005, 3971 . 3973 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 3974 RFC 3972, DOI 10.17487/RFC3972, March 2005, 3975 . 3977 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3978 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 3979 November 2005, . 3981 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3982 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3983 . 3985 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 3986 Network Address Translations (NATs)", RFC 4380, 3987 DOI 10.17487/RFC4380, February 2006, 3988 . 3990 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3991 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3992 DOI 10.17487/RFC4861, September 2007, 3993 . 3995 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3996 Address Autoconfiguration", RFC 4862, 3997 DOI 10.17487/RFC4862, September 2007, 3998 . 4000 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 4001 DOI 10.17487/RFC6081, January 2011, 4002 . 4004 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 4005 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 4006 RFC 7401, DOI 10.17487/RFC7401, April 2015, 4007 . 4009 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 4010 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 4011 February 2016, . 4013 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4014 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4015 May 2017, . 4017 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4018 (IPv6) Specification", STD 86, RFC 8200, 4019 DOI 10.17487/RFC8200, July 2017, 4020 . 4022 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 4023 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 4024 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 4025 RFC 8415, DOI 10.17487/RFC8415, November 2018, 4026 . 4028 8.2. Informative References 4030 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 4031 2016. 4033 [I-D.bonica-6man-comp-rtg-hdr] 4034 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 4035 Jalil, "The IPv6 Compact Routing Header (CRH)", draft- 4036 bonica-6man-comp-rtg-hdr-24 (work in progress), January 4037 2021. 4039 [I-D.bonica-6man-crh-helper-opt] 4040 Li, X., Bao, C., Ruan, E., and R. Bonica, "Compressed 4041 Routing Header (CRH) Helper Option", draft-bonica-6man- 4042 crh-helper-opt-03 (work in progress), April 2021. 4044 [I-D.ietf-intarea-frag-fragile] 4045 Bonica, R., Baker, F., Huston, G., Hinden, R. M., Troan, 4046 O., and F. Gont, "IP Fragmentation Considered Fragile", 4047 draft-ietf-intarea-frag-fragile-17 (work in progress), 4048 September 2019. 4050 [I-D.ietf-intarea-tunnels] 4051 Touch, J. and M. Townsley, "IP Tunnels in the Internet 4052 Architecture", draft-ietf-intarea-tunnels-10 (work in 4053 progress), September 2019. 4055 [I-D.ietf-ipwave-vehicular-networking] 4056 (editor), J. (. J., "IPv6 Wireless Access in Vehicular 4057 Environments (IPWAVE): Problem Statement and Use Cases", 4058 draft-ietf-ipwave-vehicular-networking-20 (work in 4059 progress), March 2021. 4061 [I-D.ietf-rtgwg-atn-bgp] 4062 Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. 4063 Moreno, "A Simple BGP-based Mobile Routing System for the 4064 Aeronautical Telecommunications Network", draft-ietf- 4065 rtgwg-atn-bgp-10 (work in progress), January 2021. 4067 [I-D.templin-6man-dhcpv6-ndopt] 4068 Templin, F. L., "A Unified Stateful/Stateless 4069 Configuration Service for IPv6", draft-templin-6man- 4070 dhcpv6-ndopt-11 (work in progress), January 2021. 4072 [I-D.templin-intarea-seal] 4073 Templin, F. L., "The Subnetwork Encapsulation and 4074 Adaptation Layer (SEAL)", draft-templin-intarea-seal-68 4075 (work in progress), January 2014. 4077 [I-D.templin-intarea-vet] 4078 Templin, F. L., "Virtual Enterprise Traversal (VET)", 4079 draft-templin-intarea-vet-40 (work in progress), May 2013. 4081 [I-D.templin-ipwave-uam-its] 4082 Templin, F. L., "Urban Air Mobility Implications for 4083 Intelligent Transportation Systems", draft-templin-ipwave- 4084 uam-its-04 (work in progress), January 2021. 4086 [I-D.templin-ironbis] 4087 Templin, F. L., "The Interior Routing Overlay Network 4088 (IRON)", draft-templin-ironbis-16 (work in progress), 4089 March 2014. 4091 [I-D.templin-v6ops-pdhost] 4092 Templin, F. L., "IPv6 Prefix Delegation and Multi- 4093 Addressing Models", draft-templin-v6ops-pdhost-27 (work in 4094 progress), January 2021. 4096 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 4098 [RFC1035] Mockapetris, P., "Domain names - implementation and 4099 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4100 November 1987, . 4102 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 4103 RFC 1812, DOI 10.17487/RFC1812, June 1995, 4104 . 4106 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 4107 DOI 10.17487/RFC2003, October 1996, 4108 . 4110 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4111 DOI 10.17487/RFC2004, October 1996, 4112 . 4114 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 4115 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 4116 . 4118 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 4119 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 4120 . 4122 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 4123 Domains without Explicit Tunnels", RFC 2529, 4124 DOI 10.17487/RFC2529, March 1999, 4125 . 4127 [RFC2983] Black, D., "Differentiated Services and Tunnels", 4128 RFC 2983, DOI 10.17487/RFC2983, October 2000, 4129 . 4131 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4132 of Explicit Congestion Notification (ECN) to IP", 4133 RFC 3168, DOI 10.17487/RFC3168, September 2001, 4134 . 4136 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 4137 DOI 10.17487/RFC3330, September 2002, 4138 . 4140 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 4141 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 4142 DOI 10.17487/RFC3810, June 2004, 4143 . 4145 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 4146 Unique IDentifier (UUID) URN Namespace", RFC 4122, 4147 DOI 10.17487/RFC4122, July 2005, 4148 . 4150 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 4151 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 4152 January 2006, . 4154 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 4155 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 4156 DOI 10.17487/RFC4271, January 2006, 4157 . 4159 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 4160 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 4161 2006, . 4163 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4164 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 4165 December 2005, . 4167 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 4168 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 4169 2006, . 4171 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 4172 Control Message Protocol (ICMPv6) for the Internet 4173 Protocol Version 6 (IPv6) Specification", STD 89, 4174 RFC 4443, DOI 10.17487/RFC4443, March 2006, 4175 . 4177 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 4178 Protocol (LDAP): The Protocol", RFC 4511, 4179 DOI 10.17487/RFC4511, June 2006, 4180 . 4182 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 4183 "Considerations for Internet Group Management Protocol 4184 (IGMP) and Multicast Listener Discovery (MLD) Snooping 4185 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 4186 . 4188 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 4189 "Internet Group Management Protocol (IGMP) / Multicast 4190 Listener Discovery (MLD)-Based Multicast Forwarding 4191 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 4192 August 2006, . 4194 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 4195 Algorithms in Cryptographically Generated Addresses 4196 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 4197 . 4199 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 4200 "Bidirectional Protocol Independent Multicast (BIDIR- 4201 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 4202 . 4204 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 4205 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 4206 DOI 10.17487/RFC5214, March 2008, 4207 . 4209 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 4210 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 4211 February 2010, . 4213 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 4214 Route Optimization Requirements for Operational Use in 4215 Aeronautics and Space Exploration Mobile Networks", 4216 RFC 5522, DOI 10.17487/RFC5522, October 2009, 4217 . 4219 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 4220 RFC 5558, DOI 10.17487/RFC5558, February 2010, 4221 . 4223 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 4224 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 4225 January 2010, . 4227 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 4228 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 4229 . 4231 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 4232 "IPv6 Router Advertisement Options for DNS Configuration", 4233 RFC 6106, DOI 10.17487/RFC6106, November 2010, 4234 . 4236 [RFC6139] Russert, S., Ed., Fleischman, E., Ed., and F. Templin, 4237 Ed., "Routing and Addressing in Networks with Global 4238 Enterprise Recursion (RANGER) Scenarios", RFC 6139, 4239 DOI 10.17487/RFC6139, February 2011, 4240 . 4242 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 4243 NAT64: Network Address and Protocol Translation from IPv6 4244 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 4245 April 2011, . 4247 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 4248 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 4249 . 4251 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 4252 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 4253 DOI 10.17487/RFC6221, May 2011, 4254 . 4256 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 4257 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 4258 DOI 10.17487/RFC6273, June 2011, 4259 . 4261 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4262 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4263 January 2012, . 4265 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 4266 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 4267 DOI 10.17487/RFC6355, August 2011, 4268 . 4270 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 4271 for Equal Cost Multipath Routing and Link Aggregation in 4272 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 4273 . 4275 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 4276 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 4277 . 4279 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 4280 UDP Checksums for Tunneled Packets", RFC 6935, 4281 DOI 10.17487/RFC6935, April 2013, 4282 . 4284 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 4285 for the Use of IPv6 UDP Datagrams with Zero Checksums", 4286 RFC 6936, DOI 10.17487/RFC6936, April 2013, 4287 . 4289 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 4290 Korhonen, "Requirements for Distributed Mobility 4291 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 4292 . 4294 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 4295 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 4296 Multicast - Sparse Mode (PIM-SM): Protocol Specification 4297 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 4298 2016, . 4300 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 4301 Decraene, B., Litkowski, S., and R. Shakir, "Segment 4302 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 4303 July 2018, . 4305 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4306 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4307 . 4309 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 4310 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 4311 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 4312 . 4314 [WG] Wireguard, "WireGuard, https://www.wireguard.com", August 4315 2020. 4317 Appendix A. Non-Normative Considerations 4319 AERO can be applied to a multitude of Internetworking scenarios, with 4320 each having its own adaptations. The following considerations are 4321 provided as non-normative guidance: 4323 A.1. Implementation Strategies for Route Optimization 4325 Route optimization as discussed in Section 3.14 results in the route 4326 optimization source (ROS) creating a NCE for the target neighbor. 4327 The NCE state is set to REACHABLE for at most ReachableTime seconds. 4328 In order to refresh the NCE lifetime before the ReachableTime timer 4329 expires, the specification requires implementations to issue a new 4330 NS/NA(AR) exchange to reset ReachableTime while data packets are 4331 still flowing. However, the decision of when to initiate a new NS/ 4332 NA(AR) exchange and to perpetuate the process is left as an 4333 implementation detail. 4335 One possible strategy may be to monitor the NCE watching for data 4336 packets for (ReachableTime - 5) seconds. If any data packets have 4337 been sent to the neighbor within this timeframe, then send an NS(AR) 4338 to receive a new NA(AR). If no data packets have been sent, wait for 4339 5 additional seconds and send an immediate NS(AR) if any data packets 4340 are sent within this "expiration pending" 5 second window. If no 4341 additional data packets are sent within the 5 second window, reset 4342 the NCE state to STALE. 4344 The monitoring of the neighbor data packet traffic therefore becomes 4345 an ongoing process during the NCE lifetime. If the NCE expires, 4346 future data packets will trigger a new NS/NA(AR) exchange while the 4347 packets themselves are delivered over a longer path until route 4348 optimization state is re-established. 4350 A.2. Implicit Mobility Management 4352 OMNI interface neighbors MAY provide a configuration option that 4353 allows them to perform implicit mobility management in which no ND 4354 messaging is used. In that case, the Client only transmits packets 4355 over a single interface at a time, and the neighbor always observes 4356 packets arriving from the Client from the same link-layer source 4357 address. 4359 If the Client's underlying interface address changes (either due to a 4360 readdressing of the original interface or switching to a new 4361 interface) the neighbor immediately updates the NCE for the Client 4362 and begins accepting and sending packets according to the Client's 4363 new address. This implicit mobility method applies to use cases such 4364 as cellphones with both WiFi and Cellular interfaces where only one 4365 of the interfaces is active at a given time, and the Client 4366 automatically switches over to the backup interface if the primary 4367 interface fails. 4369 A.3. Direct Underlying Interfaces 4371 When a Client's OMNI interface is configured over a Direct interface, 4372 the neighbor at the other end of the Direct link can receive packets 4373 without any encapsulation. In that case, the Client sends packets 4374 over the Direct link according to traffic selectors. If the Direct 4375 interface is selected, then the Client's IP packets are transmitted 4376 directly to the peer without going through an ANET/INET. If other 4377 interfaces are selected, then the Client's IP packets are transmitted 4378 via a different interface, which may result in the inclusion of 4379 Proxy/Servers and Bridges in the communications path. Direct 4380 interfaces must be tested periodically for reachability, e.g., via 4381 NUD. 4383 A.4. AERO Critical Infrastructure Considerations 4385 AERO Bridges can be either Commercial off-the Shelf (COTS) standard 4386 IP routers or virtual machines in the cloud. Bridges must be 4387 provisioned, supported and managed by the INET administrative 4388 authority, and connected to the Bridges of other INETs via inter- 4389 domain peerings. Cost for purchasing, configuring and managing 4390 Bridges is nominal even for very large OMNI links. 4392 AERO INET Proxy/Servers can be standard dedicated server platforms, 4393 but most often will be deployed as virtual machines in the cloud. 4394 The only requirements for INET Proxy/Servers are that they can run 4395 the AERO/OMNI code and have at least one network interface connection 4396 to the INET. INET Proxy/Servers must be provisioned, supported and 4397 managed by the INET administrative authority. Cost for purchasing, 4398 configuring and managing cloud Proxy/Servers is nominal especially 4399 for virtual machines. 4401 AERO ANET Proxy/Servers are most often standard dedicated server 4402 platforms with one underlying interface connected to the ANET and a 4403 second interface connected to an INET. As with INET Proxy/Servers, 4404 the only requirements are that they can run the AERO/OMNI code and 4405 have at least one interface connection to the INET. ANET Proxy/ 4406 Servers must be provisioned, supported and managed by the ANET 4407 administrative authority. Cost for purchasing, configuring and 4408 managing Proxys is nominal, and borne by the ANET administrative 4409 authority. 4411 AERO Relays are simply Proxy/Servers connected to INETs and/or EUNs 4412 that provide forwarding services for non-MNP destinations. The Relay 4413 connects to the OMNI link and engages in eBGP peering with one or 4414 more Bridges as a stub AS. The Relay then injects its MNPs and/or 4415 non-MNP prefixes into the BGP routing system, and provisions the 4416 prefixes to its downstream-attached networks. The Relay can perform 4417 ROS/ROR services the same as for any Proxy/Server, and can route 4418 between the MNP and non-MNP address spaces. 4420 A.5. AERO Server Failure Implications 4422 AERO Proxy/Servers may appear as a single point of failure in the 4423 architecture, but such is not the case since all Proxy/Servers on the 4424 link provide identical services and loss of a Proxy/Server does not 4425 imply immediate and/or comprehensive communication failures. Proxy/ 4426 Server failure is quickly detected and conveyed by Bidirectional 4427 Forward Detection (BFD) and/or proactive NUD allowing Clients to 4428 migrate to new Proxy/Servers. 4430 If a Proxy/Server fails, ongoing packet forwarding to Clients will 4431 continue by virtue of the neighbor cache entries that have already 4432 been established in route optimization sources (ROSs). If a Client 4433 also experiences mobility events at roughly the same time the Proxy/ 4434 Server fails, uNA messages may be lost but neighbor cache entries in 4435 the DEPARTED state will ensure that packet forwarding to the Client's 4436 new locations will continue for up to DepartTime seconds. 4438 If a Client is left without a Proxy/Server for a considerable length 4439 of time (e.g., greater than ReachableTime seconds) then existing 4440 neighbor cache entries will eventually expire and both ongoing and 4441 new communications will fail. The original source will continue to 4442 retransmit until the Client has established a new Proxy/Server 4443 relationship, after which time continuous communications will resume. 4445 Therefore, providing many Proxy/Servers on the link with high 4446 availability profiles provides resilience against loss of individual 4447 Proxy/Servers and assurance that Clients can establish new Proxy/ 4448 Server relationships quickly in event of a Proxy/Server failure. 4450 A.6. AERO Client / Server Architecture 4452 The AERO architectural model is client / server in the control plane, 4453 with route optimization in the data plane. The same as for common 4454 Internet services, the AERO Client discovers the addresses of AERO 4455 Proxy/Servers and connects to one or more of them. The AERO service 4456 is analogous to common Internet services such as google.com, 4457 yahoo.com, cnn.com, etc. However, there is only one AERO service for 4458 the link and all Proxy/Servers provide identical services. 4460 Common Internet services provide differing strategies for advertising 4461 server addresses to clients. The strategy is conveyed through the 4462 DNS resource records returned in response to name resolution queries. 4463 As of January 2020 Internet-based 'nslookup' services were used to 4464 determine the following: 4466 o When a client resolves the domainname "google.com", the DNS always 4467 returns one A record (i.e., an IPv4 address) and one AAAA record 4468 (i.e., an IPv6 address). The client receives the same addresses 4469 each time it resolves the domainname via the same DNS resolver, 4470 but may receive different addresses when it resolves the 4471 domainname via different DNS resolvers. But, in each case, 4472 exactly one A and one AAAA record are returned. 4474 o When a client resolves the domainname "ietf.org", the DNS always 4475 returns one A record and one AAAA record with the same addresses 4476 regardless of which DNS resolver is used. 4478 o When a client resolves the domainname "yahoo.com", the DNS always 4479 returns a list of 4 A records and 4 AAAA records. Each time the 4480 client resolves the domainname via the same DNS resolver, the same 4481 list of addresses are returned but in randomized order (i.e., 4482 consistent with a DNS round-robin strategy). But, interestingly, 4483 the same addresses are returned (albeit in randomized order) when 4484 the domainname is resolved via different DNS resolvers. 4486 o When a client resolves the domainname "amazon.com", the DNS always 4487 returns a list of 3 A records and no AAAA records. As with 4488 "yahoo.com", the same three A records are returned from any 4489 worldwide Internet connection point in randomized order. 4491 The above example strategies show differing approaches to Internet 4492 resilience and service distribution offered by major Internet 4493 services. The Google approach exposes only a single IPv4 and a 4494 single IPv6 address to clients. Clients can then select whichever IP 4495 protocol version offers the best response, but will always use the 4496 same IP address according to the current Internet connection point. 4497 This means that the IP address offered by the network must lead to a 4498 highly-available server and/or service distribution point. In other 4499 words, resilience is predicated on high availability within the 4500 network and with no client-initiated failovers expected (i.e., it is 4501 all-or-nothing from the client's perspective). However, Google does 4502 provide for worldwide distributed service distribution by virtue of 4503 the fact that each Internet connection point responds with a 4504 different IPv6 and IPv4 address. The IETF approach is like google 4505 (all-or-nothing from the client's perspective), but provides only a 4506 single IPv4 or IPv6 address on a worldwide basis. This means that 4507 the addresses must be made highly-available at the network level with 4508 no client failover possibility, and if there is any worldwide service 4509 distribution it would need to be conducted by a network element that 4510 is reached via the IP address acting as a service distribution point. 4512 In contrast to the Google and IETF philosophies, Yahoo and Amazon 4513 both provide clients with a (short) list of IP addresses with Yahoo 4514 providing both IP protocol versions and Amazon as IPv4-only. The 4515 order of the list is randomized with each name service query 4516 response, with the effect of round-robin load balancing for service 4517 distribution. With a short list of addresses, there is still 4518 expectation that the network will implement high availability for 4519 each address but in case any single address fails the client can 4520 switch over to using a different address. The balance then becomes 4521 one of function in the network vs function in the end system. 4523 The same implications observed for common highly-available services 4524 in the Internet apply also to the AERO client/server architecture. 4525 When an AERO Client connects to one or more ANETs, it discovers one 4526 or more AERO Proxy/Server addresses through the mechanisms discussed 4527 in earlier sections. Each Proxy/Server address presumably leads to a 4528 fault-tolerant clustering arrangement such as supported by Linux-HA, 4529 Extended Virtual Synchrony or Paxos. Such an arrangement has 4530 precedence in common Internet service deployments in lightweight 4531 virtual machines without requiring expensive hardware deployment. 4532 Similarly, common Internet service deployments set service IP 4533 addresses on service distribution points that may relay requests to 4534 many different servers. 4536 For AERO, the expectation is that a combination of the Google/IETF 4537 and Yahoo/Amazon philosophies would be employed. The AERO Client 4538 connects to different ANET access points and can receive 1-2 Proxy/ 4539 Server ADM-LLAs at each point. It then selects one AERO Proxy/Server 4540 address, and engages in RS/RA exchanges with the same Proxy/Server 4541 from all ANET connections. The Client remains with this Proxy/Server 4542 unless or until the Proxy/Server fails, in which case it can switch 4543 over to an alternate Proxy/Server. The Client can likewise switch 4544 over to a different Proxy/Server at any time if there is some reason 4545 for it to do so. So, the AERO expectation is for a balance of 4546 function in the network and end system, with fault tolerance and 4547 resilience at both levels. 4549 Appendix B. Change Log 4551 << RFC Editor - remove prior to publication >> 4553 Changes from draft-templin-6man-aero-13 to draft-templin-6man-aero- 4554 14: 4556 o Final editorial review pass resulting in multiple changes. 4557 Document now submit for final approval (with reference to rfcdiff 4558 from previous version). 4560 Changes from draft-templin-6man-aero-12 to draft-templin-6man-aero- 4561 13: 4563 o Final editorial review pass resulting in multiple changes. 4564 Document now submit for final approval (with reference to rfcdiff 4565 from previous version). 4567 Changes from draft-templin-6man-aero-11 to draft-templin-6man-aero- 4568 12: 4570 o Final editorial review pass resulting in multiple changes. 4571 Document now submit for final approval (with reference to rfcdiff 4572 from previous version). 4574 Changes from draft-templin-6man-aero-10 to draft-templin-6man-aero- 4575 11: 4577 o Final editorial review pass resulting in multiple changes. 4578 Document now submit for final approval (with reference to rfcdiff 4579 from previous version). 4581 Changes from draft-templin-6man-aero-09 to draft-templin-6man-aero- 4582 10: 4584 o Final editorial review pass resulting in multiple changes. 4585 Document now submit for final approval (with reference to rfcdiff 4586 from previous version). 4588 Changes from draft-templin-6man-aero-08 to draft-templin-6man-aero- 4589 09: 4591 o Final editorial review pass resulting in multiple changes. 4592 Document now submit for final approval (with reference to rfcdiff 4593 from previous version). 4595 Changes from draft-templin-6man-aero-07 to draft-templin-6man-aero- 4596 08: 4598 o Final editorial review pass resulting in multiple changes. 4599 Document now submit for final approval (with reference to rfcdiff 4600 from previous version). 4602 Changes from draft-templin-6man-aero-06 to draft-templin-6man-aero- 4603 07: 4605 o Final editorial review pass resulting in multiple changes. 4606 Document now submit for final approval (with reference to rfcdiff 4607 from previous version). 4609 Changes from draft-templin-6man-aero-05 to draft-templin-6man-aero- 4610 06: 4612 o Final editorial review pass resulting in multiple changes. 4613 Document now submit for final approval. 4615 Changes from draft-templin-6man-aero-04 to draft-templin-6man-aero- 4616 05: 4618 o Changed to use traffic selectors instead of the former multilink 4619 selection strategy. 4621 Changes from draft-templin-6man-aero-03 to draft-templin-6man-aero- 4622 04: 4624 o Removed documents from "Obsoletes" list. 4626 o Introduced the concept of "secured" and "unsecured" spanning tree. 4628 o Additional security considerations. 4630 o Additional route optimization considerations. 4632 Changes from draft-templin-6man-aero-02 to draft-templin-6man-aero- 4633 03: 4635 o Support for extended route optimization from ROR to target over 4636 target's underlying interfaces. 4638 Changes from draft-templin-6man-aero-01 to draft-templin-6man-aero- 4639 02: 4641 o Changed reference citations to "draft-templin-6man-omni". 4643 o Several important updates to IPv6 ND cache states and route 4644 optimization message addressing. 4646 o Included introductory description of the "6M's". 4648 o Updated Multicast specification. 4650 Changes from draft-templin-6man-aero-00 to draft-templin-6man-aero- 4651 01: 4653 o Changed category to "Informational". 4655 o Updated implementation status. 4657 Changes from earlier versions to draft-templin-6man-aero-00: 4659 o Established working baseline reference. 4661 Author's Address 4662 Fred L. Templin (editor) 4663 Boeing Research & Technology 4664 P.O. Box 3707 4665 Seattle, WA 98124 4666 USA 4668 Email: fltemplin@acm.org