idnits 2.17.1 draft-templin-intarea-6706bis-99.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 : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2021) is 1123 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ULA' is mentioned on line 1059, but not defined == Missing Reference: 'ULA0' is mentioned on line 1059, but not defined == Missing Reference: 'ULA1' is mentioned on line 1059, but not defined == Missing Reference: 'ULA2' is mentioned on line 1059, but not defined == Unused Reference: 'RFC3971' is defined on line 3559, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 3564, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 3572, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 3621, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-comp-rtg-hdr' is defined on line 3624, but no explicit reference was found in the text == Unused Reference: 'I-D.bonica-6man-crh-helper-opt' is defined on line 3630, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-frag-fragile' is defined on line 3635, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-dhcpv6-ndopt' is defined on line 3658, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 3697, but no explicit reference was found in the text == Unused Reference: 'RFC2983' is defined on line 3718, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 3722, but no explicit reference was found in the text == Unused Reference: 'RFC4122' is defined on line 3736, but no explicit reference was found in the text == Unused Reference: 'RFC4982' is defined on line 3785, but no explicit reference was found in the text == Unused Reference: 'RFC6273' is defined on line 3841, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 3850, but no explicit reference was found in the text == Unused Reference: 'RFC6438' is defined on line 3855, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 3864, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 3869, but no explicit reference was found in the text == Outdated reference: A later version (-99) exists of draft-templin-6man-omni-interface-69 ** Downref: Normative reference to an Informational RFC: RFC 7739 == 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-02 == 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-19 == 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: 1 error (**), 0 flaws (~~), 30 warnings (==), 4 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 Obsoletes: rfc5320, rfc5558, rfc5720, March 23, 2021 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: September 24, 2021 10 Automatic Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-99 13 Abstract 15 This document specifies an Automatic Extended Route Optimization 16 (AERO) service for IP internetworking over Overlay Multilink Network 17 (OMNI) interfaces. AERO/OMNI use an IPv6 link-local address format 18 that supports operation of the IPv6 Neighbor Discovery (ND) protocol 19 and links ND to IP forwarding. Prefix delegation/registration 20 services are employed for network admission and to manage the routing 21 system. Secure multilink operation, mobility management, multicast, 22 quality of service (QoS) signaling and route optimization are 23 naturally supported through dynamic neighbor cache updates. AERO is 24 a widely-applicable mobile internetworking service especially well- 25 suited to aviation services, intelligent transportation systems, 26 mobile Virtual Private Networks (VPNs) and many other applications. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 24, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Automatic Extended Route Optimization (AERO) . . . . . . . . 12 65 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 12 66 3.2. The AERO Service over OMNI Links . . . . . . . . . . . . 13 67 3.2.1. AERO/OMNI Reference Model . . . . . . . . . . . . . . 13 68 3.2.2. Addressing and Node Identification . . . . . . . . . 16 69 3.2.3. AERO Routing System . . . . . . . . . . . . . . . . . 17 70 3.2.4. OMNI Link Segment Routing . . . . . . . . . . . . . . 19 71 3.2.5. Segment Routing Topologies (SRTs) . . . . . . . . . . 23 72 3.2.6. Segment Routing For OMNI Link Selection . . . . . . . 24 73 3.2.7. Segment Routing Within the OMNI Link . . . . . . . . 24 74 3.3. OMNI Interface Characteristics . . . . . . . . . . . . . 25 75 3.4. OMNI Interface Initialization . . . . . . . . . . . . . . 27 76 3.4.1. AERO Proxy/Server and Relay Behavior . . . . . . . . 27 77 3.4.2. AERO Client Behavior . . . . . . . . . . . . . . . . 28 78 3.4.3. AERO Bridge Behavior . . . . . . . . . . . . . . . . 28 79 3.5. OMNI Interface Neighbor Cache Maintenance . . . . . . . . 28 80 3.5.1. OMNI Neighbor Interface Attributes . . . . . . . . . 30 81 3.5.2. OMNI Neighbor Advertisement Message Flags . . . . . . 30 82 3.6. OMNI Interface Encapsulation and Re-encapsulation . . . . 31 83 3.7. OMNI Interface Decapsulation . . . . . . . . . . . . . . 31 84 3.8. OMNI Interface Data Origin Authentication . . . . . . . . 31 85 3.9. OMNI Interface MTU . . . . . . . . . . . . . . . . . . . 32 86 3.10. OMNI Interface Forwarding Algorithm . . . . . . . . . . . 33 87 3.10.1. Client Forwarding Algorithm . . . . . . . . . . . . 34 88 3.10.2. Proxy/Server Forwarding Algorithm . . . . . . . . . 35 89 3.10.3. Bridge Forwarding Algorithm . . . . . . . . . . . . 37 90 3.11. OMNI Interface Error Handling . . . . . . . . . . . . . . 39 91 3.12. AERO Router Discovery, Prefix Delegation and 92 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 41 94 3.12.1. AERO Service Model . . . . . . . . . . . . . . . . . 42 95 3.12.2. AERO Client Behavior . . . . . . . . . . . . . . . . 42 96 3.12.3. AERO Proxy/Server Behavior . . . . . . . . . . . . . 44 97 3.13. The AERO Proxy Function . . . . . . . . . . . . . . . . . 47 98 3.13.1. Detecting and Responding to Proxy/Server Failures . 50 99 3.13.2. Point-to-Multipoint Server Coordination . . . . . . 51 100 3.14. AERO Address Resolution . . . . . . . . . . . . . . . . . 51 101 3.14.1. Route Optimization Initiation . . . . . . . . . . . 52 102 3.14.2. Relaying the NS(AR) *NET Packet(s) . . . . . . . . . 53 103 3.14.3. Processing the NS(AR) and Sending the NA(AR) . . . . 53 104 3.14.4. Relaying the NA(AR) . . . . . . . . . . . . . . . . 55 105 3.14.5. Processing the NA(AR) . . . . . . . . . . . . . . . 55 106 3.14.6. Route Optimization Maintenance . . . . . . . . . . . 56 107 3.15. Neighbor Unreachability Detection (NUD) . . . . . . . . . 57 108 3.16. Mobility Management and Quality of Service (QoS) . . . . 59 109 3.16.1. Mobility Update Messaging . . . . . . . . . . . . . 59 110 3.16.2. Announcing Link-Layer Address and/or QoS Preference 111 Changes . . . . . . . . . . . . . . . . . . . . . . 60 112 3.16.3. Bringing New Links Into Service . . . . . . . . . . 61 113 3.16.4. Deactivating Existing Links . . . . . . . . . . . . 61 114 3.16.5. Moving Between Proxy/Servers . . . . . . . . . . . . 61 115 3.17. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 63 116 3.17.1. Source-Specific Multicast (SSM) . . . . . . . . . . 63 117 3.17.2. Any-Source Multicast (ASM) . . . . . . . . . . . . . 65 118 3.17.3. Bi-Directional PIM (BIDIR-PIM) . . . . . . . . . . . 65 119 3.18. Operation over Multiple OMNI Links . . . . . . . . . . . 65 120 3.19. DNS Considerations . . . . . . . . . . . . . . . . . . . 66 121 3.20. Transition/Coexistence Considerations . . . . . . . . . . 67 122 3.21. Detecting and Reacting to Server and Bridge Failures . . 67 123 3.22. AERO Clients on the Open Internet . . . . . . . . . . . . 68 124 3.23. Time-Varying MNPs . . . . . . . . . . . . . . . . . . . . 71 125 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 72 126 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 127 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 128 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 129 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 130 8.1. Normative References . . . . . . . . . . . . . . . . . . 76 131 8.2. Informative References . . . . . . . . . . . . . . . . . 77 132 Appendix A. Non-Normative Considerations . . . . . . . . . . . . 84 133 A.1. Implementation Strategies for Route Optimization . . . . 84 134 A.2. Implicit Mobility Management . . . . . . . . . . . . . . 84 135 A.3. Direct Underlying Interfaces . . . . . . . . . . . . . . 85 136 A.4. AERO Critical Infrastructure Considerations . . . . . . . 85 137 A.5. AERO Server Failure Implications . . . . . . . . . . . . 86 138 A.6. AERO Client / Server Architecture . . . . . . . . . . . . 86 139 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 89 140 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 89 142 1. Introduction 144 Automatic Extended Route Optimization (AERO) fulfills the 145 requirements of Distributed Mobility Management (DMM) [RFC7333] and 146 route optimization [RFC5522] for aeronautical networking and other 147 network mobility use cases such as intelligent transportation 148 systems. AERO is a secure internetworking and mobility management 149 service that employs the Overlay Multilink Network Interface (OMNI) 150 [I-D.templin-6man-omni-interface] Non-Broadcast, Multiple Access 151 (NBMA) virtual link model. The OMNI link is a virtual overlay 152 configured over one or more underlying Internetworks, and nodes on 153 the link can exchange original IP packets as single-hop neighbors via 154 encapsulation and fragmentation. The OMNI Adaptation Layer (OAL) 155 supports multilink operation for increased reliability, bandwidth 156 optimization and traffic path selection while performing 157 fragmentation and reassembly to accommodate Maximum Transmission Unit 158 (MTU) diversity. 160 The AERO service comprises Clients, Proxy/Servers and Relays that are 161 seen as OMNI link neighbors as well as Bridges that interconnect OMNI 162 link segments through OAL forwarding at a layer below IP. Each 163 node's OMNI interface uses an IPv6 link-local address format that 164 supports operation of the IPv6 Neighbor Discovery (ND) protocol 165 [RFC4861] and links ND to IP forwarding. A node's OMNI interface can 166 be configured over multiple underlying interfaces, and therefore 167 appears as a single interface with multiple link-layer addresses. 168 Each link-layer address is subject to change due to mobility and/or 169 QoS fluctuations, and link-layer address changes are signaled by ND 170 messaging the same as for any IPv6 link. 172 AERO provides a secure cloud-based service where mobile node Clients 173 may use any Proxy/Server acting as a Mobility Anchor Point (MAP) and 174 fixed nodes may use any Relay on the link for efficient 175 communications. Fixed nodes forward original IP packets destined to 176 other AERO nodes via the nearest Relay, which forwards them through 177 the cloud. A mobile node's initial packets are forwarded through the 178 Proxy/Server, and direct routing is supported through automatic 179 extended route optimization while packets are flowing. Both unicast 180 and multicast communications are supported, and mobile nodes may 181 efficiently move between locations while maintaining continuous 182 communications with correspondents and without changing their IP 183 Address. 185 AERO Bridges are interconnected in a secured private BGP overlay 186 routing instance to provide an OAL routing/bridging service that 187 joins the underlying Internetworks of multiple disjoint 188 administrative domains into a single unified OMNI link at a layer 189 below IP. Each OMNI link instance is characterized by the set of 190 Mobility Service Prefixes (MSPs) common to all mobile nodes. The 191 link extends to the point where a Relay is on the optimal route from 192 any correspondent node on the link, and provides a conduit between 193 the underlying Internetwork and the OMNI link. To the underlying 194 Internetwork, the Relay is the source of a route to the MSP, and 195 hence uplink traffic to the mobile node is naturally routed to the 196 nearest Relay. 198 AERO can be used with OMNI links that span private-use Internetworks 199 and/or public Internetworks such as the global Internet. In the 200 latter case, some end systems may be located behind global Internet 201 Network Address Translators (NATs). A means for robust traversal of 202 NATs while avoiding "triangle routing" is therefore provided. 204 AERO assumes the use of PIM Sparse Mode in support of multicast 205 communication. In support of Source Specific Multicast (SSM) when a 206 Mobile Node is the source, AERO route optimization ensures that a 207 shortest-path multicast tree is established with provisions for 208 mobility and multilink operation. In all other multicast scenarios 209 there are no AERO dependencies. 211 AERO was designed as a secure aeronautical internetworking service 212 for both manned and unmanned aircraft, where the aircraft is treated 213 as a mobile node that can connect an Internet of Things (IoT). AERO 214 is also applicable to a wide variety of other use cases. For 215 example, it can be used to coordinate the links of mobile nodes 216 (e.g., cellphones, tablets, laptop computers, etc.) that connect into 217 a home enterprise network via public access networks using tunneling 218 software such as OpenVPN [OVPN] with VPN or non-VPN services enabled 219 according to the appropriate security model. AERO can also be used 220 to facilitate terrestrial vehicular and urban air mobility (as well 221 as pedestrian communication services) for future intelligent 222 transportation systems 223 [I-D.ietf-ipwave-vehicular-networking][I-D.templin-ipwave-uam-its]. 224 Other applicable use cases are also in scope. 226 The following numbered sections present the AERO specification. The 227 appendices at the end of the document are non-normative. 229 2. Terminology 231 The terminology in the normative references applies; especially, the 232 terminology in the OMNI specification 233 [I-D.templin-6man-omni-interface] is used extensively throughout. 234 The following terms are defined within the scope of this document: 236 IPv6 Neighbor Discovery (ND) 237 a control message service for coordinating neighbor relationships 238 between nodes connected to a common link. AERO uses the IPv6 ND 239 messaging service specified in [RFC4861]. 241 IPv6 Prefix Delegation 242 a networking service for delegating IPv6 prefixes to nodes on the 243 link. The nominal service is DHCPv6 [RFC8415], however alternate 244 services (e.g., based on ND messaging) are also in scope. Most 245 notably, a minimal form of prefix delegation known as "prefix 246 registration" can be used if the Client knows its prefix in 247 advance and can represent it in the IPv6 source address of an ND 248 message. 250 Access Network (ANET) 251 a node's first-hop data link service network (e.g., a radio access 252 network, cellular service provider network, corporate enterprise 253 network, etc.) that often provides link-layer security services 254 such as IEEE 802.1X and physical-layer security (e.g., "protected 255 spectrum") to prevent unauthorized access internally and with 256 border network-layer security services such as firewalls and 257 proxys that prevent unauthorized outside access. 259 ANET interface 260 a node's attachment to a link in an ANET. 262 Internetwork (INET) 263 a connected IP network topology with a coherent routing and 264 addressing plan and that provides a transit backbone service for 265 ANET end systems. INETs also provide an underlay service over 266 which the AERO virtual link is configured. Example INETs include 267 corporate enterprise networks, aviation networks, and the public 268 Internet itself. When there is no administrative boundary between 269 an ANET and the INET, the ANET and INET are one and the same. 271 INET interface 272 a node's attachment to a link in an INET. 274 *NET 275 a "wildcard" term referring to either ANET or INET when it is not 276 necessary to draw a distinction between the two. 278 *NET interface 279 a node's attachment to a link in a *NET. 281 *NET Partition 282 frequently, *NETs such as large corporate enterprise networks are 283 sub-divided internally into separate isolated partitions. Each 284 partition is fully connected internally but disconnected from 285 other partitions, and there is no requirement that separate 286 partitions maintain consistent Internet Protocol and/or addressing 287 plans. (Each *NET partition is seen as a separate OMNI link 288 segment as discussed below.) 290 *NET address 291 an IP address assigned to a node's interface connection to a *NET. 293 *NET encapsulation 294 the encapsulation of a packet in an outer header or headers that 295 can be routed within the scope of the local *NET partition. 297 OMNI link 298 the same as defined in [I-D.templin-6man-omni-interface], and 299 manifested by IPv6 encapsulation [RFC2473]. The OMNI link spans 300 underlying INET segments joined by virtual bridges in a spanning 301 tree the same as a bridged campus LAN. AERO nodes on the OMNI 302 link appear as single-hop neighbors even though they may be 303 separated by multiple underlying INET hops, and can use Segment 304 Routing [RFC8402] to cause packets to visit selected waypoints on 305 the link. 307 OMNI Interface 308 a node's attachment to an OMNI link. Since the addresses assigned 309 to an OMNI interface are managed for uniqueness, OMNI interfaces 310 do not require Duplicate Address Detection (DAD) and therefore set 311 the administrative variable 'DupAddrDetectTransmits' to zero 312 [RFC4862]. 314 OMNI Adaptation Layer (OAL) 315 an OMNI interface process whereby original IP packets admitted 316 into the interface are wrapped in a mid-layer IPv6 header and 317 subject to fragmentation and reassembly. The OAL is also 318 responsible for generating MTU-related control messages as 319 necessary, and for providing addressing context for spanning 320 multiple segments of a bridged OMNI link. 322 original IP packet 323 a whole IP packet or fragment admitted into the OMNI interface by 324 the network layer prior to OAL encapsulation and fragmentation, or 325 an IP packet delivered to the network layer by the OMNI interface 326 following OAL decapsulation and reassembly. 328 OAL packet 329 an original IP packet encapsulated in OAL headers and trailers 330 before OAL fragmentation, or following OAL reassembly. 332 OAL fragment 333 a portion of an OAL packet following fragmentation but prior to 334 *NET encapsulation, or following *NET encapsulation but prior to 335 OAL reassembly. 337 (OAL) carrier packet 338 an encapsulated OAL fragment following *NET encapsulation or prior 339 to *NET decapsulation. OAL sources and destinations exchange 340 carrier packets over underlying interfaces, and may be separated 341 by one or more OAL intermediate nodes. OAL intermediate nodes may 342 perform re-encapsulation on carrier packets by removing the *NET 343 headers of the first hop network and replacing them with new *NET 344 headers for the next hop network. 346 OAL source 347 an OMNI interface acts as an OAL source when it encapsulates 348 original IP packets to form OAL packets, then performs OAL 349 fragmentation and *NET encapsulation to create carrier packets. 351 OAL destination 352 an OMNI interface acts as an OAL destination when it decapsulates 353 carrier packets, then performs OAL reassembly and decapsulation to 354 derive the original IP packet. 356 OAL intermediate node 357 an OMNI interface acts as an OAL intermediate node when it removes 358 the *NET headers of carrier packets received on a first segment, 359 then re-encapsulates the carrier packets in new *NET headers and 360 forwards them into the next segment. OAL intermediate nodes 361 decrement the Hop Limit of the OAL IPv6 header during re- 362 encapsulation, and discard the packet if the Hop Limit reaches 0. 364 underlying interface 365 a *NET interface over which an OMNI interface is configured. 367 Mobility Service Prefix (MSP) 368 an aggregated IP Global Unicast Address (GUA) prefix (e.g., 369 2001:db8::/32, 192.0.2.0/24, etc.) assigned to the OMNI link and 370 from which more-specific Mobile Network Prefixes (MNPs) are 371 delegated. OMNI link administrators typically obtain MSPs from an 372 Internet address registry, however private-use prefixes can 373 alternatively be used subject to certain limitations (see: 374 [I-D.templin-6man-omni-interface]). OMNI links that connect to 375 the global Internet advertise their MSPs to their interdomain 376 routing peers. 378 Mobile Network Prefix (MNP) 379 a longer IP prefix delegated from an MSP (e.g., 380 2001:db8:1000:2000::/56, 192.0.2.8/30, etc.) and delegated to an 381 AERO Client or Relay. 383 Mobile Network Prefix Link Local Address (MNP-LLA) 384 an IPv6 Link Local Address that embeds the most significant 64 385 bits of an MNP in the lower 64 bits of fe80::/64, as specified in 386 [I-D.templin-6man-omni-interface]. 388 Mobile Network Prefix Unique Local Address (MNP-ULA) 389 an IPv6 Unique-Local Address derived from an MNP-LLA. 391 Administrative Link Local Address (ADM-LLA) 392 an IPv6 Link Local Address that embeds a 32-bit administratively- 393 assigned identification value in the lower 32 bits of fe80::/96, 394 as specified in [I-D.templin-6man-omni-interface]. 396 Administrative Unique Local Address (ADM-ULA) 397 an IPv6 Unique-Local Address derived from an ADM-LLA. 399 AERO node 400 a node that is connected to an OMNI link and participates in the 401 AERO internetworking and mobility service. 403 AERO Client ("Client") 404 an AERO node that connects over one or more underlying interfaces 405 and requests MNP delegation/registration service from AERO Proxy/ 406 Servers. The Client assigns an MNP-LLA to the OMNI interface for 407 use in ND exchanges with other AERO nodes and forwards original IP 408 packets to correspondents according to OMNI interface neighbor 409 cache state. 411 AERO Proxy/Server ("Proxy/Server") 412 a dual-function node that provides a proxying service between AERO 413 Clients and external peers on its Client-facing ANET interfaces 414 (i.e., in the same fashion as for an enterprise network proxy) as 415 well as default forwarding and Mobility Anchor Point (MAP) 416 services for coordination with correspondents on its INET-facing 417 interfaces. The Proxy/Server configures an OMNI interface and 418 assigns an ADM-LLA to support the operation of IPv6 ND services, 419 while advertising all of its associated MNPs via BGP peerings with 420 Bridges. Note that the Proxy and Server functions can be 421 considered logically separable, but since each Proxy/Server must 422 be informed of all of the Client's other multilink Proxy/Server 423 affiliations the AERO service is best supported when the two 424 functions are coresident on the same physical or logical platform. 426 AERO Relay ("Relay") 427 a Proxy/Server that provides forwarding services between nodes 428 reached via the OMNI link and correspondents on connected 429 downstream links. AERO Relays configure an OMNI interface and 430 assign an ADM-LLA the same as Proxy/Servers. AERO Relays also run 431 a dynamic routing protocol to discover any non-MNP IP GUA routes 432 in service on its connected downstream network links. In both 433 cases, the Relay advertises the MSP(s) to its downstream networks, 434 and distributes all of its associated non-MNP IP GUA routes via 435 BGP peerings with Bridges (i.e., the same as for Proxy/Servers). 437 AERO Bridge ("Bridge") 438 a node that provides hybrid routing/bridging services (as well as 439 a security trust anchor) for nodes on an OMNI link. The Bridge 440 forwards carrier packets between OMNI link segments as OAL 441 intermediate nodes while decrementing the OAL IPv6 header Hop 442 Limit but without decrementing the network layer IP TTL/Hop Limit. 443 AERO Bridges peer with Proxy/Servers and other Bridges to discover 444 the full set of MNPs for the link as well as any non-MNP IP GUA 445 routes that are reachable via Relays. 447 ingress tunnel endpoint (ITE) 448 an OMNI interface endpoint that injects encapsulated packets into 449 an OMNI link. 451 egress tunnel endpoint (ETE) 452 an OMNI interface endpoint that receives encapsulated packets from 453 an OMNI link. 455 link-layer address 456 an IP address used as an encapsulation header source or 457 destination address from the perspective of the OMNI interface. 458 When an upper layer protocol (e.g., UDP) is used as part of the 459 encapsulation, the port number is also considered as part of the 460 link-layer address. 462 network layer address 463 the source or destination address of an original IP packet 464 presented to the OMNI interface. 466 end user network (EUN) 467 an internal virtual or external edge IP network that an AERO 468 Client or Relay connects to the rest of the network via the OMNI 469 interface. The Client/Relay sees each EUN as a "downstream" 470 network, and sees the OMNI interface as the point of attachment to 471 the "upstream" network. 473 Mobile Node (MN) 474 an AERO Client and all of its downstream-attached networks that 475 move together as a single unit, i.e., an end system that connects 476 an Internet of Things. 478 Mobile Router (MR) 479 a MN's on-board router that forwards original IP packets between 480 any downstream-attached networks and the OMNI link. The MR is the 481 MN entity that hosts the AERO Client. 483 Route Optimization Source (ROS) 484 the AERO node nearest the source that initiates route 485 optimization. The ROS may be a Proxy/Server/Relay acting on 486 behalf of the source, or may be the source Client itself. 488 Route Optimization responder (ROR) 489 the AERO node nearest the target destination that responds to 490 route optimization requests. The ROR may be a Proxy/Server acting 491 on behalf of a target MNP Client, a Relay for a non-MNP 492 destination or may be the target Client itself. 494 MAP List 495 a geographically and/or topologically referenced list of addresses 496 of all Proxy/Servers within the same OMNI link. There is a single 497 MAP list for the entire OMNI link. 499 Distributed Mobility Management (DMM) 500 a BGP-based overlay routing service coordinated by Proxy/Servers 501 and Bridges that tracks all Proxy/Server-to-Client associations. 503 Mobility Service (MS) 504 the collective set of all Proxy/Servers, Bridges and Relays that 505 provide the AERO Service to Clients. 507 Mobility Service Endpoint MSE) 508 an individual Proxy/Server, Bridge or Relay in the Mobility 509 Service. 511 Throughout the document, the simple terms "Client", "Proxy/Server", 512 "Bridge" and "Relay" refer to "AERO Client", "AERO Proxy/Server", 513 "AERO Bridge" and "AERO Relay", respectively. Capitalization is used 514 to distinguish these terms from other common Internetworking uses in 515 which they appear without capitalization. 517 The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including 518 the names of node variables, messages and protocol constants) is used 519 throughout this document. The terms "All-Routers multicast", "All- 520 Nodes multicast", "Solicited-Node multicast" and "Subnet-Router 521 anycast" are defined in [RFC4291]. Also, the term "IP" is used to 522 generically refer to either Internet Protocol version, i.e., IPv4 523 [RFC0791] or IPv6 [RFC8200]. 525 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 526 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 527 "OPTIONAL" in this document are to be interpreted as described in BCP 528 14 [RFC2119][RFC8174] when, and only when, they appear in all 529 capitals, as shown here. 531 3. Automatic Extended Route Optimization (AERO) 533 The following sections specify the operation of IP over OMNI links 534 using the AERO service: 536 3.1. AERO Node Types 538 AERO Clients are Mobile Nodes (MNs) that configure OMNI interfaces 539 over underlying interfaces with addresses that may change when the 540 Client moves to a new network connection point. AERO Clients 541 register their Mobile Network Prefixes (MNPs) with the AERO service, 542 and distribute the MNPs to nodes on EUNs. AERO Bridges, Proxy/ 543 Servers and Relays are critical infrastructure elements in fixed 544 (i.e., non-mobile) INET deployments and hence have permanent and 545 unchanging INET addresses. Together, they constitute the AERO 546 service which provides an OMNI link virtual overlay for connecting 547 AERO Clients. 549 AERO Bridges provide hybrid routing/bridging services (as well as a 550 security trust anchor) for nodes on an OMNI link. Bridges use 551 standard IPv6 routing to forward carrier packets both within the same 552 *NET partition and between disjoint *NET partitions based on an IPv6 553 encapsulation mid-layer known as the OMNI Adaptation Layer (OAL) 554 [I-D.templin-6man-omni-interface]. During forwarding, the inner IP 555 layer experiences a virtual bridging service since the inner IP TTL/ 556 Hop Limit is not decremented. Each Bridge also peers with Proxy/ 557 Servers and other Bridges in a dynamic routing protocol instance to 558 provide a Distributed Mobility Management (DMM) service for the list 559 of active MNPs (see Section 3.2.3). Bridges present the OMNI link as 560 a set of one or more Mobility Service Prefixes (MSPs) and configure 561 secured tunnels with Proxy/Servers, Relays and other Bridges; they 562 further maintain IP forwarding table entries for each MNP and any 563 other reachable non-MNP prefixes. 565 AERO Proxy/Servers in distributed INET locations provide default 566 forwarding and mobility/multilink services for AERO Client Mobile 567 Nodes (MNs). Each Proxy/Server also peers with Bridges in a dynamic 568 routing protocol instance to advertise its list of associated MNPs 569 (see Section 3.2.3). Proxy/Servers facilitate prefix delegation/ 570 registration exchanges with Clients, where each delegated prefix 571 becomes an MNP taken from an MSP. Proxy/Servers forward carrier 572 packets between OMNI interface neighbors and track each Client's 573 mobility profiles. Proxy/Servers provide a conduit for ANET Clients 574 to associate with additional Proxy/Servers in external INETs. The 575 Proxy forwards original IP packets between Clients and the OMNI link 576 according to forwarding information in the neighbor cache. 578 AERO Relays are Proxy/Servers that provide forwarding services to 579 exchange original IP packets between the OMNI interface and INET/EUN 580 interfaces. Relays are provisioned with MNPs the same as for an AERO 581 Client, and also run a dynamic routing protocol to discover any non- 582 MNP IP routes. The Relay advertises the MSP(s) to its connected 583 networks, and distributes all of its associated MNPs and non-MNP 584 routes via BGP peerings with Bridges 586 3.2. The AERO Service over OMNI Links 588 3.2.1. AERO/OMNI Reference Model 590 Figure 1 presents the basic OMNI link reference model: 592 +----------------+ 593 | AERO Bridge B1 | 594 | Nbr: S1, S2, P1| 595 |(X1->S1; X2->S2)| 596 | MSP M1 | 597 +-+------------+-+ 598 +--------------+ | Secured | +--------------+ 599 | AERO P/S S1 | | tunnels | | AERO P/S S2 | 600 | Nbr: C1, B1 +-----+ +-----+ Nbr: C2, B1 | 601 | default->B1 | | default->B1 | 602 | X1->C1 | | X2->C2 | 603 +-------+------+ +------+-------+ 604 | OMNI link | 605 X===+===+======================================+===+===X 606 | | 607 +-----+--------+ +--------+-----+ 608 |AERO Client C1| |AERO Client C2| 609 | Nbr: S1 | | Nbr: S2 | 610 | default->S1 | | default->S2 | 611 | MNP X1 | | MNP X2 | 612 +------+-------+ +-----+--------+ 613 | | 614 .-. .-. 615 ,-( _)-. ,-( _)-. 616 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 617 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 618 `-(______)-' +-------+ +-------+ `-(______)-' 620 Figure 1: AERO/OMNI Reference Model 622 In this model: 624 o the OMNI link is an overlay network service configured over one or 625 more underlying *NET partitions which may be managed by different 626 administrative authorities and have incompatible protocols and/or 627 addressing plans. 629 o AERO Bridge B1 aggregates Mobility Service Prefix (MSP) M1, 630 discovers Mobile Network Prefixes (MNPs) X* and advertises the MSP 631 via BGP peerings over secured tunnels to Proxy/Servers (S1, S2). 632 Bridges connect the disjoint segments of a partitioned OMNI link. 634 o AERO Proxy/Servers S1 and S2 configure secured tunnels with Bridge 635 B1 and also provide mobility, multilink, multicast and default 636 router services for their associated Clients C1 and C2. 638 o AERO Clients C1 and C2 associate with Proxy/Servers S1 and S2, 639 respectively. They receive Mobile Network Prefix (MNP) 640 delegations X1 and X2, and also act as default routers for their 641 associated physical or internal virtual EUNs. Simple hosts H1 and 642 H2 attach to the EUNs served by Clients C1 and C2, respectively. 644 An OMNI link configured over a single *NET appears as a single 645 unified link with a consistent underlying network addressing plan. 646 In that case, all nodes on the link can exchange carrier packets via 647 simple *NET encapsulation, since the underlying *NET is connected. 648 In common practice, however, an OMNI link may be partitioned into 649 multiple "segments", where each segment is a distinct *NET 650 potentially managed under a different administrative authority (e.g., 651 as for worldwide aviation service providers such as ARINC, SITA, 652 Inmarsat, etc.). Individual *NETs may also themselves be partitioned 653 internally, in which case each internal partition is seen as a 654 separate segment. 656 The addressing plan of each segment is consistent internally but will 657 often bear no relation to the addressing plans of other segments. 658 Each segment is also likely to be separated from others by network 659 security devices (e.g., firewalls, proxys, packet filtering gateways, 660 etc.), and in many cases disjoint segments may not even have any 661 common physical link connections. Therefore, nodes can only be 662 assured of exchanging carrier packets directly with correspondents in 663 the same segment, and not with those in other segments. The only 664 means for joining the segments therefore is through inter-domain 665 peerings between AERO Bridges. 667 The same as for traditional campus LANs, multiple OMNI link segments 668 can be joined into a single unified link via a virtual bridging 669 service using the OMNI Adaptation Layer (OAL) 670 [I-D.templin-6man-omni-interface] which inserts a mid-layer IPv6 671 encapsulation header that supports inter-segment forwarding (i.e., 672 bridging) without decrementing the network-layer TTL/Hop Limit. This 673 bridging of OMNI link segments is shown in Figure 2: 675 . . . . . . . . . . . . . . . . . . . . . . . 676 . . 677 . .-(::::::::) . 678 . .-(::::::::::::)-. +-+ . 679 . (:::: Segment A :::)--|B|---+ . 680 . `-(::::::::::::)-' +-+ | . 681 . `-(::::::)-' | . 682 . | . 683 . .-(::::::::) | . 684 . .-(::::::::::::)-. +-+ | . 685 . (:::: Segment B :::)--|B|---+ . 686 . `-(::::::::::::)-' +-+ | . 687 . `-(::::::)-' | . 688 . | . 689 . .-(::::::::) | . 690 . .-(::::::::::::)-. +-+ | . 691 . (:::: Segment C :::)--|B|---+ . 692 . `-(::::::::::::)-' +-+ | . 693 . `-(::::::)-' | . 694 . | . 695 . ..(etc).. x . 696 . . 697 . . 698 . <- OMNI link Bridged by encapsulation -> . 699 . . . . . . . . . . . . . .. . . . . . . . . 701 Figure 2: Bridging OMNI Link Segments 703 Bridges, Proxy/Servers and Relays connect via secured INET tunnels 704 over their respective segments in a spanning tree topology rooted at 705 the Bridges. The secured spanning tree supports strong 706 authentication for IPv6 ND control messages and may also be used to 707 convey the initial carrier packets in a flow. Route optimization can 708 then be employed to cause carrier packets to take more direct paths 709 between OMNI link neighbors without having to strictly follow the 710 spanning tree. 712 3.2.2. Addressing and Node Identification 714 AERO nodes on OMNI links use the Link-Local Address (LLA) prefix 715 fe80::/64 [RFC4291] to assign LLAs used for network-layer addresses 716 in link-scoped IPv6 ND and data messages. AERO Clients use LLAs 717 constructed from MNPs (i.e., "MNP-LLAs") while other AERO nodes use 718 LLAs constructed from administrative identification values ("ADM- 719 LLAs") as specified in [I-D.templin-6man-omni-interface]. 721 AERO nodes also use the Unique Local Address (ULA) prefix fd00::/8 722 followed by a pseudo-random 40-bit OMNI domain identifier to form the 723 prefix [ULA]::/48, then include a 16-bit OMNI link identifier '*' to 724 form the prefix [ULA*]::/64 [RFC4291]. The AERO node then uses the 725 prefix [ULA*]::/64 to form "MNP-ULAs" or "ADM-ULA"s as specified in 726 [I-D.templin-6man-omni-interface] to support OAL addressing. AERO 727 Clients also use Temporary ULAs constructed per 728 [I-D.templin-6man-omni-interface], where the addresses are typically 729 used only in initial control message exchanges until a stable MNP- 730 LLA/ULA is assigned. 732 AERO MSPs, MNPs and non-MNP routes are typically based on Global 733 Unicast Addresses (GUAs), but in some cases may be based on private- 734 use addresses. See [I-D.templin-6man-omni-interface] for a full 735 specification of LLAs, ULAs and GUAs used by AERO nodes on OMNI 736 links. 738 Finally, AERO Clients and Proxy/Servers configure node identification 739 values as specified in [I-D.templin-6man-omni-interface]. 741 3.2.3. AERO Routing System 743 The AERO routing system comprises a private instance of the Border 744 Gateway Protocol (BGP) [RFC4271] that is coordinated between Bridges 745 and Proxy/Servers and does not interact with either the public 746 Internet BGP routing system or any underlying INET routing systems. 748 In a reference deployment, each Proxy/Server is configured as an 749 Autonomous System Border Router (ASBR) for a stub Autonomous System 750 (AS) using a 32-bit AS Number (ASN) [RFC4271] that is unique within 751 the BGP instance, and each Proxy/Server further uses eBGP to peer 752 with one or more Bridges but does not peer with other Proxy/Servers. 753 Each *NET of a multi-segment OMNI link must include one or more 754 Bridges, which peer with the Proxy/Servers within that *NET. All 755 Bridges within the same *NET are members of the same hub AS, and use 756 iBGP to maintain a consistent view of all active routes currently in 757 service. The Bridges of different *NETs peer with one another using 758 eBGP. 760 Bridges maintain forwarding table entries only for the ULAs 761 corresponding to MNP and non-MNP routes that are currently active, 762 and carrier packets destined to all other ULAs will correctly incur 763 Destination Unreachable messages due to the black-hole route. In 764 this way, Proxy/Servers and Relays have only partial topology 765 knowledge (i.e., they know only about the routes their directly 766 associated Clients and non-AERO links) and they forward all other 767 carrier packets to Bridges which have full topology knowledge. 769 Each OMNI link segment assigns a unique ADM-ULA sub-prefix of 770 [ULA*]::/96. For example, a first segment could assign 772 [ULA*]::1000/116, a second could assign [ULA*]::2000/116, a third 773 could assign [ULA*]::3000/116, etc. Within each segment, each Proxy/ 774 Server configures an ADM-ULA within the segment's prefix, e.g., the 775 Proxy/Servers within [ULA*]::2000/116 could assign the ADM-ULAs 776 [ULA*]::2011/116, [ULA*]::2026/116, [ULA*]::2003/116, etc. 778 The administrative authorities for each segment must therefore 779 coordinate to assure mutually-exclusive ADM-ULA prefix assignments, 780 but internal provisioning of ADM-ULAs an independent local 781 consideration for each administrative authority. For each ADM-ULA 782 prefix, the Bridge(s) that connect that segment assign the all-zero's 783 address of the prefix as a Subnet Router Anycast address. For 784 example, the Subnet Router Anycast address for [ULA*]::1023/116 is 785 simply [ULA*]::1000. 787 ADM-ULA prefixes are statically represented in Bridge forwarding 788 tables. Bridges join multiple segments into a unified OMNI link over 789 multiple diverse administrative domains. They support a bridging 790 function by first establishing forwarding table entries for their 791 ADM-ULA prefixes either via standard BGP routing or static routes. 792 For example, if three Bridges ('A', 'B' and 'C') from different 793 segments serviced [ULA*]::1000/116, [ULA*]::2000/116 and 794 [ULA*]::3000/116 respectively, then the forwarding tables in each 795 Bridge are as follows: 797 A: [ULA*]::1000/116->local, [ULA*]::2000/116->B, [ULA*]::3000/116->C 799 B: [ULA*]::1000/116->A, [ULA*]::2000/116->local, [ULA*]::3000/116->C 801 C: [ULA*]::1000/116->A, [ULA*]::2000/116->B, [ULA*]::3000/116->local 803 These forwarding table entries are permanent and never change, since 804 they correspond to fixed infrastructure elements in their respective 805 segments. 807 MNP ULAs are instead dynamically advertised in the AERO routing 808 system by Proxy/Servers and Relays that provide service for their 809 corresponding MNPs. For example, if three Proxy/Servers ('D', 'E' 810 and 'F') service the MNPs 2001:db8:1000:2000::/56, 811 2001:db8:3000:4000::/56 and 2001:db8:5000:6000::/56 then the routing 812 system would include: 814 D: [ULA*]:2001:db8:1000:2000/120 816 E: [ULA*]:2001:db8:3000:4000/120 818 F: [ULA*]:2001:db8:5000:6000/120 819 A full discussion of the BGP-based routing system used by AERO is 820 found in [I-D.ietf-rtgwg-atn-bgp]. 822 3.2.4. OMNI Link Segment Routing 824 With the Client and partition prefixes in place in Bridge forwarding 825 tables, the OMNI interface sends control and data messages toward 826 AERO destination nodes located in different OMNI link segments over 827 the spanning tree. The OMNI interface uses the OMNI Adaptation Layer 828 (OAL) encapsulation service [I-D.templin-6man-omni-interface], and 829 includes an OMNI Routing Header (ORH) as an extension to the OAL 830 header if final segment forwarding information is available, e.g., in 831 the neighbor cache. (For nodes located in the same OMNI link 832 segment, or when no final segment forwarding information is 833 available, the ORH may be omitted.) The ORH is formatted as shown in 834 Figure 3: 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Next Header | Hdr Ext Len | Routing Type | SRT | FMT | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Last Hop Segment-id (LHS) | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 ~ Link Layer Address (L2ADDR) ~ 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 ~ Destination Suffix (if necessary) ~ 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 ~ Null Padding (if necessary) ~ 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Figure 3: OMNI Routing Header (ORH) Format 852 In this format: 854 o Next Header identifies the type of header immediately following 855 the ORH. 857 o Hdr Ext Len is the length of the Routing header in 8-octet units 858 (not including the first 8 octets), with trailing padding added if 859 necessary to produce an integral number of 8-octet units. 861 o Routing Type is set to TBD1 (see IANA Considerations). 863 o Segments Left is omitted, and replaced by a 5-bit SRT and 3-bit 864 FMT field. 866 o SRT - a 5-bit Segment Routing Topology prefix length value that 867 (when added to 96) determines the prefix length to apply to the 868 ADM-ULA formed from concatenating [ULA*]::/96 with the 32 bit LHS 869 value that follows (for example, the value 16 corresponds to the 870 prefix length 112). 872 o FMT - a 3-bit "Framework/Mode/Type" code corresponding to the 873 included Link Layer Address as follows: 875 * When the most significant bit (i.e., "Framework") is set to 1, 876 L2ADDR is the *NET encapsulation address for the target Client 877 itself; otherwise L2ADDR is the address of the Proxy/Server 878 named in the LHS. 880 * When the next most significant bit (i.e., "Mode") is set to 1, 881 the Framework node is (likely) located behind a *NET Network 882 Address Translator (NAT); otherwise, it is on the open *NET. 884 * When the least significant bit (i.e., "Type") is set to 0, 885 L2ADDR includes a UDP Port Number followed by an IPv4 address; 886 otherwise, it includes a UDP Port Number followed by an IPv6 887 address. 889 o LHS - the 32 bit ID of a node in the Last Hop Segment that 890 services the target. When SRT and LHS are both set to 0, the LHS 891 is considered unspecified. When SRT is set to 0 and LHS is non- 892 zero, the prefix length is set to 128. SRT and LHS provide 893 guidance to the OMNI interface forwarding algorithm. 894 Specifically, if SRT/LHS is located in the local OMNI link 895 segment, the OAL source can omit the ORH and (following any 896 necessary NAT traversal messaging) send directly to the OAL 897 destination according to FMT/L2ADDR. Otherwise, it includes the 898 ORH and forwards according to the OMNI link spanning tree. 900 o Link Layer Address (L2ADDR) - Formatted according to FMT, and 901 identifies the link-layer address (i.e., the encapsulation 902 address) of the target. The UDP Port Number appears in the first 903 two octets and the IP address appears in the next 4 octets for 904 IPv4 or 16 octets for IPv6. The Port Number and IP address are 905 recorded in network byte order, and in ones-compliment 906 "obfuscated" form per [RFC4380]. The OMNI interface forwarding 907 algorithm uses FMT/L2ADDR to determine the *NET encapsulation 908 address for local forwarding when SRT/LHS is located in the same 909 OMNI link segment. Note that if the target is behind a NAT, 910 L2ADDR will contain the mapped *NET address stored in the NAT; 911 otherwise, L2ADDR will contain the native *NET information of the 912 target itself. 914 o Destination Suffix is a 64-bit field included only for OAL non- 915 first-fragments. Present only when Hdr Ext Len indicates that at 916 least 8 bytes follow L2ADDR. When present, encodes the 64-bit 917 MNP-ULA suffix for the target Client. 919 o Null Padding contains zero-valued octets as necessary to pad the 920 ORH to an integral number of 8-octet units. 922 AERO neighbors use OAL encapsulation and fragmentation to exchange 923 OAL packets as specified in [I-D.templin-6man-omni-interface]. When 924 an AERO node's OMNI interface (acting as an OAL source) uses OAL 925 encapsulation for an original IP packet with source address 926 2001:db8:1:2::1 and destination address 2001:db8:1234:5678::1, it 927 sets the OAL header source address to its own ULA (e.g., 928 [ULA*]::2001:db8:1:2), sets the destination address to the MNP-ULA 929 corresponding to the IP destination address (e.g., 930 [ULA*]::2001:db8:1234:5678), sets the Traffic Class, Flow Label, Hop 931 Limit and Payload Length as discussed in 932 [I-D.templin-6man-omni-interface], then finally selects an 933 Identification and appends an OAL checksum. 935 If the neighbor cache information indicates that the target is in a 936 different segment, the OAL source next inserts an ORH immediately 937 following the OAL header while including the correct SRT, FMT, LHS, 938 L2ADDR and Destination Suffix if fragmentation if needed (in this 939 case, the Destination Suffix is 2001:db8:1234:5678). Next, the OAL 940 source overwrites the OAL header destination address with the LHS 941 Subnet Router Anycast address (for example, for LHS 3000:4567 with 942 SRT 16, the Subnet Router Anycast address is [ULA*]::3000:0000). 943 (Note: if the ADM-ULA of the last-hop Proxy/Server is known but the 944 SRT, FMT, LHS and L2ADDR are not (yet) known, the OAL source instead 945 overwrites the OAL header destination address with the ADM-ULA.) 947 The OAL source then fragments the OAL packet, with each resulting OAL 948 fragment including the OAL/ORH headers while only the first fragment 949 includes the original IPv6 header. (Note that the packet is prepared 950 as an "atomic" OAL fragment even if no actual fragmentation was 951 required.) The OAL source finally encapsulates each resulting OAL 952 fragment in an *NET header to form an OAL carrier packet, with source 953 address set to its own *NET address (e.g., 192.0.2.100) and 954 destination set to the *NET address of a Bridge (e.g., 192.0.2.1). 956 The carrier packet encapsulation format in the above example is shown 957 in Figure 4: 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | *NET Header | 961 | src = 192.0.2.100 | 962 | dst = 192.0.2.1 | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | OAL IPv6 Header | 965 | src = [ULA*]::2001:db8:1:2 | 966 | dst= [ULA*]::3000:0000 | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | ORH (if necessary) | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | OAL Fragment Header | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Original IP Header | 973 | (first-fragment only) | 974 | src = 2001:db8:1:2::1 | 975 | dst = 2001:db8:1234:5678::1 | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | | 978 ~ ~ 979 ~ Original Packet Body/Fragment ~ 980 ~ ~ 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 4: Carrier Packet Format 986 In this format, the original IP header and packet body/fragment are 987 from the original IP packet, the OAL header is an IPv6 header 988 prepared according to [RFC2473], the ORH is a Routing Header 989 extension of the OAL header, the Fragment Header identifies each 990 fragment, and the INET header is prepared as discussed in 991 Section 3.6. When the OAL source transmits the resulting carrier 992 packets, they are forwarded over possibly multiple OAL intermediate 993 nodes in the OMNI link spanning tree until they arrive at the OAL 994 destination. 996 This gives rise to a routing system that contains both Client MNP-ULA 997 routes that may change dynamically due to regional node mobility and 998 per-partition ADM-ULA routes that rarely if ever change. The Bridges 999 can therefore provide link-layer bridging by sending carrier packets 1000 over the spanning tree instead of network-layer routing according to 1001 MNP routes. As a result, opportunities for loss due to node mobility 1002 between different segments are mitigated. 1004 In normal operations, IPv6 ND messages are conveyed over secured 1005 paths between OMNI link neighbors so that specific Proxy/Servers or 1006 Relays can be addressed without being subject to mobility events. 1008 Conversely, only the first few carrier packets destined to Clients 1009 need to traverse secured paths until route optimization can determine 1010 a more direct path. 1012 Note: When the OAL source and destination are on the same INET 1013 segment, the ORH is not needed and OAL header compression can be used 1014 to significantly reduce encapsulation overhead 1015 [I-D.templin-6man-omni-interface]. 1017 Note: When the OAL source has multiple original IP packets to send to 1018 the same OAL destination, it can perform "packing" to generate a 1019 "super-packet" [I-D.templin-6man-omni-interface]. In that case, the 1020 OAL/ORH super-packet may include up to N original IP packets as long 1021 as the total length of the super-packet does not exceed the OMNI 1022 interface MTU. 1024 Note: Use of an IPv6 "minimal encapsulation" format (i.e., an IPv6 1025 variant of [RFC2004]) based on extensions to the ORH was considered 1026 and abandoned. In the approach, the ORH would be inserted as an 1027 extension header to the original IPv6 packet header. The IPv6 1028 destination address would then be written into the ORH, and the ULA 1029 corresponding to the destination would be overwritten in the IPv6 1030 destination address. This would seemingly convey enough forwarding 1031 information so that OAL encapsulation could be avoided. However, 1032 this "minimal encapsulation" IPv6 packet would then have a non-ULA 1033 source address and ULA destination address, an incorrect value in 1034 upper layer protocol checksums, and a Hop Limit that is decremented 1035 within the spanning tree when it should not be. The insertion and 1036 removal of the ORH would also entail rewriting the Payload Length and 1037 Next Header fields - again, invalidating upper layer checksums. 1038 These irregularities would result in implementation challenges and 1039 the potential for operational issues, e.g., since actionable ICMPv6 1040 error reports could not be delivered to the original source. In 1041 order to address the issues, still more information such as the 1042 original IPv6 source address could be written into the ORH. However, 1043 with the additional information the benefit of the "minimal 1044 encapsulation" savings quickly diminishes, and becomes overshadowed 1045 by the implementation and operational irregularities. 1047 3.2.5. Segment Routing Topologies (SRTs) 1049 The 64-bit sub-prefixes of [ULA]::/48 identify up to 2^16 distinct 1050 Segment Routing Topologies (SRTs). Each SRT is a mutually-exclusive 1051 OMNI link overlay instance using a distinct set of ULAs, and emulates 1052 a Virtual LAN (VLAN) service for the OMNI link. In some cases (e.g., 1053 when redundant topologies are needed for fault tolerance and 1054 reliability) it may be beneficial to deploy multiple SRTs that act as 1055 independent overlay instances. A communication failure in one 1056 instance therefore will not affect communications in other instances. 1058 Each SRT is identified by a distinct value in bits 48-63 of 1059 [ULA]::/48, i.e., as [ULA0]::/64, [ULA1]::/64, [ULA2]::/64, etc. 1060 Each OMNI interface is identified by a unique interface name (e.g., 1061 omni0, omni1, omni2, etc.) and assigns an anycast ADM-ULA 1062 corresponding to its SRT prefix length. The anycast ADM-ULA is used 1063 for OMNI interface determination in Safety-Based Multilink (SBM) as 1064 discussed in [I-D.templin-6man-omni-interface]. Each OMNI interface 1065 further applies Performance-Based Multilink (PBM) internally. 1067 3.2.6. Segment Routing For OMNI Link Selection 1069 An original IPv6 source can direct an IPv6 packet to an AERO node by 1070 including a standard IPv6 Segment Routing Header (SRH) [RFC8754] with 1071 the anycast ADM-ULA for the selected SRT as either the IPv6 1072 destination or as an intermediate hop within the SRH. This allows 1073 the original source to determine the specific OMNI link topology an 1074 original IPv6 packet will traverse when there may be multiple 1075 alternatives. 1077 When the AERO node processes the SRH and forwards the original IPv6 1078 packet to the correct OMNI interface, the OMNI interface writes the 1079 next IPv6 address from the SRH into the IPv6 destination address and 1080 decrements Segments Left. If decrementing would cause Segments Left 1081 to become 0, the OMNI interface deletes the SRH before forwarding. 1082 This form of Segment Routing supports Safety-Based Multilink (SBM). 1084 3.2.7. Segment Routing Within the OMNI Link 1086 OAL sources can insert an ORH for Segment Routing within the OMNI 1087 link to influence the paths of OAL packets sent to OAL destinations 1088 in remote segments without requiring all carrier packets to traverse 1089 strict spanning tree paths. 1091 When an AERO node's OMNI interface has an original IP packet to send 1092 to a target discovered through route optimization located in the same 1093 OMNI link segment, it acts as an OAL source to perform OAL 1094 encapsulation and fragmentation. The node then uses the target's 1095 Link Layer Address (L2ADDR) information for *NET encapsulation. 1097 When an AERO node's OMNI interface has an original IP packet to send 1098 to a route optimization target located in a remote OMNI link segment, 1099 it acts as an OAL source the same as above but also includes an ORH 1100 while setting the OAL destination to the Subnet Router Anycast 1101 address for the final OMNI link segment, then forwards the resulting 1102 carrier packets to a Bridge. 1104 When a Bridge receives a carrier packet destined to its Subnet Router 1105 Anycast address with an ORH with SRT/LHS values corresponding to the 1106 local segment, it examines the L2ADDR according to FMT and removes 1107 the ORH from the carrier packet. The Bridge then writes the MNP-ULA 1108 corresponding to the ORH Destination Suffix into the OAL destination 1109 address, decrements the OAL IPv6 header Hop Limit (and discards the 1110 packet if the Hop Limit reaches 0), re-encapsulates the carrier 1111 packet according to L2ADDR and forwards the carrier packet either to 1112 the LHS Proxy/Server or directly to the target Client itself. In 1113 this way, the Bridge participates in route optimization to reduce 1114 traffic load and suboptimal routing through strict spanning tree 1115 paths. 1117 3.3. OMNI Interface Characteristics 1119 OMNI interfaces are virtual interfaces configured over one or more 1120 underlying interfaces classified as follows: 1122 o INET interfaces connect to an INET either natively or through one 1123 or more NATs. Native INET interfaces have global IP addresses 1124 that are reachable from any INET correspondent. The INET-facing 1125 interfaces of Proxy/Servers are native interfaces, as are Relay 1126 and Bridge interfaces. NATed INET interfaces connect to a private 1127 network behind one or more NATs that provide INET access. Clients 1128 that are behind a NAT are required to send periodic keepalive 1129 messages to keep NAT state alive when there are no carrier packets 1130 flowing. 1132 o ANET interfaces connect to an ANET that is separated from the open 1133 INET by a Proxy/Server. Proxy/Servers can actively issue control 1134 messages over the INET on behalf of the Client to reduce ANET 1135 congestion. 1137 o VPNed interfaces use security encapsulation over the INET to a 1138 Virtual Private Network (VPN) server that also acts as a Proxy/ 1139 Server. Other than the link-layer encapsulation format, VPNed 1140 interfaces behave the same as Direct interfaces. 1142 o Direct (i.e., single-hop point-to-point) interfaces connect a 1143 Client directly to a Proxy/Server without crossing any ANET/INET 1144 paths. An example is a line-of-sight link between a remote pilot 1145 and an unmanned aircraft. The same Client considerations apply as 1146 for VPNed interfaces. 1148 OMNI interfaces use OAL encapsulation and fragmentation as discussed 1149 in Section 3.2.4. OMNI interfaces use *NET encapsulation (see: 1150 Section 3.6) to exchange carrier packets with OMNI link neighbors 1151 over INET or VPNed interfaces as well as over ANET interfaces for 1152 which the Client and Proxy/Server may be multiple IP hops away. OMNI 1153 interfaces do not use link-layer encapsulation over Direct underlying 1154 interfaces or ANET interfaces when the Client and Proxy/Server are 1155 known to be on the same underlying link. 1157 OMNI interfaces maintain a neighbor cache for tracking per-neighbor 1158 state the same as for any interface. OMNI interfaces use ND messages 1159 including Router Solicitation (RS), Router Advertisement (RA), 1160 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for 1161 neighbor cache management. 1163 OMNI interfaces send ND messages with an OMNI option formatted as 1164 specified in [I-D.templin-6man-omni-interface]. The OMNI option 1165 includes prefix registration information and Interface Attributes 1166 containing link information parameters for the OMNI interface's 1167 underlying interfaces. Each OMNI option may include multiple 1168 Interface Attributes sub-options, each identified by an ifIndex 1169 value. 1171 A Client's OMNI interface may be configured over multiple underlying 1172 interface connections. For example, common mobile handheld devices 1173 have both wireless local area network ("WLAN") and cellular wireless 1174 links. These links are often used "one at a time" with low-cost WLAN 1175 preferred and highly-available cellular wireless as a standby, but a 1176 simultaneous-use capability could provide benefits. In a more 1177 complex example, aircraft frequently have many wireless data link 1178 types (e.g. satellite-based, cellular, terrestrial, air-to-air 1179 directional, etc.) with diverse performance and cost properties. 1181 If a Client's multiple underlying interfaces are used "one at a time" 1182 (i.e., all other interfaces are in standby mode while one interface 1183 is active), then ND message OMNI options include only a single 1184 Interface Attributes sub-option set to constant values. In that 1185 case, the Client would appear to have a single interface but with a 1186 dynamically changing link-layer address. 1188 If the Client has multiple active underlying interfaces, then from 1189 the perspective of ND it would appear to have multiple link-layer 1190 addresses. In that case, ND message OMNI options MAY include 1191 multiple Interface Attributes sub-options - each with values that 1192 correspond to a specific interface. Every ND message need not 1193 include Interface Attributes for all underlying interfaces; for any 1194 attributes not included, the neighbor considers the status as 1195 unchanged. 1197 Bridge and Proxy/Server OMNI interfaces may be configured over one or 1198 more secured tunnel interfaces. The OMNI interface configures both 1199 an ADM-LLA and its corresponding ADM-ULA, while the underlying 1200 secured tunnel interfaces are either unnumbered or configure the same 1201 ULA. The OMNI interface acting as an OAL source encapsulates and 1202 fragments each original IP packet, then and presents the resulting 1203 carrier packets to the underlying secured tunnel interface. Routing 1204 protocols such as BGP that run over the OMNI interface do not employ 1205 OAL encapsulation, but rather present the routing protocol messages 1206 directly to the underlying secured tunnels while using the ULA as the 1207 source address. This distinction must be honored consistently 1208 according to each node's configuration so that the IP forwarding 1209 table will associate discovered IP routes with the correct interface. 1211 3.4. OMNI Interface Initialization 1213 AERO Proxy/Servers and Clients configure OMNI interfaces as their 1214 point of attachment to the OMNI link. AERO nodes assign the MSPs for 1215 the link to their OMNI interfaces (i.e., as a "route-to-interface") 1216 to ensure that original IP packets with destination addresses covered 1217 by an MNP not explicitly assigned to a non-OMNI interface are 1218 directed to the OMNI interface. 1220 OMNI interface initialization procedures for Proxy/Servers, Clients 1221 and Bridges are discussed in the following sections. 1223 3.4.1. AERO Proxy/Server and Relay Behavior 1225 When a Proxy/Server enables an OMNI interface, it assigns an 1226 ADM-{LLA,ULA} appropriate for the given OMNI link segment. The 1227 Proxy/Server also configures secured tunnels with one or more 1228 neighboring Bridges and engages in a BGP routing protocol session 1229 with each Bridge. 1231 The OMNI interface provides a single interface abstraction to the IP 1232 layer, but internally includes one or more secured tunnels as well as 1233 an NBMA nexus as underlying interfaces for sending carrier packets to 1234 OMNI interface neighbors. The Proxy/Server further configures a 1235 service to facilitate ND exchanges with AERO Clients and manages per- 1236 Client neighbor cache entries and IP forwarding table entries based 1237 on control message exchanges. 1239 Relays are simply Proxy/Servers that run a dynamic routing protocol 1240 to redistribute routes between the OMNI interface and INET/EUN 1241 interfaces (see: Section 3.2.3). The Relay provisions MNPs to 1242 networks on the INET/EUN interfaces (i.e., the same as a Client would 1243 do) and advertises the MSP(s) for the OMNI link over the INET/EUN 1244 interfaces. The Relay further provides an attachment point of the 1245 OMNI link to a non-MNP-based global topology. 1247 3.4.2. AERO Client Behavior 1249 When a Client enables an OMNI interface, it assigns either an 1250 MNP-{LLA, ULA} or a Temporary ULA and sends RS messages with ND 1251 parameters over its underlying interfaces to a Proxy/Server, which 1252 returns an RA message with corresponding parameters. The RS/RA 1253 messages may pass through one or more NATs in the case of a Client's 1254 INET interface. (Note: if the Client used a Temporary ULA in its 1255 initial RS message, it will discover an MNP-{LLA, ULA} in the 1256 corresponding RA that it receives from the Proxy/Server and begin 1257 using these new addresses. If the Client is operating outside the 1258 context of AERO infrastructure such as in a Mobile Ad-hoc Network 1259 (MANET), however, it may continue using Temporary ULAs for Client-to- 1260 Client communications until it encounters an infrastructure element 1261 that can provide an MNP.) 1263 3.4.3. AERO Bridge Behavior 1265 AERO Bridges configure an OMNI interface and assign the ADM-ULA 1266 Subnet Router Anycast address for each OMNI link segment they connect 1267 to. Bridges configure secured tunnels with Proxy/Servers and other 1268 Bridges, and engage in a BGP routing protocol session with neighbors 1269 on the spanning tree (see: Section 3.2.3). 1271 3.5. OMNI Interface Neighbor Cache Maintenance 1273 Each OMNI interface maintains a conceptual neighbor cache that 1274 includes an entry for each neighbor it communicates with on the OMNI 1275 link per [RFC4861]. In addition to ordinary neighbor cache entries, 1276 Proxy neighbor cache entries are created and maintained by AERO 1277 Proxy/Servers when they proxy Client ND message exchanges [RFC4389]. 1278 AERO Proxy/Servers maintain proxy neighbor cache entries for each of 1279 their associated Clients. 1281 To the list of neighbor cache entry states in Section 7.3.2 of 1282 [RFC4861], Proxy/Server OMNI interfaces add an additional state 1283 DEPARTED that applies to Clients that have recently departed. The 1284 interface sets a "DepartTime" variable for the neighbor cache entry 1285 to "DEPART_TIME" seconds. DepartTime is decremented unless a new ND 1286 message causes the state to return to REACHABLE. While a neighbor 1287 cache entry is in the DEPARTED state, the Proxy/Server forwards 1288 carrier packets destined to the target Client to the Client's new 1289 location instead. When DepartTime decrements to 0, the neighbor 1290 cache entry is deleted. It is RECOMMENDED that DEPART_TIME be set to 1291 the default constant value REACHABLE_TIME plus 10 seconds (40 seconds 1292 by default) to allow a window for carrier packets in flight to be 1293 delivered while stale route optimization state may be present. 1295 Proxy/Servers can act as RORs on behalf of disadvantaged Clients 1296 according to the Proxy Neighbor Advertisement specification in 1297 Section 7.2.8 of [RFC4861]. Well-connected Clients can act as an ROR 1298 on their own behalf. When a Proxy/Server ROR receives an authentic 1299 NS message used for route optimization, it first searches for a proxy 1300 neighbor cache entry for the target Client and accepts the message 1301 only if there is an entry. The Proxy/Server (or the actual target 1302 Client acting as an ROR) then returns a solicited NA message while 1303 creating a neighbor cache entry for the ROS and caching the 1304 Identification value found in the NS message carrier packet as the 1305 starting window Identification value for this ROS. Proxy/Servers 1306 acting as proxy RORs also create or update a "Report List" entry for 1307 the ROS in the target Client's proxy neighbor cache entry with a 1308 "ReportTime" variable set to REPORT_TIME seconds. The ROR resets 1309 ReportTime when it receives a new authentic NS message, and otherwise 1310 decrements ReportTime while no authentic NS messages have been 1311 received. It is RECOMMENDED that REPORT_TIME be set to the default 1312 constant value REACHABLE_TIME plus 10 seconds (40 seconds by default) 1313 to allow a window for route optimization to converge before 1314 ReportTime decrements below REACHABLE_TIME. 1316 When the ROS receives a solicited NA message response to its NS 1317 message used for route optimization, it creates or updates a neighbor 1318 cache entry for the target network-layer and link-layer addresses. 1319 The ROS then (re)sets ReachableTime for the neighbor cache entry to 1320 REACHABLE_TIME seconds and uses this value to determine whether 1321 carrier packets can be forwarded directly to the target, i.e., 1322 instead of via a default route. The ROS also maintains a window 1323 start Identification value that is monotonically incremented for each 1324 OAL packet sent to this target, and sets new window start 1325 Identification values when it sends a new NS. The ROS otherwise 1326 decrements ReachableTime while no further solicited NA messages 1327 arrive. It is RECOMMENDED that REACHABLE_TIME be set to the default 1328 constant value 30 seconds as specified in [RFC4861]. 1330 AERO nodes also use the value MAX_UNICAST_SOLICIT to limit the number 1331 of NS keepalives sent when a correspondent may have gone unreachable, 1332 the value MAX_RTR_SOLICITATIONS to limit the number of RS messages 1333 sent without receiving an RA and the value MAX_NEIGHBOR_ADVERTISEMENT 1334 to limit the number of unsolicited NAs that can be sent based on a 1335 single event. It is RECOMMENDED that MAX_UNICAST_SOLICIT, 1336 MAX_RTR_SOLICITATIONS and MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the 1337 same as specified in [RFC4861]. 1339 Different values for DEPART_TIME, REPORT_TIME, REACHABLE_TIME, 1340 MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and 1341 MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if 1342 different values are chosen, all nodes on the link MUST consistently 1343 configure the same values. Most importantly, DEPART_TIME and 1344 REPORT_TIME SHOULD be set to a value that is sufficiently longer than 1345 REACHABLE_TIME to avoid packet loss due to stale route optimization 1346 state. 1348 3.5.1. OMNI Neighbor Interface Attributes 1350 OMNI interface IPv6 ND messages include OMNI options 1351 [I-D.templin-6man-omni-interface] with Interface Attributes that 1352 provide Link-Layer Address and QoS Preference information for the 1353 neighbor's underlying interfaces. This information is stored in the 1354 neighbor cache and provides the basis for the forwarding algorithm 1355 specified in Section 3.10. The information is cumulative and 1356 reflects the union of the OMNI information from the most recent ND 1357 messages received from the neighbor; it is therefore not required 1358 that each ND message contain all neighbor information. 1360 The OMNI option Interface Attributes for each underlying interface 1361 includes a two-part "Link-Layer Address" consisting of a simple IP 1362 encapsulation address determined by the FMT and L2ADDR fields and an 1363 ADM-ULA determined by the SRT and LHS fields. Underlying interfaces 1364 are further selected based on their associated preference values 1365 "high", "medium", "low" or "disabled". 1367 Note: the OMNI option is distinct from any Source/Target Link-Layer 1368 Address Options (S/TLLAOs) that may appear in an ND message according 1369 to the appropriate IPv6 over specific link layer specification (e.g., 1370 [RFC2464]). If both an OMNI option and S/TLLAO appear, the former 1371 pertains to encapsulation addresses while the latter pertains to the 1372 native L2 address format of the underlying media. 1374 3.5.2. OMNI Neighbor Advertisement Message Flags 1376 As discussed in Section 4.4 of [RFC4861] NA messages include three 1377 flag bits R, S and O. OMNI interface NA messages treat the flags as 1378 follows: 1380 o R: The R ("Router") flag is set to 1 in the NA messages sent by 1381 all AERO/OMNI node types. Simple hosts that would set R to 0 do 1382 not occur on the OMNI link itself, but may occur on the downstream 1383 links of Clients and Relays. 1385 o S: The S ("Solicited") flag is set exactly as specified in 1386 Section 4.4. of [RFC4861], i.e., it is set to 1 for Solicited NAs 1387 and set to 0 for Unsolicited NAs (both unicast and multicast). 1389 o O: The O ("Override") flag is set to 0 for solicited proxy NAs 1390 returned by a Proxy/Server ROR and set to 1 for all other 1391 solicited and unsolicited NAs. For further study is whether 1392 solicited NAs for anycast targets apply for OMNI links. Since 1393 MNP-LLAs must be uniquely assigned to Clients to support correct 1394 ND protocol operation, however, no role is currently seen for 1395 assigning the same MNP-LLA to multiple Clients. 1397 3.6. OMNI Interface Encapsulation and Re-encapsulation 1399 The OMNI interface admits original IP packets then (acting as an OAL 1400 source) performs OAL encapsulation and fragmentation as specified in 1401 [I-D.templin-6man-omni-interface] while including an ORH if necessary 1402 as specified in Section 3.2.4. OAL encapsulation produces OAL 1403 packets, while OAL fragmentation turns them into OAL fragments which 1404 are then encapsulated in *NET headers as carrier packets. 1406 For carrier packets undergoing re-encapsulation at an OAL 1407 intermediate node, the OMNI interface decrements the OAL IPv6 header 1408 Hop Limit and discards the carrier packet if the Hop Limit reaches 0. 1409 The intermediate node next removes the *NET encapsulation headers 1410 from the first segment and re-encapsulates the packet in new *NET 1411 encapsulation headers for the next segment. 1413 When a Proxy/Server or Relay re-encapsulates a carrier packet 1414 received from a Client that includes an OAL but no ORH, it inserts an 1415 ORH immediately following the OAL header and adjusts the OAL payload 1416 length and destination address field. The inserted ORH will be 1417 removed by the final-hop Bridge, but its insertion and removal will 1418 not interfere with reassembly at the final destination. For this 1419 reason, Clients must reserve 40 bytes for a maximum-length ORH when 1420 they perform OAL encapsulation (see: Section 3.9). 1422 3.7. OMNI Interface Decapsulation 1424 OMNI interfaces (acting as OAL destinations) decapsulate and 1425 reassemble OAL packets into original IP packets destined either to 1426 the AERO node itself or to a destination reached via an interface 1427 other than the OMNI interface the original IP packet was received on. 1428 When carrier packets containing OAL fragments arrive, the OMNI 1429 interface reassembles as discussed in Section 3.9. 1431 3.8. OMNI Interface Data Origin Authentication 1433 AERO nodes employ simple data origin authentication procedures. In 1434 particular: 1436 o AERO Bridges and Proxy/Servers accept carrier packets (including 1437 either data or control messages) received from the (secured) 1438 spanning tree. 1440 o AERO Proxy/Servers and Clients accept carrier packets and original 1441 IP packets that originate from within the same secured ANET. 1443 o AERO Clients and Relays accept original IP packets from downstream 1444 network correspondents based on ingress filtering. 1446 o AERO Clients, Relays and Proxy/Servers verify carrier packet UDP/ 1447 IP encapsulation addresses according to [RFC4380]. 1449 o AERO Clients (as well as Proxy/Servers and Relays when acting as 1450 OAL destinations) accept OAL packets/fragments with Identification 1451 values within the current window for the OAL source. 1453 AERO nodes silently drop any packets that do not satisfy the above 1454 data origin authentication procedures. Further security 1455 considerations are discussed in Section 6. 1457 3.9. OMNI Interface MTU 1459 The OMNI interface observes the link nature of tunnels, including the 1460 Maximum Transmission Unit (MTU), Maximum Reassembly Unit (MRU) and 1461 the role of fragmentation and reassembly [I-D.ietf-intarea-tunnels]. 1462 The OMNI interface employs an OMNI Adaptation Layer (OAL) that 1463 accommodates multiple underlying links with diverse MTUs while 1464 observing both a minimum and per-path Maximum Payload Size (MPS). 1465 The functions of the OAL and the OMNI interface MTU/MRU/MPS are 1466 specified in Section 5 of [I-D.templin-6man-omni-interface] with MTU/ 1467 MRU both set to the constant value 9180 bytes, with minimum MPS set 1468 to 400 bytes, and with path MPS set to a potentially larger value 1469 depending on the underlying path. 1471 When the network layer presents an original IP packet to the OMNI 1472 interface, the OAL source encapsulates and fragments the original IP 1473 packet if necessary. When the network layer presents the OMNI 1474 interface with multiple original IP packets bound to the same OAL 1475 destination, the OAL source can concatenate them together into a 1476 single OAL super-packet as discussed in 1477 [I-D.templin-6man-omni-interface]. The OAL source then fragments the 1478 OAL packet if necessary according to the minimum/path MPS such that 1479 the OAL headers appear in each fragment while the original IP packet 1480 header appears only in the first fragment. The OAL source then 1481 encapsulates each OAL fragment in *NET headers for transmission as 1482 carrier packets over an underlying interface connected to either a 1483 physical link such as Ethernet, WiFi and the like or a virtual link 1484 such as an Internet or higher-layer tunnel (see the definition of 1485 link in [RFC8200]). 1487 Note: A Client that does not (yet) have neighbor cache state for a 1488 target may omit the ORH in carrier packets with the understanding 1489 that a Proxy/Server may insert an ORH on its behalf. For this 1490 reason, Clients reserve 40 bytes for the largest possible ORH in 1491 their OAL fragment size calculations. 1493 Note: Although the ORH may be removed by a Bridge on the path (see: 1494 Section 3.10.3), this does not interfere with the destination's 1495 ability to reassemble. This is due to the fact that the ORH is not 1496 included in the fragmentable part; therefore, its removal does not 1497 invalidate the offset values in any fragment headers. 1499 3.10. OMNI Interface Forwarding Algorithm 1501 Original IP packets enter a node's OMNI interface either from the 1502 network layer (i.e., from a local application or the IP forwarding 1503 system) while carrier packets enter from the link layer (i.e., from 1504 an OMNI interface neighbor). All original IP packets and carrier 1505 packets entering a node's OMNI interface first undergo data origin 1506 authentication as discussed in Section 3.8. Those that satisfy data 1507 origin authentication are processed further, while all others are 1508 dropped silently. 1510 Original IP packets that enter the OMNI interface from the network 1511 layer are forwarded to an OMNI interface neighbor using OAL 1512 encapsulation and fragmentation to produce carrier packets for 1513 transmission over underlying interfaces. (If routing indicates that 1514 the original IP packet should instead be forwarded back to the 1515 network layer, the packet is dropped to avoid looping). Carrier 1516 packets that enter the OMNI interface from the link layer are either 1517 re-encapsulated and re-admitted into the OMNI link, or reassembled 1518 and forwarded to the network layer where they are subject to either 1519 local delivery or IP forwarding. In all cases, the OAL MUST NOT 1520 decrement the network layer TTL/Hop-count since its forwarding 1521 actions occur below the network layer. 1523 OMNI interfaces may have multiple underlying interfaces and/or 1524 neighbor cache entries for neighbors with multiple underlying 1525 interfaces (see Section 3.3). The OAL uses interface attributes and/ 1526 or traffic classifiers (e.g., DSCP value, port number, flow 1527 specification, etc.) to select an outgoing underlying interface for 1528 each OAL packet based on the node's own QoS preferences, and also to 1529 select a destination link-layer address based on the neighbor's 1530 underlying interface with the highest preference. AERO 1531 implementations SHOULD allow for QoS preference values to be modified 1532 at runtime through network management. 1534 If multiple outgoing interfaces and/or neighbor interfaces have a 1535 preference of "high", the AERO node replicates the OAL packet and 1536 sends one copy via each of the (outgoing / neighbor) interface pairs; 1537 otherwise, the node sends a single copy of the OAL packet via an 1538 interface with the highest preference. (While not strictly required, 1539 successful delivery may be more likely when all OAL fragments of the 1540 same OAL packet are sent over the same underlying interface.) AERO 1541 nodes keep track of which underlying interfaces are currently 1542 "reachable" or "unreachable", and only use "reachable" interfaces for 1543 forwarding purposes. 1545 The following sections discuss the OMNI interface forwarding 1546 algorithms for Clients, Proxy/Servers and Bridges. In the following 1547 discussion, an original IP packet's destination address is said to 1548 "match" if it is the same as a cached address, or if it is covered by 1549 a cached prefix (which may be encoded in an MNP-LLA). 1551 3.10.1. Client Forwarding Algorithm 1553 When an original IP packet enters a Client's OMNI interface from the 1554 network layer the Client searches for a neighbor cache entry that 1555 matches the destination. If there is a match, the Client selects one 1556 or more "reachable" neighbor interfaces in the entry for forwarding 1557 purposes. If there is no neighbor cache entry, the Client instead 1558 forwards the original IP packet toward a Proxy/Server. The Client 1559 (acting as an OAL source) performs OAL encapsulation and sets the OAL 1560 destination address to the MNP-ULA if there is a matching neighbor 1561 cache entry; otherwise, it sets the OAL destination to the ADM-ULA of 1562 the Proxy/Server. If the Client has multiple original IP packets to 1563 send to the same neighbor, it can concatenate them in a single super- 1564 packet [I-D.templin-6man-omni-interface]. The OAL source then 1565 performs fragmentation to create OAL fragments (see: Section 3.9), 1566 appends any *NET encapsulation, and sends the resulting carrier 1567 packets over underlying interfaces to the neighbor acting as an OAL 1568 destination. 1570 If the neighbor interface selected for forwarding is located on the 1571 same OMNI link segment and not behind a NAT, the Client forwards the 1572 carrier packets directly according to the L2ADDR information for the 1573 neighbor. If the neighbor interface is behind a NAT on the same OMNI 1574 link segment, the Client instead forwards the initial carrier packets 1575 to its Proxy/Server and initiates NAT traversal procedures. If the 1576 Client's intended source underlying interface is also behind a NAT 1577 and located on the same OMNI link segment, it sends a "direct bubble" 1578 over the interface per [RFC6081][RFC4380] to the L2ADDR found in the 1579 neighbor cache in order to establish state in its own NAT by 1580 generating traffic toward the neighbor (note that no response to the 1581 bubble is expected). 1583 The Client next sends an NS(NUD) message toward the MNP-ULA of the 1584 neighbor via its Proxy/Server as discussed in Section 3.15. If the 1585 Client receives an NA(NUD) from the neighbor over the underlying 1586 interface, it marks the neighbor interface as "trusted" and sends 1587 future carrier packets directly to the L2ADDR information for the 1588 neighbor instead of indirectly via the Proxy/Server. The Client must 1589 honor the neighbor cache maintenance procedure by sending additional 1590 direct bubbles and/or NS/NA(NUD) messages as discussed in 1591 [RFC6081][RFC4380] in order to keep NAT state alive as long as 1592 carrier packets are still flowing. 1594 When an carrier packet enters a Client's OMNI interface from the 1595 link-layer, if the OAL destination matches one of the Client's MNPs 1596 or LLAs the Client (acting as an OAL destination) reassembles and 1597 decapsulates as necessary and delivers the original IP packet to the 1598 network layer. Otherwise, the Client drops the original IP packet 1599 and MAY return a network-layer ICMP Destination Unreachable message 1600 subject to rate limiting (see: Section 3.11). 1602 Note: Clients and their Proxy/Server (and other Client) peers can 1603 exchange original IP packets over ANET underlying interfaces without 1604 invoking the OAL, since the ANET is secured at the link and physical 1605 layers. By forwarding original IP packets without invoking the OAL, 1606 however, the ANET peers can engage only in classical path MTU 1607 discovery since the packets are subject to loss and/or corruption due 1608 to the various per-link MTU limitations that may occur within the 1609 ANET. Moreover, the original IP packets do not include per-packet 1610 Identification values that can be used for data origin authentication 1611 and link-layer retransmission purposes, nor the OAL integrity check. 1612 The tradeoff therefore involves an assessment of the per-packet 1613 encapsulation overhead saved by bypassing the OAL vs. inheritance of 1614 classical network "brittleness". 1616 3.10.2. Proxy/Server Forwarding Algorithm 1618 When the Proxy/Server receives an original IP packet from the network 1619 layer, it drops the packet if routing indicates that it should be 1620 forwarded back to the network layer to avoid looping. Otherwise, the 1621 Proxy/Server regards the original IP packet the same as if it had 1622 arrived as carrier packets with OAL destination set to its own ADM- 1623 ULA. When the Proxy/Server receives carrier packets on underlying 1624 interfaces with OAL destination set to its own ADM-ULA, it performs 1625 OAL reassembly if necessary to obtain the original IP packet. 1627 The Proxy/Server next searches for a neighbor cache entry that 1628 matches the original IP destination and proceeds as follows: 1630 o if the original IP packet destination matches a neighbor cache 1631 entry, the Proxy/Sever uses one or more "reachable" neighbor 1632 interfaces in the entry for packet forwarding using OAL 1633 encapsulation and fragmentation according to the cached link-layer 1634 address information. If the neighbor interface is in a different 1635 OMNI link segment, the Proxy/Server forwards the resulting carrier 1636 packets to a Bridge; otherwise, it forwards the carrier packets 1637 directly to the neighbor. If the neighbor is behind a NAT, the 1638 Proxy/Server instead forwards initial carrier packets via a Bridge 1639 while sending an NS(NUD) to the neighbor. When the Proxy/Server 1640 receives the NA(NUD), it can begin forwarding carrier packets 1641 directly to the neighbor the same as discussed in Section 3.10.1 1642 while sending additional NS(NUD) messages as necessary to maintain 1643 NAT state. Note that no direct bubbles are necessary since the 1644 Proxy/Server is by definition not located behind a NAT. 1646 o else, if the original IP destination matches a non-MNP route in 1647 the IP forwarding table or an ADM-LLA assigned to the Proxy/ 1648 Server's OMNI interface, the Proxy/Server presents the original IP 1649 packet to the network layer for local delivery or IP forwarding. 1651 o else, the Proxy/Server initiates address resolution as discussed 1652 in Section 3.14, while retaining initial original IP packets in a 1653 small queue awaiting address resolution completion. 1655 When the Proxy/Server receives a carrier packet with OAL destination 1656 set to a non-MNP ULA, it accepts the carrier packet only if data 1657 origin authentication succeeds and if there is a network layer 1658 routing table for a GUA route that matches the non-MNP ULA. If there 1659 is no route, the Proxy/Server drops the carrier packet; otherwise, it 1660 reassembles and decapsulates to obtain the original IP packet and 1661 presents it to the network layer where it will be delivered according 1662 to standard IP forwarding. 1664 When the Proxy/Server receives a carrier packet with OAL destination 1665 set to an MNP-ULA, it accepts the carrier packet only if data origin 1666 authentication succeeds and if there is a neighbor cache entry that 1667 matches the OAL destination. If the neighbor cache entry state is 1668 DEPARTED, the Proxy/Server inserts an ORH that encodes the MNP-ULA 1669 destination suffix and changes the OAL destination address to the 1670 ADM-ULA of the new Proxy/Server, then re-encapsulates the carrier 1671 packet and forwards it to a Bridge which will eventually deliver it 1672 to the new Proxy/Server. 1674 If the neighbor cache state is REACHABLE, the Proxy/Server can 1675 instead either reassemble first and then re-encapsulate/re-fragment 1676 before forwarding to the Client or forward the raw fragments on to 1677 the Client which then must reassemble. In the former case, the 1678 Proxy/Server can re-fragment to a size that better matches the link 1679 MTU for the Client, which may be important for low-end links with 1680 large MTUs. In the latter case, the Client may receive fragments 1681 that are smaller than its link MTU but can still be reassembled; this 1682 case may provide an important performance benefit to Proxy/Servers by 1683 permitting them to avoid excessive reassembly and re-fragmentation 1684 overhead. In either case, the Proxy/Server can return a PTB if 1685 necessary (see: [I-D.templin-6man-omni-interface]) when it receives a 1686 carrier packet containing an OAL first fragment. 1688 Note: Clients and their Proxy/Server peers can exchange original IP 1689 packets over ANET underlying interfaces without invoking the OAL, 1690 since the ANET is secured at the link and physical layers. By 1691 forwarding original IP packets without invoking the OAL, however, the 1692 Client and Proxy/Server can engage only in classical path MTU 1693 discovery since the packets are subject to loss and/or corruption due 1694 to the various per-link MTU limitations that may occur within the 1695 ANET. Moreover, the original IP packets do not include per-packet 1696 Identification values that can be used for data origin authentication 1697 and link-layer retransmission purposes, nor the OAL integrity check. 1698 The tradeoff therefore involves an assessment of the per-packet 1699 encapsulation overhead saved by bypassing the OAL vs. inheritance of 1700 classical network "brittleness". 1702 Note: If the Proxy/Server has multiple original IP packets to send to 1703 the same neighbor, it can concatenate them in a single OAL super- 1704 packet [I-D.templin-6man-omni-interface]. 1706 3.10.3. Bridge Forwarding Algorithm 1708 Bridges forward carrier packets the same as any IPv6 router. Bridges 1709 convey carrier packets and original IP packets that encapsulate IPv6 1710 ND control messages or routing protocol control messages using 1711 security encapsulations, and may convey packets that encapsulate 1712 ordinary data without including security encapsulations. When the 1713 Bridge receives a carrier packet or an original IP packet, it removes 1714 the outer *NET header and searches for a forwarding table entry that 1715 matches the OAL destination address. The Bridge then processes the 1716 packet as follows: 1718 o if the packet is a carrier packet with a destination that matches 1719 its ADM-ULA Subnet Router Anycast address the Bridge processes the 1720 carrier packet locally before forwarding. The Bridge drops the 1721 carrier packet if it does not include an ORH; otherwise, for 1722 NA(NUD) messages the Bridge replaces the OMNI option Interface 1723 Attributes sub-option with information for its own interface while 1724 retaining the ifIndex value supplied by the NA(NUD) message 1725 source. The Bridge next examines the ORH FMT code. If the code 1726 indicates the destination is a Client on the open *NET (or, a 1727 Client behind a NAT for which NAT traversal procedures have 1728 already converged) the Bridge removes the ORH then writes the MNP- 1729 ULA formed from the ORH Destination Suffix into the OAL 1730 destination. The Bridge then re-encapsulates the carrier packet 1731 and forwards it to the ORH L2ADDR. For all other destination 1732 cases, the Bridge instead writes the ADM-ULA formed from the ORH 1733 SRT/LHS into the OAL destination address and forwards the carrier 1734 packet to the ADM-ULA Proxy/Server while invoking NAT traversal 1735 procedures the same as for Proxy/Servers if necessary, noting that 1736 no direct bubbles are necessary since only the target Client and 1737 not the Bridge is behind a NAT. 1739 o else, if the packet is a carrier packet with a destination that 1740 matches a forwarding table entry the Bridge forwards the carrier 1741 packet via a secured tunnel to the next hop. (If the destination 1742 matches an MSP without matching an MNP, however, the Bridge 1743 instead drops the packet and returns an ICMP Destination 1744 Unreachable message subject to rate limiting - see: Section 3.11). 1746 o else, if the packet is an original IP packet with a destination 1747 that matches one of the Bridge's own addresses, the Bridge submits 1748 the original IP packet for local delivery to support local 1749 applications such as routing protocols. 1751 o else, the Bridge drops the packet and returns an ICMP Destination 1752 Unreachable as above. 1754 As for any IP router, the Bridge decrements the OAL IPv6 header Hop 1755 Limit when it forwards the carrier packet and drops the packet if the 1756 Hop Limit reaches 0. Therefore, when an OAL header is present only 1757 the Hop Limit in the OAL header is decremented and not the TTL/Hop 1758 Limit in the original IP packet header. Bridges do not insert OAL/ 1759 ORH headers themselves; instead, they act as IPv6 routers and forward 1760 carrier packets based on their destination addresses. 1762 Bridges forward packets received from a first segment without 1763 security encapsulations to the next segment also without including 1764 security encapsulations. Bridges forward packets received from a 1765 first segment with security encapsulations to the next segment also 1766 including security encapsulations. Bridges use a single IPv6 routing 1767 table that always determines the same next hop for a given OAL 1768 destination whether or not security encapsulation is included. 1770 3.11. OMNI Interface Error Handling 1772 When an AERO node admits an original IP packet into the OMNI 1773 interface, it may receive link-layer or network-layer error 1774 indications. 1776 A link-layer error indication is an ICMP error message generated by a 1777 router in the INET on the path to the neighbor or by the neighbor 1778 itself. The message includes an IP header with the address of the 1779 node that generated the error as the source address and with the 1780 link-layer address of the AERO node as the destination address. 1782 The IP header is followed by an ICMP header that includes an error 1783 Type, Code and Checksum. Valid type values include "Destination 1784 Unreachable", "Time Exceeded" and "Parameter Problem" 1785 [RFC0792][RFC4443]. (OMNI interfaces ignore all link-layer IPv4 1786 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1787 only emit carrier packets that are guaranteed to be no larger than 1788 the IP minimum link MTU as discussed in Section 3.9.) 1790 The ICMP header is followed by the leading portion of the original IP 1791 packet that generated the error, also known as the "packet-in-error". 1792 For ICMPv6, [RFC4443] specifies that the packet-in-error includes: 1793 "As much of invoking packet as possible without the ICMPv6 packet 1794 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1795 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1796 "Internet Header + 64 bits of Original Data Datagram", however 1797 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1798 ICMP datagram SHOULD contain as much of the original datagram as 1799 possible without the length of the ICMP datagram exceeding 576 1800 bytes". 1802 The link-layer error message format is shown in Figure 5 (where, "L2" 1803 and "L3" refer to link-layer and network-layer, respectively): 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 ~ ~ 1807 | L2 IP Header of | 1808 | error message | 1809 ~ ~ 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | L2 ICMP Header | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1813 ~ ~ P 1814 | IP and other encapsulation | a 1815 | headers of original IP packet | c 1816 ~ ~ k 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1818 ~ ~ t 1819 | IP header of | 1820 | original IP packet | i 1821 ~ ~ n 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 ~ ~ e 1824 | Upper layer headers and | r 1825 | leading portion of body | r 1826 | of the original IP packet | o 1827 ~ ~ r 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1830 Figure 5: OMNI Interface Link-Layer Error Message Format 1832 The AERO node rules for processing these link-layer error messages 1833 are as follows: 1835 o When an AERO node receives a link-layer Parameter Problem message, 1836 it processes the message the same as described as for ordinary 1837 ICMP errors in the normative references [RFC0792][RFC4443]. 1839 o When an AERO node receives persistent link-layer Time Exceeded 1840 messages, the IP ID field may be wrapping before earlier fragments 1841 awaiting reassembly have been processed. In that case, the node 1842 should begin including integrity checks and/or institute rate 1843 limits for subsequent packets. 1845 o When an AERO node receives persistent link-layer Destination 1846 Unreachable messages in response to carrier packets that it sends 1847 to one of its neighbor correspondents, the node should process the 1848 message as an indication that a path may be failing, and 1849 optionally initiate NUD over that path. If it receives 1850 Destination Unreachable messages over multiple paths, the node 1851 should allow future carrier packets destined to the correspondent 1852 to flow through a default route and re-initiate route 1853 optimization. 1855 o When an AERO Client receives persistent link-layer Destination 1856 Unreachable messages in response to carrier packets that it sends 1857 to one of its neighbor Proxy/Servers, the Client should mark the 1858 path as unusable and use another path. If it receives Destination 1859 Unreachable messages on many or all paths, the Client should 1860 associate with a new Proxy/Server and release its association with 1861 the old Proxy/Server as specified in Section 3.16.5. 1863 o When an AERO Proxy/Server receives persistent link-layer 1864 Destination Unreachable messages in response to carrier packets 1865 that it sends to one of its neighbor Clients, the Proxy/Server 1866 should mark the underlying path as unusable and use another 1867 underlying path. 1869 o When an AERO Proxy/Server receives link-layer Destination 1870 Unreachable messages in response to a carrier packet that it sends 1871 to one of its permanent neighbors, it treats the messages as an 1872 indication that the path to the neighbor may be failing. However, 1873 the dynamic routing protocol should soon reconverge and correct 1874 the temporary outage. 1876 When an AERO Bridge receives a carrier packet for which the network- 1877 layer destination address is covered by an MSP, the Bridge drops the 1878 packet if there is no more-specific routing information for the 1879 destination and returns a network-layer Destination Unreachable 1880 message subject to rate limiting. The Bridge writes the network- 1881 layer source address of the original IP packet as the destination 1882 address and uses one of its non link-local addresses as the source 1883 address of the message. 1885 When an AERO node receives a carrier packet for which the reassembly 1886 buffer it too small, it drops the packet and returns a network-layer 1887 Packet Too Big (PTB) message. The node first writes the MRU value 1888 into the PTB message MTU field, writes the network-layer source 1889 address of the original IP packet as the destination address and 1890 writes one of its non link-local addresses as the source address. 1892 3.12. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1894 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1895 coordinated as discussed in the following Sections. 1897 3.12.1. AERO Service Model 1899 Each AERO Proxy/Server on the OMNI link is configured to facilitate 1900 Client prefix delegation/registration requests. Each Proxy/Server is 1901 provisioned with a database of MNP-to-Client ID mappings for all 1902 Clients enrolled in the AERO service, as well as any information 1903 necessary to authenticate each Client. The Client database is 1904 maintained by a central administrative authority for the OMNI link 1905 and securely distributed to all Proxy/Servers, e.g., via the 1906 Lightweight Directory Access Protocol (LDAP) [RFC4511], via static 1907 configuration, etc. Clients receive the same service regardless of 1908 the Proxy/Servers they select. 1910 AERO Clients and Proxy/Servers use ND messages to maintain neighbor 1911 cache entries. AERO Proxy/Servers configure their OMNI interfaces as 1912 advertising NBMA interfaces, and therefore send unicast RA messages 1913 with a short Router Lifetime value (e.g., ReachableTime seconds) in 1914 response to a Client's RS message. Thereafter, Clients send 1915 additional RS messages to keep Proxy/Server state alive. 1917 AERO Clients and Proxy/Servers include prefix delegation and/or 1918 registration parameters in RS/RA messages (see 1919 [I-D.templin-6man-omni-interface]). The ND messages are exchanged 1920 between Client and Proxy/Server according to the prefix management 1921 schedule required by the service. If the Client knows its MNP in 1922 advance, it can employ prefix registration by including its MNP-LLA 1923 as the source address of an RS message and with an OMNI option with 1924 valid prefix registration information for the MNP. If the Proxy/ 1925 Server accepts the Client's MNP assertion, it injects the MNP into 1926 the routing system and establishes the necessary neighbor cache 1927 state. If the Client does not have a pre-assigned MNP, it can 1928 instead employ prefix delegation by including the unspecified address 1929 (::) as the source address of an RS message and with an OMNI option 1930 with prefix delegation parameters to request an MNP. 1932 The following sections specify the Client and Proxy/Server behavior. 1934 3.12.2. AERO Client Behavior 1936 AERO Clients discover the addresses of Proxy/Servers in a similar 1937 manner as described in [RFC5214]. Discovery methods include static 1938 configuration (e.g., from a flat-file map of Proxy/Server addresses 1939 and locations), or through an automated means such as Domain Name 1940 System (DNS) name resolution [RFC1035]. Alternatively, the Client 1941 can discover Proxy/Server addresses through a layer 2 data link login 1942 exchange, or through a unicast RA response to a multicast/anycast RS 1943 as described below. In the absence of other information, the Client 1944 can resolve the DNS Fully-Qualified Domain Name (FQDN) 1945 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 1946 text string and "[domainname]" is a DNS suffix for the OMNI link 1947 (e.g., "example.com"). 1949 To associate with a Proxy/Server, the Client acts as a requesting 1950 router to request MNPs. The Client prepares an RS message with 1951 prefix management parameters and includes a Nonce and Timestamp 1952 option if the Client needs them to correlate RA replies. If the 1953 Client already knows the Proxy/Server's ADM-LLA, it includes the LLA 1954 as the network-layer destination address; otherwise, the Client 1955 includes the (link-local) All-Routers multicast as the network-layer 1956 destination. If the Client already knows its own MNP-LLA, it can use 1957 the MNP-LLA as the network-layer source address and include an OMNI 1958 option with prefix registration information. Otherwise, the Client 1959 uses the unspecified address (::) as the network-layer source address 1960 and includes prefix delegation parameters in the OMNI option (see: 1961 [I-D.templin-6man-omni-interface]). The Client includes Interface 1962 Attributes corresponding to the underlying interface over which it 1963 will send the RS message, and MAY include additional Interface 1964 Attributes specific to other underlying interfaces. 1966 For INET Clients, the Client must ensure that the RS message is no 1967 larger than the minimum/path MPS for the chosen Proxy/Server and must 1968 include a security signature that the Proxy/Server can verify. The 1969 Client next applies OAL encapsulation such that the entire RS message 1970 fits within an OAL First Fragment (i.e., as an atomic fragment) while 1971 including an Identification number that will serve as the window 1972 start Identification value for future packets it will send via this 1973 Proxy/Server. 1975 The Client then sends the RS message (either directly via Direct 1976 interfaces, via a VPN for VPNed interfaces, via an access router for 1977 ANET interfaces or via INET encapsulation for INET interfaces) while 1978 using OAL encapsulation/fragmentation, then waits for an RA message 1979 reply (see Section 3.12.3). The Client retries up to 1980 MAX_RTR_SOLICITATIONS times until an RA is received. If the Client 1981 receives no RAs, or if it receives an RA with Router Lifetime set to 1982 0, the Client SHOULD abandon attempts through the first Proxy/Server 1983 and try another Proxy/Server. Otherwise, the Client processes the 1984 prefix information found in the RA message. 1986 When the Client processes an RA, it first performs OAL reassembly and 1987 decapsulation then creates a neighbor cache entry with the Proxy/ 1988 Server's ADM-LLA as the network-layer address and the Proxy/Server's 1989 encapsulation and/or link-layer addresses as the link-layer address. 1990 The Client next records the RA Router Lifetime field value in the 1991 neighbor cache entry as the time for which the Proxy/Server has 1992 committed to maintaining the MNP in the routing system via this 1993 underlying interface, and caches the other RA configuration 1994 information including Cur Hop Limit, M and O flags, Reachable Time 1995 and Retrans Timer. The Client then autoconfigures MNP-LLAs for any 1996 delegated MNPs and assigns them to the OMNI interface. The Client 1997 also caches any MSPs included in Route Information Options (RIOs) 1998 [RFC4191] as MSPs to associate with the OMNI link, and assigns the 1999 MTU value in the MTU option to the underlying interface. 2001 The Client then registers additional underlying interfaces with the 2002 Proxy/Server by sending RS messages via each additional interface as 2003 described above. The RS messages include the same parameters as for 2004 the initial RS/RA exchange, but with destination address set to the 2005 Proxy/Server's ADM-LLA. The Client finally sub-delegates the MNPs to 2006 its attached EUNs and/or the Client's own internal virtual interfaces 2007 as described in [I-D.templin-v6ops-pdhost] to support the Client's 2008 downstream attached "Internet of Things (IoT)". The Client then 2009 sends additional RS messages over each underlying interface before 2010 the Router Lifetime received for that interface expires. 2012 After the Client registers its underlying interfaces, it may wish to 2013 change one or more registrations, e.g., if an interface changes 2014 address or becomes unavailable, if QoS preferences change, etc. To 2015 do so, the Client prepares an RS message to send over any available 2016 underlying interface as above. The RS includes an OMNI option with 2017 prefix registration/delegation information, with Interface Attributes 2018 specific to the selected underlying interface, and with any 2019 additional Interface Attributes specific to other underlying 2020 interfaces. When the Client receives the Proxy/Server's RA response, 2021 it has assurance that the Proxy/Server has been updated with the new 2022 information. 2024 If the Client wishes to discontinue use of a Proxy/Server it issues 2025 an RS message over any underlying interface with an OMNI option with 2026 a prefix release indication. When the Proxy/Server processes the 2027 message, it releases the MNP, sets the neighbor cache entry state for 2028 the Client to DEPARTED and returns an RA reply with Router Lifetime 2029 set to 0. After a short delay (e.g., 2 seconds), the Proxy/Server 2030 withdraws the MNP from the routing system. 2032 3.12.3. AERO Proxy/Server Behavior 2034 AERO Proxy/Servers act as IP routers and support a prefix delegation/ 2035 registration service for Clients. Proxy/Servers arrange to add their 2036 ADM-LLAs to a static map of Proxy/Server addresses for the link and/ 2037 or the DNS resource records for the FQDN 2038 "linkupnetworks.[domainname]" before entering service. Proxy/Server 2039 addresses should be geographically and/or topologically referenced, 2040 and made available for discovery by Clients on the OMNI link. 2042 When a Proxy/Server receives a prospective Client's RS message on its 2043 OMNI interface, it SHOULD return an immediate RA reply with Router 2044 Lifetime set to 0 if it is currently too busy or otherwise unable to 2045 service the Client. Otherwise, the Proxy/Server performs OAL 2046 reassembly and decapsulation, then authenticates the RS message and 2047 processes the prefix delegation/registration parameters. The Proxy/ 2048 Server first determines the correct MNPs to provide to the Client by 2049 processing the MNP-LLA prefix parameters and/or the DHCPv6 OMNI sub- 2050 option. When the Proxy/Server returns the MNPs, it also creates a 2051 forwarding table entry for the MNP-ULA corresponding to each MNP so 2052 that the MNPs are propagated into the routing system (see: 2053 Section 3.2.3). For IPv6, the Proxy/Server creates an IPv6 2054 forwarding table entry for each MNP. For IPv4, the Proxy/Server 2055 creates an IPv6 forwarding table entry with the IPv4-compatibility 2056 MNP-ULA prefix corresponding to the IPv4 address. 2058 The Proxy/Server next creates a neighbor cache entry for the Client 2059 using the base MNP-LLA as the network-layer address and with lifetime 2060 set to no more than the smallest prefix lifetime. Next, the Proxy/ 2061 Server updates the neighbor cache entry by recording the information 2062 in each Interface Attributes sub-option in the RS OMNI option. The 2063 Proxy/Server also records the actual OAL/INET addresses in the 2064 neighbor cache entry. For INET Clients, the Proxy/Server also 2065 records the RS carrier packet Identification number which will serve 2066 as the window start Identification value for future packets it will 2067 receive from this Client. 2069 Next, the Proxy/Server prepares an RA message using its ADM-LLA as 2070 the network-layer source address and the network-layer source address 2071 of the RS message as the network-layer destination address. The 2072 Proxy/Server sets the Router Lifetime to the time for which it will 2073 maintain both this underlying interface individually and the neighbor 2074 cache entry as a whole. The Proxy/Server also sets Cur Hop Limit, M 2075 and O flags, Reachable Time and Retrans Timer to values appropriate 2076 for the OMNI link. The Proxy/Server includes the MNPs, any other 2077 prefix management parameters and an OMNI option with no Interface 2078 Attributes but with an Origin Indication sub-option per 2079 [I-D.templin-6man-omni-interface] with the mapped and obfuscated Port 2080 Number and IP address corresponding to the Client's own INET address 2081 in the case of INET Clients or to the Proxy/Server's INET-facing 2082 address for all other Clients. The Proxy/Server then includes one or 2083 more RIOs that encode the MSPs for the OMNI link, plus an MTU option 2084 (see Section 3.9). The Proxy/Server finally forwards the message to 2085 the Client using OAL encapsulation/fragmentation as necessary. 2087 After the initial RS/RA exchange, the Proxy/Server maintains a 2088 ReachableTime timer for each of the Client's underlying interfaces 2089 individually (and for the Client's neighbor cache entry collectively) 2090 set to expire after ReachableTime seconds. If the Client (or Proxy) 2091 issues additional RS messages, the Proxy/Server sends an RA response 2092 and resets ReachableTime. If the Proxy/Server receives an ND message 2093 with a prefix release indication it sets the Client's neighbor cache 2094 entry to the DEPARTED state and withdraws the MNP from the routing 2095 system after a short delay (e.g., 2 seconds). If ReachableTime 2096 expires before a new RS is received on an individual underlying 2097 interface, the Proxy/Server marks the interface as DOWN. If 2098 ReachableTime expires before any new RS is received on any individual 2099 underlying interface, the Proxy/Server sets the neighbor cache entry 2100 state to STALE and sets a 10 second timer. If the Proxy/Server has 2101 not received a new RS or ND message with a prefix release indication 2102 before the 10 second timer expires, it deletes the neighbor cache 2103 entry and withdraws the MNP from the routing system. 2105 The Proxy/Server processes any ND messages pertaining to the Client 2106 and returns an NA/RA reply in response to solicitations. The Proxy/ 2107 Server may also issue unsolicited RA messages, e.g., with reconfigure 2108 parameters to cause the Client to renegotiate its prefix delegation/ 2109 registrations, with Router Lifetime set to 0 if it can no longer 2110 service this Client, etc. Finally, If the neighbor cache entry is in 2111 the DEPARTED state, the Proxy/Server deletes the entry after 2112 DepartTime expires. 2114 Note: Clients SHOULD notify former Proxy/Servers of their departures, 2115 but Proxy/Servers are responsible for expiring neighbor cache entries 2116 and withdrawing routes even if no departure notification is received 2117 (e.g., if the Client leaves the network unexpectedly). Proxy/Servers 2118 SHOULD therefore set Router Lifetime to ReachableTime seconds in 2119 solicited RA messages to minimize persistent stale cache information 2120 in the absence of Client departure notifications. A short Router 2121 Lifetime also ensures that proactive RS/RA messaging between Clients 2122 and Proxy/Servers will keep any NAT state alive (see above). 2124 Note: All Proxy/Servers on an OMNI link MUST advertise consistent 2125 values in the RA Cur Hop Limit, M and O flags, Reachable Time and 2126 Retrans Timer fields the same as for any link, since unpredictable 2127 behavior could result if different Proxy/Servers on the same link 2128 advertised different values. 2130 3.12.3.1. DHCPv6-Based Prefix Registration 2132 When a Client is not pre-provisioned with an MNP-LLA, it will need 2133 for the Proxy/Server to select one or more MNPs on its behalf and set 2134 up the correct state in the AERO routing service. (A Client with a 2135 pre-provisioned MNP may also request the Proxy/Server to select 2136 additional MNPs.) The DHCPv6 service [RFC8415] is used to support 2137 this requirement. 2139 When a Client needs to have the Proxy/Server select MNPs, it sends an 2140 RS message with source address set to the unspecified address (::) 2141 and with an OMNI option that includes a DHCPv6 message sub-option 2142 with DHCPv6 Prefix Delegation (DHCPv6-PD) parameters. When the 2143 Proxy/Server receives the RS message, it extracts the DHCPv6-PD 2144 message from the OMNI option. 2146 The Proxy/Server then acts as a "Proxy DHCPv6 Client" in a message 2147 exchange with the locally-resident DHCPv6 server, which delegates 2148 MNPs and returns a DHCPv6-PD Reply message. (If the Proxy/Server 2149 wishes to defer creation of MN state until the DHCPv6-PD Reply is 2150 received, it can instead act as a Lightweight DHCPv6 Relay Agent per 2151 [RFC6221] by encapsulating the DHCPv6-PD message in a Relay-forward/ 2152 reply exchange with Relay Message and Interface ID options.) 2154 When the Proxy/Server receives the DHCPv6-PD Reply, it adds a route 2155 to the routing system and creates an MNP-LLA based on the delegated 2156 MNP. The Proxy/Server then sends an RA back to the Client with the 2157 (newly-created) MNP-LLA as the destination address and with the 2158 DHCPv6-PD Reply message coded in the OMNI option. When the Client 2159 receives the RA, it creates a default route, assigns the Subnet 2160 Router Anycast address and sets its MNP-LLA based on the delegated 2161 MNP. 2163 Note: See [I-D.templin-6man-omni-interface] for an MNP delegation 2164 alternative in which the Client can optionally avoid including a 2165 DHCPv6 message sub-option. Namely, when the Client requests a single 2166 MNP it can set the RS source to the unspecified address (::) and 2167 include a Node Identification sub-option and Preflen in the OMNI 2168 option (but with no DHCPv6 message sub-option). When the Proxy/ 2169 Server receives the RS message, it forwards a self-generated DHCPv6 2170 Solicit message to the DHCPv6 server on behalf of the Client. When 2171 the Proxy/Server receives the DHCPv6 Reply, it prepares an RA message 2172 with an OMNI option with Preflen information (but with no DHCPv6 2173 message sub-option), then places the (newly-created) MNP-LLA in the 2174 RA destination address and returns the message to the Client. 2176 3.13. The AERO Proxy Function 2178 Clients connect to the OMNI link via Proxy/Servers, with one Proxy/ 2179 Server for each underlying interface. Each of the Client's Proxy/ 2180 Servers must be informed of all of the Client's additional underlying 2181 interfaces. For Clients on Direct and VPNed underlying interfaces 2182 the Proxy/Server "A" for that interface is directly connected, for 2183 Clients on ANET underlying interfaces Proxy/Server "A" is located on 2184 the ANET/INET boundary, and for Clients on INET underlying interfaces 2185 Proxy/Server "A" is located somewhere in the connected Internetwork. 2186 When the Client registers with Proxy/Server "A", it must also report 2187 the registration to any other Proxy/Servers for other underlying 2188 interfaces "B", "C", "D", etc. for which an underlying interface 2189 relationship has already been established. The Proxy/Server 2190 satisfies these requirements as follows: 2192 o when Proxy/Server "A" receives an RS message from a new Client, it 2193 first authenticates the message then examines the network-layer 2194 destination address. If the destination address is Proxy/Server 2195 "A"'s ADM-LLA or (link-local) All-Routers multicast, Proxy/Server 2196 "A" creates a proxy neighbor cache entry and caches the Client 2197 link-layer addresses along with the OMNI option information and 2198 any other identifying information including OAL Identification 2199 values, Client Identifiers, Nonce values, etc. If the RS message 2200 destination was the ADM-LLA of a different Proxy/Server "B" (or, 2201 if the OMNI option included an MS-Register sub-option with the 2202 ADM-LLA of a different Proxy/Server "B"), Proxy/Server "A" 2203 encapsulates a proxyed version of the RS message in an OAL header 2204 with source set to Proxy/Server "A"'s ADM-ULA and destination set 2205 to Proxy/Server "B"'s ADM-ULA. Proxy/Server "A" also includes an 2206 OMNI header with an Interface Attributes option that includes its 2207 own INET address plus a unique UDP Port Number for this Client, 2208 then forwards the message into the OMNI link spanning tree. 2209 (Note: including a unique Port Number allows Proxy/Server "B" to 2210 distinguish different Clients located behind the same Proxy/Server 2211 "A" at the link-layer, whereas the link-layer addresses would 2212 otherwise be indistinguishable.) 2214 o when the Proxy/Server "B" receives the RS, it authenticates the 2215 message then creates or updates a neighbor cache entry for the 2216 Client with Proxy/Server "A"'s ADM-ULA, INET address and UDP Port 2217 Number as the link-layer address information. Proxy/Server "B" 2218 then sends an RA message back to Proxy/Server "A" via the spanning 2219 tree. 2221 o when Proxy/Server "A" receives the RA, it authenticates the 2222 message and matches it with the proxy neighbor cache entry created 2223 by the RS. Proxy/Server "A" then caches the prefix information as 2224 a mapping from the Client's MNPs to the Client's link-layer 2225 address, caches the Proxy/Server's advertised Router Lifetime and 2226 sets the neighbor cache entry state to REACHABLE. The Proxy then 2227 optionally rewrites the Router Lifetime and forwards the (proxyed) 2228 message to the Client. The Proxy finally includes an MTU option 2229 (if necessary) with an MTU to use for the underlying ANET 2230 interface. 2232 o The Client repeats this process with each Proxy/Server "B", "C", 2233 "D" for each of its additional underlying interfaces. 2235 After the initial RS/RA exchanges each Proxy/Server forwards any of 2236 the Client's carrier packets for which there is no matching neighbor 2237 cache entry to a Bridge using OAL encapsulation with its own ADM-ULA 2238 as the source and the MNP-ULA corresponding to the Client as the 2239 destination. The Proxy/Server instead forwards any carrier packets 2240 destined to a neighbor cache target directly to the target according 2241 to the OAL/link-layer information - the process of establishing 2242 neighbor cache entries is specified in Section 3.14. 2244 While the Client is still associated with each Proxy/Server "A", "A" 2245 can send NS, RS and/or unsolicited NA messages to update the neighbor 2246 cache entries of other AERO nodes on behalf of the Client and/or to 2247 convey QoS updates. This allows for higher-frequency Proxy-initiated 2248 RS/RA messaging over well-connected INET infrastructure supplemented 2249 by lower-frequency Client-initiated RS/RA messaging over constrained 2250 ANET data links. 2252 If any Proxy/Server "B", "C", "D" ceases to send solicited 2253 advertisements, Proxy/Server "A" sends unsolicited RAs to the Client 2254 with destination set to (link-local) All-Nodes multicast and with 2255 Router Lifetime set to zero to inform Clients that a Proxy/Server has 2256 failed. Although Proxy/Server "A" can engage in ND exchanges on 2257 behalf of the Client, the Client can also send ND messages on its own 2258 behalf, e.g., if it is in a better position than "A" to convey QoS 2259 changes, etc. The ND messages sent by the Client include the 2260 Client's MNP-LLA as the source in order to differentiate them from 2261 the ND messages sent by Proxy/Server "A". 2263 If the Client becomes unreachable over an underlying interface, 2264 Proxy/Server "A" sets the neighbor cache entry state to DEPARTED and 2265 retains the entry for DepartTime seconds. While the state is 2266 DEPARTED, Proxy/Server "A" forwards any carrier packets destined to 2267 the Client to a Bridge via OAL/ORH encapsulation. When DepartTime 2268 expires, Proxy/Server "A" deletes the neighbor cache entry and 2269 discards any further carrier packets destined to this (now forgotten) 2270 Client. 2272 In some ANETs that employ a Proxy/Server, the Client's MNP can be 2273 injected into the ANET routing system. In that case, the Client can 2274 send original IP packets without invoking the OAL so that the ANET 2275 routing system transports the original IP packets to the Proxy. This 2276 can be very beneficial, e.g., if the Client connects to the ANET via 2277 low-end data links such as some aviation wireless links. 2279 If the ANET first-hop access router is on the same underlying link as 2280 the Client and recognizes the AERO/OMNI protocol, the Client can 2281 avoid OAL encapsulation for both its control and data messages. When 2282 the Client connects to the link, it can send an unencapsulated RS 2283 message with source address set to its own MNP-LLA (or to a Temporary 2284 LLA), and with destination address set to the ADM-LLA of the Client's 2285 selected Proxy/Server or to (link-local) All-Routers multicast. The 2286 Client includes an OMNI option formatted as specified in 2287 [I-D.templin-6man-omni-interface]. The Client then sends the 2288 unencapsulated RS message, which will be intercepted by the AERO- 2289 Aware access router. 2291 The ANET access router then performs OAL encapsulation on the RS 2292 message and forwards it to a Proxy/Server at the ANET/INET boundary. 2293 When the access router and Proxy/Server are one and the same node, 2294 the Proxy/Server would share and underlying link with the Client but 2295 its message exchanges with outside correspondents would need to pass 2296 through a security gateway at the ANET/INET border. The method for 2297 deploying access routers and Proxys (i.e. as a single node or 2298 multiple nodes) is an ANET-local administrative consideration. 2300 Note: The Proxy/Server can apply packing as discussed in 2301 [I-D.templin-6man-omni-interface] if an opportunity arises to 2302 concatenate multiple original IP packets that will be destined to the 2303 same neighbor. 2305 3.13.1. Detecting and Responding to Proxy/Server Failures 2307 In environments where fast recovery from Proxy/Server failure is 2308 required, Proxy/Server "A" SHOULD use proactive Neighbor 2309 Unreachability Detection (NUD) to track peer Proxy/Server "B" 2310 reachability in a similar fashion as for Bidirectional Forwarding 2311 Detection (BFD) [RFC5880]. Proxy/Server "A" can then quickly detect 2312 and react to failures so that cached information is re-established 2313 through alternate paths. The NUD control messaging is carried only 2314 over well-connected ground domain networks (i.e., and not low-end 2315 aeronautical radio links) and can therefore be tuned for rapid 2316 response. 2318 Proxy/Server "A" performs proactive NUD with peer Proxy/Server "B" 2319 for which there are currently active Clients by sending continuous NS 2320 messages in rapid succession, e.g., one message per second. Proxy/ 2321 Server "A" sends the NS message via the spanning tree with its own 2322 ADM-LLA as the source and the ADM-LLA of the peer Proxy/Server "B" as 2323 the destination. When Proxy/Server "A" is also sending RS messages 2324 to the peer Proxy/Server "B" on behalf of ANET Clients, the resulting 2325 RA responses can be considered as equivalent hints of forward 2326 progress. This means that Proxy/Server "B" need not also send a 2327 periodic NS if it has already sent an RS within the same period. If 2328 the peer Proxy/Server "B" fails (i.e., if "A" ceases to receive 2329 advertisements), Proxy/Server "A" can quickly inform Clients by 2330 sending multicast RA messages on the ANET interface. 2332 Proxy/Server "A" sends RA messages on the ANET interface with source 2333 address set to Proxy/Server "B"'s address, destination address set to 2334 (link-local) All-Nodes multicast, and Router Lifetime set to 0. 2335 Proxy/Server "A" SHOULD send MAX_FINAL_RTR_ADVERTISEMENTS RA messages 2336 separated by small delays [RFC4861]. Any Clients on the ANET that 2337 had been using the failed Proxy/Server "B" will receive the RA 2338 messages and associate with a new Proxy/Server. 2340 3.13.2. Point-to-Multipoint Server Coordination 2342 In environments where Client messaging over ANETs is bandwidth- 2343 limited and/or expensive, Clients can enlist the services of Proxy/ 2344 Server "A" to coordinate with multiple Proxy/Servers "B", "C", "D" 2345 etc. in a single RS/RA message exchange. The Client can send a 2346 single RS message to (link-local) All-Routers multicast that includes 2347 the ID's of multiple Proxy/Servers in MS-Register sub-options of the 2348 OMNI option. 2350 When Proxy/Server "A" receives the RS and processes the OMNI option, 2351 it sends a separate RS to each MS-Register Proxy/Server ID. When 2352 Proxy/Server "A" receives an RA, it can optionally return an 2353 immediate "singleton" RA to the Client or record the Proxy/Server's 2354 ID for inclusion in a pending "aggregate" RA message. Proxy/Server 2355 "A" can then return aggregate RA messages to the Client including 2356 multiple Proxy/Server IDs in order to conserve bandwidth. Each RA 2357 includes a proper subset of the Proxy/Server IDs from the original RS 2358 message, and Proxy/Server "A" must ensure that the message contents 2359 of each RA are consistent with the information received from the 2360 (aggregated) additional Proxy/Servers. 2362 Clients can thereafter employ efficient point-to-multipoint Proxy/ 2363 Server coordination under the assistance of Proxy/Server "A" to 2364 reduce the number of messages sent over the ANET while enlisting the 2365 support of multiple Proxy/Servers for fault tolerance. Clients can 2366 further include MS-Release sub-options in IPv6 ND messages to request 2367 Proxy/Server "A" to release from former Proxy/Servers via the 2368 procedures discussed in Section 3.16.5. 2370 The OMNI interface specification [I-D.templin-6man-omni-interface] 2371 provides further discussion of the RS/RA messaging involved in point- 2372 to-multipoint coordination. 2374 3.14. AERO Address Resolution 2376 While carrier packets are flowing between a source and target node, 2377 route optimization SHOULD be used. Route optimization is initiated 2378 by the first eligible Route Optimization Source (ROS) closest to the 2379 source as follows: 2381 o For Clients on VPNed and Direct interfaces, the Proxy/Server is 2382 the ROS. 2384 o For Clients on ANET interfaces, either the Client or the Proxy/ 2385 Server may be the ROS. 2387 o For Clients on INET interfaces, the Client itself is the ROS. 2389 o For correspondent nodes on INET/EUN interfaces serviced by a 2390 Relay, the Relay is the ROS. 2392 The route optimization procedure is conducted between the ROS and 2393 with the target Proxy/Server/Relay or the target Client itself acting 2394 as a Route Optimization Responder (ROR) in the same manner as for 2395 IPv6 ND Address Resolution and using the same NS/NA messaging. The 2396 target may either be a MNP Client serviced by a Proxy/Server, or a 2397 non-MNP correspondent reachable via a Relay. 2399 The procedures are specified in the following sections. 2401 3.14.1. Route Optimization Initiation 2403 When an original IP packet from a source node destined to a target 2404 node arrives, the ROS checks for a neighbor cache entry for the LLA 2405 that matches the target destination. If there is a neighbor cache 2406 entry in the REACHABLE state, the ROS invokes the OAL and forwards 2407 the resulting carrier packets according to the cached state and 2408 returns from processing. Otherwise, if there is already a neighbor 2409 cache entry in the STALE state the ROS continues, and if there or no 2410 neighbor cache entry the ROS creates one in the INCOMPLETE state. 2412 The ROS next places the original IP packet on a short queue then 2413 sends an NS message for Address Resolution (NS(AR)) to receive a 2414 solicited NA(AR) message from a ROR. The NS(AR) message must be no 2415 larger than the minimum/path MPS so that its entire contents will fit 2416 in an OAL first fragment (i.e., as an "atomic fragment"). The ROS 2417 prepares an NS(AR) that includes: 2419 o the LLA of the ROS as the source address. 2421 o the LLA corresponding to the original IP packet's destination as 2422 the Target Address, e.g., for 2001:db8:1:2::10:2000 the LLA is 2423 fe80::2001:db8:1:2. 2425 o the Solicited-Node multicast address [RFC4291] formed from the 2426 lower 24 bits of the original IP packet's destination as the 2427 destination address, e.g., for 2001:db8:1:2::10:2000 the NS 2428 destination address is ff02:0:0:0:0:1:ff10:2000. 2430 The NS(AR) message also includes an OMNI option with an Interface 2431 Attributes entry for the sending interface, and with Prefix Length 2432 set to the length associated with the ROS's LLA. The ROS then 2433 submits the NS(AR) message for OAL encapsulation and fragmentation, 2434 with OAL source set to its own ULA and OAL destination set to the ULA 2435 corresponding to the target, and with an unpredictable initial 2436 Identification value selected according to [RFC7739]. The source 2437 caches the initial Identification value in the (newly-created) 2438 neighbor cache entry as the starting sequence number for the "send" 2439 window for future carrier packets sent to this target. 2441 The ROS then sends the resulting carrier packet into the spanning 2442 tree without decrementing the network-layer TTL/Hop Limit field. 2443 (When the ROS is an INET Client, it instead must first sign the 2444 NS(AR) message and send the resulting carrier packet to the ADM-ULA 2445 of one of its current Proxy/Servers which then verifies the NS(AR) 2446 signature and forwards the carrier packet into the spanning tree on 2447 behalf of the Client.) 2449 3.14.2. Relaying the NS(AR) *NET Packet(s) 2451 When the Bridge receives the carrier packet containing the RS from 2452 the ROS, it discards the *NET headers and determines the next hop by 2453 consulting its standard IPv6 forwarding table for the OAL header 2454 destination address. The Bridge then decrements the OAL header Hop- 2455 Limit, re-encapsulates the carrier packet and forwards it via the 2456 spanning tree the same as for any IPv6 router, where it may traverse 2457 multiple OMNI link segments. The final-hop Bridge in the spanning 2458 tree will deliver the carrier packet via a secured tunnel to a Proxy/ 2459 Server or Relay that services the target. 2461 3.14.3. Processing the NS(AR) and Sending the NA(AR) 2463 When the target Proxy/Server/Relay receives the carrier packet, it 2464 examines the enclosed atomic OAL fragment to determine that it 2465 contains an NS(AR) then examines the NS(AR) target to determine 2466 whether it has a matching neighbor cache entry and/or non-MNP route. 2467 If there is no match, the Proxy/Server/Relay drops the message. 2468 Otherwise, the Proxy/Server continues processing as follows: 2470 o if the NS(AR) target matches a Client neighbor cache entry in the 2471 DEPARTED state, the Proxy/Server inserts an ORH with destination 2472 prefix set to the lower 64 bits of the Client's MNP-ULA and sets 2473 the destination address to the ADM-ULA of the Client's new Proxy/ 2474 Server. The (old) Proxy/Server then re-encapsulates the carrier 2475 packet, forwards it into the spanning tree and returns from 2476 processing. 2478 o If the NS(AR) target matches a Client neighbor cache entry in the 2479 REACHABLE state, the Proxy/Server proceeds according to whether 2480 the Client requires Proxy services. For "dependent" Clients 2481 (e.g., those on low-end ANETs, Direct Links, VPN links, etc.) the 2482 Proxy/Server nominates itself as the ROR; otherwise, the Proxy/ 2483 Server re-encapsulates the carrier packet, includes an 2484 authentication signature if necessary, and forwards it to the 2485 target Client which will act as an ROR on its own behalf. 2487 o If the NS(AR) target matches one of its non-MNP routes, the Relay 2488 acts the ROR. 2490 The ROR next checks for a neighbor cache entry that matches the 2491 NS(AR) source LLA. If there is a neighbor cache entry in the 2492 REACHABLE state, the ROR accepts the NS(AR) only if the OAL 2493 Identification value is within the "accept" window for this NS(AR) 2494 source LLA or if the NS(AR) was forwarded securely. If the NS(AR) is 2495 authentic and the OAL Identification is outside of the current 2496 "accept", the ROR resents the current "accept" window start to the 2497 new OAL Identification value while remembering the old value for a 2498 short time in case any carrier packets are still in flight. If there 2499 was no neighbor cache entry in the REACHABLE state, the ROR instead 2500 creates an entry for the NS(AR) source LLA if necessary with state 2501 set to STALE. If the ROR is a Proxy/Server, it next adds a Report 2502 List entry to the target Client neighbor cache entry for the NS(AR) 2503 source LLA while caching the OAL Identification value in the (newly- 2504 created) neighbor cache entry as the starting sequence number for the 2505 "accept" window for future carrier packets received from this LLA 2506 source. 2508 The ROR then prepares a (solicited) NA(AR) message to send back to 2509 the ROS using the same Identification value received in the NS(AR) 2510 (unlike the NS(AR), the NA(AR) need not fit in a single OAL 2511 fragment). The ROR sets the NA(AR) source address to its own LLA, 2512 sets the destination address to the NS(AR) LLA source address and 2513 sets the Target Address to the same value that was in the NS(AR). 2514 The ROR then includes an OMNI option with Prefix Length set to the 2515 length associated with the MNP-LLA. 2517 If the NS(AR) target was an MNP Client, the ROR next includes 2518 Interface Attributes in the OMNI option for each of the target's 2519 underlying interfaces with current information for each interface and 2520 includes an authentication signature if necessary. If the ROR is a 2521 Proxy/Server/Relay, it then sets the S/T-ifIndex field in the OMNI 2522 header set to 0. If the ROR is the Client itself, it instead sets S/ 2523 T-ifIndex to the index of the underlying interface that will send the 2524 NS(AR). 2526 For each Interface Attributes sub-option, the ROR sets the L2ADDR 2527 according to the Proxy/Server's INET address for VPNed or Direct 2528 interfaces, to the INET address of the Proxy/Server for proxyed 2529 interfaces or to the Client's INET address for INET interfaces. The 2530 ROR then includes the lower 32 bits of the Proxy/Server's ADM-ULA as 2531 the LHS, encodes the ADM-ULA prefix length code in the SRT field and 2532 sets the FMT code accordingly as specified in Section 3.3. 2534 The ROR then sets the NA(AR) message R flag to 1 (as a router) and S 2535 flag to 1 (as a response to a solicitation). If the ROR is the 2536 Client itself, it sets the O flag to 1; if the ROR is the Proxy/ 2537 Server, it instead sets the O flag to 0 (as a proxy). The ROR 2538 finally submits the NA(AR) for OAL encapsulation with source set to 2539 its own ULA and destination set to the source ULA of the NS(AR) 2540 message, then performs OAL fragmentation using the same 2541 Identification value that appeared in the NS(AR) and securely 2542 forwards the resulting (*NET-encapsulated) carrier packets without 2543 decrementing the network-layer TTL/Hop Limit field. (When the ROR is 2544 an INET Client, it includes an authentication signature to be 2545 verified by its Proxy/Server; when the ROR is a Proxy/Server, it 2546 forwards the carrier packets over the secured spanning tree to a 2547 Bridge.) 2549 3.14.4. Relaying the NA(AR) 2551 When the Bridge receives the carrier packets from the ROR, it 2552 discards the *NET header and determines the next hop by consulting 2553 its standard IPv6 forwarding table for the OAL header destination 2554 address. The Bridge then decrements the OAL header Hop-Limit, re- 2555 encapsulates the carrier packet and forwards it via the spanning tree 2556 the same as for any IPv6 router, where it may traverse multiple OMNI 2557 link segments. The final-hop Bridge in the spanning tree will 2558 deliver the carrier packet via a secured tunnel to a Proxy/Server for 2559 the ROS. 2561 3.14.5. Processing the NA(AR) 2563 When the ROS receives the NA(AR) message, it first searches for a 2564 neighbor cache entry that matches the NA(AR) target address. If 2565 there is an entry in the INCOMPLETE or STALE state, the ROS matches 2566 the OAL Identification value with the value it had included in the 2567 corresponding NS(AR). If the values match, the ROS processes the 2568 message the same as for standard IPv6 Address Resolution [RFC4861]. 2569 In the process, it caches the target LLA and all information found in 2570 the OMNI option in the neighbor cache entry for the target. The ROS 2571 finally sets the neighbor cache entry state to REACHABLE and sets its 2572 lifetime to ReachableTime seconds. (When the ROS is a Client, the 2573 solicited NA(AR) message will first be delivered via the spanning 2574 tree to one of its current Proxy/Servers, which then securely 2575 forwards the message to the Client. If the Client is on an ANET, 2576 ANET physical security and protected spectrum ensures security; if 2577 the Client is on the open ANET, the Proxy/Server must include an 2578 authentication signature.) 2580 3.14.6. Route Optimization Maintenance 2582 Following route optimization, the ROS forwards future carrier packets 2583 with user data destined to the target via the addresses found in the 2584 cached link-layer information and with a monotonically-incrementing 2585 Identification value for each OAL packet. The route optimization is 2586 shared by all sources that send original IP packets to the target via 2587 the ROS, i.e., and not just the source on behalf of which the route 2588 optimization was initiated. Note that route optimization is 2589 performed only for original IP packets that contain user data, and 2590 not for those that contain other IPv6 ND control messages. 2592 While the ROS continues to forward additional original IP packets 2593 destined to the target, it sends additional NS(AR) messages to the 2594 ROR before ReachableTime expires to receive a fresh NA(AR) message 2595 the same as described in the previous sections (route optimization 2596 refreshment strategies are an implementation matter, with a non- 2597 normative example given in Appendix A.1). The ROS may supply a new 2598 unpredictable OAL Identification value if it wishes to reset the 2599 neighbor's "accept" Identification window. If the ROS is an INET 2600 Client, it must sign the NS(AR) message so that the Proxy/Server can 2601 authenticate. 2603 The ROS uses the cached ULA of the ROR (i.e., either the ADM-ULA of 2604 the Proxy/Server or the MNP-ULA of the Client itself) as the NS(AR) 2605 OAL destination address, and sends up to MAX_MULTICAST_SOLICIT NS(AR) 2606 messages separated by 1 second until an NA(AR) is received. If no 2607 NA(AR) is received, the ROS assumes that the current ROR has become 2608 unreachable and deletes the target neighbor cache entry. Subsequent 2609 original IP packets will trigger a new route optimization event (see: 2610 Section 3.14.1). 2612 If an NA(AR) is received, the ROS then updates the neighbor cache 2613 entry to refresh ReachableTime, while (for MNP destinations) the ROR 2614 adds or updates the ROS address to the target's Report List and with 2615 time set to ReportTime. While no carrier packets are flowing, the 2616 ROS instead allows ReachableTime for the neighbor cache entry to 2617 expire. When ReachableTime expires, the ROS deletes the neighbor 2618 cache entry. Any future carrier packets flowing through the ROS will 2619 again trigger a new route optimization. 2621 The ROS may also receive unsolicited NA messages from the ROR at any 2622 time (see: Section 3.16). If there is a neighbor cache entry for the 2623 target and the carrier packet(s) containing the unsolicited NA 2624 include an Identification value within the current "send" window, the 2625 ROS updates the link-layer information but does not update 2626 ReachableTime since the receipt of an unsolicited NA does not confirm 2627 that any forward paths are working. If there is no neighbor cache 2628 entry or the identification value is outside the window, the ROS 2629 simply discards the unsolicited NA. 2631 In this arrangement, the ROS holds a neighbor cache entry with only a 2632 "send" Identification window value for the target, while the ROR 2633 holds a neighbor cache entry with only an "accept" Identification 2634 window value for the ROS. The route optimization neighbor 2635 relationship is therefore asymmetric and unidirectional. If the 2636 target node also has carrier packets to send back to the source node, 2637 then a separate route optimization procedure is performed in the 2638 reverse direction. But, there is no requirement that the forward and 2639 reverse paths be symmetric. 2641 3.15. Neighbor Unreachability Detection (NUD) 2643 AERO nodes perform Neighbor Unreachability Detection (NUD) per 2644 [RFC4861] either reactively in response to persistent link-layer 2645 errors (see Section 3.11) or proactively to confirm reachability and/ 2646 or establish NAT state. The NUD algorithm is based on periodic 2647 control message exchanges. The algorithm may further be seeded by ND 2648 hints of forward progress, but care must be taken to avoid inferring 2649 reachability based on spoofed information. For example, authentic 2650 IPv6 ND message exchanges may be considered as acceptable hints of 2651 forward progress, while spurious random packets should not be. 2653 AERO nodes can use standard NS/NA(NUD) exchanges sent over the OMNI 2654 link spanning tree to securely test reachability without risk of DoS 2655 attacks from nodes pretending to be a neighbor. These NS/NA(NUD) 2656 messages use the unicast LLAs and ULAs of the two parties involved in 2657 the NUD test the same as for standard IPv6 ND over the secured 2658 spanning tree, however a means for an ROS to test the unsecured 2659 target route optimized paths is also necessary. 2661 When an ROR directs an ROS to a target neighbor with one or more 2662 link-layer addresses, the ROS can proactively test each such 2663 unsecured route optimized path through secured NS(NUD) messages over 2664 the spanning tree that invoke an unsecured NA(NUD) reply that travels 2665 over the route optimized path. (The NS(NUD) messages must therefore 2666 include Identification values (and optionally Nonce and Timestamp 2667 options) that will be echoed in the unsecured NA(NUD) replies.) 2668 While testing the paths, the ROS can optionally continue to send 2669 carrier packets via the spanning tree, maintain a small queue of 2670 carrier packets until target reachability is confirmed, or 2671 (optimistically) allow carrier packets to flow via the route 2672 optimized paths. 2674 When the ROS sends an NS(NUD) message, it sets the IPv6 source to its 2675 own LLA, sets the destination to the LLA of the ROR, and sets the LLA 2676 corresponding to the target as the Target Address. The ROS also 2677 includes an OMNI option with a single Interface Attributes sub-option 2678 with the SRT, FMT, LHS and L2ADDR information for its own underlying 2679 interface it wishes to test, but sets the S/T-ifIndex field to the 2680 index for target's underlying interface to be tested. The ROS 2681 includes an Identification value with the current "send" window (and 2682 optionally Nonce and Timestamp options), then encapsulates the 2683 message in OAL/INET headers with its own ULA as the source and the 2684 ULA of the ROR as the destination. The ROS then forwards the NS(NUD) 2685 message toward the target via a Proxy/Server or Bridge. 2687 When the ROR receives the NS(NUD) message, it creates an NA(NUD) by 2688 reversing the OAL and IPv6 addresses and including an Interface 2689 Attributes sub-option with attributes for its own interface 2690 identified by the NS(NUD) S/T-ifIndex. The target sets the NA(NUD) 2691 S/T-ifIndex to the index of the ROS, sets the Target Address to the 2692 same value that was in the NS(NUD), and returns the message using its 2693 own underlying interface identified by S/T-ifIndex and destined to 2694 the ROS's interface identified by the original Interface Attributes 2695 sub-option. 2697 When the ROS receives the NA(NUD) message, it can determine from the 2698 Identification value and Target Address (and optionally the Nonce and 2699 Timestamp) that the message matched its NS(NUD) and that it transited 2700 the direct path from the ROR using the selected underlying interface 2701 pair. The ROS marks route optimization target paths that pass these 2702 NUD tests as "reachable", and those that do not as "unreachable". 2703 These markings inform the OMNI interface forwarding algorithm 2704 specified in Section 3.10. 2706 Note: If the target determines that the OMNI option Interface 2707 Attributes in the NS(NUD) is located in a different OMNI link segment 2708 than its own interface named in the S/T-ifIndex, it instead returns 2709 the NA(NUD) via the spanning tree while including an ORH and setting 2710 the OAL destination address to the Subnet Router Anycast address used 2711 by Bridges on the ROS segment. When a Bridge on the ROS segment 2712 receives the NA(NUD), it replaces the Interface Attributes with 2713 information for its own interface while using the ifIndex value 2714 specific to the target. 2716 3.16. Mobility Management and Quality of Service (QoS) 2718 AERO is a Distributed Mobility Management (DMM) service. Each Proxy/ 2719 Server is responsible for only a subset of the Clients on the OMNI 2720 link, as opposed to a Centralized Mobility Management (CMM) service 2721 where there is a single network mobility collective entity for all 2722 Clients. Clients coordinate with their associated Proxy/Servers via 2723 RS/RA exchanges to maintain the DMM profile, and the AERO routing 2724 system tracks all current Client/Proxy/Server peering relationships. 2726 Proxy/Servers provide default routing and mobility/multilink services 2727 for their dependent Clients. Clients are responsible for maintaining 2728 neighbor relationships with their Proxy/Servers through periodic RS/ 2729 RA exchanges, which also serves to confirm neighbor reachability. 2730 When a Client's underlying interface address and/or QoS information 2731 changes, the Client is responsible for updating the Proxy/Server with 2732 this new information. Note that when there is a Proxy/Server in the 2733 path, the Proxy function can also perform some RS/RA exchanges on the 2734 Client's behalf. 2736 Mobility management messaging is based on the transmission and 2737 reception of unsolicited Neighbor Advertisement (uNA) messages. Each 2738 uNA message sets the IPv6 destination address to (link-local) All- 2739 Nodes multicast to convey a general update of Interface Attributes to 2740 (possibly) multiple recipients, or to a specific unicast LLA to 2741 announce a departure event to a specific recipient. Implementations 2742 must therefore examine the destination address to determine the 2743 nature of the mobility event (i.e., update vs departure). 2745 Mobility management considerations are specified in the following 2746 sections. 2748 3.16.1. Mobility Update Messaging 2750 RORs accommodate Client mobility, multilink and/or QoS change events 2751 by sending unsolicited NA (uNA) messages to each ROS in the target 2752 Client's Report List. When an ROR sends a uNA message, it sets the 2753 IPv6 source address to the its own LLA, sets the destination address 2754 to (link-local) All-Nodes multicast and sets the Target Address to 2755 the Client's MNP-LLA. The ROR also includes an OMNI option with 2756 Prefix Length set to the length associated with the Client's MNP-LLA, 2757 with Interface Attributes for the target Client's underlying 2758 interfaces and with the OMNI header S/T-ifIndex set to 0. The ROR 2759 then sets the NA R flag to 1, the S flag to 0 and the O flag to 1, 2760 then encapsulates the message in an OAL header with source set to its 2761 own ULA and destination set to the ULA of the ROS and sends the 2762 message into the spanning tree. 2764 As discussed in Section 7.2.6 of [RFC4861], the transmission and 2765 reception of uNA messages is unreliable but provides a useful 2766 optimization. In well-connected Internetworks with robust data links 2767 uNA messages will be delivered with high probability, but in any case 2768 the Proxy/Server can optionally send up to MAX_NEIGHBOR_ADVERTISEMENT 2769 uNAs to each ROS to increase the likelihood that at least one will be 2770 received. 2772 When the ROS receives a uNA message prepared as above, it ignores the 2773 message if there is no existing neighbor cache entry for the target 2774 Client. Otherwise, it uses the included OMNI option information to 2775 update the neighbor cache entry, but does not reset ReachableTime 2776 since the receipt of an unsolicited NA message from the ROR does not 2777 provide confirmation that any forward paths to the target Client are 2778 working. 2780 If uNA messages are lost, the ROS may be left with stale address and/ 2781 or QoS information for the Client for up to ReachableTime seconds. 2782 During this time, the ROS can continue sending carrier packets 2783 according to its stale neighbor cache information. When 2784 ReachableTime is close to expiring, the ROS will re-initiate route 2785 optimization and receive fresh link-layer address information. 2787 In addition to sending uNA messages to the current set of ROSs for 2788 the Client, the ROR also sends uNAs to the MNP-ULA associated with 2789 the link-layer address for any underlying interface for which the 2790 link-layer address has changed. These uNA messages update an old 2791 Proxy/Server that cannot easily detect (e.g., without active probing) 2792 when a formerly-active Client has departed. When the ROR sends the 2793 uNA, it sets the IPv6 source address to its LLA, sets the destination 2794 address to the old Proxy/Server's ADM-LLA, and sets the Target 2795 Address to the Client's MNP-LLA. The ROR also includes an OMNI 2796 option with Prefix Length set to the length associated with the 2797 Client's MNP-LLA, with Interface Attributes for the changed 2798 underlying interface, and with the OMNI header S/T-ifIndex set to its 2799 own omIndex if the ROR is a Client or 0 if the ROR is a Proxy/Server. 2800 The ROR then sets the NA R flag to 1, the S flag to 0 and the O flag 2801 to 1, then encapsulates the message in an OAL header with source set 2802 to its own ULA and destination set to the ADM-ULA of the old Proxy/ 2803 Server and sends the message into the spanning tree. 2805 3.16.2. Announcing Link-Layer Address and/or QoS Preference Changes 2807 When a Client needs to change its underlying interface addresses and/ 2808 or QoS preferences (e.g., due to a mobility event), the Client 2809 requests one of its Proxy/Servers to send RS messages to all of its 2810 other Proxy/Servers via the spanning tree with an OMNI option that 2811 includes Interface attributes with the new link quality and address 2812 information. 2814 Up to MAX_RTR_SOLICITATIONS RS messages MAY be sent in parallel with 2815 sending carrier packets containing user data in case one or more RAs 2816 are lost. If all RAs are lost, the Client SHOULD re-associate with a 2817 new Proxy/Server. 2819 When the Proxy/Server receives the Client's changes, it sends uNA 2820 messages to all nodes in the Report List the same as described in the 2821 previous section. 2823 3.16.3. Bringing New Links Into Service 2825 When a Client needs to bring new underlying interfaces into service 2826 (e.g., when it activates a new data link), it sends an RS message to 2827 the Proxy/Server via the underlying interface with an OMNI option 2828 that includes Interface Attributes with appropriate link quality 2829 values and with link-layer address information for the new link. 2831 3.16.4. Deactivating Existing Links 2833 When a Client needs to deactivate an existing underlying interface, 2834 it sends an RS or uNA message to its Proxy/Server with an OMNI option 2835 with appropriate Interface Attribute values - in particular, the link 2836 quality value 0 assures that neighbors will cease to use the link. 2838 If the Client needs to send RS/uNA messages over an underlying 2839 interface other than the one being deactivated, it MUST include 2840 Interface Attributes with appropriate link quality values for any 2841 underlying interfaces being deactivated. 2843 Note that when a Client deactivates an underlying interface, 2844 neighbors that have received the RS/uNA messages need not purge all 2845 references for the underlying interface from their neighbor cache 2846 entries. The Client may reactivate or reuse the underlying interface 2847 and/or its ifIndex at a later point in time, when it will send RS/uNA 2848 messages with fresh Interface Attributes to update any neighbors. 2850 3.16.5. Moving Between Proxy/Servers 2852 The Client performs the procedures specified in Section 3.12.2 when 2853 it first associates with a new Proxy/Server or renews its association 2854 with an existing Proxy/Server. The Client also includes MS-Release 2855 identifiers in the RS message OMNI option per 2856 [I-D.templin-6man-omni-interface] if it wants the new Proxy/Server to 2857 notify any old Proxy/Servers from which the Client is departing. 2859 When the new Proxy/Server receives the Client's RS message, it 2860 returns an RA as specified in Section 3.12.3 and sends up to 2861 MAX_NEIGHBOR_ADVERTIISEMENT uNA messages to any old Proxy/Servers 2862 listed in OMNI option MS-Release identifiers. When the new Proxy/ 2863 Server sends a uNA message, it sets the IPv6 source address to the 2864 Client's MNP-LLA, sets the destination address to the old Proxy/ 2865 Server's ADM-LLA, and sets the Target Address to the Client's LLA. 2866 The new Proxy/Server also includes an OMNI option with Prefix Length 2867 set to the length associated with the Client's MNP-LLA, with 2868 Interface Attributes for its own underlying interface, and with the 2869 OMNI header S/T-ifIndex set to 0. The new Proxy/Server then sets the 2870 NA R flag to 1, the S flag to 0 and the O flag to 1, then 2871 encapsulates the message in an OAL header with source set to its own 2872 ADM-ULA and destination set to the ADM-ULA of the old Proxy/Server 2873 and sends the message into the spanning tree. 2875 When an old Proxy/Server receives the uNA, it changes the Client's 2876 neighbor cache entry state to DEPARTED, sets the link-layer address 2877 of the Client to the new Proxy/Server's ADM-ULA, and resets 2878 DepartTime. After a short delay (e.g., 2 seconds) the old Proxy/ 2879 Server withdraws the Client's MNP from the routing system. After 2880 DepartTime expires, the old Proxy/Server deletes the Client's 2881 neighbor cache entry. 2883 The old Proxy/Server also iteratively forwards a copy of the uNA 2884 message to each ROS in the Client's Report List by changing the OAL 2885 destination address to the ULA of the ROS while leaving all other 2886 fields of the message unmodified. When the ROS receives the uNA, it 2887 examines the Target address to determine the correct neighbor cache 2888 entry and verifies that the IPv6 destination address matches the old 2889 Proxy/Server. The ROS then caches the IPv6 source address as the new 2890 Proxy/Server for the existing neighbor cache entry and marks the 2891 entry as STALE. While in the STALE state, the ROS allows new carrier 2892 packets to flow according to any existing cached link-layer 2893 information and sends new NS(AR) messages using its own ULA as the 2894 OAL source and the ADM-ULA of the new Proxy/Server as the OAL 2895 destination address to elicit NA messages that reset the neighbor 2896 cache entry state to REACHABLE. If no new NA message is received for 2897 10 seconds while in the STALE state, the ROS deletes the neighbor 2898 cache entry. 2900 Clients SHOULD NOT move rapidly between Proxy/Servers in order to 2901 avoid causing excessive oscillations in the AERO routing system. 2902 Examples of when a Client might wish to change to a different Proxy/ 2903 Server include a Proxy/Server that has gone unreachable, topological 2904 movements of significant distance, movement to a new geographic 2905 region, movement to a new OMNI link segment, etc. 2907 When a Client moves to a new Proxy/Server, some of the fragments of a 2908 multiple fragment OAL packet may have already arrived at the old 2909 Proxy/Server while others are en route to the new Proxy/Server, 2910 however no special attention in the reassembly algorithm is necessary 2911 since all fragments will eventually be delivered to the Client which 2912 can then reassemble. 2914 3.17. Multicast 2916 The AERO Client provides an IGMP (IPv4) [RFC2236] or MLD (IPv6) 2917 [RFC3810] proxy service for its EUNs and/or hosted applications 2918 [RFC4605]. The Client forwards IGMP/MLD messages over any of its 2919 underlying interfaces for which group membership is required. The 2920 IGMP/MLD messages may be further forwarded by a first-hop ANET access 2921 router acting as an IGMP/MLD-snooping switch [RFC4541], then 2922 ultimately delivered to an AERO Proxy/Server acting as a Protocol 2923 Independent Multicast - Sparse-Mode (PIM-SM, or simply "PIM") 2924 Designated Router (DR) [RFC7761]. AERO Relays also act as PIM 2925 routers (i.e., the same as AERO Proxys/Servers) on behalf of nodes on 2926 INET/EUN networks. The behaviors identified in the following 2927 sections correspond to Source-Specific Multicast (SSM) and Any-Source 2928 Multicast (ASM) operational modes. 2930 3.17.1. Source-Specific Multicast (SSM) 2932 When an ROS (i.e., an AERO Proxy/Server/Relay) "X" acting as PIM 2933 router receives a Join/Prune message from a node on its downstream 2934 interfaces containing one or more ((S)ource, (G)roup) pairs, it 2935 updates its Multicast Routing Information Base (MRIB) accordingly. 2936 For each S belonging to a prefix reachable via X's non-OMNI 2937 interfaces, X then forwards the (S, G) Join/Prune to any PIM routers 2938 on those interfaces per [RFC7761]. 2940 For each S belonging to a prefix reachable via X's OMNI interface, X 2941 originates a separate copy of the Join/Prune for each (S,G) in the 2942 message using its own LLA as the source address and ALL-PIM-ROUTERS 2943 as the destination address. X then encapsulates each message in an 2944 OAL header with source address set to the ULA of X and destination 2945 address set to S then forwards the message into the spanning tree, 2946 which delivers it to AERO Proxy/Server/Relay "Y" that services S. At 2947 the same time, if the message was a Join, X sends a route- 2948 optimization NS message toward each S the same as discussed in 2949 Section 3.14. The resulting NAs will return the LLA for the prefix 2950 that matches S as the network-layer source address and with an OMNI 2951 option with the ULA corresponding to any underlying interfaces that 2952 are currently servicing S. 2954 When Y processes the Join/Prune message, if S located behind any 2955 INET, Direct, or VPNed interfaces Y acts as a PIM router and updates 2956 its MRIB to list X as the next hop in the reverse path. If S is 2957 located behind any Proxys "Z"*, Y also forwards the message to each 2958 Z* over the spanning tree while continuing to use the LLA of X as the 2959 source address. Each Z* then updates its MRIB accordingly and 2960 maintains the LLA of X as the next hop in the reverse path. Since 2961 the Bridges do not examine network layer control messages, this means 2962 that the (reverse) multicast tree path is simply from each Z* (and/or 2963 Y) to X with no other multicast-aware routers in the path. If any Z* 2964 (and/or Y) is located on the same OMNI link segment as X, the 2965 multicast data traffic sent to X directly using OAL/INET 2966 encapsulation instead of via a Bridge. 2968 Following the initial Join/Prune and NS/NA messaging, X maintains a 2969 neighbor cache entry for each S the same as if X was sending unicast 2970 data traffic to S. In particular, X performs additional NS/NA 2971 exchanges to keep the neighbor cache entry alive for up to t_periodic 2972 seconds [RFC7761]. If no new Joins are received within t_periodic 2973 seconds, X allows the neighbor cache entry to expire. Finally, if X 2974 receives any additional Join/Prune messages for (S,G) it forwards the 2975 messages to each Y and Z* in the neighbor cache entry over the 2976 spanning tree. 2978 At some later time, Client C that holds an MNP for source S may 2979 depart from a first Proxy/Server Z1 and/or connect via a new Proxy/ 2980 Server Z2. In that case, Y sends an unsolicited NA message to X the 2981 same as specified for unicast mobility in Section 3.16. When X 2982 receives the unsolicited NA message, it updates its neighbor cache 2983 entry for the LLA for source S and sends new Join messages to any new 2984 Proxys Z2. There is no requirement to send any Prune messages to old 2985 Proxy/Server Z1 since source S will no longer source any multicast 2986 data traffic via Z1. Instead, the multicast state for (S,G) in 2987 Proxy/Server Z1 will soon time out since no new Joins will arrive. 2989 After some later time, C may move to a new Proxy/Server Y2 and depart 2990 from old Sever Y1. In that case, Y1 sends Join messages for any of 2991 C's active (S,G) groups to Y2 while including its own LLA as the 2992 source address. This causes Y2 to include Y1 in the multicast 2993 forwarding tree during the interim time that Y1's neighbor cache 2994 entry for C is in the DEPARTED state. At the same time, Y1 sends an 2995 unsolicited NA message to X with an OMNI option with S/T-ifIndex in 2996 the header set to 0 and a release indication to cause X to release 2997 its neighbor cache entry. X then sends a new Join message to S via 2998 the spanning tree and re-initiates route optimization the same as if 2999 it were receiving a fresh Join message from a node on a downstream 3000 link. 3002 3.17.2. Any-Source Multicast (ASM) 3004 When an ROS X acting as a PIM router receives a Join/Prune from a 3005 node on its downstream interfaces containing one or more (*,G) pairs, 3006 it updates its Multicast Routing Information Base (MRIB) accordingly. 3007 X then forwards a copy of the message to the Rendezvous Point (RP) R 3008 for each G over the spanning tree. X uses its own LLA as the source 3009 address and ALL-PIM-ROUTERS as the destination address, then 3010 encapsulates each message in an OAL header with source address set to 3011 the ULA of X and destination address set to R, then sends the message 3012 into the spanning tree. At the same time, if the message was a Join 3013 X initiates NS/NA route optimization the same as for the SSM case 3014 discussed in Section 3.17.1. 3016 For each source S that sends multicast traffic to group G via R, the 3017 Proxy/Server Z* for the Client that aggregates S encapsulates the 3018 original IP packets in PIM Register messages and forwards them to R 3019 via the spanning tree, which may then elect to send a PIM Join to Z*. 3020 This will result in an (S,G) tree rooted at Z* with R as the next hop 3021 so that R will begin to receive two copies of the original IP packet; 3022 one native copy from the (S, G) tree and a second copy from the pre- 3023 existing (*, G) tree that still uses PIM Register encapsulation. R 3024 can then issue a PIM Register-stop message to suppress the Register- 3025 encapsulated stream. At some later time, if C moves to a new Proxy/ 3026 Server Z*, it resumes sending original IP packets via PIM Register 3027 encapsulation via the new Z*. 3029 At the same time, as multicast listeners discover individual S's for 3030 a given G, they can initiate an (S,G) Join for each S under the same 3031 procedures discussed in Section 3.17.1. Once the (S,G) tree is 3032 established, the listeners can send (S, G) Prune messages to R so 3033 that multicast original IP packets for group G sourced by S will only 3034 be delivered via the (S, G) tree and not from the (*, G) tree rooted 3035 at R. All mobility considerations discussed for SSM apply. 3037 3.17.3. Bi-Directional PIM (BIDIR-PIM) 3039 Bi-Directional PIM (BIDIR-PIM) [RFC5015] provides an alternate 3040 approach to ASM that treats the Rendezvous Point (RP) as a Designated 3041 Forwarder (DF). Further considerations for BIDIR-PIM are out of 3042 scope. 3044 3.18. Operation over Multiple OMNI Links 3046 An AERO Client can connect to multiple OMNI links the same as for any 3047 data link service. In that case, the Client maintains a distinct 3048 OMNI interface for each link, e.g., 'omni0' for the first link, 3049 'omni1' for the second, 'omni2' for the third, etc. Each OMNI link 3050 would include its own distinct set of Bridges and Proxy/Servers, 3051 thereby providing redundancy in case of failures. 3053 Each OMNI link could utilize the same or different ANET connections. 3054 The links can be distinguished at the link-layer via the SRT prefix 3055 in a similar fashion as for Virtual Local Area Network (VLAN) tagging 3056 (e.g., IEEE 802.1Q) and/or through assignment of distinct sets of 3057 MSPs on each link. This gives rise to the opportunity for supporting 3058 multiple redundant networked paths, with each VLAN distinguished by a 3059 different SRT "color" (see: Section 3.2.5). 3061 The Client's IP layer can select the outgoing OMNI interface 3062 appropriate for a given traffic profile while (in the reverse 3063 direction) correspondent nodes must have some way of steering their 3064 original IP packets destined to a target via the correct OMNI link. 3066 In a first alternative, if each OMNI link services different MSPs, 3067 then the Client can receive a distinct MNP from each of the links. 3068 IP routing will therefore assure that the correct OMNI link is used 3069 for both outbound and inbound traffic. This can be accomplished 3070 using existing technologies and approaches, and without requiring any 3071 special supporting code in correspondent nodes or Bridges. 3073 In a second alternative, if each OMNI link services the same MSP(s) 3074 then each link could assign a distinct "OMNI link Anycast" address 3075 that is configured by all Bridges on the link. Correspondent nodes 3076 can then perform Segment Routing to select the correct SRT, which 3077 will then direct the original IP packet over multiple hops to the 3078 target. 3080 3.19. DNS Considerations 3082 AERO Client MNs and INET correspondent nodes consult the Domain Name 3083 System (DNS) the same as for any Internetworking node. When 3084 correspondent nodes and Client MNs use different IP protocol versions 3085 (e.g., IPv4 correspondents and IPv6 MNs), the INET DNS must maintain 3086 A records for IPv4 address mappings to MNs which must then be 3087 populated in Relay NAT64 mapping caches. In that way, an IPv4 3088 correspondent node can send original IPv4 packets to the IPv4 address 3089 mapping of the target MN, and the Relay will translate the IPv4 3090 header and destination address into an IPv6 header and IPv6 3091 destination address of the MN. 3093 When an AERO Client registers with an AERO Proxy/Server, the Proxy/ 3094 Server can return the address(es) of DNS servers in RDNSS options 3095 [RFC6106]. The DNS server provides the IP addresses of other MNs and 3096 correspondent nodes in AAAA records for IPv6 or A records for IPv4. 3098 3.20. Transition/Coexistence Considerations 3100 OAL encapsulation ensures that dissimilar INET partitions can be 3101 joined into a single unified OMNI link, even though the partitions 3102 themselves may have differing protocol versions and/or incompatible 3103 addressing plans. However, a commonality can be achieved by 3104 incrementally distributing globally routable (i.e., native) IP 3105 prefixes to eventually reach all nodes (both mobile and fixed) in all 3106 OMNI link segments. This can be accomplished by incrementally 3107 deploying AERO Bridges on each INET partition, with each Bridge 3108 distributing its MNPs and/or discovering non-MNP IP GUA prefixes on 3109 its INET links. 3111 This gives rise to the opportunity to eventually distribute native IP 3112 addresses to all nodes, and to present a unified OMNI link view even 3113 if the INET partitions remain in their current protocol and 3114 addressing plans. In that way, the OMNI link can serve the dual 3115 purpose of providing a mobility/multilink service and a transition/ 3116 coexistence service. Or, if an INET partition is transitioned to a 3117 native IP protocol version and addressing scheme that is compatible 3118 with the OMNI link MNP-based addressing scheme, the partition and 3119 OMNI link can be joined by Bridges. 3121 Relays that connect INETs/EUNs with dissimilar IP protocol versions 3122 may need to employ a network address and protocol translation 3123 function such as NAT64 [RFC6146]. 3125 3.21. Detecting and Reacting to Server and Bridge Failures 3127 In environments where rapid failure recovery is required, Proxy/ 3128 Servers and Bridges SHOULD use Bidirectional Forwarding Detection 3129 (BFD) [RFC5880]. Nodes that use BFD can quickly detect and react to 3130 failures so that cached information is re-established through 3131 alternate nodes. BFD control messaging is carried only over well- 3132 connected ground domain networks (i.e., and not low-end radio links) 3133 and can therefore be tuned for rapid response. 3135 Proxy/Servers and Bridges maintain BFD sessions in parallel with 3136 their BGP peerings. If a Proxy/Server or Bridge fails, BGP peers 3137 will quickly re-establish routes through alternate paths the same as 3138 for common BGP deployments. Similarly, Proxys maintain BFD sessions 3139 with their associated Bridges even though they do not establish BGP 3140 peerings with them. 3142 Proxys SHOULD use proactive NUD for Proxy/Servers for which there are 3143 currently active ANET Clients in a manner that parallels BFD, i.e., 3144 by sending unicast NS messages in rapid succession to receive 3145 solicited NA messages. When the Proxy is also sending RS messages on 3146 behalf of ANET Clients, the RS/RA messaging can be considered as 3147 equivalent hints of forward progress. This means that the Proxy need 3148 not also send a periodic NS if it has already sent an RS within the 3149 same period. If a Proxy/Server fails, the Proxy will cease to 3150 receive advertisements and can quickly inform Clients of the outage 3151 by sending multicast RA messages on the ANET interface. 3153 The Proxy sends multicast RA messages with source address set to the 3154 Proxy/Server's address, destination address set to (link-local) All- 3155 Nodes multicast, and Router Lifetime set to 0. The Proxy SHOULD send 3156 MAX_FINAL_RTR_ADVERTISEMENTS RA messages separated by small delays 3157 [RFC4861]. Any Clients on the ANET interface that have been using 3158 the (now defunct) Proxy/Server will receive the RA messages and 3159 associate with a new Proxy/Server. 3161 3.22. AERO Clients on the Open Internet 3163 AERO Clients that connect to the open Internet via INET interfaces 3164 can establish a VPN or direct link to securely connect to a Proxy/ 3165 Server in a "tethered" arrangement with all of the Client's traffic 3166 transiting the Proxy/Server. Alternatively, the Client can associate 3167 with an INET Proxy/Server using UDP/IP encapsulation and control 3168 message securing services as discussed in the following sections. 3170 When a Client's OMNI interface enables an INET underlying interface, 3171 it first determines whether the interface is likely to be behind a 3172 NAT. For IPv4, the Client assumes it is on the open Internet if the 3173 INET address is not a special-use IPv4 address per [RFC3330]. 3174 Similarly for IPv6, the Client assumes it is on the open Internet if 3175 the INET address is a Global Unicast Address (GUA) [RFC4291]. 3176 Otherwise, the Client assumes it may be behind one or several NATs. 3178 The Client then prepares an RS message with IPv6 source address set 3179 to its MNP-LLA, with IPv6 destination set to (link-local) All-Routers 3180 multicast and with an OMNI option with underlying interface 3181 attributes. If the Client believes that it is on the open Internet, 3182 it SHOULD include an L2ADDR in the Interface Attributes sub-option 3183 corresponding to the underlying interface; otherwise, it MAY omit 3184 L2ADDR. If the underlying address is IPv4, the Client includes the 3185 Port Number and IPv4 address written in obfuscated form [RFC4380] as 3186 discussed in Section 3.3. If the underlying interface address is 3187 IPv6, the Client instead includes the Port Number and IPv6 address in 3188 obfuscated form. The Client finally includes an authentication 3189 signature sub-option in the OMNI option 3190 [I-D.templin-6man-omni-interface] to provide message authentication 3191 and submits the RS for OAL encapsulation as an OAL atomic fragment 3192 using an unpredictable Identification value to establish the start of 3193 the "send" window for this Proxy/Server. The Client then 3194 encapsulates the OAL fragment in UDP/IP headers to form a carrier 3195 packet, sets the UDP/IP source to its INET address and UDP port, sets 3196 the UDP/IP destination to the Proxy/Server's INET address and the 3197 AERO service port number (8060), then sends the carrier packet to the 3198 Proxy/Server. 3200 When the Proxy/Server receives the RS, it discards the OAL 3201 encapsulation, authenticates the RS message, creates a neighbor cache 3202 entry and registers the Client's MNP, Identification and INET 3203 interface information according to the OMNI option parameters. If 3204 the RS message OMNI option includes Interface Attributes with an 3205 L2ADDR, the Proxy/Server compares the encapsulation IP address and 3206 UDP port number with the (unobfuscated) values. If the values are 3207 the same, the Proxy/Server caches the Client's information as "INET" 3208 addresses meaning that the Client is likely to accept direct messages 3209 without requiring NAT traversal exchanges. If the values are 3210 different (or, if the OMNI option did not include an L2ADDR) the 3211 Proxy/Server instead caches the Client's information as "mapped" 3212 addresses meaning that NAT traversal exchanges may be necessary. 3214 The Proxy/Server then prepares an RA message with IPv6 source and 3215 destination set corresponding to the addresses in the RS, and with an 3216 OMNI option with an Origin Indication sub-option per 3217 [I-D.templin-6man-omni-interface] with the mapped and obfuscated Port 3218 Number and IP address observed in the encapsulation headers. The 3219 Proxy/Server also includes an authentication signature sub-option per 3220 [I-D.templin-6man-omni-interface] that contains an acknowledgement of 3221 the update sent by the Client. The Proxy/Server then performs OAL 3222 encapsulation and fragmentation if necessary using the same 3223 Identification value that appeared in the RS, and encapsulates each 3224 fragment in UDP/IP headers with addresses set per the L2ADDR 3225 information in the neighbor cache entry for the Client. 3227 When the Client receives the RA message, it verifies the OAL 3228 Identification value, performs OAL reassembly if necessary, 3229 authenticates the message, then compares the mapped Port Number and 3230 IP address from the Origin Indication sub-option with its own 3231 address. If the addresses are the same, the Client assumes the open 3232 Internet / Cone NAT principle; if the addresses are different, the 3233 Client instead assumes that further qualification procedures are 3234 necessary to detect the type of NAT and proceeds according to 3235 standard procedures [RFC6081][RFC4380]. 3237 After the Client has registered its INET interfaces in such RS/RA 3238 exchanges it sends periodic RS messages to receive fresh RA messages 3239 before the Router Lifetime received on each INET interface expires. 3240 The Client also maintains default routes via its Proxy/Servers, i.e., 3241 the same as described in earlier sections. 3243 When the Client sends messages to target IP addresses, it also 3244 invokes route optimization per Section 3.14 using IPv6 ND address 3245 resolution messaging. The Client first creates a neighbor cache 3246 entry for the target in the INCOMPLETE state, then sends the NS(AR) 3247 message to the Proxy/Server with an OMNI option with an 3248 authentication signature sub-option. The Client sets the NS source 3249 address to its own MNP-LLA, destination address to the target 3250 solicited node multicast address and target address to the LLA of the 3251 target. The Client then wraps the NS message in OAL headers (i.e., 3252 as an atomic OAL fragment) with an unpredictable Identification value 3253 to establish the "send" window for this target, with source address 3254 set to its own MNP-ULA and destination address set to the target's 3255 MNP-ULA. The Client then wraps the atomic OAL fragment in a UDP/IP 3256 header and sends the resulting carrier packet to the Proxy/Server. 3258 When the Client's Proxy/Server receives the OAL-encapsulated NS, it 3259 authenticates the message by processing the authentication signature 3260 sub-option and forwards the message over the spanning tree on behalf 3261 of the Client. When the ROR receives the NS(AR), it creates a 3262 neighbor cache entry for the ROS in the STALE state and caches the 3263 Identification value as the start of the "accept" window for packets 3264 originating from this ROS (if the ROR is a Proxy/Server, it also 3265 creates a Report List entry for this ROS in the target Client's 3266 neighbor cache entry). The ROR then returns an NA(AR) with OMNI 3267 option information for the target including all of the target's 3268 Interface Attributes. 3270 The ROR sets the NA(AR) source address to its own LLA, sets the 3271 destination address to the ROS LLA and sets the target address to the 3272 LLA of the target. The ROR then performs OAL encapsulation using the 3273 same Identification value that appeared in the NS(AR), then sets the 3274 OAL source address to the ROR's ULA and destination address to ULA 3275 source of the NS(AR). If the ROR is an INET Client, it includes an 3276 authentication signature and sends the NA(AR) to its Proxy/Sever 3277 which verifies the authentication signature and forwards the NA(AR) 3278 into the secured spanning tree. If the ROR is an ANET Client or a 3279 Proxy/Server, it simply forwards the NA(AR) into the secured spanning 3280 tree. 3282 When the Proxy/Sever for the ROS Client receives the NA(AR) message 3283 contained in one or more carrier packets, it verifies the OAL 3284 Identification matches the same value that was used in the NS(AR) 3285 then reassembles if necessary. When reassembly is complete, the 3286 Proxy/Server includes an authentication signature and forwards the 3287 NA(AR) to the ROS Client. The ROS Client then verifies the 3288 authentication signature and changes the neighbor cache entry state 3289 for this target to REACHABLE. 3291 Following route optimization for targets in the same OMNI link 3292 segment, if the target's L2ADDR is on the open INET, the Client 3293 forwards carrier packets directly to the target INET address. If the 3294 target is behind a NAT, the Client first establishes NAT state for 3295 the L2ADDR using the "direct bubble" and NUD mechanisms discussed in 3296 Section 3.10.1. The Client continues to send carrier packets via its 3297 Proxy/Server until NAT state is populated, then begins forwarding 3298 carrier packets via the direct path through the NAT to the target. 3299 For targets in different OMNI link segments, the Client uses OAL/ORH 3300 encapsulation and forwards carrier packets to the Bridge that 3301 returned the NA message. 3303 The ROR may return uNAs via the ROS Proxy/Server if the target moves, 3304 and the Proxy/Server will send corresponding uNAs to the Client with 3305 an OMNI authentication sub-option. The Client can also send NUD 3306 messages to test forward path reachability even though there is no 3307 security association between the Client and the target. 3309 The Client can send original IP packets to route-optimized neighbors 3310 in the same OMNI link segment no larger than the minimum/path MPS in 3311 one piece and with OAL encapsulation but without fragmentation. For 3312 larger original IP packets, the Client applies OAL encapsulation and 3313 fragmentation if necessary according to Section 3.9, with OAL header 3314 with source set to its own MNP-ULA and destination set to the MNP-ULA 3315 of the target. The Client then encapsulates each original IP packet 3316 or OAL fragment in UDP/IP *NET headers and sends them to the next 3317 hop. 3319 Note: The NAT traversal procedures specified in this document are 3320 applicable for Cone, Address-Restricted and Port-Restricted NATs 3321 only. While future updates to this document may specify procedures 3322 for other NAT variations (e.g., hairpinning and various forms of 3323 Symmetric NATs), it should be noted that continuous communications 3324 are always possible through forwarding via a Proxy/Server even if NAT 3325 traversal is not employed. 3327 3.23. Time-Varying MNPs 3329 In some use cases, it is desirable, beneficial and efficient for the 3330 Client to receive a constant MNP that travels with the Client 3331 wherever it moves. For example, this would allow air traffic 3332 controllers to easily track aircraft, etc. In other cases, however 3333 (e.g., intelligent transportation systems), the MN may be willing to 3334 sacrifice a modicum of efficiency in order to have time-varying MNPs 3335 that can be changed every so often to defeat adversarial tracking. 3337 The DHCPv6 service offers a way for Clients that desire time-varying 3338 MNPs to obtain short-lived prefixes (e.g., on the order of a small 3339 number of minutes). In that case, the identity of the Client would 3340 not be bound to the MNP but rather to a Node Identification value 3341 (see: [I-D.templin-6man-omni-interface]) to be used as the Client ID 3342 seed for MNP prefix delegation. The Client would then be obligated 3343 to renumber its internal networks whenever its MNP (and therefore 3344 also its MNP-LLA) changes. This should not present a challenge for 3345 Clients with automated network renumbering services, however presents 3346 limits for the durations of ongoing sessions that would prefer to use 3347 a constant address. 3349 4. Implementation Status 3351 An early AERO implementation based on OpenVPN (https://openvpn.net/) 3352 was announced on the v6ops mailing list on January 10, 2018 and an 3353 initial public release of the AERO proof-of-concept source code was 3354 announced on the intarea mailing list on August 21, 2015. 3356 AERO Release-3.0.2 was tagged on October 15, 2020, and is undergoing 3357 internal testing. Additional internal releases expected within the 3358 coming months, with first public release expected end of 1H2021. 3360 5. IANA Considerations 3362 The IANA is instructed to assign a new type value TBD1 in the IPv6 3363 Routing Types registry. 3365 The IANA has assigned the UDP port number "8060" for an earlier 3366 experimental first version of AERO [RFC6706]. This document 3367 obsoletes [RFC6706], and together with 3368 [I-D.templin-6man-omni-interface] reclaims the UDP port number "8060" 3369 for 'aero' as the service port for UDP/IP encapsulation. (Note that, 3370 although [RFC6706] was not widely implemented or deployed, any 3371 messages coded to that specification can be easily distinguished and 3372 ignored since they use the invalid ICMPv6 message type number '0'.) 3373 This document makes no request of IANA, since 3374 [I-D.templin-6man-omni-interface] already provides instructions. 3376 No further IANA actions are required. 3378 6. Security Considerations 3380 AERO Bridges configure secured tunnels with AERO Proxy/Servers, 3381 Relays and Proxys within their local OMNI link segments. Applicable 3382 secured tunnel alternatives include IPsec [RFC4301], TLS/SSL 3383 [RFC8446], DTLS [RFC6347], WireGuard [WG], etc. The AERO Bridges of 3384 all OMNI link segments in turn configure secured tunnels for their 3385 neighboring AERO Bridges in a spanning tree topology. Therefore, 3386 control messages exchanged between any pair of OMNI link neighbors on 3387 the spanning tree are already secured. 3389 AERO nodes acting as Route Optimization Responders (RORs) may also 3390 receive packets directly from arbitrary nodes in INET partitions 3391 instead of via the spanning tree. For INET partitions that apply 3392 effective ingress filtering to defeat source address spoofing, the 3393 simple data origin authentication procedures in Section 3.8 can be 3394 applied. 3396 For INET partitions that require strong security in the data plane, 3397 two options for securing communications include 1) disable route 3398 optimization so that all traffic is conveyed over secured tunnels, or 3399 2) enable on-demand secure tunnel creation between INET partition 3400 neighbors. Option 1) would result in longer routes than necessary 3401 and traffic concentration on critical infrastructure elements. 3402 Option 2) could be coordinated by establishing a secured tunnel on- 3403 demand instead of performing an NS/NA exchange in the route 3404 optimization procedures. Procedures for establishing on-demand 3405 secured tunnels are out of scope. 3407 AERO Clients that connect to secured ANETs need not apply security to 3408 their ND messages, since the messages will be intercepted by a 3409 perimeter Proxy that applies security on its INET-facing interface as 3410 part of the spanning tree (see above). AERO Clients connected to the 3411 open INET can use network and/or transport layer security services 3412 such as VPNs or can by some other means establish a direct link. 3413 When a VPN or direct link may be impractical, however, the 3414 authentication services specified in [RFC7401] and/or [RFC4380] 3415 should be applied. 3417 Application endpoints SHOULD use application-layer security services 3418 such as TLS/SSL, DTLS or SSH [RFC4251] to assure the same level of 3419 protection as for critical secured Internet services. AERO Clients 3420 that require host-based VPN services SHOULD use network and/or 3421 transport layer security services such as IPsec, TLS/SSL, DTLS, etc. 3422 AERO Proxys and Proxy/Servers can also provide a network-based VPN 3423 service on behalf of the Client, e.g., if the Client is located 3424 within a secured enclave and cannot establish a VPN on its own 3425 behalf. 3427 AERO Proxy/Servers and Bridges present targets for traffic 3428 amplification Denial of Service (DoS) attacks. This concern is no 3429 different than for widely-deployed VPN security gateways in the 3430 Internet, where attackers could send spoofed packets to the gateways 3431 at high data rates. This can be mitigated by connecting Proxy/ 3432 Servers and Bridges over dedicated links with no connections to the 3433 Internet and/or when connections to the Internet are only permitted 3434 through well-managed firewalls. Traffic amplification DoS attacks 3435 can also target an AERO Client's low data rate links. This is a 3436 concern not only for Clients located on the open Internet but also 3437 for Clients in secured enclaves. AERO Proxy/Servers and Proxys can 3438 institute rate limits that protect Clients from receiving packet 3439 floods that could DoS low data rate links. 3441 AERO Relays must implement ingress filtering to avoid a spoofing 3442 attack in which spurious messages with ULA addresses are injected 3443 into an OMNI link from an outside attacker. AERO Clients MUST ensure 3444 that their connectivity is not used by unauthorized nodes on their 3445 EUNs to gain access to a protected network, i.e., AERO Clients that 3446 act as routers MUST NOT provide routing services for unauthorized 3447 nodes. (This concern is no different than for ordinary hosts that 3448 receive an IP address delegation but then "share" the address with 3449 other nodes via some form of Internet connection sharing such as 3450 tethering.) 3452 The MAP list MUST be well-managed and secured from unauthorized 3453 tampering, even though the list contains only public information. 3454 The MAP list can be conveyed to the Client in a similar fashion as in 3455 [RFC5214] (e.g., through layer 2 data link login messaging, secure 3456 upload of a static file, DNS lookups, etc.). 3458 SRH authentication facilities are specified in [RFC8754]. 3460 Security considerations for accepting link-layer ICMP messages and 3461 reflected packets are discussed throughout the document. 3463 Security considerations for IPv6 fragmentation and reassembly are 3464 discussed in [I-D.templin-6man-omni-interface]. 3466 7. Acknowledgements 3468 Discussions in the IETF, aviation standards communities and private 3469 exchanges helped shape some of the concepts in this work. 3470 Individuals who contributed insights include Mikael Abrahamsson, Mark 3471 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 3472 Wojciech Dec, Pavel Drasil, Ralph Droms, Adrian Farrel, Nick Green, 3473 Sri Gundavelli, Brian Haberman, Bernhard Haindl, Joel Halpern, Tom 3474 Herbert, Sascha Hlusiak, Lee Howard, Zdenek Jaron, Andre Kostur, 3475 Hubert Kuenig, Ted Lemon, Andy Malis, Satoru Matsushima, Tomek 3476 Mrugalski, Madhu Niraula, Alexandru Petrescu, Behcet Saikaya, Michal 3477 Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, Lloyd 3478 Wood and James Woodyatt. Members of the IESG also provided valuable 3479 input during their review process that greatly improved the document. 3480 Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman 3481 for their shepherding guidance during the publication of the AERO 3482 first edition. 3484 This work has further been encouraged and supported by Boeing 3485 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 3486 Brodie, John Bush, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, 3487 Claudiu Danilov, Don Dillenburg, Joe Dudkowski, Wen Fang, Samad 3488 Farooqui, Anthony Gregory, Jeff Holland, Seth Jahne, Brian Jaury, 3489 Greg Kimberly, Ed King, Madhuri Madhava Badgandi, Laurel Matthew, 3490 Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Vijay 3491 Rajagopalan, Greg Saccone, Rod Santiago, Kent Shuey, Brian Skeen, 3492 Mike Slane, Carrie Spiker, Katie Tran, Brendan Williams, Amelia 3493 Wilson, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 3494 Boeing mobility, networking and autonomy teams. Kyle Bae, Wayne 3495 Benson, Katie Tran and Eric Yeh are especially acknowledged for 3496 implementing the AERO functions as extensions to the public domain 3497 OpenVPN distribution. 3499 Earlier works on NBMA tunneling approaches are found in 3500 [RFC2529][RFC5214][RFC5569]. 3502 Many of the constructs presented in this second edition of AERO are 3503 based on the author's earlier works, including: 3505 o The Internet Routing Overlay Network (IRON) 3506 [RFC6179][I-D.templin-ironbis] 3508 o Virtual Enterprise Traversal (VET) 3509 [RFC5558][I-D.templin-intarea-vet] 3511 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 3512 [RFC5320][I-D.templin-intarea-seal] 3514 o AERO, First Edition [RFC6706] 3516 Note that these works cite numerous earlier efforts that are not also 3517 cited here due to space limitations. The authors of those earlier 3518 works are acknowledged for their insights. 3520 This work is aligned with the NASA Safe Autonomous Systems Operation 3521 (SASO) program under NASA contract number NNA16BD84C. 3523 This work is aligned with the FAA as per the SE2025 contract number 3524 DTFAWA-15-D-00030. 3526 This work is aligned with the Boeing Commercial Airplanes (BCA) 3527 Internet of Things (IoT) and autonomy programs. 3529 This work is aligned with the Boeing Information Technology (BIT) 3530 MobileNet program. 3532 8. References 3534 8.1. Normative References 3536 [I-D.templin-6man-omni-interface] 3537 Templin, F. and T. Whyman, "Transmission of IP Packets 3538 over Overlay Multilink Network (OMNI) Interfaces", draft- 3539 templin-6man-omni-interface-69 (work in progress), January 3540 2021. 3542 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3543 DOI 10.17487/RFC0791, September 1981, 3544 . 3546 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3547 RFC 792, DOI 10.17487/RFC0792, September 1981, 3548 . 3550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3551 Requirement Levels", BCP 14, RFC 2119, 3552 DOI 10.17487/RFC2119, March 1997, 3553 . 3555 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3556 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 3557 December 1998, . 3559 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 3560 "SEcure Neighbor Discovery (SEND)", RFC 3971, 3561 DOI 10.17487/RFC3971, March 2005, 3562 . 3564 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 3565 RFC 3972, DOI 10.17487/RFC3972, March 2005, 3566 . 3568 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3569 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 3570 November 2005, . 3572 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3573 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3574 . 3576 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 3577 Network Address Translations (NATs)", RFC 4380, 3578 DOI 10.17487/RFC4380, February 2006, 3579 . 3581 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3582 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3583 DOI 10.17487/RFC4861, September 2007, 3584 . 3586 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3587 Address Autoconfiguration", RFC 4862, 3588 DOI 10.17487/RFC4862, September 2007, 3589 . 3591 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, 3592 DOI 10.17487/RFC6081, January 2011, 3593 . 3595 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 3596 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 3597 RFC 7401, DOI 10.17487/RFC7401, April 2015, 3598 . 3600 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 3601 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 3602 February 2016, . 3604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3606 May 2017, . 3608 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3609 (IPv6) Specification", STD 86, RFC 8200, 3610 DOI 10.17487/RFC8200, July 2017, 3611 . 3613 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 3614 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 3615 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3616 RFC 8415, DOI 10.17487/RFC8415, November 2018, 3617 . 3619 8.2. Informative References 3621 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 3622 2016. 3624 [I-D.bonica-6man-comp-rtg-hdr] 3625 Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. 3626 Jalil, "The IPv6 Compact Routing Header (CRH)", draft- 3627 bonica-6man-comp-rtg-hdr-24 (work in progress), January 3628 2021. 3630 [I-D.bonica-6man-crh-helper-opt] 3631 Li, X., Bao, C., Ruan, E., and R. Bonica, "Compressed 3632 Routing Header (CRH) Helper Option", draft-bonica-6man- 3633 crh-helper-opt-02 (work in progress), October 2020. 3635 [I-D.ietf-intarea-frag-fragile] 3636 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 3637 and F. Gont, "IP Fragmentation Considered Fragile", draft- 3638 ietf-intarea-frag-fragile-17 (work in progress), September 3639 2019. 3641 [I-D.ietf-intarea-tunnels] 3642 Touch, J. and M. Townsley, "IP Tunnels in the Internet 3643 Architecture", draft-ietf-intarea-tunnels-10 (work in 3644 progress), September 2019. 3646 [I-D.ietf-ipwave-vehicular-networking] 3647 Jeong, J., "IPv6 Wireless Access in Vehicular Environments 3648 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 3649 ipwave-vehicular-networking-19 (work in progress), July 3650 2020. 3652 [I-D.ietf-rtgwg-atn-bgp] 3653 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 3654 Moreno, "A Simple BGP-based Mobile Routing System for the 3655 Aeronautical Telecommunications Network", draft-ietf- 3656 rtgwg-atn-bgp-10 (work in progress), January 2021. 3658 [I-D.templin-6man-dhcpv6-ndopt] 3659 Templin, F., "A Unified Stateful/Stateless Configuration 3660 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-11 3661 (work in progress), January 2021. 3663 [I-D.templin-intarea-seal] 3664 Templin, F., "The Subnetwork Encapsulation and Adaptation 3665 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 3666 progress), January 2014. 3668 [I-D.templin-intarea-vet] 3669 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 3670 templin-intarea-vet-40 (work in progress), May 2013. 3672 [I-D.templin-ipwave-uam-its] 3673 Templin, F., "Urban Air Mobility Implications for 3674 Intelligent Transportation Systems", draft-templin-ipwave- 3675 uam-its-04 (work in progress), January 2021. 3677 [I-D.templin-ironbis] 3678 Templin, F., "The Interior Routing Overlay Network 3679 (IRON)", draft-templin-ironbis-16 (work in progress), 3680 March 2014. 3682 [I-D.templin-v6ops-pdhost] 3683 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 3684 Models", draft-templin-v6ops-pdhost-27 (work in progress), 3685 January 2021. 3687 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 3689 [RFC1035] Mockapetris, P., "Domain names - implementation and 3690 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3691 November 1987, . 3693 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 3694 RFC 1812, DOI 10.17487/RFC1812, June 1995, 3695 . 3697 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 3698 DOI 10.17487/RFC2003, October 1996, 3699 . 3701 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 3702 DOI 10.17487/RFC2004, October 1996, 3703 . 3705 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3706 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 3707 . 3709 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 3710 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 3711 . 3713 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3714 Domains without Explicit Tunnels", RFC 2529, 3715 DOI 10.17487/RFC2529, March 1999, 3716 . 3718 [RFC2983] Black, D., "Differentiated Services and Tunnels", 3719 RFC 2983, DOI 10.17487/RFC2983, October 2000, 3720 . 3722 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3723 of Explicit Congestion Notification (ECN) to IP", 3724 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3725 . 3727 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 3728 DOI 10.17487/RFC3330, September 2002, 3729 . 3731 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 3732 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 3733 DOI 10.17487/RFC3810, June 2004, 3734 . 3736 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3737 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3738 DOI 10.17487/RFC4122, July 2005, 3739 . 3741 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 3742 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 3743 January 2006, . 3745 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 3746 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3747 DOI 10.17487/RFC4271, January 2006, 3748 . 3750 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3751 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3752 2006, . 3754 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3755 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3756 December 2005, . 3758 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 3759 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 3760 2006, . 3762 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3763 Control Message Protocol (ICMPv6) for the Internet 3764 Protocol Version 6 (IPv6) Specification", STD 89, 3765 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3766 . 3768 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3769 Protocol (LDAP): The Protocol", RFC 4511, 3770 DOI 10.17487/RFC4511, June 2006, 3771 . 3773 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 3774 "Considerations for Internet Group Management Protocol 3775 (IGMP) and Multicast Listener Discovery (MLD) Snooping 3776 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 3777 . 3779 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3780 "Internet Group Management Protocol (IGMP) / Multicast 3781 Listener Discovery (MLD)-Based Multicast Forwarding 3782 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 3783 August 2006, . 3785 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 3786 Algorithms in Cryptographically Generated Addresses 3787 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 3788 . 3790 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 3791 "Bidirectional Protocol Independent Multicast (BIDIR- 3792 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 3793 . 3795 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3796 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3797 DOI 10.17487/RFC5214, March 2008, 3798 . 3800 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 3801 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 3802 February 2010, . 3804 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 3805 Route Optimization Requirements for Operational Use in 3806 Aeronautics and Space Exploration Mobile Networks", 3807 RFC 5522, DOI 10.17487/RFC5522, October 2009, 3808 . 3810 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 3811 RFC 5558, DOI 10.17487/RFC5558, February 2010, 3812 . 3814 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 3815 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 3816 January 2010, . 3818 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 3819 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 3820 . 3822 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 3823 "IPv6 Router Advertisement Options for DNS Configuration", 3824 RFC 6106, DOI 10.17487/RFC6106, November 2010, 3825 . 3827 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3828 NAT64: Network Address and Protocol Translation from IPv6 3829 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3830 April 2011, . 3832 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 3833 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 3834 . 3836 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 3837 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 3838 DOI 10.17487/RFC6221, May 2011, 3839 . 3841 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 3842 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 3843 DOI 10.17487/RFC6273, June 2011, 3844 . 3846 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3847 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3848 January 2012, . 3850 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 3851 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 3852 DOI 10.17487/RFC6355, August 2011, 3853 . 3855 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 3856 for Equal Cost Multipath Routing and Link Aggregation in 3857 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3858 . 3860 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3861 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3862 . 3864 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3865 UDP Checksums for Tunneled Packets", RFC 6935, 3866 DOI 10.17487/RFC6935, April 2013, 3867 . 3869 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3870 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3871 RFC 6936, DOI 10.17487/RFC6936, April 2013, 3872 . 3874 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 3875 Korhonen, "Requirements for Distributed Mobility 3876 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 3877 . 3879 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 3880 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 3881 Multicast - Sparse Mode (PIM-SM): Protocol Specification 3882 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 3883 2016, . 3885 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 3886 Decraene, B., Litkowski, S., and R. Shakir, "Segment 3887 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 3888 July 2018, . 3890 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3891 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3892 . 3894 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 3895 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 3896 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 3897 . 3899 [WG] Wireguard, "Wireguard, https://www.wireguard.com", August 3900 2020. 3902 Appendix A. Non-Normative Considerations 3904 AERO can be applied to a multitude of Internetworking scenarios, with 3905 each having its own adaptations. The following considerations are 3906 provided as non-normative guidance: 3908 A.1. Implementation Strategies for Route Optimization 3910 Route optimization as discussed in Section 3.14 results in the route 3911 optimization source (ROS) creating a neighbor cache entry for the 3912 target neighbor. The neighbor cache entry is maintained for at most 3913 ReachableTime seconds and then deleted unless updated. In order to 3914 refresh the neighbor cache entry lifetime before the ReachableTime 3915 timer expires, the specification requires implementations to issue a 3916 new NS/NA exchange to reset ReachableTime while data packets are 3917 still flowing. However, the decision of when to initiate a new NS/NA 3918 exchange and to perpetuate the process is left as an implementation 3919 detail. 3921 One possible strategy may be to monitor the neighbor cache entry 3922 watching for data packets for (ReachableTime - 5) seconds. If any 3923 data packets have been sent to the neighbor within this timeframe, 3924 then send an NS to receive a new NA. If no data packets have been 3925 sent, wait for 5 additional seconds and send an immediate NS if any 3926 data packets are sent within this "expiration pending" 5 second 3927 window. If no additional data packets are sent within the 5 second 3928 window, delete the neighbor cache entry. 3930 The monitoring of the neighbor data packet traffic therefore becomes 3931 an asymmetric ongoing process during the neighbor cache entry 3932 lifetime. If the neighbor cache entry expires, future data packets 3933 will trigger a new NS/NA exchange while the packets themselves are 3934 delivered over a longer path until route optimization state is re- 3935 established. 3937 A.2. Implicit Mobility Management 3939 OMNI interface neighbors MAY provide a configuration option that 3940 allows them to perform implicit mobility management in which no ND 3941 messaging is used. In that case, the Client only transmits packets 3942 over a single interface at a time, and the neighbor always observes 3943 packets arriving from the Client from the same link-layer source 3944 address. 3946 If the Client's underlying interface address changes (either due to a 3947 readdressing of the original interface or switching to a new 3948 interface) the neighbor immediately updates the neighbor cache entry 3949 for the Client and begins accepting and sending packets according to 3950 the Client's new address. This implicit mobility method applies to 3951 use cases such as cellphones with both WiFi and Cellular interfaces 3952 where only one of the interfaces is active at a given time, and the 3953 Client automatically switches over to the backup interface if the 3954 primary interface fails. 3956 A.3. Direct Underlying Interfaces 3958 When a Client's OMNI interface is configured over a Direct interface, 3959 the neighbor at the other end of the Direct link can receive packets 3960 without any encapsulation. In that case, the Client sends packets 3961 over the Direct link according to QoS preferences. If the Direct 3962 interface has the highest QoS preference, then the Client's IP 3963 packets are transmitted directly to the peer without going through an 3964 ANET/INET. If other interfaces have higher QoS preferences, then the 3965 Client's IP packets are transmitted via a different interface, which 3966 may result in the inclusion of Proxys, Proxy/Servers and Bridges in 3967 the communications path. Direct interfaces must be tested 3968 periodically for reachability, e.g., via NUD. 3970 A.4. AERO Critical Infrastructure Considerations 3972 AERO Bridges can be either Commercial off-the Shelf (COTS) standard 3973 IP routers or virtual machines in the cloud. Bridges must be 3974 provisioned, supported and managed by the INET administrative 3975 authority, and connected to the Bridges of other INETs via inter- 3976 domain peerings. Cost for purchasing, configuring and managing 3977 Bridges is nominal even for very large OMNI links. 3979 AERO Proxy/Servers can be standard dedicated server platforms, but 3980 most often will be deployed as virtual machines in the cloud. The 3981 only requirements for Proxy/Servers are that they can run the AERO 3982 user-level code and have at least one network interface connection to 3983 the INET. As with Bridges, Proxy/Servers must be provisioned, 3984 supported and managed by the INET administrative authority. Cost for 3985 purchasing, configuring and managing Proxy/Servers is nominal 3986 especially for virtual Proxy/Servers hosted in the cloud. 3988 AERO Proxys are most often standard dedicated server platforms with 3989 one network interface connected to the ANET and a second interface 3990 connected to an INET. As with Proxy/Servers, the only requirements 3991 are that they can run the AERO user-level code and have at least one 3992 interface connection to the INET. Proxys must be provisioned, 3993 supported and managed by the ANET administrative authority. Cost for 3994 purchasing, configuring and managing Proxys is nominal, and borne by 3995 the ANET administrative authority. 3997 AERO Relays can be any dedicated server or COTS router platform 3998 connected to INETs and/or EUNs. The Relay connects to the OMNI link 3999 and engages in eBGP peering with one or more Bridges as a stub AS. 4000 The Relay then injects its MNPs and/or non-MNP prefixes into the BGP 4001 routing system, and provisions the prefixes to its downstream- 4002 attached networks. The Relay can perform ROS/ROR services the same 4003 as for any Proxy/Server, and can route between the MNP and non-MNP 4004 address spaces. 4006 A.5. AERO Server Failure Implications 4008 AERO Proxy/Servers may appear as a single point of failure in the 4009 architecture, but such is not the case since all Proxy/Servers on the 4010 link provide identical services and loss of a Proxy/Server does not 4011 imply immediate and/or comprehensive communication failures. 4012 Although Clients typically associate with a single Proxy/Server at a 4013 time, Proxy/Server failure is quickly detected and conveyed by 4014 Bidirectional Forward Detection (BFD) and/or proactive NUD allowing 4015 Clients to migrate to new Proxy/Servers. 4017 If a Proxy/Server fails, ongoing packet forwarding to Clients will 4018 continue by virtue of the neighbor cache entries that have already 4019 been established in route optimization sources (ROSs). If a Client 4020 also experiences mobility events at roughly the same time the Proxy/ 4021 Server fails, unsolicited NA messages may be lost but proxy neighbor 4022 cache entries in the DEPARTED state will ensure that packet 4023 forwarding to the Client's new locations will continue for up to 4024 DepartTime seconds. 4026 If a Client is left without a Proxy/Server for an extended timeframe 4027 (e.g., greater than ReachableTime seconds) then existing neighbor 4028 cache entries will eventually expire and both ongoing and new 4029 communications will fail. The original source will continue to 4030 retransmit until the Client has established a new Proxy/Server 4031 relationship, after which time continuous communications will resume. 4033 Therefore, providing many Proxy/Servers on the link with high 4034 availability profiles provides resilience against loss of individual 4035 Proxy/Servers and assurance that Clients can establish new Proxy/ 4036 Server relationships quickly in event of a Proxy/Server failure. 4038 A.6. AERO Client / Server Architecture 4040 The AERO architectural model is client / server in the control plane, 4041 with route optimization in the data plane. The same as for common 4042 Internet services, the AERO Client discovers the addresses of AERO 4043 Proxy/Servers and selects one Proxy/Server to connect to. The AERO 4044 service is analogous to common Internet services such as google.com, 4045 yahoo.com, cnn.com, etc. However, there is only one AERO service for 4046 the link and all Proxy/Servers provide identical services. 4048 Common Internet services provide differing strategies for advertising 4049 server addresses to clients. The strategy is conveyed through the 4050 DNS resource records returned in response to name resolution queries. 4051 As of January 2020 Internet-based 'nslookup' services were used to 4052 determine the following: 4054 o When a client resolves the domainname "google.com", the DNS always 4055 returns one A record (i.e., an IPv4 address) and one AAAA record 4056 (i.e., an IPv6 address). The client receives the same addresses 4057 each time it resolves the domainname via the same DNS resolver, 4058 but may receive different addresses when it resolves the 4059 domainname via different DNS resolvers. But, in each case, 4060 exactly one A and one AAAA record are returned. 4062 o When a client resolves the domainname "ietf.org", the DNS always 4063 returns one A record and one AAAA record with the same addresses 4064 regardless of which DNS resolver is used. 4066 o When a client resolves the domainname "yahoo.com", the DNS always 4067 returns a list of 4 A records and 4 AAAA records. Each time the 4068 client resolves the domainname via the same DNS resolver, the same 4069 list of addresses are returned but in randomized order (i.e., 4070 consistent with a DNS round-robin strategy). But, interestingly, 4071 the same addresses are returned (albeit in randomized order) when 4072 the domainname is resolved via different DNS resolvers. 4074 o When a client resolves the domainname "amazon.com", the DNS always 4075 returns a list of 3 A records and no AAAA records. As with 4076 "yahoo.com", the same three A records are returned from any 4077 worldwide Internet connection point in randomized order. 4079 The above example strategies show differing approaches to Internet 4080 resilience and service distribution offered by major Internet 4081 services. The Google approach exposes only a single IPv4 and a 4082 single IPv6 address to clients. Clients can then select whichever IP 4083 protocol version offers the best response, but will always use the 4084 same IP address according to the current Internet connection point. 4085 This means that the IP address offered by the network must lead to a 4086 highly-available server and/or service distribution point. In other 4087 words, resilience is predicated on high availability within the 4088 network and with no client-initiated failovers expected (i.e., it is 4089 all-or-nothing from the client's perspective). However, Google does 4090 provide for worldwide distributed service distribution by virtue of 4091 the fact that each Internet connection point responds with a 4092 different IPv6 and IPv4 address. The IETF approach is like google 4093 (all-or-nothing from the client's perspective), but provides only a 4094 single IPv4 or IPv6 address on a worldwide basis. This means that 4095 the addresses must be made highly-available at the network level with 4096 no client failover possibility, and if there is any worldwide service 4097 distribution it would need to be conducted by a network element that 4098 is reached via the IP address acting as a service distribution point. 4100 In contrast to the Google and IETF philosophies, Yahoo and Amazon 4101 both provide clients with a (short) list of IP addresses with Yahoo 4102 providing both IP protocol versions and Amazon as IPv4-only. The 4103 order of the list is randomized with each name service query 4104 response, with the effect of round-robin load balancing for service 4105 distribution. With a short list of addresses, there is still 4106 expectation that the network will implement high availability for 4107 each address but in case any single address fails the client can 4108 switch over to using a different address. The balance then becomes 4109 one of function in the network vs function in the end system. 4111 The same implications observed for common highly-available services 4112 in the Internet apply also to the AERO client/server architecture. 4113 When an AERO Client connects to one or more ANETs, it discovers one 4114 or more AERO Proxy/Server addresses through the mechanisms discussed 4115 in earlier sections. Each Proxy/Server address presumably leads to a 4116 fault-tolerant clustering arrangement such as supported by Linux-HA, 4117 Extended Virtual Synchrony or Paxos. Such an arrangement has 4118 precedence in common Internet service deployments in lightweight 4119 virtual machines without requiring expensive hardware deployment. 4120 Similarly, common Internet service deployments set service IP 4121 addresses on service distribution points that may relay requests to 4122 many different servers. 4124 For AERO, the expectation is that a combination of the Google/IETF 4125 and Yahoo/Amazon philosophies would be employed. The AERO Client 4126 connects to different ANET access points and can receive 1-2 Proxy/ 4127 Server ADM-LLAs at each point. It then selects one AERO Proxy/Server 4128 address, and engages in RS/RA exchanges with the same Proxy/Server 4129 from all ANET connections. The Client remains with this Proxy/Server 4130 unless or until the Proxy/Server fails, in which case it can switch 4131 over to an alternate Proxy/Server. The Client can likewise switch 4132 over to a different Proxy/Server at any time if there is some reason 4133 for it to do so. So, the AERO expectation is for a balance of 4134 function in the network and end system, with fault tolerance and 4135 resilience at both levels. 4137 Appendix B. Change Log 4139 << RFC Editor - remove prior to publication >> 4141 Changes from draft-templin-intarea-6706bis-61 to draft-templin- 4142 intrea-6706bis-62: 4144 o New sub-section on OMNI Neighbor Interface Attributes 4146 Changes from draft-templin-intarea-6706bis-59 to draft-templin- 4147 intrea-6706bis-60: 4149 o Removed all references to S/TLLAO - all Interface Attributes are 4150 now maintained completely in the OMNI option. 4152 Changes from draft-templin-intarea-6706bis-58 to draft-templin- 4153 intrea-6706bis-59: 4155 o The term "Relay" used in older draft versions is now "Bridge". 4156 "Relay" now refers to what was formally called: "Gateway". 4158 o Fine-grained cleanup of Forwarding Algorithm; IPv6 ND message 4159 addressing; OMNI Prefix Lengths, etc. 4161 Changes from draft-templin-intarea-6706bis-54 to draft-templin- 4162 intrea-6706bis-55: 4164 o Updates on Segment Routing and S/TLLAO contents. 4166 o Various editorials and addressing cleanups. 4168 Changes from draft-templin-intarea-6706bis-52 to draft-templin- 4169 intrea-6706bis-53: 4171 o Normative reference to the OMNI spec, and remove portions that are 4172 already specified in OMNI. 4174 o Renamed "AERO interface/link" to "OMIN interface/link" throughout 4175 the document. 4177 o Truncated obsolete back section matter. 4179 Author's Address 4180 Fred L. Templin (editor) 4181 Boeing Research & Technology 4182 P.O. Box 3707 4183 Seattle, WA 98124 4184 USA 4186 Email: fltemplin@acm.org