idnits 2.17.1 draft-templin-intarea-6706bis-06.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 (February 27, 2019) is 1884 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) == Unused Reference: 'RFC0768' is defined on line 2332, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2368, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 2382, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-rio-redirect' is defined on line 2439, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 2494, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2621, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 2626, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2649, but no explicit reference was found in the text == Unused Reference: 'TUNTAP' is defined on line 2670, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-dmm-distributed-mobility-anchoring-12 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-06 == Outdated reference: A later version (-06) exists of draft-ietf-intarea-gue-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-26) exists of draft-ietf-rtgwg-atn-bgp-01 == Outdated reference: A later version (-05) exists of draft-templin-6man-aeroaddr-04 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-07 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-07 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-23 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 20 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc5320, rfc5558, rfc5720, February 27, 2019 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: August 31, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-06.txt 13 Abstract 15 This document specifies the operation of IP over tunnel virtual links 16 using Asymmetric Extended Route Optimization (AERO). Nodes attached 17 to AERO links can exchange packets via trusted intermediate routers 18 that provide forwarding services to reach off-link destinations and 19 route optimization services for improved performance. AERO provides 20 an IPv6 link-local address format that supports operation of the IPv6 21 Neighbor Discovery (ND) protocol and links ND to IP forwarding. 22 Dynamic link selection, mobility management, quality of service (QoS) 23 signaling and route optimization are naturally supported through 24 dynamic neighbor cache updates, while IPv6 Prefix Delegation (PD) is 25 supported by network services such as the Dynamic Host Configuration 26 Protocol for IPv6 (DHCPv6). AERO is a widely-applicable tunneling 27 solution especially well-suited to aviation services, mobile Virtual 28 Private Networks (VPNs) and other applications as described in this 29 document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 31, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 7 68 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 8 69 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 71 3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 12 72 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 14 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 18 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 18 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 18 76 3.6.3. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 18 77 3.6.4. AERO Client Behavior . . . . . . . . . . . . . . . . 19 78 3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 19 79 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 21 80 3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 22 81 3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 22 82 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 23 83 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 23 84 3.8.5. Processing Return Packets . . . . . . . . . . . . . . 24 85 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 24 86 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 26 87 3.11. AERO Interface Data Origin Authentication . . . . . . . . 26 88 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 26 89 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 28 90 3.14. AERO Router Discovery, Prefix Delegation and 91 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 32 92 3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 32 93 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 33 94 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 35 95 3.15. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . 37 96 3.16. AERO Route Optimization . . . . . . . . . . . . . . . . . 38 97 3.17. Neighbor Unreachability Detection (NUD) . . . . . . . . . 41 98 3.18. Mobility Management and Quality of Service (QoS) . . . . 41 99 3.18.1. Mobility Update Messaging . . . . . . . . . . . . . 42 100 3.18.2. Forwarding Packets on Behalf of Departed Clients . . 43 101 3.18.3. Announcing Link-Layer Address and/or QoS Preference 102 Changes . . . . . . . . . . . . . . . . . . . . . . 43 103 3.18.4. Bringing New Links Into Service . . . . . . . . . . 43 104 3.18.5. Removing Existing Links from Service . . . . . . . . 44 105 3.18.6. Implicit Mobility Management . . . . . . . . . . . . 44 106 3.18.7. Moving to a New Server . . . . . . . . . . . . . . . 44 107 3.19. Multicast Considerations . . . . . . . . . . . . . . . . 45 108 4. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 45 109 5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 45 110 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 46 111 7. AERO Critical Infrastructure Considerations . . . . . . . . . 47 112 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 47 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 114 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 117 12.1. Normative References . . . . . . . . . . . . . . . . . . 50 118 12.2. Informative References . . . . . . . . . . . . . . . . . 52 119 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 57 120 Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 59 121 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63 124 1. Introduction 126 This document specifies the operation of IP over tunnel virtual links 127 using Asymmetric Extended Route Optimization (AERO). The AERO link 128 can be used for tunneling between neighboring nodes over either IPv6 129 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 130 equivalent links for tunneling. Nodes attached to AERO links can 131 exchange packets via trusted intermediate routers that provide 132 forwarding services to reach off-link destinations and route 133 optimization services for improved performance [RFC5522]. 135 AERO provides an IPv6 link-local address format that supports 136 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 137 links ND to IP forwarding. Dynamic link selection, mobility 138 management, quality of service (QoS) signaling and route optimization 139 are naturally supported through dynamic neighbor cache updates, while 140 IPv6 Prefix Delegation (PD) is supported by network services such as 141 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415]. 143 A node's AERO interface can be configured over multiple underlying 144 interfaces. From the standpoint of ND, AERO interface neighbors 145 therefore may appear to have multiple link-layer addresses (i.e., the 146 IP addresses assigned to underlying interfaces). Each link-layer 147 address is subject to change due to mobility and/or QoS fluctuations, 148 and link-layer address changes are signaled by ND messaging the same 149 as for any IPv6 link. 151 AERO is applicable to a wide variety of use cases. For example, it 152 can be used to coordinate the Virtual Private Network (VPN) links of 153 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 154 connect into a home enterprise network via public access networks 155 using services such as OpenVPN [OVPN]. AERO is also applicable to 156 aviation services for both manned and unmanned aircraft where the 157 aircraft is treated as a mobile node that can connect an Internet of 158 Things (IoT). Other applicable use cases are also in scope. 160 The following numbered sections present the AERO specification. The 161 appendices at the end of the document are non-normative. 163 2. Terminology 165 The terminology in the normative references applies; the following 166 terms are defined within the scope of this document: 168 IPv6 Neighbor Discovery (ND) 169 an IPv6 control message service for coordinating neighbor 170 relationships between nodes connected to a common link. The ND 171 service used by AERO is specified in [RFC4861]. 173 IPv6 Prefix Delegation (PD) 174 a networking service for delegating IPv6 prefixes to nodes on the 175 link. The nominal PD service is DHCPv6 [RFC8415], however 176 alternate services (e.g., based on ND messaging) are also in scope 177 [I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt]. 179 (native) Internetwork 180 a connected IP network topology over which the AERO link virtual 181 overlay is configured and native peer-to-peer communications are 182 supported. Example Internetworks include the global public 183 Internet, private enterprise networks, aviation networks, etc. 185 AERO link 186 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 187 configured over an underlying Internetwork. Nodes on the AERO 188 link appear as single-hop neighbors from the perspective of the 189 virtual overlay even though they may be separated by many 190 underlying Internetwork hops. The AERO mechanisms can also 191 operate over native link types (e.g., Ethernet, WiFi etc.) when 192 tunneling is not needed. 194 AERO interface 195 a node's attachment to an AERO link. Since the addresses assigned 196 to an AERO interface are managed for uniqueness, AERO interfaces 197 do not require Duplicate Address Detection (DAD) and therefore set 198 the administrative variable 'DupAddrDetectTransmits' to zero 199 [RFC4862]. 201 AERO address 202 an IPv6 link-local address constructed as specified in 203 Section 3.4. 205 AERO node 206 a node that is connected to an AERO link. 208 AERO Client ("Client") 209 a node that requests PDs from one or more AERO Servers. Following 210 PD, the Client assigns a Client AERO address to the AERO interface 211 for use in ND exchanges with other AERO nodes. A node that acts 212 as an AERO Client on one AERO interface can also act as an AERO 213 Server on a different AERO interface. 215 AERO Server ("Server") 216 a node that configures an AERO interface to provide default 217 forwarding services and a Mobility Anchor Point (MAP) for AERO 218 Clients. The Server assigns an administratively-provisioned AERO 219 address to the AERO interface to support the operation of the ND/ 220 PD services. An AERO Server can also act as an AERO Relay. 222 AERO Relay ("Relay") 223 an IP router that can relay IP packets between AERO Servers and/or 224 forward IP packets between the AERO link and the native 225 Internetwork. AERO Relays are standard IP routers that do not 226 require any AERO-specific functions. 228 AERO Proxy ("Proxy") 229 a node that provides proxying services, e.g., when the Client is 230 located in a secured internal enclave and the Server is located in 231 the external Internetwork. The AERO Proxy is a conduit between 232 the secured enclave and the external Internetwork in the same 233 manner as for common web proxies, and behaves in a similar fashion 234 as for ND proxies [RFC4389]. 236 ingress tunnel endpoint (ITE) 237 an AERO interface endpoint that injects encapsulated packets into 238 an AERO link. 240 egress tunnel endpoint (ETE) 241 an AERO interface endpoint that receives encapsulated packets from 242 an AERO link. 244 underlying network 245 the same as defined for Internetwork. 247 underlying link 248 a link that connects an AERO node to the underlying network. 250 underlying interface 251 an AERO node's interface point of attachment to an underlying 252 link. 254 link-layer address 255 an IP address assigned to an AERO node's underlying interface. 256 When UDP encapsulation is used, the UDP port number is also 257 considered as part of the link-layer address. Packets transmitted 258 over an AERO interface use link-layer addresses as encapsulation 259 header source and destination addresses. Destination link-layer 260 addresses can be either "reachable" or "unreachable" based on 261 dynamically-changing network conditions. 263 network layer address 264 the source or destination address of an encapsulated IP packet. 266 end user network (EUN) 267 an internal virtual or external edge IP network that an AERO 268 Client connects to the rest of the network via the AERO interface. 269 The Client sees each EUN as a "downstream" network and sees the 270 AERO interface as its point of attachment to the "upstream" 271 network. 273 AERO Service Prefix (ASP) 274 an IP prefix associated with the AERO link and from which more- 275 specific AERO Client Prefixes (ACPs) are derived. 277 AERO Client Prefix (ACP) 278 an IP prefix derived from an ASP and delegated to a Client, where 279 the ACP prefix length must be no shorter than the ASP prefix 280 length. 282 base AERO address 283 the lowest-numbered AERO address from the first ACP delegated to 284 the Client (see Section 3.4). 286 secured enclave 287 a private access network (e.g., a corporate enterprise network, 288 radio access network, cellular service provider network, etc.) 289 with secured links and perimeters. Link-layer security services 290 such as IEEE 802.1X and physical-layer security such as campus 291 wired LANs prevent unauthorized access from within the enclave, 292 while border network-layer security services such as firewalls and 293 proxies prevent unauthorized access from the external 294 Internetwork. 296 Potential Router List (PRL) 297 a geographically and/or topologically referenced list of IP 298 addresses of Servers for the AERO link. 300 Mobility Anchor Point (MAP) 301 an AERO Server that is currently tracking and reporting the 302 mobility events of its associated Clients. 304 Distributed Mobility Management (DMM) 305 an overlay routing service coordinated by Servers and Relays that 306 tracks all MAP-to-Client associations. 308 Throughout the document, the simple terms "Client", "Server", "Relay" 309 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 310 "AERO Proxy", respectively. Capitalization is used to distinguish 311 these terms from DHCPv6 client/server/relay [RFC8415]. 313 The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including 314 the names of node variables, messages and protocol constants) is used 315 throughout this document. Also, the term "IP" is used to generically 316 refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or 317 IPv6 [RFC8200]. 319 The terms Mobility Anchor Point (MAP) and Distributed Mobility 320 Management (DMM) are used in the same sense as standard 321 Internetworking terminology. 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 325 document are to be interpreted as described in [RFC2119]. Lower case 326 uses of these words are not to be interpreted as carrying RFC2119 327 significance. 329 3. Asymmetric Extended Route Optimization (AERO) 331 The following sections specify the operation of IP over Asymmetric 332 Extended Route Optimization (AERO) links: 334 3.1. AERO Link Reference Model 336 .-(::::::::) 337 .-(::::::::::::)-. 338 (:: Internetwork ::) 339 `-(::::::::::::)-' 340 `-(::::::)-' 341 | 342 +--------------+ +--------+-------+ +--------------+ 343 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 344 | Nbr: C1, R1 | | Nbr: S1, S2 | | Nbr: C2, R1 | 345 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 346 | X1->C1 | | ASP A1 | | X2->C2 | 347 +-------+------+ +--------+-------+ +------+-------+ 348 | AERO Link | | 349 X---+---+-------------------+-+----------------+---+---X 350 | | | 351 +-----+--------+ +----------+------+ +--------+-----+ 352 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 353 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 354 | default->S1 | +--------+--------+ | default->S2 | 355 | ACP X1 | | | ACP X2 | 356 +------+-------+ .--------+------. +-----+--------+ 357 | (- Proxyed Clients -) | 358 .-. `---------------' .-. 359 ,-( _)-. ,-( _)-. 360 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 361 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 362 `-(______)-' +-------+ +-------+ `-(______)-' 364 Figure 1: AERO Link Reference Model 366 Figure 1 presents the AERO link reference model. In this model: 368 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 369 default router for its associated Servers (S1 and S2), and 370 connects the AERO link to the rest of the Internetwork. 372 o AERO Servers S1 and S2 associate with Relay R1 and also act as 373 default routers for their associated Clients C1 and C2. 375 o AERO Clients C1 and C2 associate with Servers S1 and S2, 376 respectively. They receive AERO Client Prefix (ACP) delegations 377 X1 and X2, and also act as default routers for their associated 378 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 379 to the EUNs served by Clients C1 and C2, respectively. 381 o AERO Proxy P1 provides proxy services for AERO Clients in secured 382 enclaves that cannot associate directly with other AERO link 383 neighbors. 385 Each node on the AERO link maintains an AERO interface neighbor cache 386 and an IP forwarding table the same as for any link. Although the 387 figure shows a limited deployment, in common operational practice 388 there may be many additional Relays, Servers, Clients and Proxies. 390 3.2. AERO Node Types 392 AERO Relays are standard IP routers that provide default forwarding 393 services for AERO Servers. Each Relay also peers with Servers and 394 other Relays in a dynamic routing protocol instance to provide a 395 Distributed Mobility Management (DMM) service for the list of active 396 ACPs (see Section 3.3). Relays forward packets between neighbors 397 connected to the same AERO link and also forward packets between the 398 AERO link and the native Internetwork. Relays present the AERO link 399 to the native Internetwork as a set of one or more AERO Service 400 Prefixes (ASPs) and serve as a gateway between the AERO link and the 401 Internetwork. Relays maintain tunnels with neighboring Servers, and 402 maintain an IP forwarding table entry for each AERO Client Prefix 403 (ACP). 405 AERO Servers provide default forwarding and Mobility Anchor Point 406 (MAP) services for AERO Clients. Each Server also peers with Relays 407 in a dynamic routing protocol instance to advertise its list of 408 associated ACPs (see Section 3.3). Servers facilitate PD exchanges 409 with Clients, where each delegated prefix becomes an ACP taken from 410 an ASP. Servers forward packets between AERO interface neighbors, 411 and maintain AERO interface neighbor cache entries for Relays. They 412 also maintain both neighbor cache entries and IP forwarding table 413 entries for each of their associated Clients, and track each Client's 414 mobility profiles. 416 AERO Clients act as requesting routers to receive ACPs through PD 417 exchanges with AERO Servers over the AERO link. Each Client can 418 associate with a single Server or with multiple Servers, e.g., for 419 fault tolerance, load balancing, etc. Each IPv6 Client receives at 420 least a /64 IPv6 ACP, and may receive even shorter prefixes. 421 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 422 singleton IPv4 address), and may receive even shorter prefixes. 423 Clients maintain an AERO interface neighbor cache entry for each of 424 their associated Servers as well as for each of their correspondent 425 Clients. 427 AERO Proxies provide a transparent conduit for AERO Clients connected 428 to secured enclaves to associate with AERO Servers. The Client sends 429 all of its control plane messages to the Server's link-layer address 430 and the Proxy intercepts them before they leave the secured enclave. 431 The Proxy forwards the Client's control and data plane messages to 432 and from the Client's current Server(s). The Proxy may also discover 433 a more direct route toward a target destination via AERO route 434 optimization, in which case future outbound data packets would be 435 forwarded via the more direct route. The Proxy function is specified 436 in Section 3.15. 438 AERO Relays, Servers and Proxies are critical infrastructure elements 439 in fixed (i.e., non-mobile) deployments. Relays, Servers and Proxies 440 must use public link-layer addresses that do not change and can be 441 reached from any correspondent in the underlying Internetwork (i.e., 442 in the same fashion as for popular Internet services). AERO Clients 443 may be mobile, and may not have any public link-layer addresses, 444 e.g., if they are located behind NATs or Proxies. 446 3.3. AERO Routing System 448 The AERO routing system comprises a private instance of the Border 449 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 450 and Servers and does not interact with either the public Internet BGP 451 routing system or the native Internetwork routing system. Relays 452 advertise only a small and unchanging set of ASPs to the native 453 Internetwork routing system instead of the full dynamically changing 454 set of ACPs. 456 In a reference deployment, each Server is configured as an Autonomous 457 System Border Router (ASBR) for a stub Autonomous System (AS) using 458 an AS Number (ASN) that is unique within the BGP instance, and each 459 Server further uses eBGP to peer with one or more Relays but does not 460 peer with other Servers. All Relays are members of the same hub AS 461 using a common ASN, and use iBGP to maintain a consistent view of all 462 active ACPs currently in service. 464 Each Server maintains a working set of associated ACPs, and 465 dynamically announces new ACPs and withdraws departed ACPs in its 466 eBGP updates to Relays. Clients are expected to remain associated 467 with their current Servers for extended timeframes, however Servers 468 SHOULD selectively suppress updates for impatient Clients that 469 repeatedly associate and disassociate with them in order to dampen 470 routing churn. 472 Each Relay configures a black-hole route for each of its ASPs. By 473 black-holing the ASPs, the Relay will maintain forwarding table 474 entries only for the ACPs that are currently active, and packets 475 destined to all other ACPs will correctly incur Destination 476 Unreachable messages due to the black hole route. Relays do not send 477 eBGP updates for ACPs to Servers, but instead only originate a 478 default route. In this way, Servers have only partial topology 479 knowledge (i.e., they know only about the ACPs of their directly 480 associated Clients) and they forward all other packets to Relays 481 which have full topology knowledge. 483 Scaling properties of the AERO routing system are limited by the 484 number of BGP routes that can be carried by Relays. As of 2015, the 485 global public Internet BGP routing system manages more than 500K 486 routes with linear growth and no signs of router resource exhaustion 487 [BGP]. More recent network emulation studies have also shown that a 488 single Relay can accommodate at least 1M dynamically changing BGP 489 routes even on a lightweight virtual machine, i.e., and without 490 requiring high-end dedicated router hardware. 492 Therefore, assuming each Relay can carry 1M or more routes, this 493 means that at least 1M Clients can be serviced by a single set of 494 Relays. A means of increasing scaling would be to assign a different 495 set of Relays for each set of ASPs. In that case, each Server still 496 peers with one or more Relays, but the Server institutes route 497 filters so that it only sends BGP updates to the specific set of 498 Relays that aggregate the ASP. For example, if the ASP for the AERO 499 link is 2001:db8::/32, a first set of Relays could service the ASP 500 segment 2001:db8::/40, a second set of Relays could service 501 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 502 etc. 504 Assuming up to 1K sets of Relays, the AERO routing system can then 505 accommodate 1B or more ACPs with no additional overhead for Servers 506 and Relays (for example, it should be possible to service 1B /64 ACPs 507 taken from a /34 ASP and even more for shorter prefixes). In this 508 way, each set of Relays services a specific set of ASPs that they 509 advertise to the native Internetwork routing system, and each Server 510 configures ASP-specific routes that list the correct set of Relays as 511 next hops. This arrangement also allows for natural incremental 512 deployment, and can support small scale initial deployments followed 513 by dynamic deployment of additional Clients, Servers and Relays 514 without disturbing the already-deployed base. 516 In an alternate routing arrangement, each set of Relays could 517 advertise an aggregated ASP for the link into the native Internetwork 518 routing system even though each Relay services only smaller segments 519 of the ASP. In that case, a Relay upon receiving a packet with a 520 destination address covered by the ASP segment of another Relay can 521 simply tunnel the packet to the other Relay. The tradeoff then is 522 the penalty for Relay-to-Relay tunneling compared with reduced 523 routing information in the native routing system. 525 A full discussion of the BGP-based routing system used by AERO is 526 found in [I-D.ietf-rtgwg-atn-bgp]. The system provides for 527 Distributed Mobility Management (DMM) per the distributed mobility 528 anchoring architecture [I-D.ietf-dmm-distributed-mobility-anchoring]. 530 3.4. AERO Addresses 532 A Client's AERO address is an IPv6 link-local address with an 533 interface identifier based on the Client's delegated ACP. Relay, 534 Server and Proxy AERO addresses are assigned from the range fe80::/96 535 and include an administratively-provisioned value in the lower 32 536 bits. 538 For IPv6, Client AERO addresses begin with the prefix fe80::/64 and 539 include in the interface identifier (i.e., the lower 64 bits) a 540 64-bit prefix taken from one of the Client's IPv6 ACPs. For example, 541 if the AERO Client receives the IPv6 ACP: 543 2001:db8:1000:2000::/56 545 it constructs its corresponding AERO addresses as: 547 fe80::2001:db8:1000:2000 549 fe80::2001:db8:1000:2001 551 fe80::2001:db8:1000:2002 553 ... etc. ... 555 fe80::2001:db8:1000:20ff 557 For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6 558 address formed from an IPv4 ACP and with a Prefix Length of 96 plus 559 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 560 the IPv4-mapped IPv6 ACP is: 562 0:0:0:0:0:FFFF:192.0.2.16/124 564 The Client then constructs its AERO addresses with the prefix 565 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 566 in the interface identifier as: 568 fe80::FFFF:192.0.2.16 570 fe80::FFFF:192.0.2.17 572 fe80::FFFF:192.0.2.18 573 ... etc. ... 575 fe80:FFFF:192.0.2.31 577 Relay, Server and Proxy AERO addresses are allocated from the range 578 fe80::/96, and MUST be managed for uniqueness by the administrative 579 authority for the link. For interfaces that assign static IPv4 580 addresses, the lower 32 bits of the AERO address includes the IPv4 581 address, e.g., for the IPv4 address 192.0.2.1 the corresponding AERO 582 address is fe80::192.0.2.1. For other interfaces, the lower 32 bits 583 of the AERO address includes a unique integer value, e.g., fe80::1, 584 fe80::2, fe80::3, etc. The address fe80:: is reserved as the IPv6 585 link-local Subnet Router Anycast address [RFC4291], and the address 586 fe80::ffff:ffff is reserved as the unspecified AERO address; hence, 587 these values are not available for administrative assignment. (Note 588 that a special link-local-format unspecified address is defined for 589 AERO to satisfy PD services that require a link-local source 590 address.) 592 When the Server delegates ACPs to the Client, the lowest-numbered 593 AERO address from the first ACP delegation serves as the "base" AERO 594 address (for example, for the ACP 2001:db8:1000:2000::/56 the base 595 AERO address is fe80::2001:db8:1000:2000). The Client then assigns 596 the base AERO address to the AERO interface and uses it for the 597 purpose of maintaining the neighbor cache entry. The Server likewise 598 uses the AERO address as its index into the neighbor cache for this 599 Client. 601 If the Client has multiple AERO addresses (i.e., when there are 602 multiple ACPs and/or ACPs with prefix lengths shorter than /64), the 603 Client originates ND messages using the base AERO address as the 604 source address and accepts and responds to ND messages destined to 605 any of its AERO addresses as equivalent to the base AERO address. In 606 this way, the Client maintains a single neighbor cache entry that may 607 be indexed by multiple AERO addresses. 609 AERO addresses that embed an IPv6 prefix can be statelessly 610 transformed into an IPv6 Subnet Router Anycast address and vice- 611 versa. For example, for the AERO address fe80::2001:db8:2000:3000 612 the corresponding Subnet Router Anycast address is 613 2001:db8:2000:3000::. In the same way, for the IPv6 Subnet Router 614 Anycast address 2001:db8:1:2:: the corresponding AERO address is 615 fe80::2001:db8:1:2. In other words, the low-order 64 bits of an AERO 616 address can be used as the high-order 64 bits of a Subnet Router 617 Anycast address, and vice-versa. 619 AERO links additionally require a reserved IPv6 prefix to support 620 encapsulated forwarding of IPv6 ND messages between Servers on the 621 link. Although any non-link-local IPv6 prefix could be reserved for 622 this purpose, a Unique Local Address (ULA) prefix [RFC4389] would be 623 desireable since it is not routable outside of the AERO link. For 624 example, if the reserved (ULA) prefix is fd00:db8::/64 the AERO 625 Server Subnet Router Anycast Address is fd00:db8::. 627 A full discussion of the AERO addressing service is found in 628 [I-D.templin-6man-aeroaddr]. 630 3.5. AERO Interface Characteristics 632 AERO interfaces use encapsulation (see: Section 3.9) to exchange 633 packets with neighbors attached to the AERO link. 635 AERO interfaces maintain a neighbor cache for tracking per-neighbor 636 state the same as for any interface. AERO interfaces use ND messages 637 including Router Solicitation (RS), Router Advertisement (RA), 638 Neighbor Solicitation (NS), Neighbor Advertisement (NA) and Redirect 639 for neighbor cache management. 641 AERO interface ND messages include one or more Source/Target Link- 642 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type | Length = 5 | Prefix Length |X|N| Reserved | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Interface ID | UDP Port Number | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 + + 653 | | 654 + IP Address + 655 | | 656 + + 657 | | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 669 Format 671 In this format: 673 o Type is set to '1' for SLLAO or '2' for TLLAO. 675 o Length is set to the constant value '5' (i.e., 5 units of 8 676 octets). 678 o Prefix Length is set to the ACP prefix length if the ND message 679 source address is a Client AERO address, or 128 if the source is 680 an administratively-provisioned AERO address. For example, if the 681 source address is fe80::2001:db8:1:0 and the ACP is 682 2001:db8:1:0::/56, Prefix Length is set to the value 56. 683 Conversely, if the source address is fe80::1, Prefix Length is set 684 to 128. If the ND message contains multiple S/TLLAOs, only the 685 Prefix Length value in the first S/TLLAO is consulted and the 686 values in other S/TLLAOs are ignored. 688 o The 'X' bit is set to '1' in the SLLAO of RS/RA messages by the 689 Proxy when there is a Proxy in the path; otherwise, set to '0'. 690 If the ND message contains multiple SLLAOs, only the 'X' value in 691 the first SLLAO is consulted and the values in other SLLAOs are 692 ignored. 694 o The 'N' bit is set to '1' in the SLLAO of RA messages by the 695 Server if there is a NAT in the path; otherwise, set to '0'. If 696 the ND message contains multiple SLLAOs, only the 'N' value in the 697 first SLLAO is consulted and the values in other SLLAOs are 698 ignored. 700 o Reserved is set to the value '0' on transmission and ignored on 701 receipt. 703 o Interface ID is set to a 16-bit integer value corresponding to an 704 underlying interface of the AERO node. Once the node has assigned 705 an Interface ID to an underlying interface, the assignment must 706 remain unchanged until the node fully detaches from the AERO link. 707 The value '255' is reserved as the AERO Server interface ID, i.e., 708 Servers MUST use Interface ID '255', and Clients MUST number their 709 Interface IDs with values in the range of 0-254. 711 o UDP Port Number and IP Address are set to the addresses used by 712 the AERO node when it sends encapsulated packets over the 713 specified underlying interface (or to '0' when the addresses are 714 left unspecified). When UDP is not used as part of the 715 encapsulation, UDP Port Number is set to '0'. When the 716 encapsulation IP address family is IPv4, IP Address is formed as 717 an IPv4-mapped IPv6 address as specified in Section 3.4. 719 o P(i) is a set of Preferences that correspond to the 64 720 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 721 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 722 ("medium") or '3' ("high") to indicate a QoS preference level for 723 packet forwarding purposes. 725 AERO interfaces may be configured over multiple underlying interface 726 connections to underlying links. For example, common mobile handheld 727 devices have both wireless local area network ("WLAN") and cellular 728 wireless links. These links are typically used "one at a time" with 729 low-cost WLAN preferred and highly-available cellular wireless as a 730 standby. In a more complex example, aircraft frequently have many 731 wireless data link types (e.g. satellite-based, cellular, 732 terrestrial, air-to-air directional, etc.) with diverse performance 733 and cost properties. 735 A Client's underlying interfaces are classified as follows: 737 o Native interfaces connect to the open Internetwork, and have a 738 global IP address that is reachable from any open Internetwork 739 correspondent. 741 o NATed interfaces connect to a closed network that is separated 742 from the open Internetwork by a Network Address Translator (NAT). 743 The NAT does not participate in any AERO control message 744 signaling, but the AERO Server can issue control messages on 745 behalf of the Client. 747 o VPNed interfaces use security encapsulation over the Internetwork 748 to a Virtual Private Network (VPN) gateway that also acts as an 749 AERO Server. As with NATed links, the AERO Server can issue 750 control messages on behalf of the Client. 752 o Proxyed interfaces connect to a closed network that is separated 753 from the open Internetwork by an AERO Proxy. Unlike NATed and 754 VPNed interfaces, the AERO Proxy can also issue control messages 755 on behalf of the Client. 757 o Direct interfaces connect the Client directly to a neighbor 758 without crossing any networked paths. An example is a line-of- 759 sight link between a remote pilot and an unmanned aircraft. 761 If a Client's multiple underlying interfaces are used "one at a time" 762 (i.e., all other interfaces are in standby mode while one interface 763 is active), then ND messages include only a single S/TLLAO with 764 Interface ID set to a constant value. In that case, the Client would 765 appear to have a single underlying interface but with a dynamically 766 changing link-layer address. 768 If the Client has multiple active underlying interfaces, then from 769 the perspective of ND it would appear to have multiple link-layer 770 addresses. In that case, ND messages MAY include multiple S/TLLAOs 771 -- each with an Interface ID that corresponds to a specific 772 underlying interface of the AERO node. 774 When the Client includes an S/TLLAO for an underlying interface for 775 which it is aware that there is a NAT or Proxy on the path to the 776 Server, or when a node includes an S/TLLAO solely for the purpose of 777 announcing new QoS preferences, the node sets both UDP Port Number 778 and IP Address to 0 to indicate that the addresses are unspecified at 779 the network layer and must instead be derived from the link-layer 780 encapsulation headers. 782 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 783 correspond to the AERO node's underlying interface used to transmit 784 the message. 786 3.6. AERO Interface Initialization 788 3.6.1. AERO Relay Behavior 790 When a Relay enables an AERO interface, it first assigns an 791 administratively-provisioned AERO address fe80::ID to the interface. 792 Each fe80::ID address MUST be unique among all AERO nodes on the 793 link. The Relay then engages in a dynamic routing protocol session 794 with one or more Servers and all other Relays on the link (see: 795 Section 3.3), and advertises its assigned ASPs into the native 796 Internetwork. Each Relay subsequently maintains an IP forwarding 797 table entry for each active ACP covered by its ASP(s). 799 3.6.2. AERO Server Behavior 801 When a Server enables an AERO interface, it assigns an 802 administratively-provisioned AERO address fe80::ID the same as for 803 Relays. The Server further configures a service to facilitate ND/PD 804 exchanges with AERO Clients. The Server maintains neighbor cache 805 entries for one or more Relays on the link, and manages per-Client 806 neighbor cache entries and IP forwarding table entries based on 807 control message exchanges. The Server also engages in a dynamic 808 routing protocol with its neighboring Relays (see: Section 3.3). 810 When the Server receives an NS/RS message on the AERO interface it 811 authenticates the message and returns an NA/RA message. (When the 812 Server receives an unsolicited NA message, it likewise authenticates 813 the message and processes it locally.) The Server further provides a 814 simple link-layer conduit between AERO interface neighbors. In 815 particular, when a packet sent by a source Client arrives on the 816 Server's AERO interface and is destined to another AERO node, the 817 Server forwards the packet from within the AERO interface at the link 818 layer without ever disturbing the network layer. 820 3.6.3. AERO Proxy Behavior 822 When a Proxy enables an AERO interface, it assigns an 823 administratively-provisioned address fe80::ID the same as for Relays 824 and Servers. The Proxy further maintains per-Client proxy neighbor 825 cache entries based on control message exchanges. Proxies forward 826 packets between their associated Clients and each Client's associated 827 Servers. 829 When the Proxy receives an RS message from a Client in the secured 830 enclave, it creates an incomplete proxy neighbor cache entry and 831 sends a proxyed RS message to a Server selected by the Client while 832 using its own link-layer address as the source address. When the 833 Server returns an RA message, the Proxy completes the proxy neighbor 834 cache entry based on autoconfiguration information in the RA and 835 sends a proxyed RA to the Client while using its own link-layer 836 address as the source address. The Client, Server and Proxy will 837 then have the necessary state for managing the proxy neighbor 838 association. 840 3.6.4. AERO Client Behavior 842 When a Client enables an AERO interface, it sends RS messages with 843 ND/PD parameters over an underlying interface to one or more AERO 844 Servers, which return RA messages with corresponding PD parameters. 845 (The RS/RA messages may pass through a Proxy on the path in the case 846 of a Client's Proxyed interface.) See 847 [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters 848 that can be included in the RS/RA message exchanges. 850 After the initial ND/PD message exchange, the Client assigns AERO 851 addresses to the AERO interface based on the delegated prefix(es). 852 The Client can then register additional underlying interfaces with 853 the Server by sending a simple RS message (i.e., one with no PD 854 parameters) over each underlying interface using its base AERO 855 address as the source network layer address. The Server will update 856 its neighbor cache entry for the Client and return a simple RA 857 message. 859 The Client maintains a neighbor cache entry for each of its Servers 860 and each of its active correspondent Clients. When the Client 861 receives ND messages on the AERO interface it updates or creates 862 neighbor cache entries, including link-layer address and QoS 863 preferences. 865 3.7. AERO Interface Neighbor Cache Maintenance 867 Each AERO interface maintains a conceptual neighbor cache that 868 includes an entry for each neighbor it communicates with on the AERO 869 link, the same as for any IPv6 interface [RFC4861]. AERO interface 870 neighbor cache entries are said to be one of "permanent", "static", 871 "proxy" or "dynamic". 873 Permanent neighbor cache entries are created through explicit 874 administrative action; they have no timeout values and remain in 875 place until explicitly deleted. AERO Relays maintain permanent 876 neighbor cache entries for their associated Relays and Servers on the 877 link, and AERO Servers maintain permanent neighbor cache entries for 878 their associated Relays. Each entry maintains the mapping between 879 the neighbor's fe80::ID network-layer address and corresponding link- 880 layer address. 882 Static neighbor cache entries are created and maintained through ND/ 883 PD exchanges as specified in Section 3.14, and remain in place for 884 durations bounded by ND/PD lifetimes. AERO Servers maintain static 885 neighbor cache entries for each of their associated Clients, and AERO 886 Clients maintain static neighbor cache entries for each of their 887 associated Servers. 889 Proxy neighbor cache entries are created and maintained by AERO 890 Proxies when they process Client/Server ND/PD exchanges, and remain 891 in place for durations bounded by ND/PD lifetimes. AERO Proxies 892 maintain proxy neighbor cache entries for each of their associated 893 Clients. 895 Dynamic neighbor cache entries are created or updated based on 896 receipt of route optimization messages as specified in Section 3.16, 897 and are garbage-collected when keepalive timers expire. AERO route 898 optimization sources maintain dynamic neighbor cache entries for each 899 of their active target Clients with lifetimes based on ND messaging 900 constants. 902 When a target AERO Server (acting as a Mobility Anchor Point (MAP)) 903 receives a valid NS message used for route optimization, it searches 904 for a static neighbor cache entry for the target Client. The Server 905 then returns an NA message, and adds the link-layer address of the 906 source to a "Report List" associated with the Client's static 907 neighbor cache entry. The Server then sets a "ReportTime" variable 908 for the Report list entry to REPORTTIME seconds. The Server resets 909 ReportTime when it receives a new NS message, and otherwise 910 decrements ReportTime while no NS messages have been received. It is 911 RECOMMENDED that REPORTTIME be set to the default constant value 40 912 seconds to allow a 10 second window so that the AERO route 913 optimization procedure can converge before ReportTime decrements 914 below REACHABLETIME (see below). 916 When the route optimization source receives a valid NA message 917 response to its NS message, it creates or updates a dynamic neighbor 918 cache entry for the target network-layer and link-layer addresses. 919 The node then (re)sets "ReachableTime" for the neighbor cache entry 920 to REACHABLETIME seconds and uses this value to determine whether 921 packets can be forwarded directly to the target, i.e., instead of via 922 a default route. The node otherwise decrements ReachableTime while 923 no further solicited NA messages arrive. It is RECOMMENDED that 924 REACHABLETIME be set to the default constant value 30 seconds as 925 specified in [RFC4861]. 927 The route optimization source also uses the value MAX_UNICAST_SOLICIT 928 to limit the number of NS keepalives sent when a correspondent may 929 have gone unreachable, the value MAX_RTR_SOLICITATIONS to limit the 930 number of RS messages sent without receiving an RA and the value 931 MAX_NEIGHBOR_ADVERTISEMENT to limit the number of unsolicited NAs 932 that can be sent based on a single event. It is RECOMMENDED that 933 MAX_UNICAST_SOLICIT, MAX_RTR_SOLICITATIONS and 934 MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the same as specified in 935 [RFC4861]. 937 Different values for REPORTTIME, REACHABLETIME, MAX_UNICAST_SOLICIT, 938 MAX_RTR_SOLCITATIONS and MAX_NEIGHBOR_ADVERTISEMENT MAY be 939 administratively set; however, if different values are chosen, all 940 nodes on the link MUST consistently configure the same values. Most 941 importantly, REPORTTIME SHOULD be set to a value that is sufficiently 942 longer than REACHABLETIME to allow the AERO route optimization 943 procedure to converge. 945 When there may be a NAT or Proxy between the Client and the Server, 946 or if the path from the Client to the Server should be tested for 947 reachability, either the Client or the Proxy can send periodic RS 948 messages to the Server without PD parameters to receive RA replies. 949 The RS/RA messaging will keep NAT/Proxy state alive and test Server 950 reachability without disturbing the PD service. 952 3.8. AERO Interface Forwarding Algorithm 954 IP packets enter a node's AERO interface either from the network 955 layer (i.e., from a local application or the IP forwarding system) or 956 from the link layer (i.e., from the AERO tunnel virtual link). 957 Packets that enter the AERO interface from the network layer are 958 encapsulated and forwarded into the AERO link, i.e., they are 959 tunneled to an AERO interface neighbor. Packets that enter the AERO 960 interface from the link layer are either re-admitted into the AERO 961 link or forwarded to the network layer where they are subject to 962 either local delivery or IP forwarding. In all cases, the AERO 963 interface itself MUST NOT decrement the network layer TTL/Hop-count 964 since its forwarding actions occur below the network layer. 966 AERO interfaces may have multiple underlying interfaces and/or 967 neighbor cache entries for neighbors with multiple Interface ID 968 registrations (see Section 3.5). The AERO node uses each packet's 969 DSCP value to select an outgoing underlying interface based on the 970 node's own QoS preferences, and also to select a destination link- 971 layer address based on the neighbor's underlying interface with the 972 highest preference. AERO implementations SHOULD allow for QoS 973 preference values to be modified at runtime through network 974 management. 976 If multiple outgoing interfaces and/or neighbor interfaces have a 977 preference of "high", the AERO node sends one copy of the packet via 978 each of the (outgoing / neighbor) interface pairs; otherwise, the 979 node sends a single copy of the packet via the interface with the 980 highest preference. AERO nodes keep track of which underlying 981 interfaces are currently "reachable" or "unreachable", and only use 982 "reachable" interfaces for forwarding purposes. 984 The following sections discuss the AERO interface forwarding 985 algorithms for Clients, Proxies, Servers and Relays. In the 986 following discussion, a packet's destination address is said to 987 "match" if it is a non-link-local address with a prefix covered by an 988 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 989 the same as an administratively-provisioned AERO address. 991 3.8.1. Client Forwarding Algorithm 993 When an IP packet enters a Client's AERO interface from the network 994 layer the Client searches for a dynamic neighbor cache entry that 995 matches the destination. If there is a match, the Client uses one or 996 more "reachable" link-layer addresses in the entry as the link-layer 997 addresses for encapsulation and admits the packet into the AERO link. 998 Otherwise, the Client uses the link-layer address in a static 999 neighbor cache entry for a Server as the encapsulation address 1000 (noting that there may be a Proxy on the path to the real Server). 1002 When an IP packet enters a Client's AERO interface from the link- 1003 layer, if the destination matches one of the Client's ACPs or link- 1004 local addresses the Client decapsulates the packet and delivers it to 1005 the network layer. Otherwise, the Client drops the packet and MAY 1006 return a network-layer ICMP Destination Unreachable message subject 1007 to rate limiting (see: Section 3.13). 1009 3.8.2. Proxy Forwarding Algorithm 1011 When the Proxy receives a packet from a Client within the secured 1012 enclave, the Proxy searches for a dynamic neighbor cache entry that 1013 matches the destination. If there is a match, the Proxy uses one or 1014 more "reachable" link-layer addresses in the entry as the link-layer 1015 addresses for encapsulation and admits the packet into the AERO link. 1016 Otherwise, the Proxy uses the link-layer address for one of the 1017 Client's Servers as the encapsulation address. 1019 When the Proxy receives a packet from an AERO interface neighbor, it 1020 searches for a proxy neighbor cache entry for a Client within the 1021 secured enclave that matches the destination. If there is a match, 1022 the Proxy forwards the packet to the Client. Otherwise, the Proxy 1023 returns the packet to the neighbor, i.e., by reversing the source and 1024 destination link-layer addresses and re-admitting the packet into the 1025 AERO link. 1027 3.8.3. Server Forwarding Algorithm 1029 When an IP packet enters a Server's AERO interface from the network 1030 layer, the Server searches for a static neighbor cache entry for a 1031 Client that matches the destination. If there is a match, the Server 1032 uses one or more link-layer addresses in the entry as the link-layer 1033 addresses for encapsulation and admits the packet into the AERO link. 1034 Otherwise, the Server uses the link-layer address in a permanent 1035 neighbor cache entry for a Relay (selected through longest-prefix 1036 match) as the link-layer address for encapsulation. 1038 When an IP packet enters a Server's AERO interface from the link 1039 layer, the Server processes the packet according to the network-layer 1040 destination address as follows: 1042 o if the destination matches one of the Server's own addresses the 1043 Server decapsulates the packet and forwards it to the network 1044 layer for local delivery. 1046 o else, if the destination matches a static neighbor cache entry for 1047 a local Client the Server first determines whether the neighbor is 1048 the same as the one it received the packet from. If so, the 1049 Server drops the packet silently to avoid looping; otherwise, the 1050 Server uses the neighbor's link-layer address(es) as the 1051 destination for encapsulation and re-admits the packet into the 1052 AERO link. 1054 o else, if the destination matches a dynamic neighbor cache entry 1055 for a target Client, the Server forwards the packet according to 1056 the interface ID settings in the dynamic neighbor cache entry. 1058 o else, the Server uses the link-layer address in a neighbor cache 1059 entry for a Relay (selected through longest-prefix match) as the 1060 link-layer address for encapsulation. 1062 3.8.4. Relay Forwarding Algorithm 1064 Relays forward packets the same as any IP router. When the Relay 1065 receives an encapsulated packet from a Server via the AERO link, it 1066 removes the encapsulation header and searches for a forwarding table 1067 entry that matches the destination address in the next IP header. 1068 When the Relay receives an unencapsulated packet from a node outside 1069 the AERO link, it performs the same forwarding table lookup. The 1070 Relay then processes the packet as follows: 1072 o if the destination does not match an ASP, or if the destination 1073 matches one of the Relay's own addresses, the Relay submits the 1074 packet for either IP forwarding or local delivery. 1076 o else, if the destination matches an ACP entry in the IP forwarding 1077 table the Relay first determines whether the neighbor is the same 1078 as the one it received the packet from. If so the Relay MUST drop 1079 the packet silently to avoid looping; otherwise, the Relay 1080 encapsulates and forwards the packet using the neighbor's link- 1081 layer address as the destination for encapsulation. 1083 o else, the Relay drops the packet and returns an ICMP Destination 1084 Unreachable message subject to rate limiting (see: Section 3.13). 1086 As for any IP router, the Relay decrements the TTL/Hop Count when it 1087 forwards the packet. 1089 3.8.5. Processing Return Packets 1091 When an AERO Server receives a return packet from an AERO Proxy (see 1092 Section 3.8.2), it proceeds according to the AERO link trust basis. 1093 Namely, the return packets have the same trust profile as for link- 1094 layer Destination Unreachable messages. If the Server has sufficient 1095 trust basis to accept link-layer Destination Unreachable messages, it 1096 can then process the return packet by searching for a dynamic 1097 neighbor cache entry that matches the destination. If there is a 1098 match, the Server marks the corresponding link-layer address as 1099 "unreachable", selects the next-highest priority "reachable" link- 1100 layer address in the entry as the link-layer address for 1101 encapsulation then (re)admits the packet into the AERO link. If 1102 there are no "reachable" link-layer addresses, the Server instead 1103 sets ReachableTime in the dynamic neighbor cache entry to 0. 1104 Otherwise, the Server SHOULD drop the packet and treat it as an 1105 indication that a path may be failing, and MAY use Neighbor 1106 Unreachability Detection (NUD) (see: Section 3.13) to test the path 1107 for reachability. 1109 When an AERO Relay receives a return packet from an AERO Server, it 1110 searches its forwarding table for an entry that matches the inner 1111 destination address. If there is a forwarding table entry that lists 1112 a different Server as the next hop, the Relay forwards the packet to 1113 the different Server; otherwise, the Relay drops the packet. 1115 See Section 3.18 for further discussion on the nature of return 1116 packets. 1118 3.9. AERO Interface Encapsulation and Re-encapsulation 1120 AERO interfaces encapsulate IP packets according to whether they are 1121 entering the AERO interface from the network layer or if they are 1122 being re-admitted into the same AERO link they arrived on. This 1123 latter form of encapsulation is known as "re-encapsulation". 1125 The AERO interface encapsulates packets per the Generic UDP 1126 Encapsulation (GUE) procedures in 1127 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 1128 an alternate encapsulation format (e.g., see: Appendix A, [RFC2784], 1129 [RFC8086], [RFC4301], etc.). For packets entering the AERO interface 1130 from the network layer, the AERO interface copies the "TTL/Hop 1131 Limit", "Type of Service/Traffic Class" [RFC2983], "Flow 1132 Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168] 1133 values in the packet's IP header into the corresponding fields in the 1134 encapsulation IP header. For packets undergoing re-encapsulation, 1135 the AERO interface instead copies these values from the original 1136 encapsulation IP header into the new encapsulation header, i.e., the 1137 values are transferred between encapsulation headers and *not* copied 1138 from the encapsulated packet's network-layer header. (Note 1139 especially that by copying the TTL/Hop Limit between encapsulation 1140 headers the value will eventually decrement to 0 if there is a 1141 (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation, 1142 the AERO interface sets the DF bit as discussed in Section 3.12. 1144 When GUE encapsulation is used, the AERO interface next sets the UDP 1145 source port to a constant value that it will use in each successive 1146 packet it sends, and sets the UDP length field to the length of the 1147 encapsulated packet plus 8 bytes for the UDP header itself plus the 1148 length of the GUE header (or 0 if GUE direct IP encapsulation is 1149 used). For packets sent to a Server or Relay, the AERO interface 1150 sets the UDP destination port to 8060, i.e., the IANA-registered port 1151 number for AERO. For packets sent to a Client, the AERO interface 1152 sets the UDP destination port to the port value stored in the 1153 neighbor cache entry for this Client. The AERO interface then either 1154 includes or omits the UDP checksum according to the GUE 1155 specification. 1157 Clients normally use the IP address of the underlying interface as 1158 the encapsulation source address. If the underlying interface does 1159 not have an IP address, however, the Client uses an IP address taken 1160 from an ACP as the encapsulation source address (assuming the node 1161 has some way of injecting the ACP into the underlying network routing 1162 system). For IPv6 addresses, the Client normally uses the ACP Subnet 1163 Router Anycast address [RFC4291]. 1165 When GUE encapsulation is not available, encapsulation between 1166 Servers and Relays can use standard mechanisms such as Generic 1167 Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec 1168 [RFC4301] so that Relays can be standard IP routers with no AERO- 1169 specific mechanisms. 1171 3.10. AERO Interface Decapsulation 1173 AERO interfaces decapsulate packets destined either to the AERO node 1174 itself or to a destination reached via an interface other than the 1175 AERO interface the packet was received on. Decapsulation is per the 1176 procedures specified for the appropriate encapsulation format. 1178 3.11. AERO Interface Data Origin Authentication 1180 AERO nodes employ simple data origin authentication procedures for 1181 encapsulated packets they receive from other nodes on the AERO link. 1182 In particular: 1184 o AERO Relays and Servers accept encapsulated packets with a link- 1185 layer source address that matches a permanent neighbor cache 1186 entry. 1188 o AERO Servers accept authentic encapsulated ND messages from 1189 Clients (either directly or via a Proxy), and create or update a 1190 static neighbor cache entry for the Client based on the specific 1191 message type. 1193 o AERO Clients and Servers accept encapsulated packets if there is a 1194 static neighbor cache entry with a link-layer address that matches 1195 the packet's link-layer source address. 1197 o AERO Proxies accept encapsulated packets if there is a proxy 1198 neighbor cache entry that matches the packet's network-layer 1199 address. 1201 Each packet should include a signature that the recipient can use to 1202 authenticate the message origin, e.g., as for common VPN systems such 1203 as OpenVPN [OVPN]. In some environments, however, it may be 1204 sufficient to require signatures only for ND control plane messages 1205 (see: Section 10) and omit signatures for data plane messages. 1207 3.12. AERO Interface Packet Size Issues 1209 The AERO interface is the node's attachment to the AERO link. The 1210 AERO interface acts as a tunnel ingress when it sends a packet to an 1211 AERO link neighbor and as a tunnel egress when it receives a packet 1212 from an AERO link neighbor. AERO interfaces observe the packet 1213 sizing considerations for tunnels discussed in 1214 [I-D.ietf-intarea-tunnels] and as specified below. 1216 The Internet Protocol expects that IP packets will either be 1217 delivered to the destination or a suitable Packet Too Big (PTB) 1218 message returned to support the process known as IP Path MTU 1219 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1220 crafted for malicious purposes such as denial of service, or lost in 1221 the network [RFC2923]. This can be especially problematic for 1222 tunnels, where a condition known as a PMTUD "black hole" can result. 1223 For these reasons, AERO interfaces employ operational procedures that 1224 avoid interactions with PMTUD, including the use of fragmentation 1225 when necessary. 1227 AERO interfaces observe two different types of fragmentation. Source 1228 fragmentation occurs when the AERO interface (acting as a tunnel 1229 ingress) fragments the encapsulated packet into multiple fragments 1230 before admitting each fragment into the tunnel. Network 1231 fragmentation occurs when an encapsulated packet admitted into the 1232 tunnel by the ingress is fragmented by an IPv4 router on the path to 1233 the egress. Note that a packet that incurs source fragmentation may 1234 also incur network fragmentation. 1236 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1237 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1238 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1239 for IPv4 even if encapsulated packets may incur network 1240 fragmentation. 1242 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1243 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1244 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1245 than the IPv4 minimum). 1247 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1248 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1249 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1250 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1251 configure a Maximum Segment Unit (MSU) as the maximum-sized 1252 encapsulated packet that the ingress can inject into the tunnel 1253 without source fragmentation. The MSU value MUST NOT be larger than 1254 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1255 operational assurance that a larger size can traverse the link along 1256 all paths. 1258 All AERO nodes MUST configure the same MTU/MSU values for reasons 1259 cited in [RFC3819][RFC4861]; in particular, multicast support 1260 requires a common MTU value among all nodes on the link. All AERO 1261 nodes MUST configure an MRU large enough to reassemble packets up to 1262 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1263 enough MRU MUST NOT enable an AERO interface. 1265 The network layer proceeds as follow when it presents an IP packet to 1266 the AERO interface. For each IPv4 packet that is larger than the 1267 AERO interface MTU and with the DF bit set to 0, the network layer 1268 uses IPv4 fragmentation to break the packet into a minimum number of 1269 non-overlapping fragments where the first fragment is no larger than 1270 the MTU and the remaining fragments are no larger than the first. 1271 For all other IP packets, if the packet is larger than the AERO 1272 interface MTU, the network layer drops the packet and returns a PTB 1273 message to the original source. Otherwise, the network layer admits 1274 each IP packet or fragment into the AERO interface. 1276 For each IP packet admitted into the AERO interface, the interface 1277 (acting as a tunnel ingress) encapsulates the packet. If the 1278 encapsulated packet is larger than the AERO interface MSU the ingress 1279 source-fragments the encapsulated packet into a minimum number of 1280 non-overlapping fragments where the first fragment is no larger than 1281 the MSU and the remaining fragments are no larger than the first. 1282 The ingress then admits each encapsulated packet or fragment into the 1283 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1284 header in case any network fragmentation is necessary. The 1285 encapsulated packets will be delivered to the egress, which 1286 reassembles them into a whole packet if necessary. 1288 Several factors must be considered when fragmentation is needed. For 1289 AERO links over IPv4, the IP ID field is only 16 bits in length, 1290 meaning that fragmentation at high data rates could result in data 1291 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1292 AERO links over both IPv4 and IPv6, studies have also shown that IP 1293 fragments are dropped unconditionally over some network paths [I- 1294 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1295 issues could result in operational problems, the ingress SHOULD 1296 employ intermediate-layer source fragmentation (see: [RFC2764] and 1297 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1298 encapsulation headers to each fragment. Since the encapsulation 1299 fragment header reduces the room available for packet data, but the 1300 original source has no way to control its insertion, the ingress MUST 1301 include the fragment header length in the ENCAPS length even for 1302 packets in which the header is absent. 1304 3.13. AERO Interface Error Handling 1306 When an AERO node admits encapsulated packets into the AERO 1307 interface, it may receive link-layer or network-layer error 1308 indications. 1310 A link-layer error indication is an ICMP error message generated by a 1311 router in the underlying network on the path to the neighbor or by 1312 the neighbor itself. The message includes an IP header with the 1313 address of the node that generated the error as the source address 1314 and with the link-layer address of the AERO node as the destination 1315 address. 1317 The IP header is followed by an ICMP header that includes an error 1318 Type, Code and Checksum. Valid type values include "Destination 1319 Unreachable", "Time Exceeded" and "Parameter Problem" 1320 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1321 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1322 only emit packets that are guaranteed to be no larger than the IP 1323 minimum link MTU as discussed in Section 3.12.) 1325 The ICMP header is followed by the leading portion of the packet that 1326 generated the error, also known as the "packet-in-error". For 1327 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1328 much of invoking packet as possible without the ICMPv6 packet 1329 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1330 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1331 "Internet Header + 64 bits of Original Data Datagram", however 1332 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1333 ICMP datagram SHOULD contain as much of the original datagram as 1334 possible without the length of the ICMP datagram exceeding 576 1335 bytes". 1337 The link-layer error message format is shown in Figure 3 (where, "L2" 1338 and "L3" refer to link-layer and network-layer, respectively): 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 ~ ~ 1342 | L2 IP Header of | 1343 | error message | 1344 ~ ~ 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | L2 ICMP Header | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1348 ~ ~ P 1349 | IP and other encapsulation | a 1350 | headers of original L3 packet | c 1351 ~ ~ k 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1353 ~ ~ t 1354 | IP header of | 1355 | original L3 packet | i 1356 ~ ~ n 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 ~ ~ e 1359 | Upper layer headers and | r 1360 | leading portion of body | r 1361 | of the original L3 packet | o 1362 ~ ~ r 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1365 Figure 3: AERO Interface Link-Layer Error Message Format 1367 The AERO node rules for processing these link-layer error messages 1368 are as follows: 1370 o When an AERO node receives a link-layer Parameter Problem message, 1371 it processes the message the same as described as for ordinary 1372 ICMP errors in the normative references [RFC0792][RFC4443]. 1374 o When an AERO node receives persistent link-layer Time Exceeded 1375 messages, the IP ID field may be wrapping before earlier fragments 1376 awaiting reassembly have been processed. In that case, the node 1377 SHOULD begin including integrity checks and/or institute rate 1378 limits for subsequent packets. 1380 o When an AERO node receives persistent link-layer Destination 1381 Unreachable messages in response to encapsulated packets that it 1382 sends to one of its dynamic neighbor correspondents, the node 1383 SHOULD process the message as an indication that a path may be 1384 failing, and MAY initiate NUD over that path. If it receives 1385 Destination Unreachable messages on many or all paths, the node 1386 SHOULD set ReachableTime for the corresponding dynamic neighbor 1387 cache entry to 0 and allow future packets destined to the 1388 correspondent to flow through a default route. 1390 o When an AERO Client receives persistent link-layer Destination 1391 Unreachable messages in response to encapsulated packets that it 1392 sends to one of its static neighbor Servers, the Client SHOULD 1393 mark the path as unusable and use another path. If it receives 1394 Destination Unreachable messages on many or all paths, the Client 1395 SHOULD associate with a new Server and release its association 1396 with the old Server as specified in Section 3.18.7. 1398 o When an AERO Server receives persistent link-layer Destination 1399 Unreachable messages in response to encapsulated packets that it 1400 sends to one of its static neighbor Clients, the Server SHOULD 1401 mark the underlying path as unusable and use another underlying 1402 path. If it receives Destination Unreachable messages on multiple 1403 paths, the Server should take no further actions unless it 1404 receives an explicit ND/PD release message or if the PD lifetime 1405 expires. In that case, the Server MUST release the Client's 1406 delegated ACP, withdraw the ACP from the AERO routing system and 1407 delete the neighbor cache entry. 1409 o When an AERO Relay or Server receives link-layer Destination 1410 Unreachable messages in response to an encapsulated packet that it 1411 sends to one of its permanent neighbors, it treats the messages as 1412 an indication that the path to the neighbor may be failing. 1413 However, the dynamic routing protocol should soon reconverge and 1414 correct the temporary outage. 1416 When an AERO Relay receives a packet for which the network-layer 1417 destination address is covered by an ASP, if there is no more- 1418 specific routing information for the destination the Relay drops the 1419 packet and returns a network-layer Destination Unreachable message 1420 subject to rate limiting. The Relay writes the network-layer source 1421 address of the original packet as the destination address and uses 1422 one of its non link-local addresses as the source address of the 1423 message. 1425 When an AERO node receives an encapsulated packet for which the 1426 reassembly buffer it too small, it drops the packet and returns a 1427 network-layer Packet Too Big (PTB) message. The node first writes 1428 the MRU value into the PTB message MTU field, writes the network- 1429 layer source address of the original packet as the destination 1430 address and writes one of its non link-local addresses as the source 1431 address. 1433 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1435 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1436 coordinated as discussed in the following Sections. 1438 3.14.1. AERO ND/PD Service Model 1440 Each AERO Server configures a PD service to facilitate Client 1441 requests. Each Server is provisioned with a database of ACP-to- 1442 Client ID mappings for all Clients enrolled in the AERO system, as 1443 well as any information necessary to authenticate each Client. The 1444 Client database is maintained by a central administrative authority 1445 for the AERO link and securely distributed to all Servers, e.g., via 1446 the Lightweight Directory Access Protocol (LDAP) [RFC4511], via 1447 static configuration, etc. Therefore, no Server-to-Server PD state 1448 synchronization is necessary, and Clients can optionally hold 1449 separate PDs for the same ACPs from multiple Servers. In this way, 1450 Clients can associate with multiple Servers, and can receive new PDs 1451 from new Servers before releasing PDs received from existing Servers. 1452 This provides the Client with a natural fault-tolerance and/or load 1453 balancing profile. 1455 AERO Clients and Servers use ND messages to maintain neighbor cache 1456 entries. AERO Servers configure their AERO interfaces as advertising 1457 interfaces, and therefore send unicast RA messages with configuration 1458 information in response to a Client's RS message. Thereafter, 1459 Clients send additional RS messages to the Server's unicast address 1460 to refresh prefix and/or router lifetimes. 1462 AERO Clients and Servers include PD parameters in the RS/RA messages 1463 they exchange (see: [I-D.templin-6man-dhcpv6-ndopt]). The unified 1464 ND/PD messages are exchanged between Client and Server according to 1465 the prefix management schedule required by the PD service. If the 1466 Client knows its ACP in advance, it can include its AERO address as 1467 the source address of an RS message and with an SLLAO with a valid 1468 Prefix Length for the ACP. If the Server (and Proxy) accept the 1469 Client's ACP assertion, they inject the prefix into the routing 1470 system and establish the necessary neighbor cache state. If the 1471 Client does not know its ACP in advance, or if it wishes to engage in 1472 a formal PD exchange, it can use a service such as DHCPv6. 1474 On Some AERO links, PD arrangements may be through some out-of-band 1475 service such as network management, static configuration, etc. In 1476 those cases, AERO nodes can use simple RS/RA message exchanges with 1477 no explicit PD options. Instead, the RS/RA messages use AERO 1478 addresses as a means of representing the delegated prefixes, e.g., if 1479 a message includes a source address of "fe80::2001:db8:1:2" then the 1480 recipient can infer that the sender holds the prefix delegation 1481 "2001:db8:1:2::/N" (where 'N' is the Prefix Length included in the 1482 first S/TLLAO in the message). 1484 The following sections specify the Client and Server behavior. 1486 3.14.2. AERO Client Behavior 1488 AERO Clients discover the link-layer addresses of AERO Servers in the 1489 Potential Router List (PRL) via static configuration (e.g., from a 1490 flat-file map of Server addresses and locations), or through an 1491 automated means such as Domain Name System (DNS) name resolution 1492 [RFC1035]. In the absence of other information, the Client resolves 1493 the DNS Fully-Qualified Domain Name (FQDN) 1494 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 1495 text string and "[domainname]" is a DNS suffix for the Client's 1496 underlying interface (e.g., "example.com"). After discovering the 1497 link-layer addresses, the Client associates with one or more of the 1498 corresponding Servers. 1500 To associate with a Server, the Client acts as a requesting router to 1501 request ACPs through an ND/PD message exchange. The Client sends an 1502 RS message with PD parameters and with all-routers multicast as the 1503 IPv6 destination address, the address of the Client's underlying 1504 interface as the link-layer source address and the link-layer address 1505 of the Server as the link-layer destination address. If the Client 1506 already knows its own AERO address, it uses the AERO address as the 1507 IPv6 source address; otherwise, it uses the unspecified AERO address 1508 as the source address. If the Client's underlying interface connects 1509 to a subnetwork that supports ACP injection, the Client can use the 1510 ACP's Subnet Router Anycast address as the link-layer source address. 1512 The Client next includes one or more SLLAOs in the RS message 1513 formatted as described in Section 3.5 to register its link-layer 1514 address(es) with the Server. The first SLLAO MUST correspond to the 1515 underlying interface over which the Client will send the RS message. 1516 The Client MAY include additional SLLAOs specific to other underlying 1517 interfaces, but if so it sets their UDP Port Number and IP Address 1518 fields to 0. The Client can instead register additional link-layer 1519 addresses with the Server by sending additional RS messages including 1520 SLLAOs via other underlying interfaces after the initial RS/RA 1521 exchange. 1523 The Client then sends the RS message to the AERO Server and waits for 1524 an RA message reply (see Section 3.14.3) while retrying 1525 MAX_RTR_SOLICITATIONS times until an RA is received. If the Client 1526 receives no RAs, or if it receives an RA with Router Lifetime set to 1527 0 and/or with no ACP PD parameters, the Client SHOULD discontinue 1528 autoconfiguration attempts through this Server and try another 1529 Server. Otherwise, the Client processes the ACPs found in the RA 1530 message. 1532 Next, the Client creates a static neighbor cache entry with the 1533 Server's link-local address as the network-layer address and the 1534 address in the first SLLAO as the link-layer address. The Client 1535 then autoconfigures AERO addresses for each of the delegated ACPs and 1536 assigns them to the AERO interface. 1538 The Client next examines the X and N bits in the first SLLAO of the 1539 RA message. If the X bit value is '1' the Client infers that there 1540 is a Proxy on the path via the interface over which it sent the RS 1541 message, and if the N bit value is '1' the Client infers that there 1542 is a NAT on the path. If N is '1', the Client sets UDP Port Number 1543 and IP Address to 0 in the first S/TLLAO of any subsequent ND 1544 messages it sends to the Server over that link. 1546 The Client also caches any ASPs included in Route Information Options 1547 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1548 the MTU/MSU values in the MTU options to its AERO interface while 1549 configuring an appropriate MRU. This configuration information 1550 applies to the AERO link as a whole, and all AERO nodes will receive 1551 the same values. 1553 Following autoconfiguration, the Client sub-delegates the ACPs to its 1554 attached EUNs and/or the Client's own internal virtual interfaces as 1555 described in [I-D.templin-v6ops-pdhost] to support the Client's 1556 downstream attached "Internet of Things (IoT)". The Client 1557 subsequently maintains its ACP delegations through each of its 1558 Servers by sending RS messages with PD parameters to receive 1559 corresponding RA messages. 1561 After the Client registers its Interface IDs and their associated 1562 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1563 Interface ID registrations, e.g., if an underlying interface changes 1564 address or becomes unavailable, if QoS preferences change, etc. To 1565 do so, the Client prepares an RS message to send over any available 1566 underlying interface. The RS MUST include a SLLAO specific to the 1567 selected available underlying interface as the first SLLAO and MAY 1568 include any additional SLLAOs specific to other underlying 1569 interfaces. The Client includes fresh 'P(i)' values in each SLLAO to 1570 update the Server's neighbor cache entry. If the Client wishes to 1571 update 'P(i)' values without updating the link-layer address, it sets 1572 the UDP Port Number and IP Address fields to 0. If the Client wishes 1573 to disable the interface, it sets all 'P(i)' values to '0' 1574 ("disabled"). When the Client receives the Server's RS response, it 1575 has assurance that the Server has been updated with the new 1576 information. 1578 If the Client wishes to discontinue use of a Server it issues an RS 1579 message with PD parameters that will cause the Server to release the 1580 Client. When the Server processes the message, it releases the ACP, 1581 deletes its neighbor cache entry for the Client, withdraws the IP 1582 route from the routing system and returns an RA reply containing any 1583 necessary PD parameters. 1585 3.14.3. AERO Server Behavior 1587 AERO Servers act as IPv6 routers and support a PD service for 1588 Clients. AERO Servers arrange to add their encapsulation layer IP 1589 addresses (i.e., their link-layer addresses) to a static map of 1590 Server addresses for the link and/or the DNS resource records for the 1591 FQDN "linkupnetworks.[domainname]" before entering service. The list 1592 of Server addresses should be geographically and/or topologically 1593 referenced, and forms the Potential Router List (PRL) for the AERO 1594 link. 1596 When an AERO Server receives a prospective Client's RS message with 1597 PD parameters on its AERO interface, and the Server is too busy, it 1598 SHOULD return an immediate RA reply with no ACPs and with Router 1599 Lifetime set to 0. Otherwise, the Server authenticates the RS 1600 message and processes the PD parameters. The Server first determines 1601 the correct ACPs to delegate to the Client by searching the Client 1602 database. When the Server delegates the ACPs, it also creates an IP 1603 forwarding table entry for each ACP so that the AERO BGP-based 1604 routing system will propagate the ACPs to the Relays that aggregate 1605 the corresponding ASP (see: Section 3.3). 1607 Next, the Server prepares an RA message that includes the delegated 1608 ACPs, any other PD parameters and an SLLAO with the Server's link- 1609 layer address and with Interface ID set to 0. The Server then 1610 returns the RA message using its link-local address as the network- 1611 layer source address, the network-layer source address of the RS 1612 message as the network-layer destination address, the Server's link- 1613 layer address as the source link-layer address, and the source link- 1614 layer address of the RS message as the destination link-layer 1615 address. The Server next sets the N flag to 1 if the source link- 1616 layer address in the RS message was different than the address in the 1617 first SLLAO to indicate that there is a NAT on the path. The Server 1618 then includes one or more RIOs that encode the ASPs for the AERO 1619 link. The Server also includes two MTU options - the first MTU 1620 option includes the MTU for the link and the second MTU option 1621 includes the MSU for the link (see Section 3.12). The Server finally 1622 sends the RA message to the Client. 1624 The Server next creates a static neighbor cache entry for the Client 1625 using the base AERO address as the network-layer address and with 1626 lifetime set to no more than the smallest PD lifetime. Next, the 1627 Server updates the neighbor cache entry link-layer address(es) by 1628 recording the information in each SLLAO in the RS indexed by the 1629 Interface ID and including the UDP port number, IP address and P(i) 1630 values. For the first SLLAO in the list, however, the Server records 1631 the actual encapsulation source UDP and IP addresses instead of those 1632 that appear in the SLLAO in case there was a NAT in the path. The 1633 Server also records the value of the X bit to indicate whether there 1634 is a Proxy on the path. 1636 After the initial RS/RA exchange, the AERO Server maintains the 1637 neighbor cache entry for the Client until the PD lifetimes expire. 1638 If the Client (or Proxy) issues additional RS messages with PD 1639 renewal parameters, the Server extends the PD lifetimes. If the 1640 Client (or Proxy) issues an RS with PD release parameters, or if the 1641 Client (or Proxy) does not issue a renewal before the lifetime 1642 expires, the Server deletes the neighbor cache entry for the Client 1643 and withdraws the IP routes from the AERO routing system. The Server 1644 processes these and any other Client PD messages, and returns an RA 1645 reply. The Server may also issue an unsolicited RA message with PD 1646 reconfigure parameters to inform the Client that it needs to 1647 renegotiate its PDs. 1649 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1651 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 1652 Servers are always on the same link (i.e., the AERO link) from the 1653 perspective of DHCPv6. However, in some implementations the DHCPv6 1654 server and ND function may be located in separate modules. In that 1655 case, the Server's AERO interface module can act as a Lightweight 1656 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 1657 the DHCPv6 server module. 1659 When the LDRA receives an authentic RS message, it extracts the PD 1660 message parameters and uses them to fabricate an IPv6/UDP/DHCPv6 1661 message. It sets the IPv6 source address to the source address of 1662 the RS message, sets the IPv6 destination address to 1663 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 1664 that will be understood by the DHCPv6 server. 1666 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 1667 header and includes an 'Interface-Id' option that includes enough 1668 information to allow the LDRA to forward the resulting Reply message 1669 back to the Client (e.g., the Client's link-layer addresses, a 1670 security association identifier, etc.). The LDRA also wraps the 1671 information in all of the SLLAOs from the RS message into the 1672 Interface-Id option, then forwards the message to the DHCPv6 server. 1674 When the DHCPv6 server prepares a Reply message, it wraps the message 1675 in a 'Relay-Reply' message and echoes the Interface-Id option. The 1676 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1677 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1678 uses the DHCPv6 message to fabricate an RA response to the Client. 1679 The Server uses the information in the Interface-Id option to prepare 1680 the RA message and to cache the link-layer addresses taken from the 1681 SLLAOs echoed in the Interface-Id option. 1683 3.15. The AERO Proxy 1685 In some environments, Clients may be located in secured subnetwork 1686 enclaves that do not allow direct communications from the Client to a 1687 Server in the outside Internetwork. In that case, the secured 1688 enclave can employ an AERO Proxy. 1690 The Proxy is located at the secured enclave perimeter and listens for 1691 encapsulated RS messages originating from or RA messages destined to 1692 Clients located within the enclave. The Proxy acts on these control 1693 messages as follows: 1695 o when the Proxy receives an RS message from a Client within the 1696 secured enclave, it first authenticates the message then creates a 1697 proxy neighbor cache entry for the Client in the INCOMPLETE State 1698 and caches the Client and Server link-layer addresses along with 1699 any identifying information including Transaction IDs, Client 1700 Identifiers, Nonce values, etc. The Proxy then re-encapsulates 1701 the RS message using its own external address as the source link- 1702 layer address, sets the X flag in the first SLLAO to '1', and 1703 forwards the message to the Server. 1705 o when the Server receives the RS message, it authenticates the 1706 message then creates a static neighbor cache entry for the Client 1707 with the Proxy's address as the link-layer address. The Server 1708 then sends an RA message back to the Proxy. 1710 o when the Proxy receives the RA message, it matches the message 1711 with the RS that created the (INCOMPLETE) proxy neighbor cache 1712 entry. The Proxy then caches the route information in the message 1713 as a mapping from the Client's ACPs to the Client's address within 1714 the secured enclave, and sets the neighbor cache entry state to 1715 REACHABLE. The Proxy then re-encapsulates the RA message using 1716 its own internal address as the source link-layer address, sets 1717 the X flag in the first SLLAO to '1', and forwards the message to 1718 the Client. 1720 After the initial RS/RA exchange, the Proxy forwards data packets 1721 between the Client and Server with the Server acting as the Client's 1722 default router. The Proxy can send RS messages to the Client's 1723 Server(s) to update Server neighbor cache entries on behalf of the 1724 Client, e.g., to refresh neighbor cache entry lifetimes and/or to 1725 convey QoS updates. The Proxy also forwards any Client control and 1726 data messages to the Client's primary Server. 1728 In some subnetworks that employ a Proxy, the Client's ACP can be 1729 injected into the underlying network routing system. In that case, 1730 the Client can send data messages without encapsulation so that the 1731 native underlying network routing system transports the 1732 unencapsulated packets to the Proxy. This can be very beneficial, 1733 e.g., if the Client connects to the network via low-end data links 1734 such as some aviation wireless links. In that case, however, the 1735 Client's control messages are still sent encapsulated so as to supply 1736 the Proxy with the address of the Server and to transport IPv6 ND 1737 messages without decrementing the hop-count. In summary, the 1738 interface becomes one where control messages are encapsulated while 1739 data messages are either unencapsulated or encapsulated according to 1740 the specific use case. This encapsulation avoidance represents a 1741 form of "header compression", meaning that the MTU should be sized 1742 based on the size of full encapsulated messages even if most messages 1743 are sent unencapsulated. 1745 3.16. AERO Route Optimization 1747 While data packets are flowing from a source Client to a target 1748 Client that are both holders of ACPs belonging to the same AERO link, 1749 route optimization SHOULD be used to avoid sending traffic through 1750 sub-optimal routes that consume expensive resources. Route 1751 optimization is conducted on a per-interface basis based on the 1752 source Client's available underlying interfaces, and may need to 1753 involve Proxies and Servers in the process. 1755 Route optimization is initiated by the first eligible AERO node 1756 closest to the source Client (i.e., the route optimization source) as 1757 follows: 1759 o For VPNed, NATed and Direct underlying interfaces, the Server is 1760 the route optimization source. 1762 o For Proxyed underlying interfaces, the Proxy is the route 1763 optimization source. 1765 o For native underlying interfaces, the Client itself is the route 1766 optimization source. 1768 While the source Client sends data packets toward a target Client, 1769 the route optimization source also sends an NS message to receive a 1770 solicited NA message from a target Server acting as a Mobility Anchor 1771 Point (MAP) for the target Client. The route optimization process 1772 parallels IPv6 ND Address Resolution. 1774 The NS includes the AERO address of the route optimization source as 1775 the network-layer source address, the AERO address corresponding to 1776 the data packet's destination address as the network-layer 1777 destination address, and the route optimization source address as the 1778 link-layer source address. For Clients and Proxies as the route 1779 optimization source, the address of the Client's Server is used as 1780 the link-layer destination address. For Servers as the route 1781 optimization source, the address of a Relay is used as the link-layer 1782 destination address. The NS message also includes a single SLLAO 1783 with the route optimization source address in the UDP Port Number and 1784 IP address fields. Finally, the NS message includes a Timestamp and 1785 Nonce option that can be used to match against the corresponding 1786 solicited NA. 1788 When the source Server receives or originates the NS message, it 1789 inserts an additional mid-layer IP encapsulation header between the 1790 NS message link-layer and network-layer headers. This mid-layer IP 1791 header uses the AERO Server Subnet Router Anycast address as the 1792 source address and the Subnet Router Anycast address corresponding to 1793 the target AERO address as the destination address. The source 1794 Server then changes the link-layer source address to its own address 1795 and the link-layer destination address to the address of a Relay. 1796 The Server finally forwards the message to the Relay without 1797 decrementing the network-layer TTL/Hop Limit field. 1799 When the Relay receives the double-encapsulated NS message from the 1800 source Server, it discards the link-layer header(s) and determines 1801 that the target Server is the next hop toward the target Client by 1802 consulting its standard IP forwarding table for the Client Subnet 1803 Router Anycast destination address. The Relay then encapsulates and 1804 forwards the message to the target Server the same as for any IP 1805 router. 1807 When the target Server receives the double-encapsulated NS message 1808 from the Relay, it removes the link-layer and mid-layer headers and 1809 examines the network-layer destination address to determine whether 1810 the target Client is one of its static neighbors. If the target 1811 Client is not a static neighbor, the target Server discards the NS 1812 and prepares an NA message with no TLLAOs to send back to the route 1813 optimization source. The target Server then encapsulates the NA 1814 message and sets the link-layer source address to its own address and 1815 sets the link-layer destination address to the address found in the 1816 NS SLLAO. The target Server finally includes the Nonce value 1817 received in the NS plus the current Timestamp, then sends the NA 1818 message to the route optimization source. 1820 Otherwise, the target Server adds the link-layer address found in the 1821 NS SLLAO to the "Report" list for the target Client's neighbor cache 1822 entry with timer set to ReportTime seconds, but it does not create or 1823 update a neighbor cache entry. The target Server then prepares an NA 1824 message to send back to the route optimization source. The NA 1825 message includes a first TLLAO with the target Server's address in 1826 the IP address and UDP Port Number, with Interface ID set to '255', 1827 with all P(i) values set to "low" and with "Prefix Length" set to the 1828 prefix length of the target Client's ACP. The NA message then 1829 includes additional TLLAOs for all of the target Client's underlying 1830 interfaces. For NATed, VPNed and Direct interfaces, the TLLAO 1831 addresses are the address of the Server. For Proxyed interfaces, the 1832 TLLAO addresses are the addresses of the Proxies, and for native 1833 interfaces the TLLAO addresses are the addresses of the Client. The 1834 target Server then encapsulates the NA message and sets the link- 1835 layer source address to its own address and sets the link-layer 1836 destination address to the address found in the NS SLLAO. The target 1837 Server finally includes the Nonce value received in the NS plus the 1838 current Timestamp, then sends the NA message to the route 1839 optimization source. 1841 When the route optimization source receives the NA message, it 1842 verifies the Nonce and Timestamp. If there are no TLLAOs, the route 1843 optimization source discards the message; otherwise, it creates a 1844 dynamic neighbor cache entry for the target Client and caches all 1845 address, Interface ID, P(i) and Prefix Length information found in 1846 the NA TLLAOs. The route optimization source also sets the neighbor 1847 cache entry state to REACHABLE and sets the timeout value to 1848 ReachableTime. Future data packets that flow through the route 1849 optimization source will then go directly to the target Client 1850 instead of traveling through a dogleg route involving unnecessary 1851 Servers and/or Relays. The route optimization further is shared by 1852 all sources that send packets to the target Client, i.e., and not 1853 just the original source Client. 1855 While new data packets destined to the target are flowing through the 1856 route optimization source, it sends additional NS messages to the 1857 target Server before ReachableTime expires to receive a fresh NA 1858 message. The route optimization source then updates the dynamic 1859 neighbor cache entry to refresh ReachableTime, while the target 1860 Server updates the target Client's static neighbor cache entry to 1861 refresh ReportTime. While no data packets are flowing, the route 1862 optimization source instead allows the dynamic neighbor cache entry 1863 to expire. Following expiration, future data packets flowing through 1864 the route optimization source will again trigger a new route 1865 optimization exchange while initial data packets travel over a 1866 suboptimal route via Servers and/or Relays. 1868 In this arrangement, the route optimization source holds a dynamic 1869 neighbor cache entry for the target, but the target does not hold a 1870 dynamic neighbor cache entry for the route optimization source. The 1871 route optimization neighbor relationship is therefore asymmetric and 1872 unidirectional. If the target Client also has packets to send back 1873 to the source Client, then a separate route optimization procedure is 1874 required in the reverse direction. But, there is no requirement that 1875 the forward and reverse paths be symmetric. 1877 3.17. Neighbor Unreachability Detection (NUD) 1879 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1880 NS messages to elicit solicited NA messages from the target node the 1881 same as described in [RFC4861]. NUD is performed either reactively 1882 in response to persistent link-layer errors (see Section 3.13) or 1883 proactively to confirm reachability in the forward direction. 1885 When an AERO node sends an NS/NA message, it uses one of its link- 1886 local addresses as the IPv6 source address and a link-local address 1887 of the neighbor as the IPv6 destination address. When route 1888 optimization directs a source AERO node to a target AERO node, the 1889 source node SHOULD proactively test the direct path by sending an 1890 initial NS message to elicit a solicited NA response. While testing 1891 the path, the source node can optionally continue sending packets via 1892 its default router, maintain a small queue of packets until target 1893 reachability is confirmed, or (optimistically) allow packets to flow 1894 directly to the target. 1896 Note that AERO nodes may have multiple underlying interface paths 1897 toward the target neighbor. In that case, NUD SHOULD be performed 1898 over each underlying interface individually and the node should only 1899 consider the neighbor unreachable if NUD fails over multiple 1900 underlying interface paths. 1902 Underlying interface paths that pass NUD tests are marked as 1903 "reachable", while those that do not are marked as "unreachable". 1904 These markings inform the AERO interface forwarding algorithm 1905 specified in Section 3.8. 1907 3.18. Mobility Management and Quality of Service (QoS) 1909 AERO is an example of a Distributed Mobility Management (DMM) 1910 service. Each Server is responsible for only a subset of the Clients 1911 on the AERO link, as opposed to a Centralized Mobility Management 1912 (CMM) service where there is a single network mobility service for 1913 all Clients. Clients coordinate with their associated Servers via 1914 RS/RA exchanges to maintain the DMM profile, and the AERO routing 1915 system tracks all current Client/Server peering relationships. 1917 Servers provide a Mobility Anchor Point (MAP) for their dependent 1918 Clients. Clients are responsible for maintaining neighbor 1919 relationships with their Servers through periodic RS/RA exchanges, 1920 which also serves to confirm Client reachability. When a Client's 1921 underlying interface address and/or QoS information changes, the 1922 Client is responsible for updating the Server with this new 1923 information. (Note that for Proxyed interfaces, however, the Proxy 1924 can perform the RS/RA exchanges on the Client's behalf.) 1926 Mobility management considerations are specified in the following 1927 sections. 1929 3.18.1. Mobility Update Messaging 1931 AERO Servers accommodate mobility and/or QoS change events by sending 1932 unsolicited NA messages to all route optimization sources for the 1933 Client. When a Server sends an unsolicited NA message, it sets the 1934 IPv6 source address to the Client's AERO address, sets the IPv6 1935 destination address to all-nodes multicast, sets the link-layer 1936 source address to its own address and sets the link-layer destination 1937 address to either a multicast address or the unicast link-layer 1938 address of a route optimization source in the Client's Report list. 1939 If there are multiple route optimization sources, the node sends 1940 identical unicast copies of the unsolicited NA to each source. 1942 As for the hot-swap of interface cards discusssed in Section 7.2.6 of 1943 [RFC4861], the transmission and reception of unsolicited NA messages 1944 is unreliable but provided as a useful optimization. The Server can 1945 send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to each route 1946 optimization source, but in the normal case sends only one. 1948 When a route optimization source receives an unsolicited NA message, 1949 it ignores the message if there is no existing neighbor cache entry 1950 for the Client. Otherwise, it uses the included TLLAOs to update the 1951 address and QoS information in the neighbor cache entry, but does not 1952 reset ReachableTime since the receipt of an unsolicited NA message 1953 from the target Server does not provide confirmation that any forward 1954 paths to the target Client are working. 1956 If unsolicited NA messages are lost, the route optimization source 1957 may be left with stale address and/or QoS information for the Client 1958 for up to ReachableTime seconds. During this time, the route 1959 optimization source can continue sending packets to the target Client 1960 according to its current neighbor cache information but may receive 1961 persistent Destination Unreachable messages and/or unsolicited NA 1962 messages with no TLLAOs as discussed in Section 3.18.2. In that 1963 case, the route optimization source SHOULD re-initiate route 1964 optimization immediately instead of waiting for ReachableTime to 1965 expire. 1967 3.18.2. Forwarding Packets on Behalf of Departed Clients 1969 When a Server receives packets with destination addresses that do not 1970 match one of its static neighbor cache Clients, it forwards the 1971 packets to a Relay which delivers them to the target Client's current 1972 location. If the source is not one of its static neighbor Clients, 1973 the Server also returns an unsolicited NA message to the source with 1974 no TLLAOs - the sender will then realize that it needs to delete its 1975 neighbor cache entry that associated the target with this Server and 1976 re-initiate route optimization. 1978 When a Proxy receives packets with destination addresses that do not 1979 match of its proxy neighbor cache Clients, if forwards the packets to 1980 a Server which delivers them to the target Client's current location. 1981 If the source is not one of its proxy neighbor Clients, the Proxy 1982 also returns an unsolicited NA message to the source with no TLLAOs 1983 the same as described for Servers above. 1985 When a Client receives packets with destination addresses that do not 1986 match one of its ACPs, it drops the packets and returns an 1987 unsolicited NA message to the source with no TLLAOs. 1989 3.18.3. Announcing Link-Layer Address and/or QoS Preference Changes 1991 When a Client needs to change its link-layer addresses and/or QoS 1992 preferences (e.g., due to a mobility event), either the Client or 1993 Proxy sends RS messages to its Servers using the new link-layer 1994 address as the source address and with TLLAOs that include the new 1995 Client UDP Port Number, IP Address and P(i) values. If the RS 1996 messages are sent solely for the purpose of updating QoS preferences 1997 without updating the link-layer address, the UDP Port Number and IP 1998 Address are set to 0. 2000 Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with 2001 sending actual data packets in case one or more RAs are lost. If all 2002 RAs are lost, the Client SHOULD re-associate with a new Server. 2004 3.18.4. Bringing New Links Into Service 2006 When a Client needs to bring new underlying interfaces into service 2007 (e.g., when it activates a new data link), it sends RS messages to 2008 its Servers using the new link-layer address as the source address 2009 and with TLLAOs that include the new Client link-layer information. 2011 3.18.5. Removing Existing Links from Service 2013 When a Client needs to remove existing underlying interfaces from 2014 service (e.g., when it de-activates an existing data link), it sends 2015 RS messages to its Servers with SLLAOs with all P(i) values set to 0. 2017 If the Client needs to send RS messages over an underlying interface 2018 other than the one being removed from service, it MUST include a 2019 current SLLAO for the sending interface as the first SLLAO and 2020 include SLLAOs for any underlying interface being removed from 2021 service as additional TLLAOs. 2023 3.18.6. Implicit Mobility Management 2025 AERO interface neighbors MAY provide a configuration option that 2026 allows them to perform implicit mobility management in which no ND 2027 messaging is used. In that case, the Client only transmits packets 2028 over a single interface at a time, and the neighbor always observes 2029 packets arriving from the Client from the same link-layer source 2030 address. 2032 If the Client's underlying interface address changes (either due to a 2033 readdressing of the original interface or switching to a new 2034 interface) the neighbor immediately updates the neighbor cache entry 2035 for the Client and begins accepting and sending packets to the 2036 Client's new link-layer address. This implicit mobility method 2037 applies to use cases such as cellphones with both WiFi and Cellular 2038 interfaces where only one of the interfaces is active at a given 2039 time, and the Client automatically switches over to the backup 2040 interface if the primary interface fails. 2042 3.18.7. Moving to a New Server 2044 When a Client associates with a new Server, it performs the Client 2045 procedures specified in Section 3.14.2. The Client then sends RS 2046 messages with PD release parameters to the old Server to release 2047 itself from that Server's domain. If the Client does not receive an 2048 RA reply after MAX_RTR_SOLICITATIONS attempts, the old Server may 2049 have failed and the Client should discontinue its release attempts. 2050 When the old Server processes the PD release, it sends unsolicited NA 2051 messages with no TLLAOs to all route optimization sources in the 2052 Client's Report list. 2054 Clients SHOULD NOT move rapidly between Servers in order to avoid 2055 causing excessive oscillations in the AERO routing system. Such 2056 oscillations could result in intermittent reachability for the Client 2057 itself, while causing no harm to the network. Examples of when a 2058 Client might wish to change to a different Server include a Server 2059 that has gone unreachable, topological movements of significant 2060 distance, movement to a new geographic region, etc. 2062 3.19. Multicast Considerations 2064 When the underlying network does not support multicast, AERO Clients 2065 map link-scoped multicast addresses to the link-layer address of a 2066 Server, which acts as a multicast forwarding agent. The AERO Client 2067 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2068 applications per [RFC4605] while using the link-layer address of the 2069 Server as the link-layer address for all multicast packets. 2071 When the underlying network supports multicast, AERO nodes use the 2072 multicast address mapping specification found in [RFC2529] for IPv4 2073 underlying networks and use a TBD site-scoped multicast mapping for 2074 IPv6 underlying networks. In that case, border routers must ensure 2075 that the encapsulated site-scoped multicast packets do not leak 2076 outside of the site spanned by the AERO link. 2078 4. Direct Underlying Interfaces 2080 When a Client's AERO interface is configured over a Direct underlying 2081 interface, the neighbor at the other end of the Direct link can 2082 receive packets without any encapsulation. In that case, the Client 2083 sends packets over the Direct link according to the QoS preferences 2084 associated with its underling interfaces. If the Direct underlying 2085 interface has the highest QoS preference, then the Client's IP 2086 packets are transmitted directly to the peer without going through an 2087 underlying network. If other underlying interfaces have higher QoS 2088 preferences, then the Client's IP packets are transmitted via a 2089 different underlying interface, which may result in the inclusion of 2090 Proxies, Servers and Relays in the communications path. Direct 2091 underlying interfaces must be tested periodically for reachability, 2092 e.g., via NUD. 2094 5. Operation on AERO Links with /64 ASPs 2096 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2097 length /64 or shorter. However, in some cases it may be desirable to 2098 use AERO over links that have only a /64 ASP. This can be 2099 accommodated by treating all Clients on the AERO link as simple hosts 2100 that receive /128 prefix delegations. 2102 In that case, the Client sends an RS message to the Server the same 2103 as for ordinary AERO links. The Server responds with an RA message 2104 that includes one or more /128 prefixes (i.e., singleton addresses) 2105 that include the /64 ASP prefix along with an interface identifier 2106 portion to be assigned to the Client. The Client and Server then 2107 configure their AERO addresses based on the interface identifier 2108 portions of the /128s (i.e., the lower 64 bits) and not based on the 2109 /64 prefix (i.e., the upper 64 bits). 2111 For example, if the ASP for the host-only IPv6 AERO link is 2112 2001:db8:1000:2000::/64, each Client will receive one or more /128 2113 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2114 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2115 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2116 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2117 /128s) to either the AERO interface or an internal virtual interface 2118 such as a loopback. In this arrangement, the Client conducts route 2119 optimization in the same sense as discussed in Section 3.16. 2121 This specification has applicability for nodes that act as a Client 2122 on an "upstream" AERO link, but also act as a Server on "downstream" 2123 AERO links. More specifically, if the node acts as a Client to 2124 receive a /64 prefix from the upstream AERO link it can then act as a 2125 Server to provision /128s to Clients on downstream AERO links. 2127 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) 2129 SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically 2130 Generated Addresses (CGAs) [RFC3972] were designed to secure IPv6 ND 2131 messaging in environments where symmetric network and/or transport- 2132 layer security services are impractical (see: Section 10). AERO 2133 nodes that use SEND/CGA employ the following adaptations. 2135 When a source AERO node prepares a SEND-protected ND message, it uses 2136 a link-local CGA as the IPv6 source address and writes the prefix 2137 embedded in its AERO address (i.e., instead of fe80::/64) in the CGA 2138 parameters Subnet Prefix field. When the neighbor receives the ND 2139 message, it first verifies the message checksum and SEND/CGA 2140 parameters while using the link-local prefix fe80::/64 (i.e., instead 2141 of the value in the Subnet Prefix field) to match against the IPv6 2142 source address of the ND message. 2144 The neighbor then derives the AERO address of the source by using the 2145 value in the Subnet Prefix field as the interface identifier of an 2146 AERO address. For example, if the Subnet Prefix field contains 2147 2001:db8:1:2, the neighbor constructs the AERO address as 2148 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 2149 neighbor cache entry it creates for the source, and uses the AERO 2150 address as the IPv6 destination address of any ND message replies. 2152 7. AERO Critical Infrastructure Considerations 2154 AERO Relays are low-end to midrange Commercial off-the Shelf (COTS) 2155 standard IP routers with no AERO code. Relays must be provisioned, 2156 supported and managed by the AERO Link Service Provider. Cost for 2157 purchasing, configuring and managing Relays is nominal even for very 2158 large AERO links. 2160 AERO Servers can be standard dedicated server platforms, but most 2161 often will be deployed as virtual machines in the cloud. The only 2162 requirements for Servers are that they can run the AERO user-level 2163 code and have at least one network interface with a public IP 2164 address. As with Relays, Servers must be provisioned, supported and 2165 managed by the AERO Link Service Provider. Cost for purchasing, 2166 configuring and managing Servers is nominal especially for virtual 2167 Servers hosted in the cloud. 2169 AERO Proxies are most often standard dedicated server platforms with 2170 one network interface connected to the secured enclave and a second 2171 interface connected to the public Internetwork. As with Servers, the 2172 only requirements are that they can run the AERO user-level code and 2173 have at least one interface with a public IP address. Proxies must 2174 be provisioned, supported and managed by the administrative authority 2175 for the secured enclave. Cost for purchasing, configuring and 2176 managing Proxies is nominal, and borne by the secured enclave 2177 administrative authority. 2179 8. Implementation Status 2181 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2182 announced on the v6ops mailing list on January 10, 2018. The latest 2183 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2184 2.0.tgz. 2186 An initial public release of the AERO proof-of-concept source code 2187 was announced on the intarea mailing list on August 21, 2015. The 2188 latest version is available at: http://linkupnetworks.net/aero/aero- 2189 4.0.0.tgz. 2191 A survey of public domain and commercial SEND implementations is 2192 available at https://www.ietf.org/mail-archive/web/its/current/ 2193 msg02758.html. 2195 9. IANA Considerations 2197 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2198 AERO in the "enterprise-numbers" registry. 2200 The IANA has assigned the UDP port number "8060" for an earlier 2201 experimental version of AERO [RFC6706]. This document obsoletes 2202 [RFC6706] and claims the UDP port number "8060" for all future use. 2204 No further IANA actions are required. 2206 10. Security Considerations 2208 AERO link security considerations include considerations for both the 2209 data plane and the control plane. 2211 Data plane security considerations are the same as for ordinary 2212 Internet communications. Application endpoints in AERO Clients and 2213 their EUNs SHOULD use application-layer security services such as 2214 TLS/SSL [RFC5246], DTLS [RFC6347] or SSH [RFC4251] to assure the same 2215 level of protection as for critical secured Internet services such as 2216 online banking. AERO Clients that require VPN access to enterprise 2217 networks SHOULD use symmetric network and/or transport layer security 2218 services such as TLS/SSL, DTLS, IPsec [RFC4301], etc. 2220 Control plane security considerations are the same as for standard 2221 IPv6 Neighbor Discovery [RFC4861], except that the PRL also improves 2222 security by providing AERO Clients with a list of trusted Servers. 2223 As fixed infrastructure elements, AERO Proxies and Servers SHOULD 2224 pre-configure security associations for one another (e.g., using pre- 2225 placed keys) and use symmetric network and/or transport layer 2226 security services such as IPsec, TLS/SSL or DTLS to secure ND 2227 messages. AERO Clients that connect to secured enclaves need not 2228 apply security to their ND messages, since the messages will be 2229 intercepted by an enclave perimeter Proxy. AERO Clients located 2230 outside of secured enclaves SHOULD use symmetric network and/or 2231 transport layer security to secure their ND exchanges with Servers, 2232 but when there are many prospective neighbors with dynamically 2233 changing connectivity an asymmetric security service such as SEND may 2234 be needed (see: Section 6). 2236 AERO Servers and Relays present targets for traffic amplification 2237 Denial of Service (DoS) attacks. This concern is no different than 2238 for widely-deployed VPN security gateways in the Internet, where 2239 attackers could send spoofed packets to the gateways at high data 2240 rates. This can be mitigated by connecting Relays and Servers over 2241 dedicated links with no connections to the Internet and/or when 2242 connections to the Internet are only permitted through well-managed 2243 firewalls. Traffic amplification DoS attacks can also target an AERO 2244 Client's low data rate links. This is a concern not only for Clients 2245 located on the open Internet but also for Clients in secured 2246 enclaves. AERO Servers and Proxies can institute rate limits that 2247 protect Clients from receiving packet floods that could DoS low data 2248 rate links. 2250 AERO Clients MUST ensure that their connectivity is not used by 2251 unauthorized nodes on their EUNs to gain access to a protected 2252 network, i.e., AERO Clients that act as routers MUST NOT provide 2253 routing services for unauthorized nodes. (This concern is no 2254 different than for ordinary hosts that receive an IP address 2255 delegation but then "share" the address with other nodes via some 2256 form of Internet connection sharing such as tethering.) 2258 Although public domain and commercial SEND implementations exist, 2259 concerns regarding the strength of the cryptographic hash algorithm 2260 have been documented [RFC6273] [RFC4982]. 2262 The PRL MUST be well-managed and secured from unauthorized tampering, 2263 even though the list includes only public information. 2265 Security considerations for accepting link-layer ICMP messages and 2266 reflected packets are discussed throughout the document. 2268 11. Acknowledgements 2270 Discussions in the IETF, aviation standards communities and private 2271 exchanges helped shape some of the concepts in this work. 2272 Individuals who contributed insights include Mikael Abrahamsson, Mark 2273 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2274 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2275 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2276 Hlusiak, Lee Howard, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy 2277 Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru 2278 Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, 2279 Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members 2280 of the IESG also provided valuable input during their review process 2281 that greatly improved the document. Special thanks go to Stewart 2282 Bryant, Joel Halpern and Brian Haberman for their shepherding 2283 guidance during the publication of the AERO first edition. 2285 This work has further been encouraged and supported by Boeing 2286 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2287 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2288 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2289 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Greg 2290 Saccone, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan 2291 Williams, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 2292 BR&T and BIT mobile networking teams. Kyle Bae, Wayne Benson and 2293 Eric Yeh are especially acknowledged for implementing the AERO 2294 functions as extensions to the public domain OpenVPN distribution. 2296 Earlier works on NBMA tunneling approaches are found in 2297 [RFC2529][RFC5214][RFC5569]. 2299 Many of the constructs presented in this second edition of AERO are 2300 based on the author's earlier works, including: 2302 o The Internet Routing Overlay Network (IRON) 2303 [RFC6179][I-D.templin-ironbis] 2305 o Virtual Enterprise Traversal (VET) 2306 [RFC5558][I-D.templin-intarea-vet] 2308 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2309 [RFC5320][I-D.templin-intarea-seal] 2311 o AERO, First Edition [RFC6706] 2313 Note that these works cite numerous earlier efforts that are not also 2314 cited here due to space limitations. The authors of those earlier 2315 works are acknowledged for their insights. 2317 This work is aligned with the NASA Safe Autonomous Systems Operation 2318 (SASO) program under NASA contract number NNA16BD84C. 2320 This work is aligned with the FAA as per the SE2025 contract number 2321 DTFAWA-15-D-00030. 2323 This work is aligned with the Boeing Information Technology (BIT) 2324 MobileNet program. 2326 This work is aligned with the Boeing autonomy program. 2328 12. References 2330 12.1. Normative References 2332 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2333 DOI 10.17487/RFC0768, August 1980, 2334 . 2336 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2337 DOI 10.17487/RFC0791, September 1981, 2338 . 2340 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2341 RFC 792, DOI 10.17487/RFC0792, September 1981, 2342 . 2344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2345 Requirement Levels", BCP 14, RFC 2119, 2346 DOI 10.17487/RFC2119, March 1997, 2347 . 2349 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2350 "Definition of the Differentiated Services Field (DS 2351 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2352 DOI 10.17487/RFC2474, December 1998, 2353 . 2355 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2356 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2357 DOI 10.17487/RFC3971, March 2005, 2358 . 2360 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2361 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2362 . 2364 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2365 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2366 November 2005, . 2368 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2369 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2370 . 2372 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2373 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2374 DOI 10.17487/RFC4861, September 2007, 2375 . 2377 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2378 Address Autoconfiguration", RFC 4862, 2379 DOI 10.17487/RFC4862, September 2007, 2380 . 2382 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2383 Advertisement Flags Option", RFC 5175, 2384 DOI 10.17487/RFC5175, March 2008, 2385 . 2387 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2388 (IPv6) Specification", STD 86, RFC 8200, 2389 DOI 10.17487/RFC8200, July 2017, 2390 . 2392 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2393 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2394 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2395 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2396 . 2398 12.2. Informative References 2400 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2401 2016. 2403 [I-D.ietf-dmm-distributed-mobility-anchoring] 2404 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 2405 "Distributed Mobility Anchoring", draft-ietf-dmm- 2406 distributed-mobility-anchoring-12 (work in progress), 2407 January 2019. 2409 [I-D.ietf-intarea-gue] 2410 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2411 Encapsulation", draft-ietf-intarea-gue-06 (work in 2412 progress), August 2018. 2414 [I-D.ietf-intarea-gue-extensions] 2415 Herbert, T., Yong, L., and F. Templin, "Extensions for 2416 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2417 extensions-05 (work in progress), August 2018. 2419 [I-D.ietf-intarea-tunnels] 2420 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2421 Architecture", draft-ietf-intarea-tunnels-09 (work in 2422 progress), July 2018. 2424 [I-D.ietf-rtgwg-atn-bgp] 2425 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2426 Moreno, "A Simple BGP-based Mobile Routing System for the 2427 Aeronautical Telecommunications Network", draft-ietf- 2428 rtgwg-atn-bgp-01 (work in progress), January 2019. 2430 [I-D.templin-6man-aeroaddr] 2431 Templin, F., "The AERO Address", draft-templin-6man- 2432 aeroaddr-04 (work in progress), December 2018. 2434 [I-D.templin-6man-dhcpv6-ndopt] 2435 Templin, F., "A Unified Stateful/Stateless Configuration 2436 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07 2437 (work in progress), December 2018. 2439 [I-D.templin-6man-rio-redirect] 2440 Templin, F. and j. woodyatt, "Route Information Options in 2441 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2442 redirect-07 (work in progress), December 2018. 2444 [I-D.templin-intarea-grefrag] 2445 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2446 templin-intarea-grefrag-04 (work in progress), July 2016. 2448 [I-D.templin-intarea-seal] 2449 Templin, F., "The Subnetwork Encapsulation and Adaptation 2450 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2451 progress), January 2014. 2453 [I-D.templin-intarea-vet] 2454 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2455 templin-intarea-vet-40 (work in progress), May 2013. 2457 [I-D.templin-ironbis] 2458 Templin, F., "The Interior Routing Overlay Network 2459 (IRON)", draft-templin-ironbis-16 (work in progress), 2460 March 2014. 2462 [I-D.templin-v6ops-pdhost] 2463 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 2464 Models", draft-templin-v6ops-pdhost-23 (work in progress), 2465 December 2018. 2467 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2469 [RFC1035] Mockapetris, P., "Domain names - implementation and 2470 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2471 November 1987, . 2473 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2474 Communication Layers", STD 3, RFC 1122, 2475 DOI 10.17487/RFC1122, October 1989, 2476 . 2478 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2479 DOI 10.17487/RFC1191, November 1990, 2480 . 2482 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2483 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2484 . 2486 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2487 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2488 1996, . 2490 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2491 DOI 10.17487/RFC2003, October 1996, 2492 . 2494 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2495 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2496 . 2498 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2499 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2500 December 1998, . 2502 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2503 Domains without Explicit Tunnels", RFC 2529, 2504 DOI 10.17487/RFC2529, March 1999, 2505 . 2507 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2508 Malis, "A Framework for IP Based Virtual Private 2509 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2510 . 2512 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2513 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2514 DOI 10.17487/RFC2784, March 2000, 2515 . 2517 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2518 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2519 . 2521 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2522 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2523 . 2525 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2526 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2527 . 2529 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2530 of Explicit Congestion Notification (ECN) to IP", 2531 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2532 . 2534 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2535 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2536 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2537 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2538 . 2540 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2541 for IPv6 Hosts and Routers", RFC 4213, 2542 DOI 10.17487/RFC4213, October 2005, 2543 . 2545 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2546 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 2547 January 2006, . 2549 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2550 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2551 DOI 10.17487/RFC4271, January 2006, 2552 . 2554 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2555 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2556 2006, . 2558 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2559 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2560 December 2005, . 2562 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2563 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2564 2006, . 2566 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2567 Control Message Protocol (ICMPv6) for the Internet 2568 Protocol Version 6 (IPv6) Specification", STD 89, 2569 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2570 . 2572 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2573 Protocol (LDAP): The Protocol", RFC 4511, 2574 DOI 10.17487/RFC4511, June 2006, 2575 . 2577 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2578 "Internet Group Management Protocol (IGMP) / Multicast 2579 Listener Discovery (MLD)-Based Multicast Forwarding 2580 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2581 August 2006, . 2583 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2584 Errors at High Data Rates", RFC 4963, 2585 DOI 10.17487/RFC4963, July 2007, 2586 . 2588 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 2589 Algorithms in Cryptographically Generated Addresses 2590 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 2591 . 2593 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2594 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2595 DOI 10.17487/RFC5214, March 2008, 2596 . 2598 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2599 (TLS) Protocol Version 1.2", RFC 5246, 2600 DOI 10.17487/RFC5246, August 2008, 2601 . 2603 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2604 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2605 February 2010, . 2607 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2608 Route Optimization Requirements for Operational Use in 2609 Aeronautics and Space Exploration Mobile Networks", 2610 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2611 . 2613 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2614 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2615 . 2617 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2618 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2619 January 2010, . 2621 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2622 Global Enterprise Recursion (RANGER)", RFC 5720, 2623 DOI 10.17487/RFC5720, February 2010, 2624 . 2626 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2627 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2628 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2629 . 2631 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2632 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2633 . 2635 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2636 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2637 DOI 10.17487/RFC6221, May 2011, 2638 . 2640 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 2641 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 2642 DOI 10.17487/RFC6273, June 2011, 2643 . 2645 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2646 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2647 January 2012, . 2649 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2650 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2651 . 2653 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2654 for Equal Cost Multipath Routing and Link Aggregation in 2655 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2656 . 2658 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2659 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2660 . 2662 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2663 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2664 . 2666 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2667 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2668 March 2017, . 2670 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2671 October 2014. 2673 Appendix A. AERO Alternate Encapsulations 2675 When GUE encapsulation is not needed, AERO can use common 2676 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2677 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2678 encapsulation is therefore only differentiated from non-AERO tunnels 2679 through the application of AERO control messaging and not through, 2680 e.g., a well-known UDP port number. 2682 As for GUE encapsulation, alternate AERO encapsulation formats may 2683 require encapsulation layer fragmentation. For simple IP-in-IP 2684 encapsulation, an IPv6 fragment header is inserted directly between 2685 the inner and outer IP headers when needed, i.e., even if the outer 2686 header is IPv4. The IPv6 Fragment Header is identified to the outer 2687 IP layer by its IP protocol number, and the Next Header field in the 2688 IPv6 Fragment Header identifies the inner IP header version. For GRE 2689 encapsulation, a GRE fragment header is inserted within the GRE 2690 header [I-D.templin-intarea-grefrag]. 2692 Figure 4 shows the AERO IP-in-IP encapsulation format before any 2693 fragmentation is applied: 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | Outer IPv4 Header | | Outer IPv6 Header | 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | Inner IP Header | | Inner IP Header | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | | | | 2703 ~ ~ ~ ~ 2704 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2705 ~ ~ ~ ~ 2706 | | | | 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2711 Figure 4: Minimal Encapsulation Format using IP-in-IP 2713 Figure 5 shows the AERO GRE encapsulation format before any 2714 fragmentation is applied: 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | Outer IP Header | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | GRE Header | 2720 | (with checksum, key, etc..) | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | GRE Fragment Header (optional)| 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | Inner IP Header | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | | 2727 ~ ~ 2728 ~ Inner Packet Body ~ 2729 ~ ~ 2730 | | 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 Figure 5: Minimal Encapsulation Using GRE 2735 Alternate encapsulation may be preferred in environments where GUE 2736 encapsulation would add unnecessary overhead. For example, certain 2737 low-bandwidth wireless data links may benefit from a reduced 2738 encapsulation overhead. 2740 GUE encapsulation can traverse network paths that are inaccessible to 2741 non-UDP encapsulations, e.g., for crossing Network Address 2742 Translators (NATs). More and more, network middleboxes are also 2743 being configured to discard packets that include anything other than 2744 a well-known IP protocol such as UDP and TCP. It may therefore be 2745 necessary to determine the potential for middlebox filtering before 2746 enabling alternate encapsulation in a given environment. 2748 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2749 encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO 2750 control messaging and route determination occur before security 2751 encapsulation is applied for outgoing packets and after security 2752 decapsulation is applied for incoming packets. 2754 AERO is especially well suited for use with VPN system encapsulations 2755 such as OpenVPN [OVPN]. 2757 Appendix B. S/TLLAO Extensions for Special-Purpose Links 2759 The AERO S/TLLAO format specified in Section 3.5 includes a Length 2760 value of 5 (i.e., 5 units of 8 octets). However, special-purpose 2761 links may extend the basic format to include additional fields and a 2762 Length value larger than 5. 2764 For example, adaptation of AERO to the Aeronautical 2765 Telecommunications Network with Internet Protocol Services (ATN/IPS) 2766 includes link selection preferences based on transport port numbers 2767 in addition to the existing DSCP-based preferences. ATN/IPS nodes 2768 maintain a map of transport port numbers to 64 possible preference 2769 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 2770 maps to preference field 20, UDP port 8060 maps to preference field 2771 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 2772 Figure 6, where the Length value is 7 and the 'Q(i)' fields provide 2773 link preferences for the corresponding transport port number. 2775 0 1 2 3 2776 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 2777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 | Type | Length = 7 | Prefix Length | Reserved | 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Interface ID | UDP Port Number | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | | 2783 + + 2784 | | 2785 + IP Address + 2786 | | 2787 + + 2788 | | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 2801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 Figure 6: ATN/IPS Extended S/TLLAO Format 2809 Appendix C. Change Log 2811 << RFC Editor - remove prior to publication >> 2813 Changes from draft-templin-intarea-6706bis-05 to draft-templin- 2814 intrea-6706bis-06: 2816 o Major re-work and simplification of Route Optimization function 2818 o Added Distributed Mobility Management (DMM) and Mobility Anchor 2819 Point (MAP) terminology 2821 o New section on "AERO Critical Infrastructure Element 2822 Considerations" demonstrating low overall cost for the service 2824 o minor text revisions and deletions 2826 o removed extraneous appendices 2828 Changes from draft-templin-intarea-6706bis-04 to draft-templin- 2829 intrea-6706bis-05: 2831 o New Appendix E on S/TLLAO Extensions for special-purpose links. 2832 Discussed ATN/IPS as example. 2834 o New sentence in introduction to declare appendices as non- 2835 normative. 2837 Changes from draft-templin-intarea-6706bis-03 to draft-templin- 2838 intrea-6706bis-04: 2840 o Added definitions for Potential Router List (PRL) and secure 2841 enclave 2843 o Included text on mapping transport layer port numbers to network 2844 layer DSCP values 2846 o Added reference to DTLS and DMM Distributed Mobility Anchoring 2847 working group document 2849 o Reworked Security Considerations 2851 o Updated references. 2853 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 2854 intrea-6706bis-03: 2856 o Added new section on SEND. 2858 o Clarifications on "AERO Address" section. 2860 o Updated references and added new reference for RFC8086. 2862 o Security considerations updates. 2864 o General text clarifications and cleanup. 2866 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 2867 intrea-6706bis-02: 2869 o Note on encapsulation avoidance in Section 4. 2871 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 2872 intrea-6706bis-01: 2874 o Remove DHCPv6 Server Release procedures that leveraged the old way 2875 Relays used to "route" between Server link-local addresses 2877 o Remove all text relating to Relays needing to do any AERO-specific 2878 operations 2880 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 2881 as source addresses, and destination address of RA reply is to the 2882 AERO address corresponding to the Client's ACP. 2884 o Proxy uses SEND to protect RS and authenticate RA (Client does not 2885 use SEND, but rather relies on subnetwork security. When the 2886 Proxy receives an RS from the Client, it creates a new RS using 2887 its own addresses as the source and uses SEND with CGAs to send a 2888 new RS to the Server. 2890 o Emphasize distributed mobility management 2892 o AERO address-based RS injection of ACP into underlying routing 2893 system. 2895 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 2896 6706bis-00: 2898 o Document use of NUD (NS/NA) for reliable link-layer address 2899 updates as an alternative to unreliable unsolicited NA. 2900 Consistent with Section 7.2.6 of RFC4861. 2902 o Server adds additional layer of encapsulation between outer and 2903 inner headers of NS/NA messages for transmission through Relays 2904 that act as vanilla IPv6 routers. The messages include the AERO 2905 Server Subnet Router Anycast address as the source and the Subnet 2906 Router Anycast address corresponding to the Client's ACP as the 2907 destination. 2909 o Clients use Subnet Router Anycast address as the encapsulation 2910 source address when the access network does not provide a 2911 topologically-fixed address. 2913 Author's Address 2915 Fred L. Templin (editor) 2916 Boeing Research & Technology 2917 P.O. Box 3707 2918 Seattle, WA 98124 2919 USA 2921 Email: fltemplin@acm.org