idnits 2.17.1 draft-templin-intarea-6706bis-07.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 28, 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 2361, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2397, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 2411, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-rio-redirect' is defined on line 2468, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 2523, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2650, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 2655, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2678, but no explicit reference was found in the text == Unused Reference: 'TUNTAP' is defined on line 2699, 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 28, 2019 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: September 1, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-07.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 September 1, 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 . . . . 25 86 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 26 87 3.11. AERO Interface Data Origin Authentication . . . . . . . . 26 88 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 27 89 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 29 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) . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . . 44 103 3.18.4. Bringing New Links Into Service . . . . . . . . . . 44 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 . . . . . . . . . . . . . . . 45 107 3.19. Multicast Considerations . . . . . . . . . . . . . . . . 45 108 4. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 45 109 5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 46 110 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 46 111 7. AERO Critical Infrastructure Considerations . . . . . . . . . 47 112 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 48 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 114 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 117 12.1. Normative References . . . . . . . . . . . . . . . . . . 51 118 12.2. Informative References . . . . . . . . . . . . . . . . . 52 119 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 58 120 Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 60 121 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64 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 |R|X|N| Reservd | 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 R (the "Release" bit) is set to '1' in the S/TLLAOs of any ND 689 message for each Interface ID that is to be released from service; 690 otherwise, set to '0'. If the R value in the first S/TLLAO is 691 '1', the recipient deletes the neighbor cache entry entirely and 692 (in the case of RS/RA messages) also releases the corresponding 693 PD. 695 o X (the "proXy" bit) is set to '1' in the SLLAO of RS/RA messages 696 by the Proxy when there is a Proxy in the path; otherwise, set to 697 '0'. If the ND message contains multiple SLLAOs, only the X value 698 in the first SLLAO is consulted and the values in other SLLAOs are 699 ignored. 701 o N (the "NAT" bit) is set to '1' in the SLLAO of RA messages by the 702 Server if there is a NAT in the path; otherwise, set to '0'. If 703 the ND message contains multiple SLLAOs, only the N value in the 704 first SLLAO is consulted and the values in other SLLAOs are 705 ignored. 707 o Reservd is set to the value '0' on transmission and ignored on 708 receipt. 710 o Interface ID is set to a 16-bit integer value corresponding to an 711 underlying interface of the AERO node. Once the node has assigned 712 an Interface ID to an underlying interface, the assignment must 713 remain unchanged until the node fully detaches from the AERO link. 714 The value '255' is reserved as the AERO Server interface ID, i.e., 715 Servers MUST use Interface ID '255', and Clients MUST number their 716 Interface IDs with values in the range of 0-254. 718 o UDP Port Number and IP Address are set to the addresses used by 719 the AERO node when it sends encapsulated packets over the 720 specified underlying interface (or to '0' when the addresses are 721 left unspecified). When UDP is not used as part of the 722 encapsulation, UDP Port Number is set to '0'. When the 723 encapsulation IP address family is IPv4, IP Address is formed as 724 an IPv4-mapped IPv6 address as specified in Section 3.4. 726 o P(i) is a set of Preferences that correspond to the 64 727 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 728 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 729 ("medium") or '3' ("high") to indicate a QoS preference level for 730 packet forwarding purposes. 732 AERO interfaces may be configured over multiple underlying interface 733 connections to underlying links. For example, common mobile handheld 734 devices have both wireless local area network ("WLAN") and cellular 735 wireless links. These links are typically used "one at a time" with 736 low-cost WLAN preferred and highly-available cellular wireless as a 737 standby. In a more complex example, aircraft frequently have many 738 wireless data link types (e.g. satellite-based, cellular, 739 terrestrial, air-to-air directional, etc.) with diverse performance 740 and cost properties. 742 A Client's underlying interfaces are classified as follows: 744 o Native interfaces connect to the open Internetwork, and have a 745 global IP address that is reachable from any open Internetwork 746 correspondent. 748 o NATed interfaces connect to a closed network that is separated 749 from the open Internetwork by a Network Address Translator (NAT). 750 The NAT does not participate in any AERO control message 751 signaling, but the AERO Server can issue control messages on 752 behalf of the Client. 754 o VPNed interfaces use security encapsulation over the Internetwork 755 to a Virtual Private Network (VPN) gateway that also acts as an 756 AERO Server. As with NATed links, the AERO Server can issue 757 control messages on behalf of the Client. 759 o Proxyed interfaces connect to a closed network that is separated 760 from the open Internetwork by an AERO Proxy. Unlike NATed and 761 VPNed interfaces, the AERO Proxy can also issue control messages 762 on behalf of the Client. 764 o Direct interfaces connect the Client directly to a neighbor 765 without crossing any networked paths. An example is a line-of- 766 sight link between a remote pilot and an unmanned aircraft. 768 If a Client's multiple underlying interfaces are used "one at a time" 769 (i.e., all other interfaces are in standby mode while one interface 770 is active), then ND messages include only a single S/TLLAO with 771 Interface ID set to a constant value. In that case, the Client would 772 appear to have a single underlying interface but with a dynamically 773 changing link-layer address. 775 If the Client has multiple active underlying interfaces, then from 776 the perspective of ND it would appear to have multiple link-layer 777 addresses. In that case, ND messages MAY include multiple S/TLLAOs 778 -- each with an Interface ID that corresponds to a specific 779 underlying interface of the AERO node. 781 When the Client includes an S/TLLAO for an underlying interface for 782 which it is aware that there is a NAT or Proxy on the path to the 783 Server, or when a node includes an S/TLLAO solely for the purpose of 784 announcing new QoS preferences, the node sets both UDP Port Number 785 and IP Address to 0 to indicate that the addresses are unspecified at 786 the network layer and must instead be derived from the link-layer 787 encapsulation headers. 789 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 790 correspond to the AERO node's underlying interface used to transmit 791 the message. 793 3.6. AERO Interface Initialization 795 3.6.1. AERO Relay Behavior 797 When a Relay enables an AERO interface, it first assigns an 798 administratively-provisioned AERO address fe80::ID to the interface. 799 Each fe80::ID address MUST be unique among all AERO nodes on the 800 link. The Relay then engages in a dynamic routing protocol session 801 with one or more Servers and all other Relays on the link (see: 802 Section 3.3), and advertises its assigned ASPs into the native 803 Internetwork. Each Relay subsequently maintains an IP forwarding 804 table entry for each active ACP covered by its ASP(s). 806 3.6.2. AERO Server Behavior 808 When a Server enables an AERO interface, it assigns an 809 administratively-provisioned AERO address fe80::ID the same as for 810 Relays. The Server further configures a service to facilitate ND/PD 811 exchanges with AERO Clients. The Server maintains neighbor cache 812 entries for one or more Relays on the link, and manages per-Client 813 neighbor cache entries and IP forwarding table entries based on 814 control message exchanges. The Server also engages in a dynamic 815 routing protocol with its neighboring Relays (see: Section 3.3). 817 When the Server receives an NS/RS message on the AERO interface it 818 authenticates the message and returns a solicited NA/RA message. 819 (When the Server receives an unsolicited NA message, it likewise 820 authenticates the message and processes it locally.) The Server 821 further provides a simple link-layer conduit between AERO interface 822 neighbors. In particular, when a packet sent by a source Client 823 arrives on the Server's AERO interface and is destined to another 824 AERO node, the Server forwards the packet from within the AERO 825 interface at the link layer without ever disturbing the network 826 layer. 828 3.6.3. AERO Proxy Behavior 830 When a Proxy enables an AERO interface, it assigns an 831 administratively-provisioned address fe80::ID the same as for Relays 832 and Servers. The Proxy further maintains per-Client proxy neighbor 833 cache entries based on control message exchanges. Proxies forward 834 packets between their associated Clients and each Client's associated 835 Servers. 837 When the Proxy receives an RS message from a Client in the secured 838 enclave, it creates an incomplete proxy neighbor cache entry and 839 sends a proxyed RS message to a Server selected by the Client while 840 using its own link-layer address as the source address. When the 841 Server returns an RA message, the Proxy completes the proxy neighbor 842 cache entry based on autoconfiguration information in the RA and 843 sends a proxyed RA to the Client while using its own link-layer 844 address as the source address. The Client, Server and Proxy will 845 then have the necessary state for managing the proxy neighbor 846 association. 848 3.6.4. AERO Client Behavior 850 When a Client enables an AERO interface, it sends RS messages with 851 ND/PD parameters over an underlying interface to one or more AERO 852 Servers, which return RA messages with corresponding PD parameters. 853 (The RS/RA messages may pass through a Proxy on the path in the case 854 of a Client's Proxyed interface.) See 855 [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters 856 that can be included in the RS/RA message exchanges. 858 After the initial ND/PD message exchange, the Client assigns AERO 859 addresses to the AERO interface based on the delegated prefix(es). 860 The Client can then register additional underlying interfaces with 861 the Server by sending a simple RS message (i.e., one with no PD 862 parameters) over each underlying interface using its base AERO 863 address as the source network layer address. The Server will update 864 its neighbor cache entry for the Client and return a simple RA 865 message. 867 The Client maintains a neighbor cache entry for each of its Servers 868 and each of its active target Clients. When the Client receives ND 869 messages on the AERO interface it updates or creates neighbor cache 870 entries, including link-layer address and QoS preferences. 872 When there is a NAT on the path, the Client must send periodic 873 messages to keep NAT state alive. If no other periodic messaging 874 service is available, the Client can send RS messages to receive RA 875 replies from its Server(s). 877 3.7. AERO Interface Neighbor Cache Maintenance 879 Each AERO interface maintains a conceptual neighbor cache that 880 includes an entry for each neighbor it communicates with on the AERO 881 link, the same as for any IPv6 interface [RFC4861]. AERO interface 882 neighbor cache entries are said to be one of "permanent", "static", 883 "proxy" or "dynamic". 885 Permanent neighbor cache entries are created through explicit 886 administrative action; they have no timeout values and remain in 887 place until explicitly deleted. AERO Relays maintain permanent 888 neighbor cache entries for their associated Relays and Servers on the 889 link, and AERO Servers maintain permanent neighbor cache entries for 890 their associated Relays. Each entry maintains the mapping between 891 the neighbor's fe80::ID network-layer address and corresponding link- 892 layer address. 894 Static neighbor cache entries are created and maintained through ND/ 895 PD exchanges as specified in Section 3.14, and remain in place for 896 durations bounded by ND/PD lifetimes. AERO Servers maintain static 897 neighbor cache entries for each of their associated Clients, and AERO 898 Clients maintain static neighbor cache entries for each of their 899 associated Servers. 901 Proxy neighbor cache entries are created and maintained by AERO 902 Proxies when they process Client/Server ND/PD exchanges, and remain 903 in place for durations bounded by ND/PD lifetimes. AERO Proxies 904 maintain proxy neighbor cache entries for each of their associated 905 Clients. 907 Dynamic neighbor cache entries are created or updated based on 908 receipt of route optimization messages as specified in Section 3.16, 909 and are garbage-collected when keepalive timers expire. AERO route 910 optimization sources maintain dynamic neighbor cache entries for each 911 of their active target Clients with lifetimes based on ND messaging 912 constants. Dynamic neighbor cache entries are asymmetric since only 913 the route optimization source (i.e., and not the target Client) 914 creates an entry. 916 When a target AERO Server (acting as a Mobility Anchor Point (MAP)) 917 receives a valid NS message used for route optimization, it searches 918 for a static neighbor cache entry for the target Client. The Server 919 then returns a solicited NA message, and adds the link-layer address 920 of the source to a "Report List" associated with the Client's static 921 neighbor cache entry. The Server then sets a "ReportTime" variable 922 for the Report list entry to REPORTTIME seconds. The Server resets 923 ReportTime when it receives a new NS message, and otherwise 924 decrements ReportTime while no NS messages have been received. It is 925 RECOMMENDED that REPORTTIME be set to the default constant value 40 926 seconds to allow a 10 second window so that the AERO route 927 optimization procedure can converge before ReportTime decrements 928 below REACHABLETIME (see below). 930 When the route optimization source receives a solicited NA message 931 response to its NS message, it creates or updates a dynamic neighbor 932 cache entry for the target network-layer and link-layer addresses. 933 The node then (re)sets "ReachableTime" for the neighbor cache entry 934 to REACHABLETIME seconds and uses this value to determine whether 935 packets can be forwarded directly to the target, i.e., instead of via 936 a default route. The node otherwise decrements ReachableTime while 937 no further solicited NA messages arrive. It is RECOMMENDED that 938 REACHABLETIME be set to the default constant value 30 seconds as 939 specified in [RFC4861]. 941 The route optimization source also uses the value MAX_UNICAST_SOLICIT 942 to limit the number of NS keepalives sent when a correspondent may 943 have gone unreachable, the value MAX_RTR_SOLICITATIONS to limit the 944 number of RS messages sent without receiving an RA and the value 945 MAX_NEIGHBOR_ADVERTISEMENT to limit the number of unsolicited NAs 946 that can be sent based on a single event. It is RECOMMENDED that 947 MAX_UNICAST_SOLICIT, MAX_RTR_SOLICITATIONS and 948 MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the same as specified in 949 [RFC4861]. 951 Different values for REPORTTIME, REACHABLETIME, MAX_UNICAST_SOLICIT, 952 MAX_RTR_SOLCITATIONS and MAX_NEIGHBOR_ADVERTISEMENT MAY be 953 administratively set; however, if different values are chosen, all 954 nodes on the link MUST consistently configure the same values. Most 955 importantly, REPORTTIME SHOULD be set to a value that is sufficiently 956 longer than REACHABLETIME to allow the AERO route optimization 957 procedure to converge. 959 3.8. AERO Interface Forwarding Algorithm 961 IP packets enter a node's AERO interface either from the network 962 layer (i.e., from a local application or the IP forwarding system) or 963 from the link layer (i.e., from the AERO tunnel virtual link). 964 Packets that enter the AERO interface from the network layer are 965 encapsulated and forwarded into the AERO link, i.e., they are 966 tunneled to an AERO interface neighbor. Packets that enter the AERO 967 interface from the link layer are either re-admitted into the AERO 968 link or forwarded to the network layer where they are subject to 969 either local delivery or IP forwarding. In all cases, the AERO 970 interface itself MUST NOT decrement the network layer TTL/Hop-count 971 since its forwarding actions occur below the network layer. 973 AERO interfaces may have multiple underlying interfaces and/or 974 neighbor cache entries for neighbors with multiple Interface ID 975 registrations (see Section 3.5). The AERO node uses each packet's 976 DSCP value to select an outgoing underlying interface based on the 977 node's own QoS preferences, and also to select a destination link- 978 layer address based on the neighbor's underlying interface with the 979 highest preference. AERO implementations SHOULD allow for QoS 980 preference values to be modified at runtime through network 981 management. 983 If multiple outgoing interfaces and/or neighbor interfaces have a 984 preference of "high", the AERO node sends one copy of the packet via 985 each of the (outgoing / neighbor) interface pairs; otherwise, the 986 node sends a single copy of the packet via the interface with the 987 highest preference. AERO nodes keep track of which underlying 988 interfaces are currently "reachable" or "unreachable", and only use 989 "reachable" interfaces for forwarding purposes. 991 The following sections discuss the AERO interface forwarding 992 algorithms for Clients, Proxies, Servers and Relays. In the 993 following discussion, a packet's destination address is said to 994 "match" if it is a non-link-local address with a prefix covered by an 995 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 996 the same as an administratively-provisioned AERO address. 998 3.8.1. Client Forwarding Algorithm 1000 When an IP packet enters a Client's AERO interface from the network 1001 layer the Client searches for a dynamic neighbor cache entry that 1002 matches the destination. If there is a match, the Client uses one or 1003 more "reachable" link-layer addresses in the entry as the link-layer 1004 addresses for encapsulation and admits the packet into the AERO link. 1005 Otherwise, the Client uses the link-layer address in a static 1006 neighbor cache entry for a Server as the encapsulation address 1007 (noting that there may be a Proxy on the path to the real Server). 1009 When an IP packet enters a Client's AERO interface from the link- 1010 layer, if the destination matches one of the Client's ACPs or link- 1011 local addresses the Client decapsulates the packet and delivers it to 1012 the network layer. Otherwise, the Client drops the packet and MAY 1013 return a network-layer ICMP Destination Unreachable message subject 1014 to rate limiting (see: Section 3.13). 1016 3.8.2. Proxy Forwarding Algorithm 1018 When the Proxy receives a packet from a Client within the secured 1019 enclave, the Proxy searches for a dynamic neighbor cache entry that 1020 matches the destination. If there is a match, the Proxy uses one or 1021 more "reachable" link-layer addresses in the entry as the link-layer 1022 addresses for encapsulation and admits the packet into the AERO link. 1023 Otherwise, the Proxy uses the link-layer address for one of the 1024 Client's Servers as the encapsulation address. 1026 When the Proxy receives a packet from an AERO interface neighbor, it 1027 searches for a proxy neighbor cache entry for a Client within the 1028 secured enclave that matches the destination. If there is a match, 1029 the Proxy forwards the packet to the Client. Otherwise, the Proxy 1030 returns the packet to the neighbor, i.e., by reversing the source and 1031 destination link-layer addresses and re-admitting the packet into the 1032 AERO link. 1034 3.8.3. Server Forwarding Algorithm 1036 When an IP packet enters a Server's AERO interface from the network 1037 layer, the Server searches for a static neighbor cache entry for a 1038 Client that matches the destination. If there is a match, the Server 1039 uses one or more link-layer addresses in the entry as the link-layer 1040 addresses for encapsulation and admits the packet into the AERO link. 1041 Otherwise, the Server uses the link-layer address in a permanent 1042 neighbor cache entry for a Relay (selected through longest-prefix 1043 match) as the link-layer address for encapsulation. 1045 When an IP packet enters a Server's AERO interface from the link 1046 layer, the Server processes the packet according to the network-layer 1047 destination address as follows: 1049 o if the destination matches one of the Server's own addresses the 1050 Server decapsulates the packet and forwards it to the network 1051 layer for local delivery. 1053 o else, if the destination matches a static neighbor cache entry for 1054 a local Client the Server first determines whether the neighbor is 1055 the same as the one it received the packet from. If so, the 1056 Server drops the packet silently to avoid looping; otherwise, the 1057 Server uses the neighbor's link-layer address(es) as the 1058 destination for encapsulation and re-admits the packet into the 1059 AERO link. 1061 o else, if the destination matches a dynamic neighbor cache entry 1062 for a target Client, the Server forwards the packet according to 1063 the interface ID settings in the dynamic neighbor cache entry. 1065 o else, the Server uses the link-layer address in a neighbor cache 1066 entry for a Relay (selected through longest-prefix match) as the 1067 link-layer address for encapsulation. 1069 3.8.4. Relay Forwarding Algorithm 1071 Relays forward packets the same as any IP router. When the Relay 1072 receives an encapsulated packet from a Server via the AERO link, it 1073 removes the encapsulation header and searches for a forwarding table 1074 entry that matches the destination address in the next IP header. 1075 When the Relay receives an unencapsulated packet from a node outside 1076 the AERO link, it performs the same forwarding table lookup. The 1077 Relay then processes the packet as follows: 1079 o if the destination does not match an ASP, or if the destination 1080 matches one of the Relay's own addresses, the Relay submits the 1081 packet for either IP forwarding or local delivery. 1083 o else, if the destination matches an ACP entry in the IP forwarding 1084 table the Relay first determines whether the neighbor is the same 1085 as the one it received the packet from. If so the Relay MUST drop 1086 the packet silently to avoid looping; otherwise, the Relay 1087 encapsulates and forwards the packet using the neighbor's link- 1088 layer address as the destination for encapsulation. 1090 o else, the Relay drops the packet and returns an ICMP Destination 1091 Unreachable message subject to rate limiting (see: Section 3.13). 1093 As for any IP router, the Relay decrements the TTL/Hop Count when it 1094 forwards the packet. 1096 3.8.5. Processing Return Packets 1098 When an AERO Server receives a return packet from an AERO Proxy (see 1099 Section 3.8.2), it proceeds according to the AERO link trust basis. 1100 Namely, the return packets have the same trust profile as for link- 1101 layer Destination Unreachable messages. If the Server has sufficient 1102 trust basis to accept link-layer Destination Unreachable messages, it 1103 can then process the return packet by searching for a dynamic 1104 neighbor cache entry that matches the destination. If there is a 1105 match, the Server marks the corresponding link-layer address as 1106 "unreachable", selects the next-highest priority "reachable" link- 1107 layer address in the entry as the link-layer address for 1108 encapsulation then (re)admits the packet into the AERO link. If 1109 there are no "reachable" link-layer addresses, the Server instead 1110 sets ReachableTime in the dynamic neighbor cache entry to 0. 1111 Otherwise, the Server SHOULD drop the packet and treat it as an 1112 indication that a path may be failing, and MAY use Neighbor 1113 Unreachability Detection (NUD) (see: Section 3.13) to test the path 1114 for reachability. 1116 When an AERO Relay receives a return packet from an AERO Server, it 1117 searches its forwarding table for an entry that matches the inner 1118 destination address. If there is a forwarding table entry that lists 1119 a different Server as the next hop, the Relay forwards the packet to 1120 the different Server; otherwise, the Relay drops the packet. 1122 See Section 3.18 for further discussion on the nature of return 1123 packets. 1125 3.9. AERO Interface Encapsulation and Re-encapsulation 1127 AERO interfaces encapsulate IP packets according to whether they are 1128 entering the AERO interface from the network layer or if they are 1129 being re-admitted into the same AERO link they arrived on. This 1130 latter form of encapsulation is known as "re-encapsulation". 1132 The AERO interface encapsulates packets per the Generic UDP 1133 Encapsulation (GUE) procedures in 1134 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 1135 an alternate encapsulation format (e.g., see: Appendix A, [RFC2784], 1136 [RFC8086], [RFC4301], etc.). For packets entering the AERO interface 1137 from the network layer, the AERO interface copies the "TTL/Hop 1138 Limit", "Type of Service/Traffic Class" [RFC2983], "Flow 1139 Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168] 1140 values in the packet's IP header into the corresponding fields in the 1141 encapsulation IP header. For packets undergoing re-encapsulation, 1142 the AERO interface instead copies these values from the original 1143 encapsulation IP header into the new encapsulation header, i.e., the 1144 values are transferred between encapsulation headers and *not* copied 1145 from the encapsulated packet's network-layer header. (Note 1146 especially that by copying the TTL/Hop Limit between encapsulation 1147 headers the value will eventually decrement to 0 if there is a 1148 (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation, 1149 the AERO interface sets the DF bit as discussed in Section 3.12. 1151 When GUE encapsulation is used, the AERO interface next sets the UDP 1152 source port to a constant value that it will use in each successive 1153 packet it sends, and sets the UDP length field to the length of the 1154 encapsulated packet plus 8 bytes for the UDP header itself plus the 1155 length of the GUE header (or 0 if GUE direct IP encapsulation is 1156 used). For packets sent to a Server or Relay, the AERO interface 1157 sets the UDP destination port to 8060, i.e., the IANA-registered port 1158 number for AERO. For packets sent to a Client, the AERO interface 1159 sets the UDP destination port to the port value stored in the 1160 neighbor cache entry for this Client. The AERO interface then either 1161 includes or omits the UDP checksum according to the GUE 1162 specification. 1164 Clients normally use the IP address of the underlying interface as 1165 the encapsulation source address. If the underlying interface does 1166 not have an IP address, however, the Client uses an IP address taken 1167 from an ACP as the encapsulation source address (assuming the node 1168 has some way of injecting the ACP into the underlying network routing 1169 system). For IPv6 addresses, the Client normally uses the ACP Subnet 1170 Router Anycast address [RFC4291]. 1172 When GUE encapsulation is not available, encapsulation between 1173 Servers and Relays can use standard mechanisms such as Generic 1174 Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec 1175 [RFC4301] so that Relays can be standard IP routers with no AERO- 1176 specific mechanisms. 1178 3.10. AERO Interface Decapsulation 1180 AERO interfaces decapsulate packets destined either to the AERO node 1181 itself or to a destination reached via an interface other than the 1182 AERO interface the packet was received on. Decapsulation is per the 1183 procedures specified for the appropriate encapsulation format. 1185 3.11. AERO Interface Data Origin Authentication 1187 AERO nodes employ simple data origin authentication procedures for 1188 encapsulated packets they receive from other nodes on the AERO link. 1189 In particular: 1191 o AERO Relays and Servers accept encapsulated packets with a link- 1192 layer source address that matches a permanent neighbor cache 1193 entry. 1195 o AERO Servers accept authentic encapsulated ND messages from 1196 Clients (either directly or via a Proxy), and create or update a 1197 static neighbor cache entry for the Client based on the specific 1198 message type. 1200 o AERO Clients and Servers accept encapsulated packets if there is a 1201 static neighbor cache entry with a link-layer address that matches 1202 the packet's link-layer source address. 1204 o AERO Proxies accept encapsulated packets if there is a proxy 1205 neighbor cache entry that matches the packet's network-layer 1206 address. 1208 Each packet should include a signature that the recipient can use to 1209 authenticate the message origin, e.g., as for common VPN systems such 1210 as OpenVPN [OVPN]. In some environments, however, it may be 1211 sufficient to require signatures only for ND control plane messages 1212 (see: Section 10) and omit signatures for data plane messages. 1214 3.12. AERO Interface Packet Size Issues 1216 The AERO interface is the node's attachment to the AERO link. The 1217 AERO interface acts as a tunnel ingress when it sends a packet to an 1218 AERO link neighbor and as a tunnel egress when it receives a packet 1219 from an AERO link neighbor. AERO interfaces observe the packet 1220 sizing considerations for tunnels discussed in 1221 [I-D.ietf-intarea-tunnels] and as specified below. 1223 The Internet Protocol expects that IP packets will either be 1224 delivered to the destination or a suitable Packet Too Big (PTB) 1225 message returned to support the process known as IP Path MTU 1226 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1227 crafted for malicious purposes such as denial of service, or lost in 1228 the network [RFC2923]. This can be especially problematic for 1229 tunnels, where a condition known as a PMTUD "black hole" can result. 1230 For these reasons, AERO interfaces employ operational procedures that 1231 avoid interactions with PMTUD, including the use of fragmentation 1232 when necessary. 1234 AERO interfaces observe two different types of fragmentation. Source 1235 fragmentation occurs when the AERO interface (acting as a tunnel 1236 ingress) fragments the encapsulated packet into multiple fragments 1237 before admitting each fragment into the tunnel. Network 1238 fragmentation occurs when an encapsulated packet admitted into the 1239 tunnel by the ingress is fragmented by an IPv4 router on the path to 1240 the egress. Note that a packet that incurs source fragmentation may 1241 also incur network fragmentation. 1243 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1244 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1245 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1246 for IPv4 even if encapsulated packets may incur network 1247 fragmentation. 1249 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1250 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1251 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1252 than the IPv4 minimum). 1254 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1255 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1256 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1257 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1258 configure a Maximum Segment Unit (MSU) as the maximum-sized 1259 encapsulated packet that the ingress can inject into the tunnel 1260 without source fragmentation. The MSU value MUST NOT be larger than 1261 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1262 operational assurance that a larger size can traverse the link along 1263 all paths. 1265 All AERO nodes MUST configure the same MTU/MSU values for reasons 1266 cited in [RFC3819][RFC4861]; in particular, multicast support 1267 requires a common MTU value among all nodes on the link. All AERO 1268 nodes MUST configure an MRU large enough to reassemble packets up to 1269 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1270 enough MRU MUST NOT enable an AERO interface. 1272 The network layer proceeds as follow when it presents an IP packet to 1273 the AERO interface. For each IPv4 packet that is larger than the 1274 AERO interface MTU and with the DF bit set to 0, the network layer 1275 uses IPv4 fragmentation to break the packet into a minimum number of 1276 non-overlapping fragments where the first fragment is no larger than 1277 the MTU and the remaining fragments are no larger than the first. 1278 For all other IP packets, if the packet is larger than the AERO 1279 interface MTU, the network layer drops the packet and returns a PTB 1280 message to the original source. Otherwise, the network layer admits 1281 each IP packet or fragment into the AERO interface. 1283 For each IP packet admitted into the AERO interface, the interface 1284 (acting as a tunnel ingress) encapsulates the packet. If the 1285 encapsulated packet is larger than the AERO interface MSU the ingress 1286 source-fragments the encapsulated packet into a minimum number of 1287 non-overlapping fragments where the first fragment is no larger than 1288 the MSU and the remaining fragments are no larger than the first. 1289 The ingress then admits each encapsulated packet or fragment into the 1290 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1291 header in case any network fragmentation is necessary. The 1292 encapsulated packets will be delivered to the egress, which 1293 reassembles them into a whole packet if necessary. 1295 Several factors must be considered when fragmentation is needed. For 1296 AERO links over IPv4, the IP ID field is only 16 bits in length, 1297 meaning that fragmentation at high data rates could result in data 1298 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1299 AERO links over both IPv4 and IPv6, studies have also shown that IP 1300 fragments are dropped unconditionally over some network paths [I- 1301 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1302 issues could result in operational problems, the ingress SHOULD 1303 employ intermediate-layer source fragmentation (see: [RFC2764] and 1304 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1305 encapsulation headers to each fragment. Since the encapsulation 1306 fragment header reduces the room available for packet data, but the 1307 original source has no way to control its insertion, the ingress MUST 1308 include the fragment header length in the ENCAPS length even for 1309 packets in which the header is absent. 1311 3.13. AERO Interface Error Handling 1313 When an AERO node admits encapsulated packets into the AERO 1314 interface, it may receive link-layer or network-layer error 1315 indications. 1317 A link-layer error indication is an ICMP error message generated by a 1318 router in the underlying network on the path to the neighbor or by 1319 the neighbor itself. The message includes an IP header with the 1320 address of the node that generated the error as the source address 1321 and with the link-layer address of the AERO node as the destination 1322 address. 1324 The IP header is followed by an ICMP header that includes an error 1325 Type, Code and Checksum. Valid type values include "Destination 1326 Unreachable", "Time Exceeded" and "Parameter Problem" 1327 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1328 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1329 only emit packets that are guaranteed to be no larger than the IP 1330 minimum link MTU as discussed in Section 3.12.) 1332 The ICMP header is followed by the leading portion of the packet that 1333 generated the error, also known as the "packet-in-error". For 1334 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1335 much of invoking packet as possible without the ICMPv6 packet 1336 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1337 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1338 "Internet Header + 64 bits of Original Data Datagram", however 1339 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1340 ICMP datagram SHOULD contain as much of the original datagram as 1341 possible without the length of the ICMP datagram exceeding 576 1342 bytes". 1344 The link-layer error message format is shown in Figure 3 (where, "L2" 1345 and "L3" refer to link-layer and network-layer, respectively): 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 ~ ~ 1349 | L2 IP Header of | 1350 | error message | 1351 ~ ~ 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | L2 ICMP Header | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1355 ~ ~ P 1356 | IP and other encapsulation | a 1357 | headers of original L3 packet | c 1358 ~ ~ k 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1360 ~ ~ t 1361 | IP header of | 1362 | original L3 packet | i 1363 ~ ~ n 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 ~ ~ e 1366 | Upper layer headers and | r 1367 | leading portion of body | r 1368 | of the original L3 packet | o 1369 ~ ~ r 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1372 Figure 3: AERO Interface Link-Layer Error Message Format 1374 The AERO node rules for processing these link-layer error messages 1375 are as follows: 1377 o When an AERO node receives a link-layer Parameter Problem message, 1378 it processes the message the same as described as for ordinary 1379 ICMP errors in the normative references [RFC0792][RFC4443]. 1381 o When an AERO node receives persistent link-layer Time Exceeded 1382 messages, the IP ID field may be wrapping before earlier fragments 1383 awaiting reassembly have been processed. In that case, the node 1384 SHOULD begin including integrity checks and/or institute rate 1385 limits for subsequent packets. 1387 o When an AERO node receives persistent link-layer Destination 1388 Unreachable messages in response to encapsulated packets that it 1389 sends to one of its dynamic neighbor correspondents, the node 1390 SHOULD process the message as an indication that a path may be 1391 failing, and MAY initiate NUD over that path. If it receives 1392 Destination Unreachable messages on many or all paths, the node 1393 SHOULD set ReachableTime for the corresponding dynamic neighbor 1394 cache entry to 0 and allow future packets destined to the 1395 correspondent to flow through a default route. 1397 o When an AERO Client receives persistent link-layer Destination 1398 Unreachable messages in response to encapsulated packets that it 1399 sends to one of its static neighbor Servers, the Client SHOULD 1400 mark the path as unusable and use another path. If it receives 1401 Destination Unreachable messages on many or all paths, the Client 1402 SHOULD associate with a new Server and release its association 1403 with the old Server as specified in Section 3.18.7. 1405 o When an AERO Server receives persistent link-layer Destination 1406 Unreachable messages in response to encapsulated packets that it 1407 sends to one of its static neighbor Clients, the Server SHOULD 1408 mark the underlying path as unusable and use another underlying 1409 path. If it receives Destination Unreachable messages on multiple 1410 paths, the Server should take no further actions unless it 1411 receives an explicit ND/PD release message or if the PD lifetime 1412 expires. In that case, the Server MUST release the Client's 1413 delegated ACP, withdraw the ACP from the AERO routing system and 1414 delete the neighbor cache entry. 1416 o When an AERO Relay or Server receives link-layer Destination 1417 Unreachable messages in response to an encapsulated packet that it 1418 sends to one of its permanent neighbors, it treats the messages as 1419 an indication that the path to the neighbor may be failing. 1420 However, the dynamic routing protocol should soon reconverge and 1421 correct the temporary outage. 1423 When an AERO Relay receives a packet for which the network-layer 1424 destination address is covered by an ASP, if there is no more- 1425 specific routing information for the destination the Relay drops the 1426 packet and returns a network-layer Destination Unreachable message 1427 subject to rate limiting. The Relay writes the network-layer source 1428 address of the original packet as the destination address and uses 1429 one of its non link-local addresses as the source address of the 1430 message. 1432 When an AERO node receives an encapsulated packet for which the 1433 reassembly buffer it too small, it drops the packet and returns a 1434 network-layer Packet Too Big (PTB) message. The node first writes 1435 the MRU value into the PTB message MTU field, writes the network- 1436 layer source address of the original packet as the destination 1437 address and writes one of its non link-local addresses as the source 1438 address. 1440 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1442 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1443 coordinated as discussed in the following Sections. 1445 3.14.1. AERO ND/PD Service Model 1447 Each AERO Server configures a PD service to facilitate Client 1448 requests. Each Server is provisioned with a database of ACP-to- 1449 Client ID mappings for all Clients enrolled in the AERO system, as 1450 well as any information necessary to authenticate each Client. The 1451 Client database is maintained by a central administrative authority 1452 for the AERO link and securely distributed to all Servers, e.g., via 1453 the Lightweight Directory Access Protocol (LDAP) [RFC4511], via 1454 static configuration, etc. Therefore, no Server-to-Server PD state 1455 synchronization is necessary, and Clients can optionally hold 1456 separate PDs for the same ACPs from multiple Servers. In this way, 1457 Clients can associate with multiple Servers, and can receive new PDs 1458 from new Servers before releasing PDs received from existing Servers. 1459 This provides the Client with a natural fault-tolerance and/or load 1460 balancing profile. 1462 AERO Clients and Servers use ND messages to maintain neighbor cache 1463 entries. AERO Servers configure their AERO interfaces as advertising 1464 interfaces, and therefore send unicast RA messages with configuration 1465 information in response to a Client's RS message. Thereafter, 1466 Clients send additional RS messages to the Server's unicast address 1467 to refresh prefix and/or router lifetimes. 1469 AERO Clients and Servers include PD parameters in the RS/RA messages 1470 they exchange (see: [I-D.templin-6man-dhcpv6-ndopt]). The unified 1471 ND/PD messages are exchanged between Client and Server according to 1472 the prefix management schedule required by the PD service. If the 1473 Client knows its ACP in advance, it can include its AERO address as 1474 the source address of an RS message and with an SLLAO with a valid 1475 Prefix Length for the ACP. If the Server (and Proxy) accept the 1476 Client's ACP assertion, they inject the prefix into the routing 1477 system and establish the necessary neighbor cache state. If the 1478 Client does not know its ACP in advance, or if it wishes to engage in 1479 a formal PD exchange, it can use an explicit PD service such as 1480 DHCPv6. 1482 On Some AERO links, PD arrangements may be through some out-of-band 1483 service such as network management, static configuration, etc. In 1484 those cases, AERO nodes can use simple RS/RA message exchanges with 1485 no explicit PD options. Instead, the RS/RA messages use AERO 1486 addresses as a means of representing the delegated prefixes, e.g., if 1487 a message includes a source address of "fe80::2001:db8:1:2" then the 1488 recipient can infer that the sender holds the prefix delegation 1489 "2001:db8:1:2::/N" (where 'N' is the Prefix Length included in the 1490 first S/TLLAO in the message). 1492 The following sections specify the Client and Server behavior. 1494 3.14.2. AERO Client Behavior 1496 AERO Clients discover the link-layer addresses of AERO Servers in the 1497 Potential Router List (PRL) via static configuration (e.g., from a 1498 flat-file map of Server addresses and locations), or through an 1499 automated means such as Domain Name System (DNS) name resolution 1500 [RFC1035]. In the absence of other information, the Client resolves 1501 the DNS Fully-Qualified Domain Name (FQDN) 1502 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 1503 text string and "[domainname]" is a DNS suffix for the Client's 1504 underlying interface (e.g., "example.com"). After discovering the 1505 link-layer addresses, the Client associates with one or more of the 1506 corresponding Servers. 1508 To associate with a Server, the Client acts as a requesting router to 1509 request ACPs. The Client sends an RS message with PD parameters and 1510 with all-routers multicast as the IPv6 destination address, the 1511 address of the Client's underlying interface as the link-layer source 1512 address and the link-layer address of the Server as the link-layer 1513 destination address. If the Client already knows its own AERO 1514 address, it uses the AERO address as the IPv6 source address; 1515 otherwise, it uses the unspecified AERO address as the source 1516 address. If the Client's underlying interface connects to a 1517 subnetwork that supports ACP injection, the Client can use the ACP's 1518 Subnet Router Anycast address as the link-layer source address. 1520 The Client next includes one or more SLLAOs in the RS message 1521 formatted as described in Section 3.5 to register its link-layer 1522 address(es) with the Server. The first SLLAO MUST correspond to the 1523 underlying interface over which the Client will send the RS message, 1524 and the Prefix Length field MUST be set to the length of the Client's 1525 ACP if known, or '0' otherwise. The Client MAY include additional 1526 SLLAOs specific to other underlying interfaces, but if so it sets 1527 their UDP Port Number and IP Address fields to 0. The Client can 1528 instead register additional link-layer addresses with the Server by 1529 sending additional RS messages including SLLAOs via other underlying 1530 interfaces after the initial RS/RA exchange. 1532 The Client then sends the RS message to the AERO Server and waits for 1533 an RA message reply (see Section 3.14.3) while retrying up to 1534 MAX_RTR_SOLICITATIONS times until an RA is received. If the Client 1535 receives no RAs, or if it receives an RA with Router Lifetime set to 1536 0 and/or with no ACP PD parameters, the Client SHOULD discontinue 1537 autoconfiguration attempts through this Server and try another 1538 Server. Otherwise, the Client processes the ACPs found in the RA 1539 message. 1541 Next, the Client creates a static neighbor cache entry with the 1542 Server's link-local address as the network-layer address and the 1543 address in the first SLLAO as the link-layer address. The Client 1544 records the lifetime value in the RA Router Lifetime field as the 1545 time for which the Server has committed to maintaining the ACP in the 1546 routing system. The Client then autoconfigures AERO addresses for 1547 each of the delegated ACPs and assigns them to the AERO interface. 1549 The Client next examines the X and N bits in the first SLLAO of the 1550 RA message. If the X bit value is '1' the Client infers that there 1551 is a Proxy on the path via the interface over which it sent the RS 1552 message, and if the N bit value is '1' the Client infers that there 1553 is a NAT on the path. If N is '1', the Client SHOULD set UDP Port 1554 Number and IP Address to 0 in the first S/TLLAO of any subsequent ND 1555 messages it sends to the Server over that link. 1557 The Client also caches any ASPs included in Route Information Options 1558 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1559 the MTU/MSU values in the MTU options to its AERO interface while 1560 configuring an appropriate MRU. This configuration information 1561 applies to the AERO link as a whole, and all AERO nodes will receive 1562 the same values. 1564 Following autoconfiguration, the Client sub-delegates the ACPs to its 1565 attached EUNs and/or the Client's own internal virtual interfaces as 1566 described in [I-D.templin-v6ops-pdhost] to support the Client's 1567 downstream attached "Internet of Things (IoT)". The Client 1568 subsequently maintains its ACP delegations through each of its 1569 Servers by sending additional RS messages with PD parameters to 1570 receive corresponding RA messages. 1572 After the Client registers its Interface IDs and their associated 1573 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1574 Interface ID registrations, e.g., if an underlying interface changes 1575 address or becomes unavailable, if QoS preferences change, etc. To 1576 do so, the Client prepares an RS message to send over any available 1577 underlying interface. The RS MUST include a SLLAO specific to the 1578 selected available underlying interface as the first SLLAO and MAY 1579 include any additional SLLAOs specific to other underlying 1580 interfaces. The Client includes fresh 'P(i)' values in each SLLAO to 1581 update the Server's neighbor cache entry. If the Client wishes to 1582 update 'P(i)' values without updating the link-layer address, it sets 1583 the UDP Port Number and IP Address fields to 0. If the Client wishes 1584 to disable the interface, it sets all 'P(i)' values to '0' 1585 ("disabled"). When the Client receives the Server's RS response, it 1586 has assurance that the Server has been updated with the new 1587 information. 1589 If the Client wishes to discontinue use of a Server it issues an RS 1590 message with PD parameters that will cause the Server to release the 1591 Client. The Client can request that the Server release the ACP by 1592 setting the 'R' bit in the first SLLAO in the RS message. When the 1593 Server processes the message, it releases the ACP, deletes its 1594 neighbor cache entry for the Client, withdraws the IP route from the 1595 routing system and returns an RA reply containing any necessary PD 1596 parameters. 1598 3.14.3. AERO Server Behavior 1600 AERO Servers act as IPv6 routers and support a PD service for 1601 Clients. AERO Servers arrange to add their encapsulation layer IP 1602 addresses (i.e., their link-layer addresses) to a static map of 1603 Server addresses for the link and/or the DNS resource records for the 1604 FQDN "linkupnetworks.[domainname]" before entering service. The list 1605 of Server addresses should be geographically and/or topologically 1606 referenced, and forms the Potential Router List (PRL) for the AERO 1607 link. 1609 When an AERO Server receives a prospective Client's RS message with 1610 PD parameters on its AERO interface, it first checks the network- 1611 layer source address and Prefix Length in the first SLLAO to 1612 determine whether the Client already knows in advance the ACP it 1613 wishes to receive. If the Server is too busy, it SHOULD return an 1614 immediate RA reply with no SLLAOs and with Router Lifetime set to 0. 1615 Otherwise, the Server authenticates the RS message and processes the 1616 PD parameters. The Server first determines the correct ACPs to 1617 delegate to the Client by searching the Client database. When the 1618 Server delegates the ACPs, it also creates an IP forwarding table 1619 entry for each ACP so that the AERO BGP-based routing system will 1620 propagate the ACPs to the Relays that aggregate the corresponding ASP 1621 (see: Section 3.3). 1623 Next, the Server prepares an RA message that includes the delegated 1624 ACPs, any other PD parameters and an SLLAO with the Server's link- 1625 layer address and with Interface ID set to 255. The Server then 1626 returns the RA message using its link-local address as the network- 1627 layer source address, the network-layer source address of the RS 1628 message as the network-layer destination address, the Server's link- 1629 layer address as the source link-layer address, and the source link- 1630 layer address of the RS message as the destination link-layer 1631 address. The Server next sets the N flag to 1 if the source link- 1632 layer address in the RS message was different than the address in the 1633 first SLLAO to indicate that there is a NAT on the path, and sets the 1634 X flag to 1 if the first SLLAO in the RS message also had X set to 1. 1635 The Server then includes one or more RIOs that encode the ASPs for 1636 the AERO link. The Server also includes two MTU options - the first 1637 MTU option includes the MTU for the link and the second MTU option 1638 includes the MSU for the link (see Section 3.12). The Server finally 1639 sends the RA message to the Client. 1641 The Server next creates a static neighbor cache entry for the Client 1642 using the base AERO address as the network-layer address and with 1643 lifetime set to no more than the smallest PD lifetime. Next, the 1644 Server updates the neighbor cache entry link-layer address(es) by 1645 recording the information in each SLLAO in the RS indexed by the 1646 Interface ID and including the UDP port number, IP address and P(i) 1647 values. For the first SLLAO in the list, however, the Server records 1648 the actual encapsulation source UDP and IP addresses instead of those 1649 that appear in the SLLAO in case there was a NAT in the path. The 1650 Server also records the value of the X bit to indicate whether there 1651 is a Proxy on the path. 1653 After the initial RS/RA exchange, the AERO Server maintains the 1654 neighbor cache entry for the Client until the PD lifetimes expire. 1655 If the Client (or Proxy) issues additional RS messages with PD 1656 renewal parameters, the Server extends the PD lifetimes. If the 1657 Client (or Proxy) issues an RS with PD release parameters (e.g., by 1658 including a first SLLAO with R set to 1), or if the Client (or Proxy) 1659 does not issue a renewal before the lifetime expires, the Server 1660 deletes the neighbor cache entry for the Client and withdraws the IP 1661 routes from the AERO routing system. The Server processes these and 1662 any other Client PD messages, and returns an RA reply. The Server 1663 may also issue an unsolicited RA message with PD reconfigure 1664 parameters to inform the Client that it needs to renegotiate its PDs. 1666 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1668 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 1669 Servers are always on the same link (i.e., the AERO link) from the 1670 perspective of DHCPv6. However, in some implementations the DHCPv6 1671 server and ND function may be located in separate modules. In that 1672 case, the Server's AERO interface module can act as a Lightweight 1673 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 1674 the DHCPv6 server module. 1676 When the LDRA receives an authentic RS message, it extracts the PD 1677 message parameters and uses them to construct an IPv6/UDP/DHCPv6 1678 message. It sets the IPv6 source address to the source address of 1679 the RS message, sets the IPv6 destination address to 1680 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 1681 that will be understood by the DHCPv6 server. 1683 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 1684 header and includes an 'Interface-Id' option that includes enough 1685 information to allow the LDRA to forward the resulting Reply message 1686 back to the Client (e.g., the Client's link-layer addresses, a 1687 security association identifier, etc.). The LDRA also wraps the 1688 information in all of the SLLAOs from the RS message into the 1689 Interface-Id option, then forwards the message to the DHCPv6 server. 1691 When the DHCPv6 server prepares a Reply message, it wraps the message 1692 in a 'Relay-Reply' message and echoes the Interface-Id option. The 1693 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1694 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1695 uses the DHCPv6 message to construct an RA response to the Client. 1696 The Server uses the information in the Interface-Id option to prepare 1697 the RA message and to cache the link-layer addresses taken from the 1698 SLLAOs echoed in the Interface-Id option. 1700 3.15. The AERO Proxy 1702 In some environments, Clients may be located in secured subnetwork 1703 enclaves that do not allow direct communications from the Client to a 1704 Server in the outside Internetwork. In that case, the secured 1705 enclave can employ an AERO Proxy. 1707 The Proxy is located at the secured enclave perimeter and listens for 1708 encapsulated RS messages originating from or RA messages destined to 1709 Clients located within the enclave. The Proxy acts on these control 1710 messages as follows: 1712 o when the Proxy receives an RS message from a Client within the 1713 secured enclave, it first authenticates the message then creates a 1714 proxy neighbor cache entry for the Client in the INCOMPLETE State 1715 and caches the Client and Server link-layer addresses along with 1716 any identifying information including Transaction IDs, Client 1717 Identifiers, Nonce values, etc. The Proxy then examines the 1718 address in the first SLLAO of the RS message. If the address is 1719 different than the Client link-layer address, the Proxy notes that 1720 the Client is behind a NAT. The Proxy then re-encapsulates the RS 1721 message using its own external address as the source link-layer 1722 address, sets the X flag in the first SLLAO to '1', changes the 1723 address in the first SLLAO to its own external address, and 1724 forwards the message to the Server. 1726 o when the Server receives the RS message, it authenticates the 1727 message then creates a static neighbor cache entry for the Client 1728 with the Proxy's address as the link-layer address. The Server 1729 then sends an RA message back to the Proxy. 1731 o when the Proxy receives the RA message, it matches the message 1732 with the RS that created the (INCOMPLETE) proxy neighbor cache 1733 entry. The Proxy then caches the route information in the message 1734 as a mapping from the Client's ACPs to the Client's address within 1735 the secured enclave, and sets the neighbor cache entry state to 1736 REACHABLE. The Proxy then re-encapsulates the RA message using 1737 its own internal address as the source link-layer address, sets 1738 the X flag in the first SLLAO to '1', sets the N flag in the 1739 fiirst SLLAO to '1' if the Client is behind a NAT, and forwards 1740 the message to the Client. 1742 After the initial RS/RA exchange, the Proxy forwards data packets 1743 between the Client and Server with the Server acting as the Client's 1744 default router. The Proxy can send RS messages to the Client's 1745 Server(s) to update Server neighbor cache entries on behalf of the 1746 Client, e.g., to refresh neighbor cache entry lifetimes and/or to 1747 convey QoS updates. The Proxy also forwards any Client data packets 1748 for which there is no matching dynamic neighbor cache entry to the 1749 "eldest" of the Client's Servers, i.e., the first among possibly 1750 multiple Servers selected by the Client. If the eldest Server 1751 becomes unresponsive, the Proxy sends future data packets via the 1752 next-eldest Server, etc. 1754 In some subnetworks that employ a Proxy, the Client's ACP can be 1755 injected into the underlying network routing system. In that case, 1756 the Client can send data messages without encapsulation so that the 1757 native underlying network routing system transports the 1758 unencapsulated packets to the Proxy. This can be very beneficial, 1759 e.g., if the Client connects to the network via low-end data links 1760 such as some aviation wireless links. In that case, however, the 1761 Client's control messages are still sent encapsulated so as to supply 1762 the Proxy with the address of the Server and to transport IPv6 ND 1763 messages without decrementing the hop-count. In summary, the 1764 interface becomes one where control messages are encapsulated while 1765 data messages are either unencapsulated or encapsulated according to 1766 the specific use case. This encapsulation avoidance represents a 1767 form of "header compression", meaning that the MTU should be sized 1768 based on the size of full encapsulated messages even if most messages 1769 are sent unencapsulated. 1771 3.16. AERO Route Optimization 1773 While data packets are flowing from a source Client to a target 1774 Client that are both holders of ACPs belonging to the same AERO link, 1775 route optimization SHOULD be used to avoid sending traffic through 1776 sub-optimal routes that consume expensive resources. Route 1777 optimization is conducted on a per-interface basis based on the 1778 source Client's available underlying interfaces, and may need to 1779 involve Proxies and Servers in the process. 1781 Route optimization is initiated by the first eligible AERO node 1782 closest to the source Client (i.e., the route optimization source) as 1783 follows: 1785 o For VPNed, NATed and Direct underlying interfaces, the Server is 1786 the route optimization source. 1788 o For Proxyed underlying interfaces, the Proxy is the route 1789 optimization source. 1791 o For native underlying interfaces, the Client itself is the route 1792 optimization source. 1794 While the source Client sends data packets toward a target Client, 1795 the route optimization source also sends an NS message to receive a 1796 solicited NA message from a target Server acting as a Mobility Anchor 1797 Point (MAP) for the target Client. The route optimization process 1798 parallels IPv6 ND Address Resolution. 1800 The NS includes the AERO address of the route optimization source as 1801 the network-layer source address, the AERO address corresponding to 1802 the data packet's destination address as the network-layer 1803 destination address, and the route optimization source address as the 1804 link-layer source address. For Clients and Proxies as the route 1805 optimization source, the address of the Client's Server is used as 1806 the link-layer destination address. For Servers as the route 1807 optimization source, the address of a Relay is used as the link-layer 1808 destination address. The NS message also includes a single SLLAO 1809 with the route optimization source address in the UDP Port Number and 1810 IP address fields. Finally, the NS message includes a Timestamp and 1811 Nonce option that can be used to match against the corresponding 1812 solicited NA. 1814 When the source Server forwards or originates the NS message, it 1815 inserts an additional mid-layer IP encapsulation header between the 1816 NS message link-layer and network-layer headers. This mid-layer IP 1817 header uses the AERO Server Subnet Router Anycast address as the 1818 source address and the Subnet Router Anycast address corresponding to 1819 the target AERO address as the destination address. The source 1820 Server then changes the link-layer source address to its own address 1821 and the link-layer destination address to the address of a Relay. 1822 The Server finally forwards the message to the Relay without 1823 decrementing the network-layer TTL/Hop Limit field. 1825 When the Relay receives the double-encapsulated NS message from the 1826 source Server, it discards the link-layer header(s) and determines 1827 that the target Server is the next hop toward the target Client by 1828 consulting its standard IP forwarding table for the Client Subnet 1829 Router Anycast destination address. The Relay then encapsulates and 1830 forwards the message to the target Server the same as for any IP 1831 router. 1833 When the target Server receives the double-encapsulated NS message 1834 from the Relay, it removes the link-layer and mid-layer headers and 1835 examines the network-layer destination address to determine whether 1836 the target Client is one of its static neighbors. If the target 1837 Client is not a static neighbor, the target Server discards the NS 1838 and prepares a solicited NA message with no TLLAOs to send back to 1839 the route optimization source. The target Server then encapsulates 1840 the solicited NA message, sets the link-layer source address to its 1841 own address and sets the link-layer destination address to the 1842 address found in the NS SLLAO. The target Server finally includes 1843 the Nonce value received in the NS plus the current Timestamp, then 1844 sends the solicited NA message to the route optimization source. 1846 Otherwise, the target Server adds the link-layer address found in the 1847 NS SLLAO to the "Report" list for the target Client's neighbor cache 1848 entry with timer set to ReportTime seconds, but it does not create or 1849 update a neighbor cache entry. The target Server then prepares a 1850 solicited NA message to send back to the route optimization source. 1851 The solicited NA message includes a first TLLAO with the target 1852 Server's address in the IP address and UDP Port Number, with 1853 Interface ID set to '255', with all P(i) values set to "low" and with 1854 "Prefix Length" set to the prefix length of the target Client's ACP. 1855 The solicited NA message then includes additional TLLAOs for all of 1856 the target Client's underlying interfaces. For NATed, VPNed and 1857 Direct interfaces, the TLLAO addresses are the address of the Server. 1858 For Proxyed interfaces, the TLLAO addresses are the addresses of the 1859 Proxies, and for native interfaces the TLLAO addresses are the 1860 addresses of the Client. The target Server then encapsulates the 1861 solicited NA message, sets the link-layer source address to its own 1862 address and sets the link-layer destination address to the address 1863 found in the NS SLLAO. The target Server finally includes the Nonce 1864 value received in the NS plus the current Timestamp, then sends the 1865 solicited NA message to the route optimization source. 1867 When the route optimization source receives the solicited NA message, 1868 it verifies the Nonce and Timestamp. If there are no TLLAOs, the 1869 route optimization source discards the message; otherwise, it creates 1870 a dynamic neighbor cache entry for the target Client and caches all 1871 address, Interface ID, P(i) and Prefix Length information found in 1872 the solicited NA TLLAOs. The route optimization source also sets the 1873 neighbor cache entry state to REACHABLE and sets the timeout value to 1874 ReachableTime. Future data packets that flow through the route 1875 optimization source will then go directly to the target Client 1876 instead of traveling through a dogleg route involving unnecessary 1877 Servers and/or Relays. The route optimization further is shared by 1878 all sources that send packets to the target Client, i.e., and not 1879 just the original source Client. 1881 While new data packets destined to the target are flowing through the 1882 route optimization source, it sends additional NS messages to the 1883 target Server before ReachableTime expires to receive a fresh 1884 solicited NA message. The route optimization source then updates the 1885 dynamic neighbor cache entry to refresh ReachableTime, while the 1886 target Server updates the target Client's static neighbor cache entry 1887 to refresh ReportTime. While no data packets are flowing, the route 1888 optimization source instead allows the dynamic neighbor cache entry 1889 to expire. Following expiration, future data packets flowing through 1890 the route optimization source will again trigger a new route 1891 optimization exchange while initial data packets travel over a 1892 suboptimal route via Servers and/or Relays. 1894 In this arrangement, the route optimization source holds a dynamic 1895 neighbor cache entry for the target, but the target does not hold a 1896 dynamic neighbor cache entry for the route optimization source. The 1897 route optimization neighbor relationship is therefore asymmetric and 1898 unidirectional. If the target Client also has packets to send back 1899 to the source Client, then a separate route optimization procedure is 1900 required in the reverse direction. But, there is no requirement that 1901 the forward and reverse paths be symmetric. 1903 3.17. Neighbor Unreachability Detection (NUD) 1905 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1906 NS messages to elicit solicited NA messages from the target node the 1907 same as described in [RFC4861]. NUD is performed either reactively 1908 in response to persistent link-layer errors (see Section 3.13) or 1909 proactively to confirm reachability in the forward direction. 1911 When an AERO node sends an NS/NA message, it uses one of its link- 1912 local addresses as the IPv6 source address and a link-local address 1913 of the neighbor as the IPv6 destination address. When route 1914 optimization directs a source AERO node to a target AERO node, the 1915 source node SHOULD proactively test the direct path by sending an 1916 initial NS message to elicit a solicited NA response. While testing 1917 the path, the source node can optionally continue sending packets via 1918 its default router, maintain a small queue of packets until target 1919 reachability is confirmed, or (optimistically) allow packets to flow 1920 directly to the target. 1922 Note that AERO nodes may have multiple underlying interface paths 1923 toward the target neighbor. In that case, NUD SHOULD be performed 1924 over each underlying interface individually and the node should only 1925 consider the neighbor unreachable if NUD fails over multiple 1926 underlying interface paths. 1928 Underlying interface paths that pass NUD tests are marked as 1929 "reachable", while those that do not are marked as "unreachable". 1930 These markings inform the AERO interface forwarding algorithm 1931 specified in Section 3.8. 1933 3.18. Mobility Management and Quality of Service (QoS) 1935 AERO is an example of a Distributed Mobility Management (DMM) 1936 service. Each Server is responsible for only a subset of the Clients 1937 on the AERO link, as opposed to a Centralized Mobility Management 1938 (CMM) service where there is a single network mobility service for 1939 all Clients. Clients coordinate with their associated Servers via 1940 RS/RA exchanges to maintain the DMM profile, and the AERO routing 1941 system tracks all current Client/Server peering relationships. 1943 Servers provide a Mobility Anchor Point (MAP) for their dependent 1944 Clients. Clients are responsible for maintaining neighbor 1945 relationships with their Servers through periodic RS/RA exchanges, 1946 which also serves to confirm Client reachability. When a Client's 1947 underlying interface address and/or QoS information changes, the 1948 Client is responsible for updating the Server with this new 1949 information. (Note that for Proxyed interfaces, however, the Proxy 1950 can perform the RS/RA exchanges on the Client's behalf.) 1952 Mobility management considerations are specified in the following 1953 sections. 1955 3.18.1. Mobility Update Messaging 1957 AERO Servers accommodate mobility and/or QoS change events by sending 1958 unsolicited NA messages to all route optimization sources for the 1959 target Client. When a Server sends an unsolicited NA message, it 1960 sets the IPv6 source address to the Client's AERO address, sets the 1961 IPv6 destination address to all-nodes multicast, sets the link-layer 1962 source address to its own address and sets the link-layer destination 1963 address to either a multicast address or the unicast link-layer 1964 address of a route optimization source in the Client's Report list. 1965 The Server also includes a first TLLAO for its own Interface ID, and 1966 includes additional TLLAOs for all of the target Client's Interface 1967 IDs. If there are multiple route optimization sources, the node 1968 sends identical unicast copies of the unsolicited NA to each source. 1970 As for the hot-swap of interface cards discusssed in Section 7.2.6 of 1971 [RFC4861], the transmission and reception of unsolicited NA messages 1972 is unreliable but provides a useful optimization. The Server can 1973 optionally send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to 1974 each route optimization source to increase the likelihood that at 1975 least one will be received. 1977 When a route optimization source receives an unsolicited NA message, 1978 it ignores the message if there is no existing neighbor cache entry 1979 for the Client. Otherwise, it uses the included TLLAOs to update the 1980 address and QoS information in the neighbor cache entry, but does not 1981 reset ReachableTime since the receipt of an unsolicited NA message 1982 from the target Server does not provide confirmation that any forward 1983 paths to the target Client are working. 1985 If unsolicited NA messages are lost, the route optimization source 1986 may be left with stale address and/or QoS information for the Client 1987 for up to ReachableTime seconds. During this time, the route 1988 optimization source can continue sending packets to the target Client 1989 according to its current neighbor cache information but may receive 1990 persistent Destination Unreachable messages and/or unsolicited NA 1991 messages with no TLLAOs as discussed in Section 3.18.2. In that 1992 case, the route optimization source SHOULD delete the dynamic 1993 neighbor cache entry and re-initiate route optimization immediately 1994 instead of waiting for ReachableTime to expire. 1996 3.18.2. Forwarding Packets on Behalf of Departed Clients 1998 When a Server receives packets with destination addresses that do not 1999 match one of its static neighbor cache Clients, it forwards the 2000 packets to a Relay which delivers them to the target Client's current 2001 location. If the source is not one of its static neighbor Clients, 2002 the Server also returns an unsolicited NA message to the source with 2003 no TLLAOs - the sender will then realize that it needs to delete its 2004 neighbor cache entry that associated the target with this Server and 2005 re-initiate route optimization. 2007 When a Proxy receives packets with destination addresses that do not 2008 match one of its proxy neighbor cache Clients, if forwards the 2009 packets to a Server which delivers them to the target Client's 2010 current location. If the source is not one of its proxy neighbor 2011 Clients, the Proxy also returns an unsolicited NA message to the 2012 source with no TLLAOs the same as described for Servers above. 2014 When a Client receives packets with destination addresses that do not 2015 match one of its ACPs, it drops the packets and returns an 2016 unsolicited NA message to the source with no TLLAOs. 2018 3.18.3. Announcing Link-Layer Address and/or QoS Preference Changes 2020 When a Client needs to change its link-layer addresses and/or QoS 2021 preferences (e.g., due to a mobility event), either the Client or 2022 Proxy sends RS messages to its Servers using the new link-layer 2023 address as the source address and with TLLAOs that include the new 2024 Client UDP Port Number, IP Address and P(i) values. If the RS 2025 messages are sent solely for the purpose of updating QoS preferences 2026 without updating the link-layer address, the UDP Port Number and IP 2027 Address are set to 0. 2029 Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with 2030 sending actual data packets in case one or more RAs are lost. If all 2031 RAs are lost, the Client SHOULD re-associate with a new Server. 2033 3.18.4. Bringing New Links Into Service 2035 When a Client needs to bring new underlying interfaces into service 2036 (e.g., when it activates a new data link), it sends RS messages to 2037 its Servers using the new link-layer address as the source address 2038 and with TLLAOs that include the new Client link-layer information. 2040 3.18.5. Removing Existing Links from Service 2042 When a Client needs to remove existing underlying interfaces from 2043 service (e.g., when it de-activates an existing data link), it sends 2044 RS messages to its Servers with SLLAOs with all P(i) values set to 0. 2046 If the Client needs to send RS messages over an underlying interface 2047 other than the one being removed from service, it MUST include a 2048 current SLLAO for the sending interface as the first SLLAO and 2049 include SLLAOs for any underlying interface being removed from 2050 service as additional TLLAOs. 2052 3.18.6. Implicit Mobility Management 2054 AERO interface neighbors MAY provide a configuration option that 2055 allows them to perform implicit mobility management in which no ND 2056 messaging is used. In that case, the Client only transmits packets 2057 over a single interface at a time, and the neighbor always observes 2058 packets arriving from the Client from the same link-layer source 2059 address. 2061 If the Client's underlying interface address changes (either due to a 2062 readdressing of the original interface or switching to a new 2063 interface) the neighbor immediately updates the neighbor cache entry 2064 for the Client and begins accepting and sending packets to the 2065 Client's new link-layer address. This implicit mobility method 2066 applies to use cases such as cellphones with both WiFi and Cellular 2067 interfaces where only one of the interfaces is active at a given 2068 time, and the Client automatically switches over to the backup 2069 interface if the primary interface fails. 2071 3.18.7. Moving to a New Server 2073 When a Client associates with a new Server, it performs the Client 2074 procedures specified in Section 3.14.2. The Client then sends RS 2075 messages with PD release parameters to the old Server to release 2076 itself from that Server's domain. If the Client does not receive an 2077 RA reply after MAX_RTR_SOLICITATIONS attempts, the old Server may 2078 have failed and the Client should discontinue its release attempts. 2079 When the old Server processes the PD release, it sends unsolicited NA 2080 messages with no TLLAOs to all route optimization sources in the 2081 Client's Report list. 2083 Clients SHOULD NOT move rapidly between Servers in order to avoid 2084 causing excessive oscillations in the AERO routing system. Such 2085 oscillations could result in intermittent reachability for the Client 2086 itself, while causing no harm to the network. Examples of when a 2087 Client might wish to change to a different Server include a Server 2088 that has gone unreachable, topological movements of significant 2089 distance, movement to a new geographic region, etc. 2091 3.19. Multicast Considerations 2093 When the underlying network does not support multicast, AERO Clients 2094 map link-scoped multicast addresses to the link-layer address of a 2095 Server, which acts as a multicast forwarding agent. The AERO Client 2096 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2097 applications per [RFC4605] while using the link-layer address of the 2098 Server as the link-layer address for all multicast packets. 2100 When the underlying network supports multicast, AERO nodes use the 2101 multicast address mapping specification found in [RFC2529] for IPv4 2102 underlying networks and use a TBD site-scoped multicast mapping for 2103 IPv6 underlying networks. In that case, border routers must ensure 2104 that the encapsulated site-scoped multicast packets do not leak 2105 outside of the site spanned by the AERO link. 2107 4. Direct Underlying Interfaces 2109 When a Client's AERO interface is configured over a Direct underlying 2110 interface, the neighbor at the other end of the Direct link can 2111 receive packets without any encapsulation. In that case, the Client 2112 sends packets over the Direct link according to the QoS preferences 2113 associated with its underling interfaces. If the Direct underlying 2114 interface has the highest QoS preference, then the Client's IP 2115 packets are transmitted directly to the peer without going through an 2116 underlying network. If other underlying interfaces have higher QoS 2117 preferences, then the Client's IP packets are transmitted via a 2118 different underlying interface, which may result in the inclusion of 2119 Proxies, Servers and Relays in the communications path. Direct 2120 underlying interfaces must be tested periodically for reachability, 2121 e.g., via NUD. 2123 5. Operation on AERO Links with /64 ASPs 2125 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2126 length /64 or shorter. However, in some cases it may be desirable to 2127 use AERO over links that have only a /64 ASP. This can be 2128 accommodated by treating all Clients on the AERO link as simple hosts 2129 that receive /128 prefix delegations. 2131 In that case, the Client sends an RS message to the Server the same 2132 as for ordinary AERO links. The Server responds with an RA message 2133 that includes one or more /128 prefixes (i.e., singleton addresses) 2134 that include the /64 ASP prefix along with an interface identifier 2135 portion to be assigned to the Client. The Client and Server then 2136 configure their AERO addresses based on the interface identifier 2137 portions of the /128s (i.e., the lower 64 bits) and not based on the 2138 /64 prefix (i.e., the upper 64 bits). 2140 For example, if the ASP for the host-only IPv6 AERO link is 2141 2001:db8:1000:2000::/64, each Client will receive one or more /128 2142 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2143 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2144 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2145 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2146 /128s) to either the AERO interface or an internal virtual interface 2147 such as a loopback. In this arrangement, the Client conducts route 2148 optimization in the same sense as discussed in Section 3.16. 2150 This specification has applicability for nodes that act as a Client 2151 on an "upstream" AERO link, but also act as a Server on "downstream" 2152 AERO links. More specifically, if the node acts as a Client to 2153 receive a /64 prefix from the upstream AERO link it can then act as a 2154 Server to provision /128s to Clients on downstream AERO links. 2156 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) 2158 SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically 2159 Generated Addresses (CGAs) [RFC3972] were designed to secure IPv6 ND 2160 messaging in environments where symmetric network and/or transport- 2161 layer security services are impractical (see: Section 10). AERO 2162 nodes that use SEND/CGA employ the following adaptations. 2164 When a source AERO node prepares a SEND-protected ND message, it uses 2165 a link-local CGA as the IPv6 source address and writes the prefix 2166 embedded in its AERO address (i.e., instead of fe80::/64) in the CGA 2167 parameters Subnet Prefix field. When the neighbor receives the ND 2168 message, it first verifies the message checksum and SEND/CGA 2169 parameters while using the link-local prefix fe80::/64 (i.e., instead 2170 of the value in the Subnet Prefix field) to match against the IPv6 2171 source address of the ND message. 2173 The neighbor then derives the AERO address of the source by using the 2174 value in the Subnet Prefix field as the interface identifier of an 2175 AERO address. For example, if the Subnet Prefix field contains 2176 2001:db8:1:2, the neighbor constructs the AERO address as 2177 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 2178 neighbor cache entry it creates for the source, and uses the AERO 2179 address as the IPv6 destination address of any ND message replies. 2181 7. AERO Critical Infrastructure Considerations 2183 AERO Relays are low-end to midrange Commercial off-the Shelf (COTS) 2184 standard IP routers with no AERO code. Relays must be provisioned, 2185 supported and managed by the AERO Link Service Provider. Cost for 2186 purchasing, configuring and managing Relays is nominal even for very 2187 large AERO links. 2189 AERO Servers can be standard dedicated server platforms, but most 2190 often will be deployed as virtual machines in the cloud. The only 2191 requirements for Servers are that they can run the AERO user-level 2192 code and have at least one network interface with a public IP 2193 address. As with Relays, Servers must be provisioned, supported and 2194 managed by the AERO Link Service Provider. Cost for purchasing, 2195 configuring and managing Servers is nominal especially for virtual 2196 Servers hosted in the cloud. 2198 AERO Proxies are most often standard dedicated server platforms with 2199 one network interface connected to the secured enclave and a second 2200 interface connected to the public Internetwork. As with Servers, the 2201 only requirements are that they can run the AERO user-level code and 2202 have at least one interface with a public IP address. Proxies must 2203 be provisioned, supported and managed by the administrative authority 2204 for the secured enclave. Cost for purchasing, configuring and 2205 managing Proxies is nominal, and borne by the secured enclave 2206 administrative authority. 2208 8. Implementation Status 2210 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2211 announced on the v6ops mailing list on January 10, 2018. The latest 2212 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2213 2.0.tgz. 2215 An initial public release of the AERO proof-of-concept source code 2216 was announced on the intarea mailing list on August 21, 2015. The 2217 latest version is available at: http://linkupnetworks.net/aero/aero- 2218 4.0.0.tgz. 2220 A survey of public domain and commercial SEND implementations is 2221 available at https://www.ietf.org/mail-archive/web/its/current/ 2222 msg02758.html. 2224 9. IANA Considerations 2226 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2227 AERO in the "enterprise-numbers" registry. 2229 The IANA has assigned the UDP port number "8060" for an earlier 2230 experimental version of AERO [RFC6706]. This document obsoletes 2231 [RFC6706] and claims the UDP port number "8060" for all future use. 2233 No further IANA actions are required. 2235 10. Security Considerations 2237 AERO link security considerations include considerations for both the 2238 data plane and the control plane. 2240 Data plane security considerations are the same as for ordinary 2241 Internet communications. Application endpoints in AERO Clients and 2242 their EUNs SHOULD use application-layer security services such as 2243 TLS/SSL [RFC5246], DTLS [RFC6347] or SSH [RFC4251] to assure the same 2244 level of protection as for critical secured Internet services such as 2245 online banking. AERO Clients that require VPN access to enterprise 2246 networks SHOULD use symmetric network and/or transport layer security 2247 services such as TLS/SSL, DTLS, IPsec [RFC4301], etc. 2249 Control plane security considerations are the same as for standard 2250 IPv6 Neighbor Discovery [RFC4861], except that the PRL also improves 2251 security by providing AERO Clients with a list of trusted Servers. 2252 As fixed infrastructure elements, AERO Proxies and Servers SHOULD 2253 pre-configure security associations for one another (e.g., using pre- 2254 placed keys) and use symmetric network and/or transport layer 2255 security services such as IPsec, TLS/SSL or DTLS to secure ND 2256 messages. AERO Clients that connect to secured enclaves need not 2257 apply security to their ND messages, since the messages will be 2258 intercepted by an enclave perimeter Proxy. AERO Clients located 2259 outside of secured enclaves SHOULD use symmetric network and/or 2260 transport layer security to secure their ND exchanges with Servers, 2261 but when there are many prospective neighbors with dynamically 2262 changing connectivity an asymmetric security service such as SEND may 2263 be needed (see: Section 6). 2265 AERO Servers and Relays present targets for traffic amplification 2266 Denial of Service (DoS) attacks. This concern is no different than 2267 for widely-deployed VPN security gateways in the Internet, where 2268 attackers could send spoofed packets to the gateways at high data 2269 rates. This can be mitigated by connecting Relays and Servers over 2270 dedicated links with no connections to the Internet and/or when 2271 connections to the Internet are only permitted through well-managed 2272 firewalls. Traffic amplification DoS attacks can also target an AERO 2273 Client's low data rate links. This is a concern not only for Clients 2274 located on the open Internet but also for Clients in secured 2275 enclaves. AERO Servers and Proxies can institute rate limits that 2276 protect Clients from receiving packet floods that could DoS low data 2277 rate links. 2279 AERO Clients MUST ensure that their connectivity is not used by 2280 unauthorized nodes on their EUNs to gain access to a protected 2281 network, i.e., AERO Clients that act as routers MUST NOT provide 2282 routing services for unauthorized nodes. (This concern is no 2283 different than for ordinary hosts that receive an IP address 2284 delegation but then "share" the address with other nodes via some 2285 form of Internet connection sharing such as tethering.) 2287 Although public domain and commercial SEND implementations exist, 2288 concerns regarding the strength of the cryptographic hash algorithm 2289 have been documented [RFC6273] [RFC4982]. 2291 The PRL MUST be well-managed and secured from unauthorized tampering, 2292 even though the list includes only public information. 2294 Security considerations for accepting link-layer ICMP messages and 2295 reflected packets are discussed throughout the document. 2297 11. Acknowledgements 2299 Discussions in the IETF, aviation standards communities and private 2300 exchanges helped shape some of the concepts in this work. 2301 Individuals who contributed insights include Mikael Abrahamsson, Mark 2302 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2303 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2304 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2305 Hlusiak, Lee Howard, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy 2306 Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru 2307 Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, 2308 Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members 2309 of the IESG also provided valuable input during their review process 2310 that greatly improved the document. Special thanks go to Stewart 2311 Bryant, Joel Halpern and Brian Haberman for their shepherding 2312 guidance during the publication of the AERO first edition. 2314 This work has further been encouraged and supported by Boeing 2315 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2316 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2317 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2318 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Greg 2319 Saccone, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan 2320 Williams, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 2321 BR&T and BIT mobile networking teams. Kyle Bae, Wayne Benson and 2322 Eric Yeh are especially acknowledged for implementing the AERO 2323 functions as extensions to the public domain OpenVPN distribution. 2325 Earlier works on NBMA tunneling approaches are found in 2326 [RFC2529][RFC5214][RFC5569]. 2328 Many of the constructs presented in this second edition of AERO are 2329 based on the author's earlier works, including: 2331 o The Internet Routing Overlay Network (IRON) 2332 [RFC6179][I-D.templin-ironbis] 2334 o Virtual Enterprise Traversal (VET) 2335 [RFC5558][I-D.templin-intarea-vet] 2337 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2338 [RFC5320][I-D.templin-intarea-seal] 2340 o AERO, First Edition [RFC6706] 2342 Note that these works cite numerous earlier efforts that are not also 2343 cited here due to space limitations. The authors of those earlier 2344 works are acknowledged for their insights. 2346 This work is aligned with the NASA Safe Autonomous Systems Operation 2347 (SASO) program under NASA contract number NNA16BD84C. 2349 This work is aligned with the FAA as per the SE2025 contract number 2350 DTFAWA-15-D-00030. 2352 This work is aligned with the Boeing Information Technology (BIT) 2353 MobileNet program. 2355 This work is aligned with the Boeing autonomy program. 2357 12. References 2359 12.1. Normative References 2361 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2362 DOI 10.17487/RFC0768, August 1980, 2363 . 2365 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2366 DOI 10.17487/RFC0791, September 1981, 2367 . 2369 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2370 RFC 792, DOI 10.17487/RFC0792, September 1981, 2371 . 2373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2374 Requirement Levels", BCP 14, RFC 2119, 2375 DOI 10.17487/RFC2119, March 1997, 2376 . 2378 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2379 "Definition of the Differentiated Services Field (DS 2380 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2381 DOI 10.17487/RFC2474, December 1998, 2382 . 2384 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2385 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2386 DOI 10.17487/RFC3971, March 2005, 2387 . 2389 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2390 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2391 . 2393 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2394 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2395 November 2005, . 2397 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2398 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2399 . 2401 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2402 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2403 DOI 10.17487/RFC4861, September 2007, 2404 . 2406 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2407 Address Autoconfiguration", RFC 4862, 2408 DOI 10.17487/RFC4862, September 2007, 2409 . 2411 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2412 Advertisement Flags Option", RFC 5175, 2413 DOI 10.17487/RFC5175, March 2008, 2414 . 2416 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2417 (IPv6) Specification", STD 86, RFC 8200, 2418 DOI 10.17487/RFC8200, July 2017, 2419 . 2421 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2422 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2423 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2424 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2425 . 2427 12.2. Informative References 2429 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2430 2016. 2432 [I-D.ietf-dmm-distributed-mobility-anchoring] 2433 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 2434 "Distributed Mobility Anchoring", draft-ietf-dmm- 2435 distributed-mobility-anchoring-12 (work in progress), 2436 January 2019. 2438 [I-D.ietf-intarea-gue] 2439 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2440 Encapsulation", draft-ietf-intarea-gue-06 (work in 2441 progress), August 2018. 2443 [I-D.ietf-intarea-gue-extensions] 2444 Herbert, T., Yong, L., and F. Templin, "Extensions for 2445 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2446 extensions-05 (work in progress), August 2018. 2448 [I-D.ietf-intarea-tunnels] 2449 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2450 Architecture", draft-ietf-intarea-tunnels-09 (work in 2451 progress), July 2018. 2453 [I-D.ietf-rtgwg-atn-bgp] 2454 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2455 Moreno, "A Simple BGP-based Mobile Routing System for the 2456 Aeronautical Telecommunications Network", draft-ietf- 2457 rtgwg-atn-bgp-01 (work in progress), January 2019. 2459 [I-D.templin-6man-aeroaddr] 2460 Templin, F., "The AERO Address", draft-templin-6man- 2461 aeroaddr-04 (work in progress), December 2018. 2463 [I-D.templin-6man-dhcpv6-ndopt] 2464 Templin, F., "A Unified Stateful/Stateless Configuration 2465 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07 2466 (work in progress), December 2018. 2468 [I-D.templin-6man-rio-redirect] 2469 Templin, F. and j. woodyatt, "Route Information Options in 2470 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2471 redirect-07 (work in progress), December 2018. 2473 [I-D.templin-intarea-grefrag] 2474 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2475 templin-intarea-grefrag-04 (work in progress), July 2016. 2477 [I-D.templin-intarea-seal] 2478 Templin, F., "The Subnetwork Encapsulation and Adaptation 2479 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2480 progress), January 2014. 2482 [I-D.templin-intarea-vet] 2483 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2484 templin-intarea-vet-40 (work in progress), May 2013. 2486 [I-D.templin-ironbis] 2487 Templin, F., "The Interior Routing Overlay Network 2488 (IRON)", draft-templin-ironbis-16 (work in progress), 2489 March 2014. 2491 [I-D.templin-v6ops-pdhost] 2492 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 2493 Models", draft-templin-v6ops-pdhost-23 (work in progress), 2494 December 2018. 2496 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2498 [RFC1035] Mockapetris, P., "Domain names - implementation and 2499 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2500 November 1987, . 2502 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2503 Communication Layers", STD 3, RFC 1122, 2504 DOI 10.17487/RFC1122, October 1989, 2505 . 2507 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2508 DOI 10.17487/RFC1191, November 1990, 2509 . 2511 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2512 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2513 . 2515 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2516 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2517 1996, . 2519 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2520 DOI 10.17487/RFC2003, October 1996, 2521 . 2523 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2524 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2525 . 2527 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2528 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2529 December 1998, . 2531 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2532 Domains without Explicit Tunnels", RFC 2529, 2533 DOI 10.17487/RFC2529, March 1999, 2534 . 2536 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2537 Malis, "A Framework for IP Based Virtual Private 2538 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2539 . 2541 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2542 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2543 DOI 10.17487/RFC2784, March 2000, 2544 . 2546 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2547 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2548 . 2550 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2551 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2552 . 2554 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2555 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2556 . 2558 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2559 of Explicit Congestion Notification (ECN) to IP", 2560 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2561 . 2563 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2564 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2565 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2566 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2567 . 2569 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2570 for IPv6 Hosts and Routers", RFC 4213, 2571 DOI 10.17487/RFC4213, October 2005, 2572 . 2574 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2575 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 2576 January 2006, . 2578 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2579 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2580 DOI 10.17487/RFC4271, January 2006, 2581 . 2583 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2584 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2585 2006, . 2587 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2588 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2589 December 2005, . 2591 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2592 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2593 2006, . 2595 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2596 Control Message Protocol (ICMPv6) for the Internet 2597 Protocol Version 6 (IPv6) Specification", STD 89, 2598 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2599 . 2601 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2602 Protocol (LDAP): The Protocol", RFC 4511, 2603 DOI 10.17487/RFC4511, June 2006, 2604 . 2606 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2607 "Internet Group Management Protocol (IGMP) / Multicast 2608 Listener Discovery (MLD)-Based Multicast Forwarding 2609 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2610 August 2006, . 2612 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2613 Errors at High Data Rates", RFC 4963, 2614 DOI 10.17487/RFC4963, July 2007, 2615 . 2617 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 2618 Algorithms in Cryptographically Generated Addresses 2619 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 2620 . 2622 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2623 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2624 DOI 10.17487/RFC5214, March 2008, 2625 . 2627 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2628 (TLS) Protocol Version 1.2", RFC 5246, 2629 DOI 10.17487/RFC5246, August 2008, 2630 . 2632 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2633 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2634 February 2010, . 2636 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2637 Route Optimization Requirements for Operational Use in 2638 Aeronautics and Space Exploration Mobile Networks", 2639 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2640 . 2642 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2643 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2644 . 2646 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2647 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2648 January 2010, . 2650 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2651 Global Enterprise Recursion (RANGER)", RFC 5720, 2652 DOI 10.17487/RFC5720, February 2010, 2653 . 2655 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2656 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2657 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2658 . 2660 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2661 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2662 . 2664 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2665 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2666 DOI 10.17487/RFC6221, May 2011, 2667 . 2669 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 2670 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 2671 DOI 10.17487/RFC6273, June 2011, 2672 . 2674 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2675 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2676 January 2012, . 2678 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2679 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2680 . 2682 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2683 for Equal Cost Multipath Routing and Link Aggregation in 2684 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2685 . 2687 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2688 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2689 . 2691 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2692 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2693 . 2695 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2696 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2697 March 2017, . 2699 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2700 October 2014. 2702 Appendix A. AERO Alternate Encapsulations 2704 When GUE encapsulation is not needed, AERO can use common 2705 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2706 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2707 encapsulation is therefore only differentiated from non-AERO tunnels 2708 through the application of AERO control messaging and not through, 2709 e.g., a well-known UDP port number. 2711 As for GUE encapsulation, alternate AERO encapsulation formats may 2712 require encapsulation layer fragmentation. For simple IP-in-IP 2713 encapsulation, an IPv6 fragment header is inserted directly between 2714 the inner and outer IP headers when needed, i.e., even if the outer 2715 header is IPv4. The IPv6 Fragment Header is identified to the outer 2716 IP layer by its IP protocol number, and the Next Header field in the 2717 IPv6 Fragment Header identifies the inner IP header version. For GRE 2718 encapsulation, a GRE fragment header is inserted within the GRE 2719 header [I-D.templin-intarea-grefrag]. 2721 Figure 4 shows the AERO IP-in-IP encapsulation format before any 2722 fragmentation is applied: 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Outer IPv4 Header | | Outer IPv6 Header | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | Inner IP Header | | Inner IP Header | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | | | | 2732 ~ ~ ~ ~ 2733 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2734 ~ ~ ~ ~ 2735 | | | | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2740 Figure 4: Minimal Encapsulation Format using IP-in-IP 2742 Figure 5 shows the AERO GRE encapsulation format before any 2743 fragmentation is applied: 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | Outer IP Header | 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | GRE Header | 2749 | (with checksum, key, etc..) | 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 | GRE Fragment Header (optional)| 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | Inner IP Header | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 | | 2756 ~ ~ 2757 ~ Inner Packet Body ~ 2758 ~ ~ 2759 | | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 Figure 5: Minimal Encapsulation Using GRE 2764 Alternate encapsulation may be preferred in environments where GUE 2765 encapsulation would add unnecessary overhead. For example, certain 2766 low-bandwidth wireless data links may benefit from a reduced 2767 encapsulation overhead. 2769 GUE encapsulation can traverse network paths that are inaccessible to 2770 non-UDP encapsulations, e.g., for crossing Network Address 2771 Translators (NATs). More and more, network middleboxes are also 2772 being configured to discard packets that include anything other than 2773 a well-known IP protocol such as UDP and TCP. It may therefore be 2774 necessary to determine the potential for middlebox filtering before 2775 enabling alternate encapsulation in a given environment. 2777 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2778 encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO 2779 control messaging and route determination occur before security 2780 encapsulation is applied for outgoing packets and after security 2781 decapsulation is applied for incoming packets. 2783 AERO is especially well suited for use with VPN system encapsulations 2784 such as OpenVPN [OVPN]. 2786 Appendix B. S/TLLAO Extensions for Special-Purpose Links 2788 The AERO S/TLLAO format specified in Section 3.5 includes a Length 2789 value of 5 (i.e., 5 units of 8 octets). However, special-purpose 2790 links may extend the basic format to include additional fields and a 2791 Length value larger than 5. 2793 For example, adaptation of AERO to the Aeronautical 2794 Telecommunications Network with Internet Protocol Services (ATN/IPS) 2795 includes link selection preferences based on transport port numbers 2796 in addition to the existing DSCP-based preferences. ATN/IPS nodes 2797 maintain a map of transport port numbers to 64 possible preference 2798 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 2799 maps to preference field 20, UDP port 8060 maps to preference field 2800 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 2801 Figure 6, where the Length value is 7 and the 'Q(i)' fields provide 2802 link preferences for the corresponding transport port number. 2804 0 1 2 3 2805 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 2806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 | Type | Length = 7 | Prefix Length | Reserved | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2809 | Interface ID | UDP Port Number | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 | | 2812 + + 2813 | | 2814 + IP Address + 2815 | | 2816 + + 2817 | | 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 Figure 6: ATN/IPS Extended S/TLLAO Format 2838 Appendix C. Change Log 2840 << RFC Editor - remove prior to publication >> 2842 Changes from draft-templin-intarea-6706bis-06 to draft-templin- 2843 intrea-6706bis-07: 2845 o Added "R" bit for release of PDs. Now have a full RS/RA service 2846 that can do PD without requiring DHCPv6 messaging over-the-air 2848 o Clarifications on solicited vs unsolicited NAs 2850 o Clarified use of MAX_NEIGHBOR_ADVERTISEMENTS for the purpose of 2851 increase reliability 2853 Changes from draft-templin-intarea-6706bis-05 to draft-templin- 2854 intrea-6706bis-06: 2856 o Major re-work and simplification of Route Optimization function 2858 o Added Distributed Mobility Management (DMM) and Mobility Anchor 2859 Point (MAP) terminology 2861 o New section on "AERO Critical Infrastructure Element 2862 Considerations" demonstrating low overall cost for the service 2864 o minor text revisions and deletions 2866 o removed extraneous appendices 2868 Changes from draft-templin-intarea-6706bis-04 to draft-templin- 2869 intrea-6706bis-05: 2871 o New Appendix E on S/TLLAO Extensions for special-purpose links. 2872 Discussed ATN/IPS as example. 2874 o New sentence in introduction to declare appendices as non- 2875 normative. 2877 Changes from draft-templin-intarea-6706bis-03 to draft-templin- 2878 intrea-6706bis-04: 2880 o Added definitions for Potential Router List (PRL) and secure 2881 enclave 2883 o Included text on mapping transport layer port numbers to network 2884 layer DSCP values 2886 o Added reference to DTLS and DMM Distributed Mobility Anchoring 2887 working group document 2889 o Reworked Security Considerations 2891 o Updated references. 2893 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 2894 intrea-6706bis-03: 2896 o Added new section on SEND. 2898 o Clarifications on "AERO Address" section. 2900 o Updated references and added new reference for RFC8086. 2902 o Security considerations updates. 2904 o General text clarifications and cleanup. 2906 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 2907 intrea-6706bis-02: 2909 o Note on encapsulation avoidance in Section 4. 2911 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 2912 intrea-6706bis-01: 2914 o Remove DHCPv6 Server Release procedures that leveraged the old way 2915 Relays used to "route" between Server link-local addresses 2917 o Remove all text relating to Relays needing to do any AERO-specific 2918 operations 2920 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 2921 as source addresses, and destination address of RA reply is to the 2922 AERO address corresponding to the Client's ACP. 2924 o Proxy uses SEND to protect RS and authenticate RA (Client does not 2925 use SEND, but rather relies on subnetwork security. When the 2926 Proxy receives an RS from the Client, it creates a new RS using 2927 its own addresses as the source and uses SEND with CGAs to send a 2928 new RS to the Server. 2930 o Emphasize distributed mobility management 2932 o AERO address-based RS injection of ACP into underlying routing 2933 system. 2935 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 2936 6706bis-00: 2938 o Document use of NUD (NS/NA) for reliable link-layer address 2939 updates as an alternative to unreliable unsolicited NA. 2940 Consistent with Section 7.2.6 of RFC4861. 2942 o Server adds additional layer of encapsulation between outer and 2943 inner headers of NS/NA messages for transmission through Relays 2944 that act as vanilla IPv6 routers. The messages include the AERO 2945 Server Subnet Router Anycast address as the source and the Subnet 2946 Router Anycast address corresponding to the Client's ACP as the 2947 destination. 2949 o Clients use Subnet Router Anycast address as the encapsulation 2950 source address when the access network does not provide a 2951 topologically-fixed address. 2953 Author's Address 2955 Fred L. Templin (editor) 2956 Boeing Research & Technology 2957 P.O. Box 3707 2958 Seattle, WA 98124 2959 USA 2961 Email: fltemplin@acm.org