idnits 2.17.1 draft-templin-intarea-6706bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1852 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 2475, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2511, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 2525, but no explicit reference was found in the text == Unused Reference: 'I-D.templin-6man-rio-redirect' is defined on line 2582, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 2637, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2764, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 2769, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2792, but no explicit reference was found in the text == Unused Reference: 'TUNTAP' is defined on line 2813, 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-07 == 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 (~~), 19 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, March 25, 2019 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: September 26, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-10.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 26, 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 . . . . . . . . . . . . . . . . . 19 77 3.6.4. AERO Client Behavior . . . . . . . . . . . . . . . . 19 78 3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 20 79 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 22 80 3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 22 81 3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 23 82 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 23 83 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 24 84 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 25 85 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 26 86 3.11. AERO Interface Data Origin Authentication . . . . . . . . 26 87 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 27 88 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 29 89 3.14. AERO Router Discovery, Prefix Delegation and 90 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 32 91 3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 32 92 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 33 93 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 35 94 3.15. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . 37 95 3.15.1. The AERO-Aware Access Router . . . . . . . . . . . . 39 97 3.16. AERO Route Optimization . . . . . . . . . . . . . . . . . 39 98 3.17. Neighbor Unreachability Detection (NUD) . . . . . . . . . 42 99 3.18. Mobility Management and Quality of Service (QoS) . . . . 43 100 3.18.1. Mobility Update Messaging . . . . . . . . . . . . . 43 101 3.18.2. Forwarding Packets on Behalf of Departed Clients . . 44 102 3.18.3. Announcing Link-Layer Address and/or QoS Preference 103 Changes . . . . . . . . . . . . . . . . . . . . . . 45 104 3.18.4. Bringing New Links Into Service . . . . . . . . . . 45 105 3.18.5. Removing Existing Links from Service . . . . . . . . 46 106 3.18.6. Implicit Mobility Management . . . . . . . . . . . . 46 107 3.18.7. Moving to a New Server . . . . . . . . . . . . . . . 46 108 3.19. Multicast Considerations . . . . . . . . . . . . . . . . 47 109 4. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 47 110 5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 48 111 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 48 112 7. AERO Critical Infrastructure Considerations . . . . . . . . . 49 113 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 115 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 118 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 119 12.2. Informative References . . . . . . . . . . . . . . . . . 55 120 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 60 121 Appendix B. S/TLLAO Extensions for Special-Purpose Links . . . . 62 122 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 64 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67 125 1. Introduction 127 This document specifies the operation of IP over tunnel virtual links 128 using Asymmetric Extended Route Optimization (AERO). The AERO link 129 can be used for tunneling between neighboring nodes over either IPv6 130 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 131 equivalent links for tunneling. Nodes attached to AERO links can 132 exchange packets via trusted intermediate routers that provide 133 forwarding services to reach off-link destinations and route 134 optimization services for improved performance [RFC5522]. 136 AERO provides an IPv6 link-local address format that supports 137 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 138 links ND to IP forwarding. Dynamic link selection, mobility 139 management, quality of service (QoS) signaling and route optimization 140 are naturally supported through dynamic neighbor cache updates, while 141 IPv6 Prefix Delegation (PD) is supported by network services such as 142 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415]. 144 A node's AERO interface can be configured over multiple underlying 145 interfaces. From the standpoint of ND, AERO interface neighbors 146 therefore may appear to have multiple link-layer addresses (i.e., the 147 IP addresses assigned to underlying interfaces). Each link-layer 148 address is subject to change due to mobility and/or QoS fluctuations, 149 and link-layer address changes are signaled by ND messaging the same 150 as for any IPv6 link. 152 AERO is applicable to a wide variety of use cases. For example, it 153 can be used to coordinate the Virtual Private Network (VPN) links of 154 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 155 connect into a home enterprise network via public access networks 156 using services such as OpenVPN [OVPN]. AERO is also applicable to 157 aviation services for both manned and unmanned aircraft where the 158 aircraft is treated as a mobile node that can connect an Internet of 159 Things (IoT). Other applicable use cases are also in scope. 161 The following numbered sections present the AERO specification. The 162 appendices at the end of the document are non-normative. 164 2. Terminology 166 The terminology in the normative references applies; the following 167 terms are defined within the scope of this document: 169 IPv6 Neighbor Discovery (ND) 170 an IPv6 control message service for coordinating neighbor 171 relationships between nodes connected to a common link. The ND 172 service used by AERO is specified in [RFC4861]. 174 IPv6 Prefix Delegation (PD) 175 a networking service for delegating IPv6 prefixes to nodes on the 176 link. The nominal PD service is DHCPv6 [RFC8415], however 177 alternate services (e.g., based on ND messaging) are also in scope 178 [I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt]. 180 (native) Internetwork 181 a connected IP network topology over which the AERO link virtual 182 overlay is configured and native peer-to-peer communications are 183 supported. Example Internetworks include the global public 184 Internet, private enterprise networks, aviation networks, etc. 186 AERO link 187 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 188 configured over an underlying Internetwork. Nodes on the AERO 189 link appear as single-hop neighbors from the perspective of the 190 virtual overlay even though they may be separated by many 191 underlying Internetwork hops. The AERO mechanisms can also 192 operate over native link types (e.g., Ethernet, WiFi etc.) when 193 tunneling is not needed. 195 AERO interface 196 a node's attachment to an AERO link. Since the addresses assigned 197 to an AERO interface are managed for uniqueness, AERO interfaces 198 do not require Duplicate Address Detection (DAD) and therefore set 199 the administrative variable 'DupAddrDetectTransmits' to zero 200 [RFC4862]. 202 AERO address 203 an IPv6 link-local address constructed as specified in 204 Section 3.4. 206 AERO node 207 a node that is connected to an AERO link. 209 AERO Client ("Client") 210 a node that requests PDs from one or more AERO Servers. Following 211 PD, the Client assigns a Client AERO address to the AERO interface 212 for use in ND exchanges with other AERO nodes. A node that acts 213 as an AERO Client on one AERO interface can also act as an AERO 214 Server on a different AERO interface. 216 AERO Server ("Server") 217 a node that configures an AERO interface to provide default 218 forwarding services and a Mobility Anchor Point (MAP) for AERO 219 Clients. The Server assigns an administratively-provisioned AERO 220 address to the AERO interface to support the operation of the ND/ 221 PD services. An AERO Server can also act as an AERO Relay. 223 AERO Relay ("Relay") 224 an IP router that can relay IP packets between AERO Servers and/or 225 forward IP packets between the AERO link and the native 226 Internetwork. AERO Relays are standard IP routers that do not 227 require any AERO-specific functions. 229 AERO Proxy ("Proxy") 230 a node that provides proxying services, e.g., when the Client is 231 located in a secured internal enclave and the Server is located in 232 the external Internetwork. The AERO Proxy is a conduit between 233 the secured enclave and the external Internetwork in the same 234 manner as for common web proxies, and behaves in a similar fashion 235 as for ND proxies [RFC4389]. 237 ingress tunnel endpoint (ITE) 238 an AERO interface endpoint that injects encapsulated packets into 239 an AERO link. 241 egress tunnel endpoint (ETE) 242 an AERO interface endpoint that receives encapsulated packets from 243 an AERO link. 245 underlying network 246 the same as defined for Internetwork. 248 underlying link 249 a link that connects an AERO node to the underlying network. 251 underlying interface 252 an AERO node's interface point of attachment to an underlying 253 link. 255 link-layer address 256 an IP address assigned to an AERO node's underlying interface. 257 When UDP encapsulation is used, the UDP port number is also 258 considered as part of the link-layer address. Packets transmitted 259 over an AERO interface use link-layer addresses as encapsulation 260 header source and destination addresses. Destination link-layer 261 addresses can be either "reachable" or "unreachable" based on 262 dynamically-changing network conditions. 264 network layer address 265 the source or destination address of an encapsulated IP packet. 267 end user network (EUN) 268 an internal virtual or external edge IP network that an AERO 269 Client connects to the rest of the network via the AERO interface. 270 The Client sees each EUN as a "downstream" network and sees the 271 AERO interface as its point of attachment to the "upstream" 272 network. 274 AERO Service Prefix (ASP) 275 an IP prefix associated with the AERO link and from which more- 276 specific AERO Client Prefixes (ACPs) are derived. 278 AERO Client Prefix (ACP) 279 an IP prefix derived from an ASP and delegated to a Client, where 280 the ACP prefix length must be no shorter than the ASP prefix 281 length. 283 base AERO address 284 the lowest-numbered AERO address from the first ACP delegated to 285 the Client (see Section 3.4). 287 secured enclave 288 a private access network (e.g., a corporate enterprise network, 289 radio access network, cellular service provider network, etc.) 290 with secured links and perimeters. Link-layer security services 291 such as IEEE 802.1X and physical-layer security such as campus 292 wired LANs prevent unauthorized access from within the enclave, 293 while border network-layer security services such as firewalls and 294 proxies prevent unauthorized access from the external 295 Internetwork. 297 Potential Router List (PRL) 298 a geographically and/or topologically referenced list of IP 299 addresses of Servers for the AERO link. 301 Mobility Anchor Point (MAP) 302 an AERO Server that is currently tracking and reporting the 303 mobility events of its associated Clients. 305 Distributed Mobility Management (DMM) 306 an overlay routing service coordinated by Servers and Relays that 307 tracks all MAP-to-Client associations. 309 Throughout the document, the simple terms "Client", "Server", "Relay" 310 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 311 "AERO Proxy", respectively. Capitalization is used to distinguish 312 these terms from DHCPv6 client/server/relay [RFC8415]. 314 The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including 315 the names of node variables, messages and protocol constants) is used 316 throughout this document. Also, the term "IP" is used to generically 317 refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or 318 IPv6 [RFC8200]. 320 The terms Mobility Anchor Point (MAP) and Distributed Mobility 321 Management (DMM) are used in the same sense as standard 322 Internetworking terminology. 324 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 325 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 326 document are to be interpreted as described in [RFC2119]. Lower case 327 uses of these words are not to be interpreted as carrying RFC2119 328 significance. 330 3. Asymmetric Extended Route Optimization (AERO) 332 The following sections specify the operation of IP over Asymmetric 333 Extended Route Optimization (AERO) links: 335 3.1. AERO Link Reference Model 337 .-(::::::::) 338 .-(::::::::::::)-. 339 (:: Internetwork ::) 340 `-(::::::::::::)-' 341 `-(::::::)-' 342 | 343 +--------------+ +--------+-------+ +--------------+ 344 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 345 | Nbr: C1, R1 | | Nbr: S1, S2 | | Nbr: C2, R1 | 346 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 347 | X1->C1 | | ASP A1 | | X2->C2 | 348 +-------+------+ +--------+-------+ +------+-------+ 349 | AERO Link | | 350 X---+---+-------------------+-+----------------+---+---X 351 | | | 352 +-----+--------+ +----------+------+ +--------+-----+ 353 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 354 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 355 | default->S1 | +--------+--------+ | default->S2 | 356 | ACP X1 | | | ACP X2 | 357 +------+-------+ .--------+------. +-----+--------+ 358 | (- Proxyed Clients -) | 359 .-. `---------------' .-. 360 ,-( _)-. ,-( _)-. 361 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 362 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 363 `-(______)-' +-------+ +-------+ `-(______)-' 365 Figure 1: AERO Link Reference Model 367 Figure 1 presents the AERO link reference model. In this model: 369 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 370 default router for its associated Servers (S1 and S2), and 371 connects the AERO link to the rest of the Internetwork. 373 o AERO Servers S1 and S2 associate with Relay R1 and also act as 374 Mobility Anchor Points (MAPs) and default routers for their 375 associated Clients C1 and C2. 377 o AERO Clients C1 and C2 associate with Servers S1 and S2, 378 respectively. They receive AERO Client Prefix (ACP) delegations 379 X1 and X2, and also act as default routers for their associated 380 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 381 to the EUNs served by Clients C1 and C2, respectively. 383 o AERO Proxy P1 provides proxy services for AERO Clients in secured 384 enclaves that cannot associate directly with other AERO link 385 neighbors. 387 Each node on the AERO link maintains an AERO interface neighbor cache 388 and an IP forwarding table the same as for any link. Although the 389 figure shows a limited deployment, in common operational practice 390 there may be many additional Relays, Servers, Clients and Proxies. 392 3.2. AERO Node Types 394 AERO Relays are standard IP routers that provide default forwarding 395 services for AERO Servers. Each Relay also peers with Servers and 396 other Relays in a dynamic routing protocol instance to provide a 397 Distributed Mobility Management (DMM) service for the list of active 398 ACPs (see Section 3.3). Relays forward packets between neighbors 399 connected to the same AERO link and also forward packets between the 400 AERO link and the native Internetwork. Relays present the AERO link 401 to the native Internetwork as a set of one or more AERO Service 402 Prefixes (ASPs) and serve as a gateway between the AERO link and the 403 Internetwork. Relays maintain tunnels with neighboring Servers, and 404 maintain an IP forwarding table entry for each AERO Client Prefix 405 (ACP). 407 AERO Servers provide default forwarding services and a Mobility 408 Anchor Point (MAP) for AERO Clients. Each Server also peers with 409 Relays in a dynamic routing protocol instance to advertise its list 410 of associated ACPs (see Section 3.3). Servers facilitate PD 411 exchanges with Clients, where each delegated prefix becomes an ACP 412 taken from an ASP. Servers forward packets between AERO interface 413 neighbors, and maintain AERO interface neighbor cache entries for 414 Relays. They also maintain both neighbor cache entries and IP 415 forwarding table entries for each of their associated Clients, and 416 track each Client's mobility profiles. 418 AERO Clients act as requesting routers to receive ACPs through PD 419 exchanges with AERO Servers over the AERO link. Each Client can 420 associate with a single Server or with multiple Servers, e.g., for 421 fault tolerance, load balancing, etc. Each IPv6 Client receives at 422 least a /64 IPv6 ACP, and may receive even shorter prefixes. 423 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 424 singleton IPv4 address), and may receive even shorter prefixes. 425 Clients maintain an AERO interface neighbor cache entry for each of 426 their associated Servers as well as for each of their correspondent 427 Clients. 429 AERO Proxies provide a conduit for AERO Clients in secured enclaves 430 to associate with AERO Servers. The Client sends all of its control 431 plane messages to the Server's link-layer address and the Proxy 432 intercepts them before they leave the secured enclave. The Proxy 433 forwards the Client's control and data plane messages to and from the 434 Client's current Server(s). The Proxy may also discover a more 435 direct route toward a target destination via AERO route optimization, 436 in which case future outbound data packets would be forwarded via the 437 more direct route. The Proxy function is specified in Section 3.15. 439 AERO Relays, Servers and Proxies are critical infrastructure elements 440 in fixed (i.e., non-mobile) deployments. Relays, Servers and Proxies 441 must use public link-layer addresses that do not change and can be 442 reached from any correspondent in the underlying Internetwork (i.e., 443 in the same fashion as for popular Internet services). AERO Clients 444 may be mobile, and may not have any public link-layer addresses, 445 e.g., if they are located behind NATs or Proxies. 447 3.3. AERO Routing System 449 The AERO routing system comprises a private instance of the Border 450 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 451 and Servers and does not interact with either the public Internet BGP 452 routing system or the native Internetwork routing system. Relays 453 advertise only a small and unchanging set of ASPs to the native 454 Internetwork routing system instead of the full dynamically changing 455 set of ACPs. 457 In a reference deployment, each Server is configured as an Autonomous 458 System Border Router (ASBR) for a stub Autonomous System (AS) using 459 an AS Number (ASN) that is unique within the BGP instance, and each 460 Server further uses eBGP to peer with one or more Relays but does not 461 peer with other Servers. All Relays are members of the same hub AS 462 using a common ASN, and use iBGP to maintain a consistent view of all 463 active ACPs currently in service. 465 Each Server maintains a working set of associated ACPs, and 466 dynamically announces new ACPs and withdraws departed ACPs in its 467 eBGP updates to Relays. Clients are expected to remain associated 468 with their current Servers for extended timeframes, however Servers 469 SHOULD selectively suppress updates for impatient Clients that 470 repeatedly associate and disassociate with them in order to dampen 471 routing churn. 473 Each Relay configures a black-hole route for each of its ASPs. By 474 black-holing the ASPs, the Relay will maintain forwarding table 475 entries only for the ACPs that are currently active, and packets 476 destined to all other ACPs will correctly incur Destination 477 Unreachable messages due to the black hole route. Relays do not send 478 eBGP updates for ACPs to Servers, but instead only originate a 479 default route. In this way, Servers have only partial topology 480 knowledge (i.e., they know only about the ACPs of their directly 481 associated Clients) and they forward all other packets to Relays 482 which have full topology knowledge. 484 Scaling properties of the AERO routing system are limited by the 485 number of BGP routes that can be carried by Relays. As of 2015, the 486 global public Internet BGP routing system manages more than 500K 487 routes with linear growth and no signs of router resource exhaustion 488 [BGP]. More recent network emulation studies have also shown that a 489 single Relay can accommodate at least 1M dynamically changing BGP 490 routes even on a lightweight virtual machine, i.e., and without 491 requiring high-end dedicated router hardware. 493 Therefore, assuming each Relay can carry 1M or more routes, this 494 means that at least 1M Clients can be serviced by a single set of 495 Relays. A means of increasing scaling would be to assign a different 496 set of Relays for each set of ASPs. In that case, each Server still 497 peers with one or more Relays, but the Server institutes route 498 filters so that it only sends BGP updates to the specific set of 499 Relays that aggregate the ASP. For example, if the ASP for the AERO 500 link is 2001:db8::/32, a first set of Relays could service the ASP 501 segment 2001:db8::/40, a second set of Relays could service 502 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 503 etc. 505 Assuming up to 1K sets of Relays, the AERO routing system can then 506 accommodate 1B or more ACPs with no additional overhead for Servers 507 and Relays (for example, it should be possible to service 1B /64 ACPs 508 taken from a /34 ASP and even more for shorter prefixes). In this 509 way, each set of Relays services a specific set of ASPs that they 510 advertise to the native Internetwork routing system, and each Server 511 configures ASP-specific routes that list the correct set of Relays as 512 next hops. This arrangement also allows for natural incremental 513 deployment, and can support small scale initial deployments followed 514 by dynamic deployment of additional Clients, Servers and Relays 515 without disturbing the already-deployed base. 517 In an alternate routing arrangement, each set of Relays could 518 advertise an aggregated ASP for the link into the native Internetwork 519 routing system even though each Relay services only smaller segments 520 of the ASP. In that case, a Relay upon receiving a packet with a 521 destination address covered by the ASP segment of another Relay can 522 simply tunnel the packet to the other Relay. The tradeoff then is 523 the penalty for Relay-to-Relay tunneling compared with reduced 524 routing information in the native routing system. 526 A full discussion of the BGP-based routing system used by AERO is 527 found in [I-D.ietf-rtgwg-atn-bgp]. The system provides for 528 Distributed Mobility Management (DMM) per the distributed mobility 529 anchoring architecture [I-D.ietf-dmm-distributed-mobility-anchoring]. 531 3.4. AERO Addresses 533 A Client's AERO address is an IPv6 link-local address with an 534 interface identifier based on the Client's delegated ACP. Relay, 535 Server and Proxy AERO addresses are assigned from the range fe80::/96 536 and include an administratively-provisioned value in the lower 32 537 bits. 539 For IPv6, Client AERO addresses begin with the prefix fe80::/64 and 540 include in the interface identifier (i.e., the lower 64 bits) a 541 64-bit prefix taken from one of the Client's IPv6 ACPs. For example, 542 if the AERO Client receives the IPv6 ACP: 544 2001:db8:1000:2000::/56 546 it constructs its corresponding AERO addresses as: 548 fe80::2001:db8:1000:2000 550 fe80::2001:db8:1000:2001 552 fe80::2001:db8:1000:2002 554 ... etc. ... 556 fe80::2001:db8:1000:20ff 558 For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6 559 address formed from an IPv4 ACP and with a Prefix Length of 96 plus 560 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 561 the IPv4-mapped IPv6 ACP is: 563 0:0:0:0:0:FFFF:192.0.2.16/124 565 The Client then constructs its AERO addresses with the prefix 566 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 567 in the interface identifier as: 569 fe80::FFFF:192.0.2.16 571 fe80::FFFF:192.0.2.17 573 fe80::FFFF:192.0.2.18 574 ... etc. ... 576 fe80:FFFF:192.0.2.31 578 Relay, Server and Proxy AERO addresses are allocated from the range 579 fe80::/96, and MUST be managed for uniqueness by the administrative 580 authority for the link. For interfaces that assign static IPv4 581 addresses, the lower 32 bits of the AERO address includes the IPv4 582 address, e.g., for the IPv4 address 192.0.2.1 the corresponding AERO 583 address is fe80::192.0.2.1. For other interfaces, the lower 32 bits 584 of the AERO address includes a unique integer value, e.g., fe80::1, 585 fe80::2, fe80::3, etc. The address fe80:: is reserved as the IPv6 586 link-local Subnet Router Anycast address [RFC4291], and the address 587 fe80::ffff:ffff is reserved as the unspecified AERO address; hence, 588 these values are not available for administrative assignment. (Note 589 that this special link-local-format unspecified address is defined 590 for AERO to satisfy PD services that require a link-local source 591 address.) 593 When the Server delegates ACPs to the Client, the lowest-numbered 594 AERO address from the first ACP delegation serves as the "base" AERO 595 address (for example, for the ACP 2001:db8:1000:2000::/56 the base 596 AERO address is fe80::2001:db8:1000:2000). The Client then assigns 597 the base AERO address to the AERO interface and uses it for the 598 purpose of maintaining the neighbor cache entry. The Server likewise 599 uses the AERO address as its index into the neighbor cache for this 600 Client. 602 If the Client has multiple AERO addresses (i.e., when there are 603 multiple ACPs and/or ACPs with prefix lengths shorter than /64), the 604 Client originates ND messages using the base AERO address as the 605 source address and accepts and responds to ND messages destined to 606 any of its AERO addresses as equivalent to the base AERO address. In 607 this way, the Client maintains a single neighbor cache entry that may 608 be indexed by multiple AERO addresses. 610 AERO addresses that embed an IPv6 prefix can be statelessly 611 transformed into an IPv6 Subnet Router Anycast address and vice- 612 versa. For example, for the AERO address fe80::2001:db8:2000:3000 613 the corresponding Subnet Router Anycast address is 614 2001:db8:2000:3000::. In the same way, for the IPv6 Subnet Router 615 Anycast address 2001:db8:1:2:: the corresponding AERO address is 616 fe80::2001:db8:1:2. In other words, the low-order 64 bits of an AERO 617 address can be used as the high-order 64 bits of a Subnet Router 618 Anycast address, and vice-versa. 620 AERO links additionally require a reserved IPv6 prefix to support 621 encapsulated forwarding of IPv6 ND messages between Servers on the 622 link. Although any non-link-local IPv6 prefix could be reserved for 623 this purpose, a Unique Local Address (ULA) prefix [RFC4389] would be 624 preferred since packets with ULAs cannot be forwarded into the AERO 625 link by an external IPv6 node. For example, if the reserved (ULA) 626 prefix is fd00:db8::/64 the AERO Server Subnet Router Anycast Address 627 is fd00:db8::. 629 A full discussion of the AERO addressing service is found in 630 [I-D.templin-6man-aeroaddr]. 632 3.5. AERO Interface Characteristics 634 AERO interfaces use encapsulation (see: Section 3.9) to exchange 635 packets with neighbors attached to the AERO link. 637 AERO interfaces maintain a neighbor cache for tracking per-neighbor 638 state the same as for any interface. AERO interfaces use ND messages 639 including Router Solicitation (RS), Router Advertisement (RA), 640 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) for 641 neighbor cache management. 643 AERO interface ND messages include one or more Source/Target Link- 644 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Type | Length = 5 | Prefix Length |R|D|X|N| Resvd | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Interface ID | UDP Port Number | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 + + 655 | | 656 + IP Address + 657 | | 658 + + 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 671 Format 673 In this format: 675 o Type is set to '1' for SLLAO or '2' for TLLAO. 677 o Length is set to the constant value '5' (i.e., 5 units of 8 678 octets). 680 o Prefix Length is set to the ACP prefix length in an ND message for 681 the Client AERO address found in the source (RS), destination (RA) 682 or target (NA) address; otherwise set to 0 if the message is not 683 being used for PD or neighbor prefix discovery. If the message 684 contains multiple SLLAOs, only the Prefix Length value in the 685 first SLLAO is consulted and the values in other SLLAOs are 686 ignored. 688 o R (the "Release" bit) is set to '1' in the SLLAO of an RS message 689 sent for the purpose of departing from a Server; otherwise, set to 690 '0'. If the message contains multiple SLLAOs, only the R value in 691 the first SLLAO is consulted and the values in other SLLAOs are 692 ignored. The Server places the correponsing neighbor cache entry 693 in the DEPARTED state and releases the corresponding PD, then 694 returns an RA with Router Lifetime set to '0'. 696 o D (the "Disable" bit) is set to '1' in the S/TLLAOs of an RS/NA 697 message for each Interface ID that is to be disabled in the 698 neighbor cache entry; otherwise, set to '0'. If the message 699 contains an S/TLLAO with Interface ID 255, the node places the 700 corresponding neighbor cache entry in the DEPARTED state. If the 701 message contains multiple S/TLLAOs the D value in each S/TLLAO is 702 honored. 704 o X (the "proXy" bit) is set to '1' in the SLLAO of an RS/RA message 705 by the Proxy when there is a Proxy in the path; otherwise, set to 706 '0'. If the message contains multiple SLLAOs, only the X value in 707 the first SLLAO is consulted and the values in other SLLAOs are 708 ignored. 710 o N (the "NAT" bit) is set to '1' in the SLLAO of an RA message by 711 the Server if there is a NAT in the path; otherwise, set to '0'. 712 If the message contains multiple SLLAOs, only the N value in the 713 first SLLAO is consulted and the values in other SLLAOs are 714 ignored. 716 o Resvd is set to the value '0' on transmission and ignored on 717 receipt. 719 o Interface ID is set to a 16-bit integer value corresponding to an 720 underlying interface of the AERO node. Once the node has assigned 721 an Interface ID to an underlying interface, the assignment must 722 remain unchanged until the node fully detaches from the AERO link. 723 The value '255' is reserved as the AERO Server interface ID, i.e., 724 Servers MUST use Interface ID '255', and Clients MUST number their 725 Interface IDs with values in the range of 0-254. 727 o UDP Port Number and IP Address are set to the addresses used by 728 the AERO node when it sends encapsulated packets over the 729 specified underlying interface (or to '0' when the addresses are 730 left unspecified). When UDP is not used as part of the 731 encapsulation, UDP Port Number is set to '0'. When the 732 encapsulation IP address family is IPv4, IP Address is formed as 733 an IPv4-mapped IPv6 address as specified in Section 3.4. 735 o P(i) is a set of Preferences that correspond to the 64 736 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 737 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 738 ("medium") or '3' ("high") to indicate a QoS preference level for 739 packet forwarding purposes. 741 AERO interfaces may be configured over multiple underlying interface 742 connections to underlying links. For example, common mobile handheld 743 devices have both wireless local area network ("WLAN") and cellular 744 wireless links. These links are typically used "one at a time" with 745 low-cost WLAN preferred and highly-available cellular wireless as a 746 standby. In a more complex example, aircraft frequently have many 747 wireless data link types (e.g. satellite-based, cellular, 748 terrestrial, air-to-air directional, etc.) with diverse performance 749 and cost properties. 751 A Client's underlying interfaces are classified as follows: 753 o Native interfaces connect to the open Internetwork, and have a 754 global IP address that is reachable from any open Internetwork 755 correspondent. 757 o NATed interfaces connect to a closed network that is separated 758 from the open Internetwork by a Network Address Translator (NAT). 759 The NAT does not participate in any AERO control message 760 signaling, but the AERO Server can issue control messages on 761 behalf of the Client. 763 o VPNed interfaces use security encapsulation over the Internetwork 764 to a Virtual Private Network (VPN) gateway that also acts as an 765 AERO Server. As with NATed links, the AERO Server can issue 766 control messages on behalf of the Client. 768 o Proxyed interfaces connect to a closed network that is separated 769 from the open Internetwork by an AERO Proxy. Unlike NATed and 770 VPNed interfaces, the AERO Proxy can also issue control messages 771 on behalf of the Client. 773 o Direct interfaces connect the Client directly to a neighbor 774 without crossing any networked paths. An example is a line-of- 775 sight link between a remote pilot and an unmanned aircraft. 777 If a Client's multiple underlying interfaces are used "one at a time" 778 (i.e., all other interfaces are in standby mode while one interface 779 is active), then ND messages include only a single S/TLLAO with 780 Interface ID set to a constant value. In that case, the Client would 781 appear to have a single underlying interface but with a dynamically 782 changing link-layer address. 784 If the Client has multiple active underlying interfaces, then from 785 the perspective of ND it would appear to have multiple link-layer 786 addresses. In that case, ND messages MAY include multiple S/TLLAOs 787 -- each with an Interface ID that corresponds to a specific 788 underlying interface of the AERO node. 790 When the Client includes an S/TLLAO for an underlying interface for 791 which it is aware that there is a NAT or Proxy on the path to the 792 Server, or when a node includes an S/TLLAO solely for the purpose of 793 announcing new QoS preferences, the node sets both UDP Port Number 794 and IP Address to 0 to indicate that the addresses are unspecified at 795 the network layer and must instead be derived from the link-layer 796 encapsulation headers. 798 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 799 correspond to the AERO node's underlying interface used to transmit 800 the message. 802 3.6. AERO Interface Initialization 804 3.6.1. AERO Relay Behavior 806 When a Relay enables an AERO interface, it first assigns an 807 administratively-provisioned AERO address fe80::ID to the interface. 808 Each fe80::ID address MUST be unique among all AERO nodes on the 809 link. The Relay then engages in a dynamic routing protocol session 810 with one or more Servers and all other Relays on the link (see: 811 Section 3.3), and advertises its assigned ASPs into the native 812 Internetwork. Each Relay subsequently maintains an IP forwarding 813 table entry for each active ACP covered by its ASP(s). 815 3.6.2. AERO Server Behavior 817 When a Server enables an AERO interface, it assigns an 818 administratively-provisioned AERO address fe80::ID the same as for 819 Relays. The Server further configures a service to facilitate ND/PD 820 exchanges with AERO Clients. The Server maintains neighbor cache 821 entries for one or more Relays on the link, and manages per-Client 822 neighbor cache entries and IP forwarding table entries based on 823 control message exchanges. The Server also engages in a dynamic 824 routing protocol with its neighboring Relays (see: Section 3.3). 826 When the Server receives an NS/RS message on the AERO interface it 827 authenticates the message and returns a solicited NA/RA message. 828 (When the Server receives an unsolicited NA message, it likewise 829 authenticates the message and processes it locally.) The Server 830 further provides a simple link-layer conduit between AERO interface 831 neighbors. In particular, when a packet sent by a source Client 832 arrives on the Server's AERO interface and is destined to another 833 AERO node, the Server forwards the packet from within the AERO 834 interface at the link layer without ever disturbing the network 835 layer. 837 3.6.3. AERO Proxy Behavior 839 When a Proxy enables an AERO interface, it assigns an 840 administratively-provisioned address fe80::ID the same as for Relays 841 and Servers. The Proxy further maintains per-Client proxy neighbor 842 cache entries based on control message exchanges. Proxies forward 843 packets between their associated Clients and each Client's associated 844 Servers. 846 When the Proxy receives an RS message from a Client in the secured 847 enclave, it creates an incomplete proxy neighbor cache entry and 848 sends a proxyed RS message to a Server selected by the Client while 849 using its own link-layer address as the source address. When the 850 Server returns an RA message, the Proxy completes the proxy neighbor 851 cache entry based on autoconfiguration information in the RA and 852 sends a proxyed RA to the Client while using its own link-layer 853 address as the source address. The Client, Server and Proxy will 854 then have the necessary state for managing the proxy neighbor 855 association. 857 3.6.4. AERO Client Behavior 859 When a Client enables an AERO interface, it sends RS messages with 860 ND/PD parameters over an underlying interface to one or more AERO 861 Servers, which return RA messages with corresponding PD parameters. 862 (The RS/RA messages may pass through a Proxy on the path in the case 863 of a Client's Proxyed interface.) See 864 [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters 865 that can be included in the RS/RA message exchanges. 867 After the initial ND/PD message exchange, the Client assigns AERO 868 addresses to the AERO interface based on the delegated prefix(es). 869 The Client can then register additional underlying interfaces with 870 the Server by sending a simple RS message (i.e., one with no PD 871 parameters) over each underlying interface using its base AERO 872 address as the source network layer address. The Server will update 873 its neighbor cache entry for the Client and return a simple RA 874 message. 876 The Client maintains a neighbor cache entry for each of its Servers 877 and each of its active target Clients. When the Client receives ND 878 messages on the AERO interface it updates or creates neighbor cache 879 entries, including link-layer address and QoS preferences. 881 When there is a NAT on the path, the Client must send periodic 882 messages to keep NAT state alive. If no other periodic messaging 883 service is available, the Client can send RS messages to receive RA 884 replies from its Server(s). 886 3.7. AERO Interface Neighbor Cache Maintenance 888 Each AERO interface maintains a conceptual neighbor cache that 889 includes an entry for each neighbor it communicates with on the AERO 890 link per [RFC4861]. AERO interface neighbor cache entries are said 891 to be one of "permanent", "symmetric", "asymmetric" or "proxy". 893 Permanent neighbor cache entries are created through explicit 894 administrative action; they have no timeout values and remain in 895 place until explicitly deleted. AERO Relays maintain permanent 896 neighbor cache entries for their associated Relays and Servers on the 897 link, and AERO Servers maintain permanent neighbor cache entries for 898 their associated Relays. Each entry maintains the mapping between 899 the neighbor's fe80::ID network-layer address and corresponding link- 900 layer address. 902 Symmetric neighbor cache entries are created and maintained through 903 ND/PD exchanges as specified in Section 3.14, and remain in place for 904 durations bounded by ND/PD lifetimes. AERO Servers maintain 905 symmetric neighbor cache entries for each of their associated 906 Clients, and AERO Clients maintain symmetric neighbor cache entries 907 for each of their associated Servers. 909 Asymmetric neighbor cache entries are created or updated based on 910 route optimization messaging as specified in Section 3.16, and are 911 garbage-collected when keepalive timers expire. AERO route 912 optimization sources maintain asymmetric neighbor cache entries for 913 each of their active target Clients with lifetimes based on ND 914 messaging constants. Asymmetric neighbor cache entries are 915 unidirectional since only the route optimization source (i.e., and 916 not the target) creates an entry. 918 Proxy neighbor cache entries are created and maintained by AERO 919 Proxies when they process Client/Server ND/PD exchanges, and remain 920 in place for durations bounded by ND/PD lifetimes. AERO Proxies 921 maintain proxy neighbor cache entries for each of their associated 922 Clients. Proxy neighbor cache entries track the Client state and the 923 state of each of the Client's associated Servers. 925 To the list of neighbor cache entry states in Section 7.3.2 of 926 [RFC4861], AERO interfaces add an additional state DEPARTED that 927 applies to symmetric and proxy neighbor cache entries for Clients 928 that have recently departed. The interface sets a "DepartTime" 929 varibale for the neighbor cache entry to "DEPARTTIME" seconds. 930 DepartTime is decremented unless a new ND message causes the state to 931 return to REACHABLE. While a neighbor cache entry is in the DEPARTED 932 state, packets destined to the target Client are forwarded according 933 to the remaining underlying interface state instead of being dropped. 935 When DepartTime decrements to 0, the neighbor cache entry is deleted. 936 It is RECOMMENDED that DEPARTTIME be set to the default constant 937 value 40 seconds to allow for packets in flight to be delivered while 938 stale route optimization state may be present. 940 When a target AERO Server (acting as a Mobility Anchor Point (MAP)) 941 receives a valid NS message used for route optimization, it searches 942 for a symmetric neighbor cache entry for the target Client. The 943 Server then returns a solicited NA message without creating a 944 neighbor cache entry for the route optimization source, but maintains 945 a "Report List" for the Client's symmetric neighbor cache entry. 946 When the Server receives an authentic NS message it adds a Report 947 list entry for the NS source and sets a "ReportTime" variable for the 948 entry to REPORTTIME seconds. The Server resets ReportTime when it 949 receives a new authentic NS message, and otherwise decrements 950 ReportTime while no NS messages have been received. It is 951 RECOMMENDED that REPORTTIME be set to the default constant value 40 952 seconds to allow a 10 second window so that route optimization can 953 converege before ReportTime decrements below REACHABLETIME. 955 When the route optimization source receives a solicited NA message 956 response to its NS message, it creates or updates an asymmetric 957 neighbor cache entry for the target network-layer and link-layer 958 addresses. The node then (re)sets ReachableTime for the neighbor 959 cache entry to REACHABLETIME seconds and uses this value to determine 960 whether packets can be forwarded directly to the target, i.e., 961 instead of via a default route. The node otherwise decrements 962 ReachableTime while no further solicited NA messages arrive. It is 963 RECOMMENDED that REACHABLETIME be set to the default constant value 964 30 seconds as specified in [RFC4861]. 966 The route optimization source also uses the value MAX_UNICAST_SOLICIT 967 to limit the number of NS keepalives sent when a correspondent may 968 have gone unreachable, the value MAX_RTR_SOLICITATIONS to limit the 969 number of RS messages sent without receiving an RA and the value 970 MAX_NEIGHBOR_ADVERTISEMENT to limit the number of unsolicited NAs 971 that can be sent based on a single event. It is RECOMMENDED that 972 MAX_UNICAST_SOLICIT, MAX_RTR_SOLICITATIONS and 973 MAX_NEIGHBOR_ADVERTISEMENT be set to 3 the same as specified in 974 [RFC4861]. 976 Different values for DEPARTTIME, REPORTTIME, REACHABLETIME, 977 MAX_UNICAST_SOLICIT, MAX_RTR_SOLCITATIONS and 978 MAX_NEIGHBOR_ADVERTISEMENT MAY be administratively set; however, if 979 different values are chosen, all nodes on the link MUST consistently 980 configure the same values. Most importantly, DEPARTTIME and 981 REPORTTIME SHOULD be set to a value that is sufficiently longer than 982 REACHABLETIME to avoid packet loss due to stale route optimization 983 state. 985 3.8. AERO Interface Forwarding Algorithm 987 IP packets enter a node's AERO interface either from the network 988 layer (i.e., from a local application or the IP forwarding system) or 989 from the link layer (i.e., from the AERO tunnel virtual link). 990 Packets that enter the AERO interface from the network layer are 991 encapsulated and forwarded into the AERO link, i.e., they are 992 tunneled to an AERO interface neighbor. Packets that enter the AERO 993 interface from the link layer are either re-admitted into the AERO 994 link or forwarded to the network layer where they are subject to 995 either local delivery or IP forwarding. In all cases, the AERO 996 interface itself MUST NOT decrement the network layer TTL/Hop-count 997 since its forwarding actions occur below the network layer. 999 AERO interfaces may have multiple underlying interfaces and/or 1000 neighbor cache entries for neighbors with multiple Interface ID 1001 registrations (see Section 3.5). The AERO node uses each packet's 1002 DSCP value to select an outgoing underlying interface based on the 1003 node's own QoS preferences, and also to select a destination link- 1004 layer address based on the neighbor's underlying interface with the 1005 highest preference. AERO implementations SHOULD allow for QoS 1006 preference values to be modified at runtime through network 1007 management. 1009 If multiple outgoing interfaces and/or neighbor interfaces have a 1010 preference of "high", the AERO node sends one copy of the packet via 1011 each of the (outgoing / neighbor) interface pairs; otherwise, the 1012 node sends a single copy of the packet via the interface with the 1013 highest preference. AERO nodes keep track of which underlying 1014 interfaces are currently "reachable" or "unreachable", and only use 1015 "reachable" interfaces for forwarding purposes. 1017 The following sections discuss the AERO interface forwarding 1018 algorithms for Clients, Proxies, Servers and Relays. In the 1019 following discussion, a packet's destination address is said to 1020 "match" if it is a non-link-local address with a prefix covered by an 1021 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 1022 the same as an administratively-provisioned AERO address. 1024 3.8.1. Client Forwarding Algorithm 1026 When an IP packet enters a Client's AERO interface from the network 1027 layer the Client searches for an asymmetric neighbor cache entry that 1028 matches the destination. If there is a match, the Client uses one or 1029 more "reachable" link-layer addresses in the entry as the link-layer 1030 addresses for encapsulation and admits the packet into the AERO link. 1031 Otherwise, the Client uses the link-layer address in a symmetric 1032 neighbor cache entry as the encapsulation address. 1034 When an IP packet enters a Client's AERO interface from the link- 1035 layer, if the destination matches one of the Client's ACPs or link- 1036 local addresses the Client decapsulates the packet and delivers it to 1037 the network layer. Otherwise, the Client drops the packet and MAY 1038 return a network-layer ICMP Destination Unreachable message subject 1039 to rate limiting (see: Section 3.13). 1041 3.8.2. Proxy Forwarding Algorithm 1043 When the Proxy receives a packet from a Client within the secured 1044 enclave, the Proxy searches for an asymmetric neighbor cache entry 1045 that matches the network-layer destination. If there is a match, the 1046 Proxy uses one or more "reachable" link-layer addresses in the entry 1047 as the destination link-layer addresses for encapsulation and admits 1048 the packet into the AERO link. Otherwise, the Proxy uses the link- 1049 layer address for one of the Client's Servers as the encapsulation 1050 address. 1052 When the Proxy receives an encapsulated data packet from outside of 1053 the secured enclave, it searches for a proxy neighbor cache entry 1054 that matches the destination. If there is a proxy neighbor cache 1055 entry for the target Client, the Proxy forwards the packet according 1056 to the cached link-layer address. If the proxy neighbor cache entry 1057 is in the DEPARTED state, the Proxy instead forwards the packet to 1058 the Client's Server and may return an unsolicited NA message as 1059 discussed in Section 3.18. If there is no neighbor cache entry, the 1060 Proxy discards the packet. 1062 3.8.3. Server Forwarding Algorithm 1064 When an IP packet enters a Server's AERO interface from the network 1065 layer, the Server searches for a symmetric neighbor cache entry for a 1066 Client that matches the destination. If there is a symmetric 1067 neighbor cache entry, the Server uses one or more link-layer 1068 addresses in the entry as the link-layer addresses for encapsulation 1069 and admits the packet into the AERO link. Otherwise, the Server uses 1070 the link-layer address in a permanent neighbor cache entry for a 1071 Relay (selected through longest-prefix match) as the link-layer 1072 address for encapsulation. 1074 When an IP packet enters a Server's AERO interface from the link 1075 layer, the Server processes the packet according to the network-layer 1076 destination address as follows: 1078 o if the destination matches one of the Server's own addresses the 1079 Server decapsulates the packet and forwards it to the network 1080 layer for local delivery. 1082 o else, if the destination matches a symmetric neighbor cache entry 1083 the Server first determines whether the packet originated from the 1084 same Client. If so, the Server drops the packet silently to avoid 1085 looping. Otherwise, the Server uses the neighbor's link-layer 1086 address(es) as the destination for encapsulation and re-admits the 1087 packet into the AERO link. If the neighbor cache entry is in the 1088 DEPARTED state, the Server continues to forward packets according 1089 to its most recent underlying interface state and may return an 1090 unsolicited NA message as discussed in Section 3.18. 1092 o else, if the destination matches an asymmetric neighbor cache 1093 entry for a target Client, the Server forwards the packet 1094 according to the interface ID settings in the asymmetric neighbor 1095 cache entry. 1097 o else, the Server uses the link-layer address in a neighbor cache 1098 entry for a Relay (selected through longest-prefix match) as the 1099 link-layer address for encapsulation. 1101 3.8.4. Relay Forwarding Algorithm 1103 Relays forward packets the same as any IP router. When the Relay 1104 receives an encapsulated packet from a Server via the AERO link, it 1105 removes the encapsulation header and searches for a forwarding table 1106 entry that matches the network layer destination address. When the 1107 Relay receives an unencapsulated packet from a node outside the AERO 1108 link, it performs the same forwarding table lookup. The Relay then 1109 processes the packet as follows: 1111 o if the destination does not match an ASP, or if the destination 1112 matches one of the Relay's own addresses, the Relay submits the 1113 packet for either IP forwarding or local delivery. 1115 o else, if the destination matches an ACP entry in the IP forwarding 1116 table the Relay first determines whether the neighbor is the same 1117 as the one it received the packet from. If so the Relay MUST drop 1118 the packet silently to avoid looping; otherwise, the Relay 1119 encapsulates and forwards the packet using the neighbor's link- 1120 layer address as the destination for encapsulation. 1122 o else, the Relay drops the packet and returns an ICMP Destination 1123 Unreachable message subject to rate limiting (see: Section 3.13). 1125 As for any IP router, the Relay decrements the TTL/Hop Count when it 1126 forwards the packet. 1128 3.9. AERO Interface Encapsulation and Re-encapsulation 1130 AERO interfaces encapsulate IP packets according to whether they are 1131 entering the AERO interface from the network layer or if they are 1132 being re-admitted into the same AERO link they arrived on. This 1133 latter form of encapsulation is known as "re-encapsulation". 1135 The AERO interface encapsulates packets per the Generic UDP 1136 Encapsulation (GUE) procedures in 1137 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 1138 an alternate encapsulation format (e.g., see: Appendix A, [RFC2784], 1139 [RFC8086], [RFC4301], etc.). For packets entering the AERO interface 1140 from the network layer, the AERO interface copies the "TTL/Hop 1141 Limit", "Type of Service/Traffic Class" [RFC2983], "Flow 1142 Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168] 1143 values in the packet's IP header into the corresponding fields in the 1144 encapsulation IP header. For packets undergoing re-encapsulation, 1145 the AERO interface instead copies these values from the original 1146 encapsulation IP header into the new encapsulation header, i.e., the 1147 values are transferred between encapsulation headers and *not* copied 1148 from the encapsulated packet's network-layer header. (Note 1149 especially that by copying the TTL/Hop Limit between encapsulation 1150 headers the value will eventually decrement to 0 if there is a 1151 (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation, 1152 the AERO interface sets the DF bit as discussed in Section 3.12. 1154 When GUE encapsulation is used, the AERO interface next sets the UDP 1155 source port to a constant value that it will use in each successive 1156 packet it sends, and sets the UDP length field to the length of the 1157 encapsulated packet plus 8 bytes for the UDP header itself plus the 1158 length of the GUE header (or 0 if GUE direct IP encapsulation is 1159 used). For packets sent to a Server or Relay, the AERO interface 1160 sets the UDP destination port to 8060, i.e., the IANA-registered port 1161 number for AERO. For packets sent to a Client, the AERO interface 1162 sets the UDP destination port to the port value stored in the 1163 neighbor cache entry for this Client. The AERO interface then either 1164 includes or omits the UDP checksum according to the GUE 1165 specification. 1167 Clients normally use the IP address of the underlying interface as 1168 the encapsulation source address. If the underlying interface does 1169 not have an IP address, however, the Client uses an IP address taken 1170 from an ACP as the encapsulation source address (assuming the node 1171 has some way of injecting the ACP into the underlying network routing 1172 system). For IPv6 addresses, the Client normally uses the ACP Subnet 1173 Router Anycast address [RFC4291]. 1175 When GUE encapsulation is not available, encapsulation between 1176 Servers and Relays can use standard mechanisms such as Generic 1177 Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec 1178 [RFC4301] so that Relays can be standard IP routers with no AERO- 1179 specific mechanisms. 1181 3.10. AERO Interface Decapsulation 1183 AERO interfaces decapsulate packets destined either to the AERO node 1184 itself or to a destination reached via an interface other than the 1185 AERO interface the packet was received on. Decapsulation is per the 1186 procedures specified for the appropriate encapsulation format. 1188 3.11. AERO Interface Data Origin Authentication 1190 AERO nodes employ simple data origin authentication procedures for 1191 encapsulated packets they receive from other nodes on the AERO link. 1192 In particular: 1194 o AERO Relays and Servers accept encapsulated packets with a link- 1195 layer source address that matches a permanent neighbor cache 1196 entry. 1198 o AERO Servers accept authentic encapsulated ND messages from 1199 Clients (either directly or via a Proxy), and create or update a 1200 symmetric neighbor cache entry for the Client based on the 1201 specific message type. 1203 o AERO Clients and Servers accept encapsulated packets if there is a 1204 symmetric neighbor cache entry with a link-layer address that 1205 matches the packet's link-layer source address. 1207 o AERO Proxies accept encapsulated packets if there is a proxy 1208 neighbor cache entry that matches the packet's network-layer 1209 address. 1211 Each packet should include a signature that the recipient can use to 1212 authenticate the message origin, e.g., as for common VPN systems such 1213 as OpenVPN [OVPN]. In some environments, however, it may be 1214 sufficient to require signatures only for ND control plane messages 1215 (see: Section 10) and omit signatures for data plane messages. 1217 3.12. AERO Interface Packet Size Issues 1219 The AERO interface is the node's attachment to the AERO link. The 1220 AERO interface acts as a tunnel ingress when it sends a packet to an 1221 AERO link neighbor and as a tunnel egress when it receives a packet 1222 from an AERO link neighbor. AERO interfaces observe the packet 1223 sizing considerations for tunnels discussed in 1224 [I-D.ietf-intarea-tunnels] and as specified below. 1226 The Internet Protocol expects that IP packets will either be 1227 delivered to the destination or a suitable Packet Too Big (PTB) 1228 message returned to support the process known as IP Path MTU 1229 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1230 crafted for malicious purposes such as denial of service, or lost in 1231 the network [RFC2923]. This can be especially problematic for 1232 tunnels, where a condition known as a PMTUD "black hole" can result. 1233 For these reasons, AERO interfaces employ operational procedures that 1234 avoid interactions with PMTUD, including the use of fragmentation 1235 when necessary. 1237 AERO interfaces observe two different types of fragmentation. Source 1238 fragmentation occurs when the AERO interface (acting as a tunnel 1239 ingress) fragments the encapsulated packet into multiple fragments 1240 before admitting each fragment into the tunnel. Network 1241 fragmentation occurs when an encapsulated packet admitted into the 1242 tunnel by the ingress is fragmented by an IPv4 router on the path to 1243 the egress. Note that a packet that incurs source fragmentation may 1244 also incur network fragmentation. 1246 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1247 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1248 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1249 for IPv4 even if encapsulated packets may incur network 1250 fragmentation. 1252 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1253 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1254 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1255 than the IPv4 minimum). 1257 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1258 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1259 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1260 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1261 configure a Maximum Segment Unit (MSU) as the maximum-sized 1262 encapsulated packet that the ingress can inject into the tunnel 1263 without source fragmentation. The MSU value MUST NOT be larger than 1264 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1265 operational assurance that a larger size can traverse the link along 1266 all paths. 1268 All AERO nodes MUST configure the same MTU/MSU values for reasons 1269 cited in [RFC3819][RFC4861]; in particular, multicast support 1270 requires a common MTU value among all nodes on the link. All AERO 1271 nodes MUST configure an MRU large enough to reassemble packets up to 1272 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1273 enough MRU MUST NOT enable an AERO interface. 1275 The network layer proceeds as follow when it presents an IP packet to 1276 the AERO interface. For each IPv4 packet that is larger than the 1277 AERO interface MTU and with the DF bit set to 0, the network layer 1278 uses IPv4 fragmentation to break the packet into a minimum number of 1279 non-overlapping fragments where the first fragment is no larger than 1280 the MTU and the remaining fragments are no larger than the first. 1281 For all other IP packets, if the packet is larger than the AERO 1282 interface MTU, the network layer drops the packet and returns a PTB 1283 message to the original source. Otherwise, the network layer admits 1284 each IP packet or fragment into the AERO interface. 1286 For each IP packet admitted into the AERO interface, the interface 1287 (acting as a tunnel ingress) encapsulates the packet. If the 1288 encapsulated packet is larger than the AERO interface MSU the ingress 1289 source-fragments the encapsulated packet into a minimum number of 1290 non-overlapping fragments where the first fragment is no larger than 1291 the MSU and the remaining fragments are no larger than the first. 1292 The ingress then admits each encapsulated packet or fragment into the 1293 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1294 header in case any network fragmentation is necessary. The 1295 encapsulated packets will be delivered to the egress, which 1296 reassembles them into a whole packet if necessary. 1298 Several factors must be considered when fragmentation is needed. For 1299 AERO links over IPv4, the IP ID field is only 16 bits in length, 1300 meaning that fragmentation at high data rates could result in data 1301 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1302 AERO links over both IPv4 and IPv6, studies have also shown that IP 1303 fragments are dropped unconditionally over some network paths [I- 1304 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1305 issues could result in operational problems, the ingress SHOULD 1306 employ intermediate-layer source fragmentation (see: [RFC2764] and 1307 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1308 encapsulation headers to each fragment. Since the encapsulation 1309 fragment header reduces the room available for packet data, but the 1310 original source has no way to control its insertion, the ingress MUST 1311 include the fragment header length in the ENCAPS length even for 1312 packets in which the header is absent. 1314 3.13. AERO Interface Error Handling 1316 When an AERO node admits encapsulated packets into the AERO 1317 interface, it may receive link-layer or network-layer error 1318 indications. 1320 A link-layer error indication is an ICMP error message generated by a 1321 router in the underlying network on the path to the neighbor or by 1322 the neighbor itself. The message includes an IP header with the 1323 address of the node that generated the error as the source address 1324 and with the link-layer address of the AERO node as the destination 1325 address. 1327 The IP header is followed by an ICMP header that includes an error 1328 Type, Code and Checksum. Valid type values include "Destination 1329 Unreachable", "Time Exceeded" and "Parameter Problem" 1330 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1331 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1332 only emit packets that are guaranteed to be no larger than the IP 1333 minimum link MTU as discussed in Section 3.12.) 1335 The ICMP header is followed by the leading portion of the packet that 1336 generated the error, also known as the "packet-in-error". For 1337 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1338 much of invoking packet as possible without the ICMPv6 packet 1339 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1340 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1341 "Internet Header + 64 bits of Original Data Datagram", however 1342 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1343 ICMP datagram SHOULD contain as much of the original datagram as 1344 possible without the length of the ICMP datagram exceeding 576 1345 bytes". 1347 The link-layer error message format is shown in Figure 3 (where, "L2" 1348 and "L3" refer to link-layer and network-layer, respectively): 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 ~ ~ 1352 | L2 IP Header of | 1353 | error message | 1354 ~ ~ 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | L2 ICMP Header | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1358 ~ ~ P 1359 | IP and other encapsulation | a 1360 | headers of original L3 packet | c 1361 ~ ~ k 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1363 ~ ~ t 1364 | IP header of | 1365 | original L3 packet | i 1366 ~ ~ n 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 ~ ~ e 1369 | Upper layer headers and | r 1370 | leading portion of body | r 1371 | of the original L3 packet | o 1372 ~ ~ r 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1375 Figure 3: AERO Interface Link-Layer Error Message Format 1377 The AERO node rules for processing these link-layer error messages 1378 are as follows: 1380 o When an AERO node receives a link-layer Parameter Problem message, 1381 it processes the message the same as described as for ordinary 1382 ICMP errors in the normative references [RFC0792][RFC4443]. 1384 o When an AERO node receives persistent link-layer Time Exceeded 1385 messages, the IP ID field may be wrapping before earlier fragments 1386 awaiting reassembly have been processed. In that case, the node 1387 SHOULD begin including integrity checks and/or institute rate 1388 limits for subsequent packets. 1390 o When an AERO node receives persistent link-layer Destination 1391 Unreachable messages in response to encapsulated packets that it 1392 sends to one of its asymmetric neighbor correspondents, the node 1393 SHOULD process the message as an indication that a path may be 1394 failing, and MAY initiate NUD over that path. If it receives 1395 Destination Unreachable messages on many or all paths, the node 1396 SHOULD set ReachableTime for the corresponding asymmetric neighbor 1397 cache entry to 0 and allow future packets destined to the 1398 correspondent to flow through a default route. 1400 o When an AERO Client receives persistent link-layer Destination 1401 Unreachable messages in response to encapsulated packets that it 1402 sends to one of its symmetric neighbor Servers, the Client SHOULD 1403 mark the path as unusable and use another path. If it receives 1404 Destination Unreachable messages on many or all paths, the Client 1405 SHOULD associate with a new Server and release its association 1406 with the old Server as specified in Section 3.18.7. 1408 o When an AERO Server receives persistent link-layer Destination 1409 Unreachable messages in response to encapsulated packets that it 1410 sends to one of its symmetric neighbor Clients, the Server SHOULD 1411 mark the underlying path as unusable and use another underlying 1412 path. If it receives Destination Unreachable messages on multiple 1413 paths, the Server should take no further actions unless it 1414 receives an explicit ND/PD release message or if the PD lifetime 1415 expires. In that case, the Server MUST release the Client's 1416 delegated ACP, withdraw the ACP from the AERO routing system and 1417 delete the neighbor cache entry. 1419 o When an AERO Relay or Server receives link-layer Destination 1420 Unreachable messages in response to an encapsulated packet that it 1421 sends to one of its permanent neighbors, it treats the messages as 1422 an indication that the path to the neighbor may be failing. 1423 However, the dynamic routing protocol should soon reconverge and 1424 correct the temporary outage. 1426 When an AERO Relay receives a packet for which the network-layer 1427 destination address is covered by an ASP, if there is no more- 1428 specific routing information for the destination the Relay drops the 1429 packet and returns a network-layer Destination Unreachable message 1430 subject to rate limiting. The Relay writes the network-layer source 1431 address of the original packet as the destination address and uses 1432 one of its non link-local addresses as the source address of the 1433 message. 1435 When an AERO node receives an encapsulated packet for which the 1436 reassembly buffer it too small, it drops the packet and returns a 1437 network-layer Packet Too Big (PTB) message. The node first writes 1438 the MRU value into the PTB message MTU field, writes the network- 1439 layer source address of the original packet as the destination 1440 address and writes one of its non link-local addresses as the source 1441 address. 1443 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1445 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1446 coordinated as discussed in the following Sections. 1448 3.14.1. AERO ND/PD Service Model 1450 Each AERO Server configures a PD service to facilitate Client 1451 requests. Each Server is provisioned with a database of ACP-to- 1452 Client ID mappings for all Clients enrolled in the AERO system, as 1453 well as any information necessary to authenticate each Client. The 1454 Client database is maintained by a central administrative authority 1455 for the AERO link and securely distributed to all Servers, e.g., via 1456 the Lightweight Directory Access Protocol (LDAP) [RFC4511], via 1457 static configuration, etc. Therefore, no Server-to-Server PD state 1458 synchronization is necessary, and Clients can optionally hold 1459 separate PDs for the same ACPs from multiple Servers. In this way, 1460 Clients can associate with multiple Servers, and can receive new PDs 1461 from new Servers before releasing PDs received from existing Servers. 1462 This provides the Client with a natural fault-tolerance and/or load 1463 balancing profile. 1465 AERO Clients and Servers use ND messages to maintain neighbor cache 1466 entries. AERO Servers configure their AERO interfaces as advertising 1467 interfaces, and therefore send unicast RA messages with configuration 1468 information in response to a Client's RS message. Thereafter, 1469 Clients send additional RS messages to the Server's unicast address 1470 to refresh prefix and/or router lifetimes. 1472 AERO Clients and Servers include PD parameters in RS/RA messages to 1473 be used for Prefix Delegation (see [I-D.templin-6man-dhcpv6-ndopt] 1474 for ND/PD alternatives). The unified ND/PD messages are exchanged 1475 between Client and Server according to the prefix management schedule 1476 required by the PD service. If the Client knows its ACP in advance, 1477 it can include its AERO address as the source address of an RS 1478 message and with an SLLAO with a valid Prefix Length for the ACP. If 1479 the Server (and Proxy) accept the Client's ACP assertion, they inject 1480 the prefix into the routing system and establish the necessary 1481 neighbor cache state. If the Client does not know its ACP in 1482 advance, or if it wishes to engage in an explicit PD exchange, it can 1483 include ND/PD parameters for an ancillary service such as DHCPv6. 1485 On Some AERO links, PD arrangements may be through some out-of-band 1486 service such as network management, static configuration, etc. In 1487 those cases, AERO nodes can use simple RS/RA message exchanges with 1488 no PD options. In other cases, the RS/RA messages can use AERO 1489 addresses as a means of representing the delegated prefixes, e.g., if 1490 a message includes a source address of "fe80::2001:db8:1:2" then the 1491 recipient can infer that the sender holds the prefix delegation 1492 "2001:db8:1:2::/N" (where 'N' is the Prefix Length included in the 1493 first SLLAO in the message). 1495 The following sections specify the Client and Server behavior. 1497 3.14.2. AERO Client Behavior 1499 AERO Clients discover the link-layer addresses of AERO Servers in the 1500 MAP list via static configuration (e.g., from a flat-file map of 1501 Server addresses and locations), or through an automated means such 1502 as Domain Name System (DNS) name resolution [RFC1035]. In the 1503 absence of other information, the Client resolves the DNS Fully- 1504 Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" where 1505 "linkupnetworks" is a constant text string and "[domainname]" is a 1506 DNS suffix for the Client's underlying interface (e.g., 1507 "example.com"). After discovering the link-layer addresses, the 1508 Client associates with one or more of the corresponding Servers. 1510 To associate with a Server, the Client acts as a requesting router to 1511 request ACPs. The Client prepares an RS message with PD parameters 1512 (e.g., with an SLLAO with non-zero Prefix Length), the address of the 1513 Client's underlying interface as the link-layer source address and 1514 the link-layer address of the Server as the link-layer destination 1515 address. If the Client already knows its own AERO address, it uses 1516 the AERO address as the network-layer source address; otherwise, it 1517 uses the unspecified AERO address (fe80::ffff:ffff) as the network- 1518 layer source address. If the Client's underlying interface connects 1519 to a subnetwork that supports ACP injection, the Client can use the 1520 ACP's Subnet Router Anycast address as the link-layer source address. 1522 The Client next includes an SLLAO in the RS message formatted as 1523 described in Section 3.5 to register its link-layer address with the 1524 Server. The first SLLAO MUST correspond to the underlying interface 1525 over which the Client will send the RS message. The Client MAY 1526 include additional SLLAOs specific to other underlying interfaces, 1527 but if so it sets their UDP Port Number and IP Address fields to 0. 1529 The Client then sends the RS message to the AERO Server and waits for 1530 an RA message reply (see Section 3.14.3) while retrying up to 1531 MAX_RTR_SOLICITATIONS times until an RA is received. If the Client 1532 receives no RAs, or if it receives an RA with Router Lifetime set to 1533 0, the Client SHOULD abandon this Server and try another Server. 1534 Otherwise, the Client processes the PD information found in the RA 1535 message. 1537 Next, the Client creates a symmetric neighbor cache entry with the 1538 Server's link-local address as the network-layer address and the 1539 address in the first SLLAO as the link-layer address. The Client 1540 records the RA Router Lifetime field value in the cache entry as the 1541 time for which the Server has committed to maintaining the ACP in the 1542 routing system. The Client then autoconfigures AERO addresses for 1543 each of the delegated ACPs and assigns them to the AERO interface. 1544 The Client also caches any ASPs included in Route Information Options 1545 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1546 the MTU/MSU values in the MTU options to its AERO interface while 1547 configuring an appropriate MRU. This configuration information 1548 applies to the AERO link as a whole, and all AERO nodes will receive 1549 the same values. 1551 The Client then registers additional link-layer addresses with the 1552 Server by sending additional RS messages including SLLAOs via other 1553 underlying interfaces after the initial RS/RA exchange. The Client 1554 omits PD parameters from these additional messages, since the initial 1555 RS/RA exchange has already established PD state. The Client examines 1556 the X and N bits in the first SLLAO of each RA message. If the X bit 1557 value is '1' the Client infers that there is a Proxy on the path via 1558 the interface over which it sent the RS message, and if the N bit 1559 value is '1' the Client infers that there is a NAT on the path. If N 1560 is '1', the Client SHOULD set UDP Port Number and IP Address to 0 in 1561 the first S/TLLAO of any subsequent ND messages it sends to the 1562 Server over that link. 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 before 1570 Router Lifetime expires. 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 an 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 underlying interface, it sets the 'D' bit to 1. When 1585 the Client receives the Server's RA response, it has assurance that 1586 the Server has been updated with the new information. 1588 If the Client wishes to associate with multiple Servers, it repeats 1589 the same procedures above for each additional Server. If the Client 1590 wishes to discontinue use of a Server it issues an RS message over 1591 any underlying interface with the 'R' bit set to 1 in the first 1592 SLLAO. When the Server processes the message, it releases the ACP, 1593 sets the symmetric neighbor cache entry state for the Client to 1594 DEPARTED, withdraws the IP route from the routing system and returns 1595 RA replies with Router Lifetime set to 0. 1597 3.14.3. AERO Server Behavior 1599 AERO Servers act as IPv6 routers and support a PD service for 1600 Clients. AERO Servers arrange to add their encapsulation layer IP 1601 addresses (i.e., their link-layer addresses) to a static map of 1602 Server addresses for the link and/or the DNS resource records for the 1603 FQDN "linkupnetworks.[domainname]" before entering service. The list 1604 of Server addresses should be geographically and/or topologically 1605 referenced, and forms the MAP list for the AERO link. 1607 When an AERO Server receives a prospective Client's RS message with 1608 PD parameters on its AERO interface, it SHOULD return an immediate RA 1609 reply with Router Lifetime set to 0 if it is currently too busy or 1610 otherwise unable to service the Client. Otherwise, the Server 1611 authenticates the RS message and processes the PD parameters. The 1612 Server first determines the correct ACPs to delegate to the Client by 1613 searching the Client database. When the Server delegates the ACPs, 1614 it also creates an IP forwarding table entry for each ACP so that the 1615 AERO BGP-based routing system will propagate the ACPs to the Relays 1616 that aggregate the corresponding ASP (see: Section 3.3). 1618 The Server next creates a symmetric neighbor cache entry for the 1619 Client using the base AERO address as the network-layer address and 1620 with lifetime set to no more than the smallest PD lifetime. Next, 1621 the Server updates the neighbor cache entry link-layer address(es) by 1622 recording the information in each SLLAO in the RS indexed by the 1623 Interface ID and including the UDP port number, IP address and P(i) 1624 values. For the first SLLAO in the list, however, the Server records 1625 the actual encapsulation source UDP and IP addresses instead of those 1626 that appear in the SLLAO in case there was a NAT in the path. The 1627 Server also records the value of the X bit to indicate whether there 1628 is a Proxy on the path. 1630 Next, the Server prepares an RA message that includes the delegated 1631 ACPs, any other PD parameters and an SLLAO with the Server's link- 1632 layer address and with Interface ID set to 255. The Server uses its 1633 link-local address as the network-layer source address, the network- 1634 layer source address of the RS message as the network-layer 1635 destination address, the Server's link-layer address as the source 1636 link-layer address, and the source link-layer address of the RS 1637 message as the destination link-layer address. The Server next sets 1638 the N flag to 1 if the source link-layer address in the RS message 1639 was different than the address in the first SLLAO to indicate that 1640 there is a NAT on the path. The Server then includes one or more 1641 RIOs that encode the ASPs for the AERO link. The Server also 1642 includes two MTU options - the first MTU option includes the MTU for 1643 the link and the second MTU option includes the MSU for the link (see 1644 Section 3.12). The Server finally sends the RA message to the 1645 Client. 1647 After the initial RS/RA exchange, the AERO Server maintains the 1648 symmetric neighbor cache entry for the Client. If the Client (or 1649 Proxy) issues additional NS/RS messages, the Server resets 1650 ReachableTime. If the Client (or Proxy) issues an RS with PD release 1651 parameters (e.g., by including an SLLAO with R set to 1), or if the 1652 Client becomes unreachable, the Server sets the Client's symmetric 1653 neighbor cache entry to the DEPARTED state and withdraws the IP 1654 routes from the AERO routing system. 1656 The Server processes these and any other Client ND/PD messages, and 1657 returns an NA/RA reply. The Server may also issue an unsolicited RA 1658 message with PD reconfigure parameters to cause the Client to 1659 renegotiate its PDs, and may issue an unsolicited RA message with 1660 Router Lifetime set to 0 if it can no longer service this Client. 1661 Finally, If the symmetric neighbor cache entry is in the DEPARTED 1662 state, the Server deletes the entry after DepartTime expires. 1664 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1666 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 1667 Servers are always on the same link (i.e., the AERO link) from the 1668 perspective of DHCPv6. However, in some implementations the DHCPv6 1669 server and ND function may be located in separate modules. In that 1670 case, the Server's AERO interface module can act as a Lightweight 1671 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 1672 the DHCPv6 server module. 1674 When the LDRA receives an authentic RS message, it extracts the PD 1675 message parameters and uses them to construct an IPv6/UDP/DHCPv6 1676 message. It sets the IPv6 source address to the source address of 1677 the RS message, sets the IPv6 destination address to 1678 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 1679 that will be understood by the DHCPv6 server. 1681 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 1682 header and includes an 'Interface-Id' option that includes enough 1683 information to allow the LDRA to forward the resulting Reply message 1684 back to the Client (e.g., the Client's link-layer addresses, a 1685 security association identifier, etc.). The LDRA also wraps the 1686 information in all of the SLLAOs from the RS message into the 1687 Interface-Id option, then forwards the message to the DHCPv6 server. 1689 When the DHCPv6 server prepares a Reply message, it wraps the message 1690 in a 'Relay-Reply' message and echoes the Interface-Id option. The 1691 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1692 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1693 uses the DHCPv6 message to construct an RA response to the Client. 1694 The Server uses the information in the Interface-Id option to prepare 1695 the RA message and to cache the link-layer addresses taken from the 1696 SLLAOs echoed in the Interface-Id option. 1698 3.15. The AERO Proxy 1700 In some environments, Clients may be located in secured subnetwork 1701 enclaves that do not allow direct communications from the Client to a 1702 Server in the outside Internetwork. In that case, the secured 1703 enclave can employ an AERO Proxy. 1705 The Proxy is located at the secured enclave perimeter and listens for 1706 encapsulated RS messages originating from or RA messages destined to 1707 Clients located within the enclave. The Proxy acts on these control 1708 messages as follows: 1710 o when the Proxy receives an RS message from a new Client within the 1711 secured enclave, it first authenticates the message then creates a 1712 proxy neighbor cache entry and caches the Client and Server link- 1713 layer addresses along with any identifying information including 1714 Transaction IDs, Client Identifiers, Nonce values, etc. The Proxy 1715 then examines the address in the first SLLAO of the RS message. 1716 If the address is different than the Client link-layer address, 1717 the Proxy notes that the Client is behind a NAT. The Proxy then 1718 re-encapsulates the RS message using its own external address as 1719 the source link-layer address, sets the X flag in the first SLLAO 1720 to '1', changes the address in the first SLLAO to its own external 1721 address, and forwards the message to the Server. 1723 o when the Server receives the RS message, it authenticates the 1724 message then creates or updates a symmetric neighbor cache entry 1725 for the Client with the Proxy's address as the link-layer address. 1726 The Server then sends an RA message back to the Proxy. 1728 o when the Proxy receives the RA message, it matches the message 1729 with the RS that created the proxy neighbor cache entry. The 1730 Proxy then caches the route information in the message as a 1731 mapping from the Client's ACPs to the Client's address within the 1732 secured enclave, and sets the neighbor cache entry state to 1733 REACHABLE. The Proxy then re-encapsulates the RA message using 1734 its own internal address as the source link-layer address, sets 1735 the X flag in the first SLLAO to '1', sets the N flag in the first 1736 SLLAO to '1' if the Client is behind a NAT, and forwards the 1737 message to the Client. 1739 After the initial RS/RA exchange, the Proxy forwards any Client data 1740 packets for which there is no matching asymmetric neighbor cache 1741 entry to the "eldest" of the Client's Servers, i.e., the first among 1742 possibly multiple Servers selected by the Client. If the eldest 1743 Server becomes unreachable, the Proxy sends future data packets via 1744 the next-eldest Server, etc. Finally, the Proxy forwards any Client 1745 data destined to an asymmetric neighbor cache target directly to the 1746 target according to the link-layer information - the process of 1747 establishing asymmetric neighbor cache entries is specified in 1748 Section 3.16. 1750 While the Client is still active, the Proxy continues to send NS/RS 1751 messages to update each Server's symmetric neighbor cache entries on 1752 behalf of the Client according to Neighbor Unreachability Detection 1753 (NUD) and/or to convey QoS updates. If the Server ceases to send 1754 solicited NA/RA responses, the Proxy marks the Server as unreachable 1755 and sends an unsolicited RA to the Client with Router Lifetime set to 1756 zero so that the Client knows that this Server is no longer able to 1757 provide Service. If the Client becomes unreachable, the Proxy sets 1758 the neighbor cache entry state to DEPARTED and sends an RS message to 1759 each Server with an SLLAO with the 'D' bit set to 1 and with 1760 Interface ID set to the Client's interface ID so that the Server will 1761 de-register this Interface ID. Although the Proxy engages in these 1762 ND exchanges on behalf of the Client, the Client can also send ND 1763 messages on its own behalf, e.g., if it is in a better position than 1764 the Proxy to convey QoS changes, etc. 1766 In some subnetworks that employ a Proxy, the Client's ACP can be 1767 injected into the underlying network routing system. In that case, 1768 the Client can send data messages without encapsulation so that the 1769 native underlying network routing system transports the 1770 unencapsulated packets to the Proxy. This can be very beneficial, 1771 e.g., if the Client connects to the network via low-end data links 1772 such as some aviation wireless links. In that case, however, the 1773 Client's control messages are still sent encapsulated so as to supply 1774 the Proxy with the address of the Server and to transport IPv6 ND 1775 messages without decrementing the hop-count. In summary, the 1776 interface becomes one where control messages are encapsulated while 1777 data messages are either unencapsulated or encapsulated according to 1778 the specific use case. This encapsulation avoidance represents a 1779 form of "header compression", meaning that the MTU should be sized 1780 based on the size of full encapsulated messages even if most messages 1781 are sent unencapsulated. 1783 3.15.1. The AERO-Aware Access Router 1785 If the Client is aware that its data link interface connects to a 1786 Proxyed domain with an AERO-aware Access Router as the first-hop 1787 router, it can avoid encapsulation for its control messages as well 1788 as its data messages. When the Client comes onto the link, it can 1789 send an unencapsulated RS message with source address set to its AERO 1790 address and with destination address set to the link-layer address of 1791 the Client's selected Server. If the Server is on an IPv6 network, 1792 the destination address is set to the Server's public IPv6 address. 1793 If the Server is on an IPv4 network, the destination address is set 1794 to the IPv4-mapped AERO address (For example, if the Server's address 1795 is 192.0.2.1 then the IPv4-mapped AERO address is 1796 fe80::FFFF:192.0.2.1.) 1798 The Client includes an SLLAO with Interface ID, Prefix Length and 1799 P(i) information but with UDP Port Number and IP Address set to 0. 1800 The Client then sends the unencapsulated RS message, which will be 1801 intercepted by the on-link AERO-Aware Access Router. The Access 1802 Router then encapsulates the RS message in an outer header with its 1803 own address as the source address and the address of a Proxy as the 1804 destination address. The Access Router further remembers the address 1805 of the Proxy so that it can encapsulate future data packets from the 1806 Client via the same Proxy. If the Access Router needs to change to a 1807 new Proxy, it simply sends another RS message toward the Server via 1808 the new Proxy on behalf of the Client. 1810 In this arrangement, the only control messages that would ever be 1811 sent by the Client are unencapsulated RS messages with its AERO 1812 address as the source address and the address of the Server as the 1813 destination address. The Client will also receive unencapsulated RA 1814 messages from the Server via both the Proxy and Access Router. 1816 3.16. AERO Route Optimization 1818 While data packets are flowing from a source Client to a target 1819 Client that are both holders of ACPs belonging to the same AERO link, 1820 route optimization SHOULD be used to avoid sending traffic through 1821 sub-optimal routes that consume expensive resources. Route 1822 optimization is conducted on a per-interface basis based on the 1823 source Client's available underlying interfaces, and may need to 1824 involve Proxies and Servers in the process. 1826 Route optimization is initiated by the first eligible AERO node 1827 closest to the source Client (i.e., the route optimization source) as 1828 follows: 1830 o For VPNed, NATed and Direct underlying interfaces, the Server is 1831 the route optimization source. 1833 o For Proxyed underlying interfaces, the Proxy is the route 1834 optimization source. 1836 o For native underlying interfaces, the Client itself is the route 1837 optimization source. 1839 While the source Client sends data packets toward a target Client, 1840 the route optimization source also sends an NS message to receive a 1841 solicited NA message from a target Server acting as a Mobility Anchor 1842 Point (MAP) for the target Client. The route optimization process is 1843 conducted in the same manner as IPv6 ND Address Resolution, and using 1844 the same NS/NA messaging. 1846 The NS includes the AERO address of the route optimization source as 1847 the network-layer source address, the AERO address corresponding to 1848 the data packet's destination address as the network-layer 1849 destination address, and the route optimization source address as the 1850 link-layer source address. For Clients and Proxies as the route 1851 optimization source, the address of the Client's Server is used as 1852 the link-layer destination address. For Servers as the route 1853 optimization source, the address of a Relay is used as the link-layer 1854 destination address. The NS message also includes a single SLLAO 1855 with the route optimization source address in the UDP Port Number and 1856 IP address fields. Finally, the NS message includes a Timestamp and 1857 Nonce option that can be used to match against the corresponding 1858 solicited NA but does not include any other security codes since the 1859 identity of the target Server is not yet known. 1861 When the source Server forwards or originates the NS message, it 1862 inserts an additional mid-layer IP encapsulation header between the 1863 NS message link-layer and network-layer headers. This mid-layer IP 1864 header uses the AERO Server Subnet Router Anycast address as the 1865 source address and the Subnet Router Anycast address corresponding to 1866 the target AERO address as the destination address. The source 1867 Server then changes the link-layer source address to its own address 1868 and the link-layer destination address to the address of a Relay. 1869 The source Server finally forwards the message to the Relay without 1870 decrementing the network-layer TTL/Hop Limit field. 1872 When the Relay receives the double-encapsulated NS message from the 1873 source Server, it discards the link-layer header(s) and determines 1874 that the target Server is the next hop toward the target Client by 1875 consulting its standard IP forwarding table for the Client Subnet 1876 Router Anycast destination address. The Relay then encapsulates and 1877 forwards the message to the target Server the same as for any IP 1878 router. 1880 When the target Server receives the (unsecured) NS message from the 1881 Relay, it removes the link-layer and mid-layer headers and examines 1882 the network-layer destination address to determine whether the target 1883 Client is one of its symmetric neighbors in the REACHABLE state. If 1884 the target Client is not a symmetric neighbor in the REACHABLE state, 1885 the target Server discards the NS. Otherwise, it prepares a 1886 solicited NA message to send back to the route optimization source 1887 but does not create a neighbor cache entry. The solicited NA message 1888 includes a first TLLAO with the target Server's address in the IP 1889 address and UDP Port Number, with Interface ID set to 255, with all 1890 P(i) values set to "low" and with "Prefix Length" set to the prefix 1891 length of the target Client's ACP. The solicited NA message then 1892 includes additional TLLAOs for all of the target Client's underlying 1893 interfaces. For NATed, VPNed and Direct interfaces, the TLLAO 1894 addresses are the address of the target Server. For Proxyed 1895 interfaces, the TLLAO addresses are the addresses of the target 1896 Proxies, and for native interfaces the TLLAO addresses are the 1897 addresses of the target Client. The target Server then encapsulates 1898 the solicited NA message, sets the link-layer source address to its 1899 own address and sets the link-layer destination address to the 1900 address found in the NS SLLAO. The target Server finally includes 1901 the Nonce value received in the NS plus the current Timestamp, 1902 applies security according to the route optmization source security 1903 association, then sends the solicited NA message directly to the 1904 route optimization source. 1906 When the route optimization source receives the (secured) solicited 1907 NA message, it first verifies the Nonce and Timestamp values. It 1908 then creates an asymmetric neighbor cache entry for the target Client 1909 and caches all address, Interface ID, P(i) and Prefix Length 1910 information found in the solicited NA TLLAOs. The route optimization 1911 source then forwards future data packets directly to the target 1912 Client instead of through a dogleg route involving unnecessary 1913 Servers and/or Relays. The route optimization further is shared by 1914 all sources that send packets to the target Client, i.e., and not 1915 just the original source Client. 1917 While new data packets destined to the target are flowing through the 1918 route optimization source, it sends additional secured NS messages to 1919 the target Server before ReachableTime expires to receive a fresh 1920 secured solicited NA message. The route optimization source then 1921 updates the asymmetric neighbor cache entry to refresh ReachableTime, 1922 while the target Server adds or updates the route optimization source 1923 address to the target Client's symmetric neighbor cache entry Report 1924 list, with time set to ReportTime. While no data packets are 1925 flowing, the route optimization source instead allows ReachableTime 1926 for the asymmetric neighbor cache entry to expire. When 1927 ReachableTime expires, the route optimization source deletes the 1928 asymmetric neighbor cache entry. Future data packets flowing through 1929 the route optimization source will again trigger a new route 1930 optimization exchange while initial data packets travel over a 1931 suboptimal route via Servers and/or Relays. 1933 The route optimization source may also receive unsolicited NA 1934 messages from the target at any time. If there is an asymmetric 1935 neighbor cache entry for the target, the route optimization source 1936 updates the link-layer information but does not update ReachableTime 1937 since the receipt of an unsolicited NA does not confirm that the 1938 forward path is still working. If there is no asymmetric neighbor 1939 cache entry, the route optimization source simply discards the 1940 unsolicited NA. Cases in which unsolicited NA messages are generated 1941 are specified in Section 3.18. 1943 In this arrangement, the route optimization source holds an 1944 asymmetric neighbor cache entry for the target, but the target does 1945 not hold an asymmetric neighbor cache entry for the route 1946 optimization source. The route optimization neighbor relationship is 1947 therefore asymmetric and unidirectional. If the target Client also 1948 has packets to send back to the source Client, then a separate route 1949 optimization procedure is required in the reverse direction. But, 1950 there is no requirement that the forward and reverse paths be 1951 symmetric. 1953 3.17. Neighbor Unreachability Detection (NUD) 1955 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1956 NS messages to elicit solicited NA messages from the target node the 1957 same as described in [RFC4861]. NUD is performed either reactively 1958 in response to persistent link-layer errors (see Section 3.13) or 1959 proactively to confirm reachability in the forward direction. The 1960 NUD algorithm may further be seeded by neighbor discovery hints of 1961 forward progress, but care must be taken to avoid inferring 1962 reachability based on spoofed information. 1964 When an AERO node sends an NS/NA message, it uses one of its link- 1965 local addresses as the IPv6 source address and a link-local address 1966 of the neighbor as the IPv6 destination address. When route 1967 optimization directs a route optimization source to one or more 1968 target addresses, the source SHOULD proactively test the direct path 1969 to each target address by sending an initial NS message to elicit a 1970 solicited NA response. While testing the path, the source node can 1971 optionally continue sending packets via its default router, maintain 1972 a small queue of packets until target reachability is confirmed, or 1973 (optimistically) allow packets to flow directly to the target. 1975 Note that AERO nodes may have multiple underlying interface paths 1976 toward the target neighbor. In that case, NUD SHOULD be performed 1977 over each underlying interface individually and the node should only 1978 consider the neighbor unreachable if NUD fails over multiple 1979 underlying interface paths. 1981 Underlying interface paths that pass NUD tests are marked as 1982 "reachable", while those that do not are marked as "unreachable". 1983 These markings inform the AERO interface forwarding algorithm 1984 specified in Section 3.8. 1986 Proxies can perform NUD to verify Server reachability on behalf of 1987 their proxyed Clients so that the Clients need not engage in NUD 1988 messaging themselves. 1990 3.18. Mobility Management and Quality of Service (QoS) 1992 AERO is an example of a Distributed Mobility Management (DMM) 1993 service. Each Server is responsible for only a subset of the Clients 1994 on the AERO link, as opposed to a Centralized Mobility Management 1995 (CMM) service where there is a single network mobility service for 1996 all Clients. Clients coordinate with their associated Servers via 1997 RS/RA exchanges to maintain the DMM profile, and the AERO routing 1998 system tracks all current Client/Server peering relationships. 2000 Servers provide a Mobility Anchor Point (MAP) for their dependent 2001 Clients. Clients are responsible for maintaining neighbor 2002 relationships with their Servers through periodic RS/RA exchanges, 2003 which also serves to confirm neighbor reachability. When a Client's 2004 underlying interface address and/or QoS information changes, the 2005 Client is responsible for updating the Server with this new 2006 information. Note that for Proxyed interfaces, however, the Proxy 2007 can perform the RS/RA exchanges on the Client's behalf. 2009 Mobility management considerations are specified in the following 2010 sections. 2012 3.18.1. Mobility Update Messaging 2014 AERO Servers (acting as MAPs) accommodate mobility and/or QoS change 2015 events by sending unsolicited NA messages to all route optimization 2016 sources for the target Client. When a Server sends an unsolicited NA 2017 message, it sets the IPv6 source address to the Client's AERO 2018 address, sets the IPv6 destination address to all-nodes multicast, 2019 sets the link-layer source address to its own address and sets the 2020 link-layer destination address to either a multicast address or the 2021 unicast link-layer address of a route optimization source in the 2022 Client's Report list. The Server also includes a first TLLAO for 2023 Interface ID 255, and includes additional TLLAOs for all of the 2024 target Client's Interface IDs. If there are multiple route 2025 optimization sources, the node sends an identical unicast copy of the 2026 unsolicited NA to each source. 2028 As for the hot-swap of interface cards discussed in Section 7.2.6 of 2029 [RFC4861], the transmission and reception of unsolicited NA messages 2030 is unreliable but provides a useful optimization. In well-connected 2031 Internetworks with robust data links unsolicited NA messages will be 2032 delivered with high probability, but in any case the Server can 2033 optionally send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited NAs to 2034 each route optimization source to increase the likelihood that at 2035 least one will be received. 2037 When a route optimization source receives an unsolicited NA message, 2038 it ignores the message if there is no existing neighbor cache entry 2039 for the Client. Otherwise, it uses the included TLLAOs to update the 2040 address and QoS information in the neighbor cache entry, but does not 2041 reset ReachableTime since the receipt of an unsolicited NA message 2042 from the target Server does not provide confirmation that any forward 2043 paths to the target Client are working. 2045 If unsolicited NA messages are lost, the route optimization source 2046 may be left with stale address and/or QoS information for the Client 2047 for up to ReachableTime seconds. During this time, the route 2048 optimization source can continue sending packets to the target Client 2049 according to its current neighbor cache information but may receive 2050 persistent unsolicited NA messages as discussed in Section 3.18.2. 2052 3.18.2. Forwarding Packets on Behalf of Departed Clients 2054 When a Server receives packets with destination addresses that match 2055 a symmetric neighbor cache entry in the DEPARTED state, it forwards 2056 the packets according to the Client's cached link layer address 2057 information, noting that the information may be stale. If the source 2058 is not a Relay or a symmetric neighbor Client, the Server also 2059 returns an unsolicited NA message (subject to rate limiting) with a 2060 first TLLAO with Interface ID 255 and with D set to 1. The (route 2061 optimization) source will then realize that it needs to set its 2062 asymmetric neighbor cache entry state for the target to DEPARTED, and 2063 SHOULD re-initiate route optimization after a short delay. (Note 2064 that if the NA includes additional TLLAOs with D set to 1, the route 2065 optimization source marks the corresponding neighbor cache interface 2066 IDs as "unreachable".) 2068 When a Proxy receives packets with destination addresses that match a 2069 proxy neighbor cache entry in the DEPARTED state, if forwards the 2070 packets to one of the target Client's Servers. If the source is 2071 neither one of target Client's Servers nor one of its proxy neighbor 2072 Clients, the Proxy also returns an unsolicited NA message (subject to 2073 rate limiting) with a single TLLAO with the target Client's Interface 2074 ID and with D set to 1. The (route optimization) source will then 2075 realize that it needs to mark its neighbor cache entry Interface ID 2076 for the Proxy as "unreachable", and SHOULD re-initiate route 2077 optimization while continuing to forward according to the remaining 2078 neighbor cache entry state. 2080 When a Server receives packets from a symmteric neighbor Client that 2081 are destined to the same Client, the Server marks the neighbor cache 2082 entry Interface ID for this path as "unreachable", and forwards the 2083 packets via a "reachable" Interface ID. If there are no "reachable" 2084 Interface IDs, the Server drops the packet. 2086 When a Client receives packets with destination addresses that do not 2087 match one of its ACPs, it drops the packets silently. 2089 3.18.3. Announcing Link-Layer Address and/or QoS Preference Changes 2091 When a Client needs to change its link-layer addresses and/or QoS 2092 preferences (e.g., due to a mobility event), either the Client or 2093 Proxy sends RS messages to its Servers using the new link-layer 2094 address as the source address and with TLLAOs that include the new 2095 Client UDP Port Number, IP Address and P(i) values. If the RS 2096 messages are sent solely for the purpose of updating QoS preferences 2097 without updating the link-layer address, the UDP Port Number and IP 2098 Address are set to 0. If the RS message is not sent for the purpose 2099 of asserting a PD, the Prefix Length is set to 0. 2101 Up to MAX_RTR_SOLICITATION RS messages MAY be sent in parallel with 2102 sending actual data packets in case one or more RAs are lost. If all 2103 RAs are lost, the Client SHOULD re-associate with a new Server. 2105 3.18.4. Bringing New Links Into Service 2107 When a Client needs to bring new underlying interfaces into service 2108 (e.g., when it activates a new data link), it sends RS messages to 2109 its Servers using the new link-layer address as the source address 2110 and with TLLAOs that include the new Client link-layer information. 2111 If the RS message is not sent for the purpose of asserting a PD, the 2112 Prefix Length is set to 0. 2114 3.18.5. Removing Existing Links from Service 2116 When a Client needs to remove existing underlying interfaces from 2117 service (e.g., when it de-activates an existing data link), it sends 2118 RS messages to its Servers with SLLAOs with the D flag set to 1. 2120 If the Client needs to send RS messages over an underlying interface 2121 other than the one being removed from service, it MUST include a 2122 current SLLAO for the sending interface as the first SLLAO and 2123 include SLLAOs for any underlying interfaces being removed from 2124 service as additional SLLAOs. 2126 3.18.6. Implicit Mobility Management 2128 AERO interface neighbors MAY provide a configuration option that 2129 allows them to perform implicit mobility management in which no ND 2130 messaging is used. In that case, the Client only transmits packets 2131 over a single interface at a time, and the neighbor always observes 2132 packets arriving from the Client from the same link-layer source 2133 address. 2135 If the Client's underlying interface address changes (either due to a 2136 readdressing of the original interface or switching to a new 2137 interface) the neighbor immediately updates the neighbor cache entry 2138 for the Client and begins accepting and sending packets to the 2139 Client's new link-layer address. This implicit mobility method 2140 applies to use cases such as cellphones with both WiFi and Cellular 2141 interfaces where only one of the interfaces is active at a given 2142 time, and the Client automatically switches over to the backup 2143 interface if the primary interface fails. 2145 3.18.7. Moving to a New Server 2147 When a Client associates with a new Server, it performs the Client 2148 procedures specified in Section 3.14.2. The Client then sends an RS 2149 message with R set to 1 in the first SLLAO and with PD parameters 2150 over any working underlying interface to fully release itself from 2151 the old Server. If the Client does not receive an RA reply after 2152 MAX_RTR_SOLICITATIONS attempts over multiple underlying interfaces, 2153 the old Server may have failed and the Client should discontinue its 2154 release attempts. 2156 When the old Server processes the RS, it sends unsolicited NA 2157 messages with a single TLLAO with Interface ID set to 255 and with D 2158 set to 1 to all route optimization sources in the Client's Report 2159 list. The Server also changes the symmetric neighbor cache entry 2160 state to DEPARTED and sets a timer to DepartTime seconds. The Server 2161 then returns an RA message to the Client with Router Lifetime set to 2162 0. After DepartTime seconds expires, the Server deletes the 2163 symmetric neighbor cache entry. 2165 When the Client receives the RA message with Router Lifetime set to 2166 0, it still must inform each of its remaining Proxies that it has 2167 released this Server from service. To do so, it sends an RS over 2168 each remaining proxyed underlying interface with destination set to 2169 the released Server's address and with R set to 1 in the first SLLAO 2170 but with no PD parameters. The Proxy will mark this Server as 2171 DEAPARTED and return an immediate RA without first performing an RS/ 2172 RA exchange with the Server. 2174 Clients SHOULD NOT move rapidly between Servers in order to avoid 2175 causing excessive oscillations in the AERO routing system. Such 2176 oscillations could result in intermittent reachability for the Client 2177 itself, while causing no harm to the network. Examples of when a 2178 Client might wish to change to a different Server include a Server 2179 that has gone unreachable, topological movements of significant 2180 distance, movement to a new geographic region, etc. 2182 3.19. Multicast Considerations 2184 When the underlying network does not support multicast, AERO Clients 2185 map link-scoped multicast addresses to the link-layer address of a 2186 Server, which acts as a multicast forwarding agent. The AERO Client 2187 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2188 applications per [RFC4605] while using the link-layer address of the 2189 Server as the link-layer address for all multicast packets. 2191 When the underlying network supports multicast, AERO nodes use the 2192 multicast address mapping specification found in [RFC2529] for IPv4 2193 underlying networks and use a TBD site-scoped multicast mapping for 2194 IPv6 underlying networks. In that case, border routers must ensure 2195 that the encapsulated site-scoped multicast packets do not leak 2196 outside of the site spanned by the AERO link. 2198 4. Direct Underlying Interfaces 2200 When a Client's AERO interface is configured over a Direct underlying 2201 interface, the neighbor at the other end of the Direct link can 2202 receive packets without any encapsulation. In that case, the Client 2203 sends packets over the Direct link according to the QoS preferences 2204 associated with its underling interfaces. If the Direct underlying 2205 interface has the highest QoS preference, then the Client's IP 2206 packets are transmitted directly to the peer without going through an 2207 underlying network. If other underlying interfaces have higher QoS 2208 preferences, then the Client's IP packets are transmitted via a 2209 different underlying interface, which may result in the inclusion of 2210 Proxies, Servers and Relays in the communications path. Direct 2211 underlying interfaces must be tested periodically for reachability, 2212 e.g., via NUD. 2214 5. Operation on AERO Links with /64 ASPs 2216 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2217 length /64 or shorter. However, in some cases it may be desirable to 2218 use AERO over links that have only a /64 ASP. This can be 2219 accommodated by treating all Clients on the AERO link as simple hosts 2220 that receive /128 prefix delegations. 2222 In that case, the Client sends an RS message to the Server the same 2223 as for ordinary AERO links. The Server responds with an RA message 2224 that includes one or more /128 prefixes (i.e., singleton addresses) 2225 that include the /64 ASP prefix along with an interface identifier 2226 portion to be assigned to the Client. The Client and Server then 2227 configure their AERO addresses based on the interface identifier 2228 portions of the /128s (i.e., the lower 64 bits) and not based on the 2229 /64 prefix (i.e., the upper 64 bits). 2231 For example, if the ASP for the host-only IPv6 AERO link is 2232 2001:db8:1000:2000::/64, each Client will receive one or more /128 2233 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2234 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2235 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2236 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2237 /128s) to either the AERO interface or an internal virtual interface 2238 such as a loopback. In this arrangement, the Client conducts route 2239 optimization in the same sense as discussed in Section 3.16. 2241 This specification has applicability for nodes that act as a Client 2242 on an "upstream" AERO link, but also act as a Server on "downstream" 2243 AERO links. More specifically, if the node acts as a Client to 2244 receive a /64 prefix from the upstream AERO link it can then act as a 2245 Server to provision /128s to Clients on downstream AERO links. 2247 6. AERO Adaptations for SEcure Neighbor Discovery (SEND) 2249 SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically 2250 Generated Addresses (CGAs) [RFC3972] were designed to secure IPv6 ND 2251 messaging in environments where symmetric network and/or transport- 2252 layer security services are impractical (see: Section 10). AERO 2253 nodes that use SEND/CGA employ the following adaptations. 2255 When a source AERO node prepares a SEND-protected ND message, it uses 2256 a link-local CGA as the IPv6 source address and writes the prefix 2257 embedded in its AERO address (i.e., instead of fe80::/64) in the CGA 2258 parameters Subnet Prefix field. When the neighbor receives the ND 2259 message, it first verifies the message checksum and SEND/CGA 2260 parameters while using the link-local prefix fe80::/64 (i.e., instead 2261 of the value in the Subnet Prefix field) to match against the IPv6 2262 source address of the ND message. 2264 The neighbor then derives the AERO address of the source by using the 2265 value in the Subnet Prefix field as the interface identifier of an 2266 AERO address. For example, if the Subnet Prefix field contains 2267 2001:db8:1:2, the neighbor constructs the AERO address as 2268 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 2269 neighbor cache entry it creates for the source, and uses the AERO 2270 address as the IPv6 destination address of any ND message replies. 2272 7. AERO Critical Infrastructure Considerations 2274 AERO Relays are low-end to midrange Commercial off-the Shelf (COTS) 2275 standard IP routers with no AERO code. Relays must be provisioned, 2276 supported and managed by the AERO Link Service Provider. Cost for 2277 purchasing, configuring and managing Relays is nominal even for very 2278 large AERO links. 2280 AERO Servers can be standard dedicated server platforms, but most 2281 often will be deployed as virtual machines in the cloud. The only 2282 requirements for Servers are that they can run the AERO user-level 2283 code and have at least one network interface with a public IP 2284 address. As with Relays, Servers must be provisioned, supported and 2285 managed by the AERO Link Service Provider. Cost for purchasing, 2286 configuring and managing Servers is nominal especially for virtual 2287 Servers hosted in the cloud. 2289 AERO Proxies are most often standard dedicated server platforms with 2290 one network interface connected to the secured enclave and a second 2291 interface connected to the public Internetwork. As with Servers, the 2292 only requirements are that they can run the AERO user-level code and 2293 have at least one interface with a public IP address. Proxies must 2294 be provisioned, supported and managed by the administrative authority 2295 for the secured enclave. Cost for purchasing, configuring and 2296 managing Proxies is nominal, and borne by the secured enclave 2297 administrative authority. 2299 AERO Clients are most often mobile nodes, but fixed AERO Clients can 2300 also be used to attach large non-mobile networks to the AERO link. 2301 In that case, the AERO Client would be a fixed IPv6 router that would 2302 appear the same as for any Client, albeit with no mobility signaling 2303 requirements. 2305 8. Implementation Status 2307 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2308 announced on the v6ops mailing list on January 10, 2018. The latest 2309 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2310 2.0.tgz. 2312 An initial public release of the AERO proof-of-concept source code 2313 was announced on the intarea mailing list on August 21, 2015. The 2314 latest version is available at: http://linkupnetworks.net/aero/aero- 2315 4.0.0.tgz. 2317 A survey of public domain and commercial SEND implementations is 2318 available at https://www.ietf.org/mail-archive/web/its/current/ 2319 msg02758.html. 2321 9. IANA Considerations 2323 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2324 AERO in the "enterprise-numbers" registry. 2326 The IANA has assigned the UDP port number "8060" for an earlier 2327 experimental version of AERO [RFC6706]. This document obsoletes 2328 [RFC6706] and claims the UDP port number "8060" for all future use. 2330 No further IANA actions are required. 2332 10. Security Considerations 2334 AERO link security considerations include considerations for both the 2335 data plane and the control plane. 2337 Data plane security considerations are the same as for ordinary 2338 Internet communications. Application endpoints in AERO Clients and 2339 their EUNs SHOULD use application-layer security services such as 2340 TLS/SSL [RFC5246], DTLS [RFC6347] or SSH [RFC4251] to assure the same 2341 level of protection as for critical secured Internet services such as 2342 online banking. AERO Clients that require host-based VPN services 2343 SHOULD use symmetric network and/or transport layer security services 2344 such as TLS/SSL, DTLS, IPsec [RFC4301], etc. AERO Proxies and 2345 Servers can also provide a network-based VPN service on behalf of the 2346 Client, e.g., if the Client is located within a secured enclave and 2347 cannot establish a VPN on its own behalf. 2349 Control plane security considerations are the same as for standard 2350 IPv6 Neighbor Discovery [RFC4861], except that the MAP list also 2351 improves security by providing AERO Clients with an authentic list of 2352 trusted Servers. As fixed infrastructure elements, AERO Proxies and 2353 Servers SHOULD pre-configure security associations for one another 2354 (e.g., using pre-placed keys) and use symmetric network and/or 2355 transport layer security services such as IPsec, TLS/SSL or DTLS to 2356 secure ND messages. AERO Relays do not maintain security 2357 associations since the only ND messages they accommodate are 2358 unprotected NS messages used for route optimization. AERO Clients 2359 that connect to secured enclaves need not apply security to their ND 2360 messages, since the messages will be intercepted by an enclave 2361 perimeter Proxy. AERO Clients located outside of secured enclaves 2362 SHOULD use symmetric network and/or transport layer security to 2363 secure their ND exchanges with Servers, but when there are many 2364 prospective neighbors with dynamically changing connectivity an 2365 asymmetric security service such as SEND may be needed (see: 2366 Section 6). 2368 AERO Servers and Relays present targets for traffic amplification 2369 Denial of Service (DoS) attacks. This concern is no different than 2370 for widely-deployed VPN security gateways in the Internet, where 2371 attackers could send spoofed packets to the gateways at high data 2372 rates. This can be mitigated by connecting Relays and Servers over 2373 dedicated links with no connections to the Internet and/or when 2374 connections to the Internet are only permitted through well-managed 2375 firewalls. Traffic amplification DoS attacks can also target an AERO 2376 Client's low data rate links. This is a concern not only for Clients 2377 located on the open Internet but also for Clients in secured 2378 enclaves. AERO Servers and Proxies can institute rate limits that 2379 protect Clients from receiving packet floods that could DoS low data 2380 rate links. 2382 AERO Relays must implement ingress filtering to discard packets with 2383 the AERO Server Subent Router Anycast address to avoid a spoofing 2384 attack in which spurious packets are injected into an AERO link from 2385 an outside attacker. Also, since an AERO link spans an entire 2386 Internetwork restricting access to the link can be achieved by having 2387 Internetwork border routers implement ingress filtering to discard 2388 encapsulted packets injected into the link by an outside agent. 2390 AERO Clients MUST ensure that their connectivity is not used by 2391 unauthorized nodes on their EUNs to gain access to a protected 2392 network, i.e., AERO Clients that act as routers MUST NOT provide 2393 routing services for unauthorized nodes. (This concern is no 2394 different than for ordinary hosts that receive an IP address 2395 delegation but then "share" the address with other nodes via some 2396 form of Internet connection sharing such as tethering.) 2398 The MAP list MUST be well-managed and secured from unauthorized 2399 tampering, even though the list contains only public information. 2401 The MAP list can be conveyed to the Client, e.g., through secure 2402 upload of a static file, through DNS lookups, etc. 2404 Although public domain and commercial SEND implementations exist, 2405 concerns regarding the strength of the cryptographic hash algorithm 2406 have been documented [RFC6273] [RFC4982]. 2408 Security considerations for accepting link-layer ICMP messages and 2409 reflected packets are discussed throughout the document. 2411 11. Acknowledgements 2413 Discussions in the IETF, aviation standards communities and private 2414 exchanges helped shape some of the concepts in this work. 2415 Individuals who contributed insights include Mikael Abrahamsson, Mark 2416 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2417 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2418 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2419 Hlusiak, Lee Howard, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy 2420 Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru 2421 Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, 2422 Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members 2423 of the IESG also provided valuable input during their review process 2424 that greatly improved the document. Special thanks go to Stewart 2425 Bryant, Joel Halpern and Brian Haberman for their shepherding 2426 guidance during the publication of the AERO first edition. 2428 This work has further been encouraged and supported by Boeing 2429 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2430 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2431 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2432 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Greg 2433 Saccone, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan 2434 Williams, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 2435 BR&T and BIT mobile networking teams. Kyle Bae, Wayne Benson and 2436 Eric Yeh are especially acknowledged for implementing the AERO 2437 functions as extensions to the public domain OpenVPN distribution. 2439 Earlier works on NBMA tunneling approaches are found in 2440 [RFC2529][RFC5214][RFC5569]. 2442 Many of the constructs presented in this second edition of AERO are 2443 based on the author's earlier works, including: 2445 o The Internet Routing Overlay Network (IRON) 2446 [RFC6179][I-D.templin-ironbis] 2448 o Virtual Enterprise Traversal (VET) 2449 [RFC5558][I-D.templin-intarea-vet] 2451 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2452 [RFC5320][I-D.templin-intarea-seal] 2454 o AERO, First Edition [RFC6706] 2456 Note that these works cite numerous earlier efforts that are not also 2457 cited here due to space limitations. The authors of those earlier 2458 works are acknowledged for their insights. 2460 This work is aligned with the NASA Safe Autonomous Systems Operation 2461 (SASO) program under NASA contract number NNA16BD84C. 2463 This work is aligned with the FAA as per the SE2025 contract number 2464 DTFAWA-15-D-00030. 2466 This work is aligned with the Boeing Information Technology (BIT) 2467 MobileNet program. 2469 This work is aligned with the Boeing autonomy program. 2471 12. References 2473 12.1. Normative References 2475 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2476 DOI 10.17487/RFC0768, August 1980, 2477 . 2479 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2480 DOI 10.17487/RFC0791, September 1981, 2481 . 2483 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2484 RFC 792, DOI 10.17487/RFC0792, September 1981, 2485 . 2487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2488 Requirement Levels", BCP 14, RFC 2119, 2489 DOI 10.17487/RFC2119, March 1997, 2490 . 2492 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2493 "Definition of the Differentiated Services Field (DS 2494 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2495 DOI 10.17487/RFC2474, December 1998, 2496 . 2498 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2499 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2500 DOI 10.17487/RFC3971, March 2005, 2501 . 2503 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2504 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2505 . 2507 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2508 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2509 November 2005, . 2511 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2512 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2513 . 2515 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2516 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2517 DOI 10.17487/RFC4861, September 2007, 2518 . 2520 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2521 Address Autoconfiguration", RFC 4862, 2522 DOI 10.17487/RFC4862, September 2007, 2523 . 2525 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2526 Advertisement Flags Option", RFC 5175, 2527 DOI 10.17487/RFC5175, March 2008, 2528 . 2530 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2531 (IPv6) Specification", STD 86, RFC 8200, 2532 DOI 10.17487/RFC8200, July 2017, 2533 . 2535 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2536 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2537 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2538 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2539 . 2541 12.2. Informative References 2543 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2544 2016. 2546 [I-D.ietf-dmm-distributed-mobility-anchoring] 2547 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 2548 "Distributed Mobility Anchoring", draft-ietf-dmm- 2549 distributed-mobility-anchoring-12 (work in progress), 2550 January 2019. 2552 [I-D.ietf-intarea-gue] 2553 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2554 Encapsulation", draft-ietf-intarea-gue-07 (work in 2555 progress), March 2019. 2557 [I-D.ietf-intarea-gue-extensions] 2558 Herbert, T., Yong, L., and F. Templin, "Extensions for 2559 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2560 extensions-06 (work in progress), March 2019. 2562 [I-D.ietf-intarea-tunnels] 2563 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2564 Architecture", draft-ietf-intarea-tunnels-09 (work in 2565 progress), July 2018. 2567 [I-D.ietf-rtgwg-atn-bgp] 2568 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2569 Moreno, "A Simple BGP-based Mobile Routing System for the 2570 Aeronautical Telecommunications Network", draft-ietf- 2571 rtgwg-atn-bgp-01 (work in progress), January 2019. 2573 [I-D.templin-6man-aeroaddr] 2574 Templin, F., "The AERO Address", draft-templin-6man- 2575 aeroaddr-04 (work in progress), December 2018. 2577 [I-D.templin-6man-dhcpv6-ndopt] 2578 Templin, F., "A Unified Stateful/Stateless Configuration 2579 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07 2580 (work in progress), December 2018. 2582 [I-D.templin-6man-rio-redirect] 2583 Templin, F. and j. woodyatt, "Route Information Options in 2584 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2585 redirect-07 (work in progress), December 2018. 2587 [I-D.templin-intarea-grefrag] 2588 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2589 templin-intarea-grefrag-04 (work in progress), July 2016. 2591 [I-D.templin-intarea-seal] 2592 Templin, F., "The Subnetwork Encapsulation and Adaptation 2593 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2594 progress), January 2014. 2596 [I-D.templin-intarea-vet] 2597 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2598 templin-intarea-vet-40 (work in progress), May 2013. 2600 [I-D.templin-ironbis] 2601 Templin, F., "The Interior Routing Overlay Network 2602 (IRON)", draft-templin-ironbis-16 (work in progress), 2603 March 2014. 2605 [I-D.templin-v6ops-pdhost] 2606 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 2607 Models", draft-templin-v6ops-pdhost-23 (work in progress), 2608 December 2018. 2610 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2612 [RFC1035] Mockapetris, P., "Domain names - implementation and 2613 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2614 November 1987, . 2616 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2617 Communication Layers", STD 3, RFC 1122, 2618 DOI 10.17487/RFC1122, October 1989, 2619 . 2621 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2622 DOI 10.17487/RFC1191, November 1990, 2623 . 2625 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2626 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2627 . 2629 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2630 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2631 1996, . 2633 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2634 DOI 10.17487/RFC2003, October 1996, 2635 . 2637 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2638 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2639 . 2641 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2642 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2643 December 1998, . 2645 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2646 Domains without Explicit Tunnels", RFC 2529, 2647 DOI 10.17487/RFC2529, March 1999, 2648 . 2650 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2651 Malis, "A Framework for IP Based Virtual Private 2652 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2653 . 2655 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2656 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2657 DOI 10.17487/RFC2784, March 2000, 2658 . 2660 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2661 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2662 . 2664 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2665 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2666 . 2668 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2669 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2670 . 2672 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2673 of Explicit Congestion Notification (ECN) to IP", 2674 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2675 . 2677 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2678 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2679 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2680 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2681 . 2683 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2684 for IPv6 Hosts and Routers", RFC 4213, 2685 DOI 10.17487/RFC4213, October 2005, 2686 . 2688 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2689 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 2690 January 2006, . 2692 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2693 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2694 DOI 10.17487/RFC4271, January 2006, 2695 . 2697 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2698 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2699 2006, . 2701 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2702 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2703 December 2005, . 2705 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2706 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2707 2006, . 2709 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2710 Control Message Protocol (ICMPv6) for the Internet 2711 Protocol Version 6 (IPv6) Specification", STD 89, 2712 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2713 . 2715 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2716 Protocol (LDAP): The Protocol", RFC 4511, 2717 DOI 10.17487/RFC4511, June 2006, 2718 . 2720 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2721 "Internet Group Management Protocol (IGMP) / Multicast 2722 Listener Discovery (MLD)-Based Multicast Forwarding 2723 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2724 August 2006, . 2726 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2727 Errors at High Data Rates", RFC 4963, 2728 DOI 10.17487/RFC4963, July 2007, 2729 . 2731 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 2732 Algorithms in Cryptographically Generated Addresses 2733 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 2734 . 2736 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2737 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2738 DOI 10.17487/RFC5214, March 2008, 2739 . 2741 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2742 (TLS) Protocol Version 1.2", RFC 5246, 2743 DOI 10.17487/RFC5246, August 2008, 2744 . 2746 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2747 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2748 February 2010, . 2750 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2751 Route Optimization Requirements for Operational Use in 2752 Aeronautics and Space Exploration Mobile Networks", 2753 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2754 . 2756 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2757 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2758 . 2760 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2761 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2762 January 2010, . 2764 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2765 Global Enterprise Recursion (RANGER)", RFC 5720, 2766 DOI 10.17487/RFC5720, February 2010, 2767 . 2769 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2770 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2771 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2772 . 2774 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2775 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2776 . 2778 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2779 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2780 DOI 10.17487/RFC6221, May 2011, 2781 . 2783 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 2784 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 2785 DOI 10.17487/RFC6273, June 2011, 2786 . 2788 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2789 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2790 January 2012, . 2792 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2793 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2794 . 2796 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2797 for Equal Cost Multipath Routing and Link Aggregation in 2798 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2799 . 2801 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2802 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2803 . 2805 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2806 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2807 . 2809 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2810 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2811 March 2017, . 2813 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2814 October 2014. 2816 Appendix A. AERO Alternate Encapsulations 2818 When GUE encapsulation is not needed, AERO can use common 2819 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2820 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2821 encapsulation is therefore only differentiated from non-AERO tunnels 2822 through the application of AERO control messaging and not through, 2823 e.g., a well-known UDP port number. 2825 As for GUE encapsulation, alternate AERO encapsulation formats may 2826 require encapsulation layer fragmentation. For simple IP-in-IP 2827 encapsulation, an IPv6 fragment header is inserted directly between 2828 the inner and outer IP headers when needed, i.e., even if the outer 2829 header is IPv4. The IPv6 Fragment Header is identified to the outer 2830 IP layer by its IP protocol number, and the Next Header field in the 2831 IPv6 Fragment Header identifies the inner IP header version. For GRE 2832 encapsulation, a GRE fragment header is inserted within the GRE 2833 header [I-D.templin-intarea-grefrag]. 2835 Figure 4 shows the AERO IP-in-IP encapsulation format before any 2836 fragmentation is applied: 2838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2839 | Outer IPv4 Header | | Outer IPv6 Header | 2840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2841 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 | Inner IP Header | | Inner IP Header | 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 | | | | 2846 ~ ~ ~ ~ 2847 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2848 ~ ~ ~ ~ 2849 | | | | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2852 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2854 Figure 4: Minimal Encapsulation Format using IP-in-IP 2856 Figure 5 shows the AERO GRE encapsulation format before any 2857 fragmentation is applied: 2859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2860 | Outer IP Header | 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | GRE Header | 2863 | (with checksum, key, etc..) | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | GRE Fragment Header (optional)| 2866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 | Inner IP Header | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | | 2870 ~ ~ 2871 ~ Inner Packet Body ~ 2872 ~ ~ 2873 | | 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 Figure 5: Minimal Encapsulation Using GRE 2878 Alternate encapsulation may be preferred in environments where GUE 2879 encapsulation would add unnecessary overhead. For example, certain 2880 low-bandwidth wireless data links may benefit from a reduced 2881 encapsulation overhead. 2883 GUE encapsulation can traverse network paths that are inaccessible to 2884 non-UDP encapsulations, e.g., for crossing Network Address 2885 Translators (NATs). More and more, network middleboxes are also 2886 being configured to discard packets that include anything other than 2887 a well-known IP protocol such as UDP and TCP. It may therefore be 2888 necessary to determine the potential for middlebox filtering before 2889 enabling alternate encapsulation in a given environment. 2891 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2892 encapsulations such as IPsec, TLS/SSL, DTLS, etc. In that case, AERO 2893 control messaging and route determination occur before security 2894 encapsulation is applied for outgoing packets and after security 2895 decapsulation is applied for incoming packets. 2897 AERO is especially well suited for use with VPN system encapsulations 2898 such as OpenVPN [OVPN]. 2900 Appendix B. S/TLLAO Extensions for Special-Purpose Links 2902 The AERO S/TLLAO format specified in Section 3.5 includes a Length 2903 value of 5 (i.e., 5 units of 8 octets). However, special-purpose 2904 links may extend the basic format to include additional fields and a 2905 Length value larger than 5. 2907 For example, adaptation of AERO to the Aeronautical 2908 Telecommunications Network with Internet Protocol Services (ATN/IPS) 2909 includes link selection preferences based on transport port numbers 2910 in addition to the existing DSCP-based preferences. ATN/IPS nodes 2911 maintain a map of transport port numbers to 64 possible preference 2912 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 2913 maps to preference field 20, UDP port 8060 maps to preference field 2914 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 2915 Figure 6, where the Length value is 7 and the 'Q(i)' fields provide 2916 link preferences for the corresponding transport port number. 2918 0 1 2 3 2919 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 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | Type | Length = 7 | Prefix Length | Reserved | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | Interface ID | UDP Port Number | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 | | 2926 + + 2927 | | 2928 + IP Address + 2929 | | 2930 + + 2931 | | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 2934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2935 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 2936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 2938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2939 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 2940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2941 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2947 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2950 Figure 6: ATN/IPS Extended S/TLLAO Format 2952 Appendix C. Change Log 2954 << RFC Editor - remove prior to publication >> 2956 Changes from draft-templin-intarea-6706bis-09 to draft-templin- 2957 intrea-6706bis-10: 2959 o Orphaned packets in flight (e.g., when a neighbor cache entry is 2960 in the DEPARTED state) are now forwarded at the link layer instead 2961 of at the network layer. Forwarding at the network layer can 2962 result in routing loops and/or excessive delays of forwarded 2963 packets while the routing system is still reconverging. 2965 o Update route optimization to calrify the unsecured nature of the 2966 first NS used for route discovery 2968 o Many cleanups and clarifcations on ND messaging parameters 2970 Changes from draft-templin-intarea-6706bis-08 to draft-templin- 2971 intrea-6706bis-09: 2973 o Changed PRL to "MAP list" 2975 o For neighbor cache entries, changed "static" to "symmetric", and 2976 "dynamic" to "asymmetric" 2978 o Specified Proxy RS/RA exchanges with Servers on behalf of Clients 2980 o Added discussion of unsolicited NAs in Section 3.16, and included 2981 forward reference to Section 3.18 2983 o Added discussion of AERO Clients used as critical infrastructure 2984 elements to connect fixed networks. 2986 o Added network-based VPN under security considerations 2988 Changes from draft-templin-intarea-6706bis-07 to draft-templin- 2989 intrea-6706bis-08: 2991 o New section on AERO-Aware Access Router 2993 Changes from draft-templin-intarea-6706bis-06 to draft-templin- 2994 intrea-6706bis-07: 2996 o Added "R" bit for release of PDs. Now have a full RS/RA service 2997 that can do PD without requiring DHCPv6 messaging over-the-air 2999 o Clarifications on solicited vs unsolicited NAs 3000 o Clarified use of MAX_NEIGHBOR_ADVERTISEMENTS for the purpose of 3001 increase reliability 3003 Changes from draft-templin-intarea-6706bis-05 to draft-templin- 3004 intrea-6706bis-06: 3006 o Major re-work and simplification of Route Optimization function 3008 o Added Distributed Mobility Management (DMM) and Mobility Anchor 3009 Point (MAP) terminology 3011 o New section on "AERO Critical Infrastructure Element 3012 Considerations" demonstrating low overall cost for the service 3014 o minor text revisions and deletions 3016 o removed extraneous appendices 3018 Changes from draft-templin-intarea-6706bis-04 to draft-templin- 3019 intrea-6706bis-05: 3021 o New Appendix E on S/TLLAO Extensions for special-purpose links. 3022 Discussed ATN/IPS as example. 3024 o New sentence in introduction to declare appendices as non- 3025 normative. 3027 Changes from draft-templin-intarea-6706bis-03 to draft-templin- 3028 intrea-6706bis-04: 3030 o Added definitions for Potential Router List (PRL) and secure 3031 enclave 3033 o Included text on mapping transport layer port numbers to network 3034 layer DSCP values 3036 o Added reference to DTLS and DMM Distributed Mobility Anchoring 3037 working group document 3039 o Reworked Security Considerations 3041 o Updated references. 3043 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 3044 intrea-6706bis-03: 3046 o Added new section on SEND. 3048 o Clarifications on "AERO Address" section. 3050 o Updated references and added new reference for RFC8086. 3052 o Security considerations updates. 3054 o General text clarifications and cleanup. 3056 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 3057 intrea-6706bis-02: 3059 o Note on encapsulation avoidance in Section 4. 3061 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 3062 intrea-6706bis-01: 3064 o Remove DHCPv6 Server Release procedures that leveraged the old way 3065 Relays used to "route" between Server link-local addresses 3067 o Remove all text relating to Relays needing to do any AERO-specific 3068 operations 3070 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 3071 as source addresses, and destination address of RA reply is to the 3072 AERO address corresponding to the Client's ACP. 3074 o Proxy uses SEND to protect RS and authenticate RA (Client does not 3075 use SEND, but rather relies on subnetwork security. When the 3076 Proxy receives an RS from the Client, it creates a new RS using 3077 its own addresses as the source and uses SEND with CGAs to send a 3078 new RS to the Server. 3080 o Emphasize distributed mobility management 3082 o AERO address-based RS injection of ACP into underlying routing 3083 system. 3085 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 3086 6706bis-00: 3088 o Document use of NUD (NS/NA) for reliable link-layer address 3089 updates as an alternative to unreliable unsolicited NA. 3090 Consistent with Section 7.2.6 of RFC4861. 3092 o Server adds additional layer of encapsulation between outer and 3093 inner headers of NS/NA messages for transmission through Relays 3094 that act as vanilla IPv6 routers. The messages include the AERO 3095 Server Subnet Router Anycast address as the source and the Subnet 3096 Router Anycast address corresponding to the Client's ACP as the 3097 destination. 3099 o Clients use Subnet Router Anycast address as the encapsulation 3100 source address when the access network does not provide a 3101 topologically-fixed address. 3103 Author's Address 3105 Fred L. Templin (editor) 3106 Boeing Research & Technology 3107 P.O. Box 3707 3108 Seattle, WA 98124 3109 USA 3111 Email: fltemplin@acm.org