idnits 2.17.1 draft-templin-intarea-6706bis-00.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 (September 6, 2018) is 2052 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 2539, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2581, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2809, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2828, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-06 == Outdated reference: A later version (-06) exists of draft-ietf-intarea-gue-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-05 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-06 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-21 -- 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) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc5320, rfc5558, rfc5720, September 6, 2018 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: March 10, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-00.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 March 10, 2019. 48 Copyright Notice 50 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 7 69 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 71 3.4. AERO Interface Addresses . . . . . . . . . . . . . . . . 11 72 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 13 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 16 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 16 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 17 76 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 17 77 3.6.4. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 18 78 3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 18 79 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 20 80 3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 20 81 3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 21 82 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 21 83 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 22 84 3.8.5. Processing Return Packets . . . . . . . . . . . . . . 22 85 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 23 86 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 24 87 3.11. AERO Interface Data Origin Authentication . . . . . . . . 24 88 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 25 89 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 27 90 3.14. AERO Router Discovery, Prefix Delegation and 91 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 30 92 3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 30 93 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 31 94 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 33 95 3.15. AERO Interface Route Optimization . . . . . . . . . . . . 35 96 3.15.1. Reference Operational Scenario . . . . . . . . . . . 36 97 3.15.2. Concept of Operations . . . . . . . . . . . . . . . 37 98 3.15.3. Sending NS Messages . . . . . . . . . . . . . . . . 37 99 3.15.4. Re-encapsulating and Relaying the NS . . . . . . . . 38 100 3.15.5. Processing NSs and Sending NAs . . . . . . . . . . . 39 101 3.15.6. Re-encapsulating and Relaying NAs . . . . . . . . . 40 102 3.15.7. Processing NAs . . . . . . . . . . . . . . . . . . . 41 103 3.15.8. Server and Proxy Extended Route Optimization . . . . 42 104 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 43 105 3.17. Mobility Management and Quality of Service (QoS) . . . . 44 106 3.17.1. Forwarding Packets on Behalf of Departed Clients . . 45 107 3.17.2. Announcing Link-Layer Address and QoS Preference 108 Changes . . . . . . . . . . . . . . . . . . . . . . 45 109 3.17.3. Bringing New Links Into Service . . . . . . . . . . 45 110 3.17.4. Removing Existing Links from Service . . . . . . . . 45 111 3.17.5. Implicit Mobility Management . . . . . . . . . . . . 46 112 3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 46 113 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 47 114 4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 47 115 5. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 50 116 6. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 50 117 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 51 118 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 119 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 120 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 122 11.1. Normative References . . . . . . . . . . . . . . . . . . 54 123 11.2. Informative References . . . . . . . . . . . . . . . . . 55 124 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 60 125 Appendix B. When to Insert an Encapsulation Fragment Header . . 62 126 Appendix C. Autoconfiguration for Constrained Platforms . . . . 63 127 Appendix D. Operational Deployment Alternatives . . . . . . . . 64 128 D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 64 129 D.2. Operation on Server-less AERO Links . . . . . . . . . . . 64 130 D.3. Operation on Client-less AERO Links . . . . . . . . . . . 64 131 D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 65 132 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 65 133 D.6. Encapsulation Protocol Version Considerations . . . . . . 65 134 D.7. Extending AERO Links Through Security Gateways . . . . . 65 135 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 67 136 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67 138 1. Introduction 140 This document specifies the operation of IP over tunnel virtual links 141 using Asymmetric Extended Route Optimization (AERO). The AERO link 142 can be used for tunneling between neighboring nodes over either IPv6 143 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 144 equivalent links for tunneling. Nodes attached to AERO links can 145 exchange packets via trusted intermediate routers that provide 146 forwarding services to reach off-link destinations and route 147 optimization services for improved performance [RFC5522]. 149 AERO provides an IPv6 link-local address format that supports 150 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 151 links ND to IP forwarding. Dynamic link selection, mobility 152 management, quality of service (QoS) signaling and route optimization 153 are naturally supported through dynamic neighbor cache updates, while 154 IPv6 Prefix Delegation (PD) is supported by network services such as 155 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 156 [RFC3315][RFC3633]. 158 A node's AERO interface can be configured over multiple underlying 159 interfaces. From the standpoint of ND, AERO interface neighbors 160 therefore may appear to have multiple link-layer addresses (i.e., the 161 addresses assigned to underlying interfaces). Each link-layer 162 address is subject to change due to mobility and/or QoS fluctuations, 163 and link-layer address changes are signaled by ND messaging the same 164 as for any IPv6 link. 166 AERO is applicable to a wide variety of use cases. For example, it 167 can be used to coordinate the Virtual Private Network (VPN) links of 168 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 169 connect into a home enterprise network via public access networks 170 using services such as OpenVPN [OVPN]. AERO is also applicable to 171 aviation services for both manned and unmanned aircraft where the 172 aircraft is treated as a mobile node that can connect an Internet of 173 Things (IoT). Other applicable use cases are also in scope. 175 The remainder of this document presents the AERO specification. 177 2. Terminology 179 The terminology in the normative references applies; the following 180 terms are defined within the scope of this document: 182 IPv6 Neighbor Discovery (ND) 183 an IPv6 control message service for coordinating neighbor 184 relationships between nodes connected to a common link. The ND 185 service used by AERO is specified in [RFC4861]. 187 IPv6 Prefix Delegation (PD) 188 a networking service for delegating IPv6 prefixes to nodes on the 189 link. The nominal PD service is DHCPv6 [RFC3315] [RFC3633], 190 however other services (e.g., alternate ND options, network 191 management, static configuration, etc.) are also possible. 193 (native) Internetwork 194 a connected IPv6 or IPv4 network topology over which the AERO link 195 virtual overlay is configured and native peer-to-peer 196 communications are supported. Example Internetworks include the 197 global public Internet, private enterprise networks, aviation 198 networks, etc. 200 AERO link 201 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 202 configured over an underlying Internetwork. All nodes on the AERO 203 link appear as single-hop neighbors from the perspective of the 204 virtual overlay even though they may be separated by many 205 underlying Internetwork hops. The AERO mechanisms can also 206 operate over native link types (e.g., Ethernet, WiFi etc.) when a 207 tunnel virtual overlay is not needed. 209 AERO interface 210 a node's attachment to an AERO link. Since the addresses assigned 211 to an AERO interface are managed for uniqueness, AERO interfaces 212 do not require Duplicate Address Detection (DAD) and therefore set 213 the administrative variable DupAddrDetectTransmits to zero 214 [RFC4862]. 216 AERO address 217 an IPv6 link-local address constructed as specified in 218 Section 3.4. 220 AERO node 221 a node that is connected to an AERO link. 223 AERO Client ("Client") 224 a node that requests IP PDs from one or more AERO Servers. 225 Following PD, the Client assigns an AERO address to the AERO 226 interface for use in ND exchanges with other AERO nodes. A node 227 that acts as an AERO Client on one AERO interface can also act as 228 an AERO Server on a different AERO interface. 230 AERO Server ("Server") 231 a node that configures an AERO interface to provide default 232 forwarding services for AERO Clients. The Server assigns an 233 administratively-provisioned IPv6 link-local address to the AERO 234 interface to support the operation of the ND/PD services. An AERO 235 Server can also act as an AERO Relay. 237 AERO Relay ("Relay") 238 an IP router that can relay IP packets between AERO Servers and/or 239 forward IP packets between the AERO link and the native 240 Internetwork. Relays are standard IP routers that can be 241 purchased from any major network equipment supplier. 243 AERO Proxy ("Proxy") 244 a node that provides proxying services for Clients that cannot 245 associate directly with Servers, e.g., when the Client is located 246 in a secured internal enclave and the Server is located in the 247 external Internetwork. The AERO Proxy is a conduit between the 248 secured enclave and the external Internetwork in the same manner 249 as for common web proxies, and behaves in a similar fashion as for 250 ND proxies [RFC4389]. 252 ingress tunnel endpoint (ITE) 253 an AERO interface endpoint that injects encapsulated packets into 254 an AERO link. 256 egress tunnel endpoint (ETE) 257 an AERO interface endpoint that receives encapsulated packets from 258 an AERO link. 260 underlying network 261 the same as defined for Internetwork. 263 underlying link 264 a link that connects an AERO node to the underlying network. 266 underlying interface 267 an AERO node's interface point of attachment to an underlying 268 link. 270 link-layer address 271 an IP address assigned to an AERO node's underlying interface. 272 When UDP encapsulation is used, the UDP port number is also 273 considered as part of the link-layer address. Packets transmitted 274 over an AERO interface use link-layer addresses as encapsulation 275 header source and destination addresses. Destination link-layer 276 addresses can be either "reachable" or "unreachable" based on 277 dynamically-changing network conditions. 279 network layer address 280 the source or destination address of an encapsulated IP packet. 282 end user network (EUN) 283 an internal virtual or external edge IP network that an AERO 284 Client connects to the rest of the network via the AERO interface. 285 The Client sees each EUN as a "downstream" network and sees the 286 AERO interface as its point of attachment to the "upstream" 287 network. 289 AERO Service Prefix (ASP) 290 an IP prefix associated with the AERO link and from which more- 291 specific AERO Client Prefixes (ACPs) are derived. 293 AERO Client Prefix (ACP) 294 an IP prefix derived from an ASP and delegated to a Client, where 295 the ACP prefix length must be no shorter than the ASP prefix 296 length and must be no longer than 64 for IPv6 or 32 for IPv4. 298 base AERO address 299 the lowest-numbered AERO address from the first ACP delegated to 300 the Client (see Section 3.4). 302 Throughout the document, the simple terms "Client", "Server", "Relay" 303 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 304 "AERO Proxy", respectively. Capitalization is used to distinguish 305 these terms from DHCPv6 client/server/relay [RFC3315]. 307 The terminology of DHCPv6 [RFC3315][RFC3633] and IPv6 ND [RFC4861] 308 (including the names of node variables, messages and protocol 309 constants) is used throughout this document. Also, the term "IP" is 310 used to generically refer to either Internet Protocol version, i.e., 311 IPv4 [RFC0791] or IPv6 [RFC8200]. 313 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 314 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 315 document are to be interpreted as described in [RFC2119]. Lower case 316 uses of these words are not to be interpreted as carrying RFC2119 317 significance. 319 3. Asymmetric Extended Route Optimization (AERO) 321 The following sections specify the operation of IP over Asymmetric 322 Extended Route Optimization (AERO) links: 324 3.1. AERO Link Reference Model 325 .-(::::::::) 326 .-(::::::::::::)-. 327 (:: Internetwork ::) 328 `-(::::::::::::)-' 329 `-(::::::)-' 330 | 331 +--------------+ +--------+-------+ +--------------+ 332 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 333 | Nbr: C1, R1 | | Nbr: S1, S2 | | Nbr: C2, R1 | 334 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 335 | X1->C1 | | ASP A1 | | X2->C2 | 336 +-------+------+ +--------+-------+ +------+-------+ 337 | AERO Link | | 338 X---+---+-------------------+-+----------------+---+---X 339 | | | 340 +-----+--------+ +----------+------+ +--------+-----+ 341 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 342 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 343 | default->S1 | +--------+--------+ | default->S2 | 344 | ACP X1 | | | ACP X2 | 345 +------+-------+ .--------+------. +-----+--------+ 346 | (- Proxyed Clients -) | 347 .-. `---------------' .-. 348 ,-( _)-. ,-( _)-. 349 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 350 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 351 `-(______)-' +-------+ +-------+ `-(______)-' 353 Figure 1: AERO Link Reference Model 355 Figure 1 presents the AERO link reference model. In this model: 357 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 358 default router for its associated Servers (S1 and S2), and 359 connects the AERO link to the rest of the Internetwork. 361 o AERO Servers S1 and S2 associate with Relay R1 and also act as 362 default routers for their associated Clients C1 and C2. 364 o AERO Clients C1 and C2 associate with Servers S1 and S2, 365 respectively. They receive AERO Client Prefix (ACP) delegations 366 X1 and X2, and also act as default routers for their associated 367 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 368 to the EUNs served by Clients C1 and C2, respectively. 370 o AERO Proxy P1 provides proxy services for AERO Clients in secured 371 enclaves that cannot associate directly with other AERO link 372 neighbors. 374 Each node on the AERO link maintains an AERO interface neighbor cache 375 and an IP forwarding table the same as for any link. Although the 376 figure shows a limited deployment, in common operational practice 377 there may be many additional Relays, Servers, Clients and Proxies. 379 3.2. AERO Node Types 381 AERO Relays are standard IP routers that provide default forwarding 382 services to AERO Servers. Each Relay also peers with Servers and 383 other Relays in a dynamic routing protocol instance to discover the 384 list of active ACPs (see Section 3.3). Relays forward packets 385 between neighbors connected to the same AERO link and also forward 386 packets between the AERO link and the native Internetwork. Relays 387 present the AERO link to the native Internetwork as a set of one or 388 more AERO Service Prefixes (ASPs) and serve as a gateway between the 389 AERO link and the Internetwork. Relays maintain tunnels with 390 neighboring Servers, and maintain an IP forwarding table entry for 391 each AERO Client Prefix (ACP). 393 AERO Servers provide default forwarding services to AERO Clients. 394 Each Server also peers with Relays in a dynamic routing protocol 395 instance to advertise its list of associated ACPs (see Section 3.3). 396 Servers facilitate PD exchanges with Clients, where each delegated 397 prefix becomes an ACP taken from an ASP. Servers forward packets 398 between AERO interface neighbors, and maintain AERO interface 399 neighbor cache entries for Relays. They also maintain both neighbor 400 cache entries and IP forwarding table entries for each of their 401 associated Clients. 403 AERO Clients act as requesting routers to receive ACPs through PD 404 exchanges with AERO Servers over the AERO link. Each Client can 405 associate with a single Server or with multiple Servers, e.g., for 406 fault tolerance, load balancing, etc. Each IPv6 Client receives at 407 least a /64 IPv6 ACP, and may receive even shorter prefixes. 408 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 409 singleton IPv4 address), and may receive even shorter prefixes. 410 Clients maintain an AERO interface neighbor cache entry for each of 411 their associated Servers as well as for each of their correspondent 412 Clients. 414 AERO Proxies provide a conduit for AERO Clients connected to secured 415 enclaves to associate with AERO link Servers. The Proxy can either 416 be explicit or transparent. In the explicit case, the Client sends 417 all of its control plane messages addressed to the Server to the 418 link-layer address of the Proxy. In the transparent case, the Client 419 sends all of its control plane messages to the Server's link-layer 420 address and the Proxy intercepts them before they leave the secured 421 enclave. In both cases, the Proxy forwards the Client's control and 422 data plane messages to and from the Client's current Server(s). The 423 Proxy may also discover a more direct route toward a target 424 destination via AERO route optimization, in which case future 425 outbound data packets would be forwarded via the more direct route. 426 The Proxy function is specified in Section 4. 428 3.3. AERO Routing System 430 The AERO routing system comprises a private instance of the Border 431 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 432 and Servers and does not interact with either the public Internet BGP 433 routing system or the native Internetwork routing system. Relays 434 advertise only a small and unchanging set of ASPs to the native 435 Internetwork routing system instead of the full dynamically changing 436 set of ACPs. 438 In a reference deployment, each AERO Server is configured as an 439 Autonomous System Border Router (ASBR) for a stub Autonomous System 440 (AS) using an AS Number (ASN) that is unique within the BGP instance, 441 and each Server further uses eBGP to peer with one or more Relays but 442 does not peer with other Servers. All Relays are members of the same 443 hub AS using a common ASN, and use iBGP to maintain a consistent view 444 of all active ACPs currently in service. 446 Each Server maintains a working set of associated ACPs, and 447 dynamically announces new ACPs and withdraws departed ACPs in its 448 eBGP updates to Relays. Clients are expected to remain associated 449 with their current Servers for extended timeframes, however Servers 450 SHOULD selectively suppress updates for impatient Clients that 451 repeatedly associate and disassociate with them in order to dampen 452 routing churn. 454 Each Relay configures a black-hole route for each of its ASPs. By 455 black-holing the ASPs, the Relay will maintain forwarding table 456 entries only for the ACPs that are currently active, and packets 457 destined to all other ACPs will correctly incur Destination 458 Unreachable messages due to the black hole route. Relays do not send 459 eBGP updates for ACPs to Servers, but instead only originate a 460 default route. In this way, Servers have only partial topology 461 knowledge (i.e., they know only about the ACPs of their directly 462 associated Clients) and they forward all other packets to Relays 463 which have full topology knowledge. 465 Scaling properties of the AERO routing system are limited by the 466 number of BGP routes that can be carried by Relays. At the time of 467 this writing, the global public Internet BGP routing system manages 468 more than 500K routes with linear growth and no signs of router 469 resource exhaustion [BGP]. Network emulation studies have also shown 470 that a single Relay can accommodate at least 1M dynamically changing 471 BGP routes even on a lightweight virtual machine, i.e., and without 472 requiring high-end dedicated router hardware. 474 Therefore, assuming each Relay can carry 1M or more routes, this 475 means that at least 1M Clients can be serviced by a single set of 476 Relays. A means of increasing scaling would be to assign a different 477 set of Relays for each set of ASPs. In that case, each Server still 478 peers with one or more Relays, but the Server institutes route 479 filters so that it only sends BGP updates to the specific set of 480 Relays that aggregate the ASP. For example, if the ASP for the AERO 481 link is 2001:db8::/32, a first set of Relays could service the ASP 482 segment 2001:db8::/40, a second set of Relays could service 483 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 484 etc. 486 Assuming up to 1K sets of Relays, the AERO routing system can then 487 accommodate 1B or more ACPs with no additional overhead for Servers 488 and Relays (for example, it should be possible to service 1B /64 ACPs 489 taken from a /34 ASP and even more for shorter prefixes). In this 490 way, each set of Relays services a specific set of ASPs that they 491 advertise to the native Internetwork routing system, and each Server 492 configures ASP-specific routes that list the correct set of Relays as 493 next hops. This arrangement also allows for natural incremental 494 deployment, and can support small scale initial deployments followed 495 by dynamic deployment of additional Clients, Servers and Relays 496 without disturbing the already-deployed base. 498 Note that in an alternate routing arrangement each set of Relays 499 could advertise an aggregated ASP for the link into the native 500 Internetwork routing system even though each Relay services only 501 smaller segments of the ASP. In that case, a Relay upon receiving a 502 packet with a destination address covered by the ASP segment of 503 another Relay can simply tunnel the packet to the other Relay. The 504 tradeoff then is the penalty for Relay-to-Relay tunneling compared 505 with reduced routing information in the native routing system. 507 A full discussion of the BGP-based routing system used by AERO is 508 found in [I-D.templin-atn-bgp]. 510 3.4. AERO Interface Addresses 512 AERO interface link-local address types include administratively- 513 provisioned addresses and AERO addresses. 515 Administratively-provisioned addresses are allocated from the range 516 fe80::/96 and assigned to a Server's AERO interface. 517 Administratively-provisioned addresses MUST be managed for uniqueness 518 by the administrative authority for the AERO link. The address 519 fe80:: is reserved as the IPv6 link-local Subnet Router Anycast 520 address, and the address fe80::ffff:ffff is reserved as the "prefix- 521 solicitation" address used by Clients to bootstrap AERO address 522 autoconfiguration. These reserved addresses are therefore not 523 available for general assignment. 525 An AERO address is an IPv6 link-local address with an embedded prefix 526 based on an ACP and associated with a Client's AERO interface. AERO 527 addresses remain stable as the Client moves between topological 528 locations, i.e., even if its link-layer addresses change. 530 For IPv6, AERO addresses begin with the prefix fe80::/64 and include 531 in the interface identifier (i.e., the lower 64 bits) a 64-bit prefix 532 taken from one of the Client's IPv6 ACPs. For example, if the AERO 533 Client receives the IPv6 ACP: 535 2001:db8:1000:2000::/56 537 it constructs its corresponding AERO addresses as: 539 fe80::2001:db8:1000:2000 541 fe80::2001:db8:1000:2001 543 fe80::2001:db8:1000:2002 545 ... etc. ... 547 fe80::2001:db8:1000:20ff 549 For IPv4, AERO addresses are based on an IPv4-mapped IPv6 address 550 formed from an IPv4 ACP and with a Prefix Length of 96 plus the ACP 551 prefix length. For example, for the IPv4 ACP 192.0.2.32/28 the 552 IPv4-mapped IPv6 ACP is: 554 0:0:0:0:0:FFFF:192.0.2.16/124 556 The Client then constructs its AERO addresses with the prefix 557 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 558 in the interface identifier as: 560 fe80::FFFF:192.0.2.16 562 fe80::FFFF:192.0.2.17 564 fe80::FFFF:192.0.2.18 565 ... etc. ... 567 fe80:FFFF:192.0.2.31 569 When the Server delegates ACPs to the Client, both the Server and 570 Client use the lowest-numbered AERO address from the first ACP 571 delegation as the "base" AERO address (for example, for the ACP 572 2001:db8:1000:2000::/56 the base AERO address is 573 fe80::2001:db8:1000:2000). The Client then assigns the base AERO 574 address to the AERO interface and uses it for the purpose of 575 maintaining the neighbor cache entry. The Server likewise uses the 576 AERO address as its index into the neighbor cache for this Client. 578 If the Client has multiple AERO addresses (i.e., when there are 579 multiple ACPs and/or ACPs with short prefix lengths), the Client 580 originates ND messages using the base AERO address as the source 581 address and accepts and responds to ND messages destined to any of 582 its AERO addresses as equivalent to the base AERO address. In this 583 way, the Client maintains a single neighbor cache entry that may be 584 indexed by multiple AERO addresses. 586 AERO addresses that embed an IPv6 prefix can be statelessly 587 transformed into an IPv6 Subnet Router Anycast address. For example, 588 for the AERO address fe80::2001:db8:2000:3000 the corresponding 589 Subnet Router Anycast address is 2001:db8:2000:3000::. In the same 590 way, for the IPv6 Subnet Router Anycast address 2001:db8:1:2:: the 591 corresponding AERO address is fe80::2001:db8:1:2. In other words, 592 the low-order 64 bits of an AERO address can be used as the high- 593 order 64 bits of a Subnet Router Anycast address, and vice-versa. 595 The IPv6 Subnet Router Anycast address corresponding to an AERO 596 address is used as the destination address for forwarding route 597 optimization control messages via a Relay acting as a standard IPv6 598 router. The source address used in these control messages is the 599 AERO Server Subnet Router Anycast Address taken from a reserved 600 Unique Local Address (ULA) prefix [RFC4389] for the AERO link (for 601 example, for the ULA prefix fd00:db8::/64 the AERO Server Subnet 602 Router Anycast Address is fd00:db8::). See Section 3.15 for further 603 details. 605 3.5. AERO Interface Characteristics 607 AERO interfaces use encapsulation (see: Section 3.9) to exchange 608 packets with neighbors attached to the AERO link. 610 AERO interfaces maintain a neighbor cache for tracking per-neighbor 611 state the same as for any interface. AERO interfaces use ND messages 612 including Neighbor Solicitation (NS), Neighbor Advertisement (NA), 613 Router Solicitation (RS), Router Advertisement (RA) and Redirect for 614 neighbor cache management. AERO interfaces use RS/RA messages with 615 an embedded PD message (e.g., see: [I-D.templin-6man-dhcpv6-ndopt]). 616 AERO interfaces include routing information in ND messages to support 617 route optimization. 619 AERO interface ND messages include one or more Source/Target Link- 620 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | Length = 5 |X| Reserved | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Interface ID | UDP Port Number | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | | 630 + + 631 | | 632 + IP Address + 633 | | 634 + + 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 647 Format 649 In this format: 651 o Type is set to '1' for SLLAO or '2' for TLLAO. 653 o Length is set to the constant value '5' (i.e., 5 units of 8 654 octets). 656 o X (proXy) is set to '1' in an S/TLLAO if the address corresponds 657 to a Proxy; otherwise, X is set to '0'. 659 o Reserved is set to the value '0' on transmission and ignored on 660 receipt. 662 o Interface ID is set to a 16-bit integer value corresponding to an 663 underlying interface of the AERO node. The value 255 is reserved 664 for Server-based route optimization (see: Section 3.15.8). 666 o UDP Port Number and IP Address are set to the addresses used by 667 the AERO node when it sends encapsulated packets over the 668 specified underlying interface (or to '0' when the addresses are 669 left unspecified). When UDP is not used as part of the 670 encapsulation, UDP Port Number is set to '0'. When the 671 encapsulation IP address family is IPv4, IP Address is formed as 672 an IPv4-mapped IPv6 address as specified in Section 3.4. 674 o P(i) is a set of 64 Preference values that correspond to the 64 675 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 676 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 677 ("medium") or '3' ("high") to indicate a QoS preference level for 678 packet forwarding purposes. 680 AERO interfaces may be configured over multiple underlying interface 681 connections to underlying links. For example, common mobile handheld 682 devices have both wireless local area network ("WLAN") and cellular 683 wireless links. These links are typically used "one at a time" with 684 low-cost WLAN preferred and highly-available cellular wireless as a 685 standby. In a more complex example, aircraft frequently have many 686 wireless data link types (e.g. satellite-based, cellular, 687 terrestrial, air-to-air directional, etc.) with diverse performance 688 and cost properties. 690 A Client's underlying interfaces are classified as follows: 692 o Native interfaces connect to the open Internetwork, and have a 693 global IP address that is reachable from any open Internetwork 694 correspondent. 696 o NAT'ed interfaces connect to a closed network that is separated 697 from the open Internetwork by a Network Address Translator (NAT). 698 The NAT does not participate in any AERO control message 699 signaling, but the AERO Server can issue AERO control messages on 700 behalf of the Client. 702 o VPN'ed interfaces use security encapsulation over the Internetwork 703 to a Virtual Private Network (VPN) gateway that also acts as an 704 AERO Server. As with NAT'ed links, the AERO Server can issue 705 control messages on behalf of the Client. 707 o Proxy'ed interfaces connect to a closed network that is separated 708 from the open Internetwork by an AERO Proxy. Unlike NAT'ed and 709 VPN'ed interfaces, the AERO Proxy (rather than the Server) can 710 issue control message on behalf of the Client. 712 o Direct interfaces connect the Client directly to a peer without 713 crossing any networked paths. An example is a line-of-sight link 714 between a remote pilot and an unmanned aircraft. 716 If a Client's multiple underlying interfaces are used "one at a time" 717 (i.e., all other interfaces are in standby mode while one interface 718 is active), then ND messages include only a single S/TLLAO with 719 Interface ID set to a constant value. In that case, the Client would 720 appear to have a single underlying interface but with a dynamically 721 changing link-layer address. 723 If the Client has multiple active underlying interfaces, then from 724 the perspective of ND it would appear to have multiple link-layer 725 addresses. In that case, ND messages MAY include multiple S/TLLAOs 726 -- each with an Interface ID that corresponds to a specific 727 underlying interface of the AERO node. 729 When the Client includes an S/TLLAO for an underlying interface for 730 which it is aware that there is a NAT or Proxy on the path to the 731 Server, or when a node includes an S/TLLAO solely for the purpose of 732 announcing new QoS preferences, the node sets both UDP Port Number 733 and IP Address to 0 to indicate that the addresses are unspecified. 735 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 736 correspond to the AERO node's underlying interface used to transmit 737 the message. 739 3.6. AERO Interface Initialization 741 3.6.1. AERO Relay Behavior 743 When a Relay enables an AERO interface, it first assigns an 744 administratively-provisioned link-local address fe80::ID to the 745 interface. Each fe80::ID address MUST be unique among all AERO nodes 746 on the link. The Relay then engages in a dynamic routing protocol 747 session with one or more Servers and all other Relays on the link 748 (see: Section 3.3), and advertises its assigned ASPs into the native 749 Internetwork. 751 Each Relay subsequently maintains an IP forwarding table entry for 752 each active ACP covered by its ASP(s), and maintains neighbor cache 753 entries for all Servers on the link. 755 3.6.2. AERO Server Behavior 757 When a Server enables an AERO interface, it assigns an 758 administratively-provisioned link-local address fe80::ID the same as 759 for Relays. The Server further configures a service to facilitate PD 760 exchanges with AERO Clients. The Server maintains neighbor cache 761 entries for one or more Relays on the link, and manages per-Client 762 neighbor cache entries and IP forwarding table entries based on 763 control message exchanges. Each Server also engages in a dynamic 764 routing protocol with their neighboring Relays (see: Section 3.3). 766 When the Server receives an NS/RS message from a Client on the AERO 767 interface it authenticates the message and returns an NA/RA message. 768 The Server further provides a simple link-layer conduit between AERO 769 interface neighbors. In particular, when a packet sent by a source 770 Client arrives on the Server's AERO interface and is destined to 771 another AERO node, the Server forwards the packet from within the 772 AERO interface driver at the link layer without ever disturbing the 773 network layer. 775 3.6.3. AERO Client Behavior 777 When a Client enables an AERO interface, it sends RS messages with PD 778 "Solicit" options over an underlying interface using the prefix- 779 solicitation address as the source network layer address and all- 780 routers [RFC4861] as the destination network layer address to obtain 781 ACPs from one or more AERO Servers. Each Server processes the 782 message and returns an RA message with a PD "Reply" option with the 783 Server's link-layer address as the source and the base AERO address 784 as the destination network layer addresses. In this way, the ND/PD 785 control messages securely perform all autoconfiguration operations in 786 a single request/response exchange. 788 After the initial ND/PD message exchange, the Client can register 789 additional underlying interfaces with the Server by sending an RS 790 message over each underlying interface using its base AERO address as 791 the source network layer address and without including a PD option. 792 The Server will update its neighbor cache entry for the Client and 793 return an RA message. 795 The Client maintains a neighbor cache entry for each of its Servers 796 and each of its active correspondent Clients. When the Client 797 receives ND messages on the AERO interface it updates or creates 798 neighbor cache entries, including link-layer address and QoS 799 preferences. 801 3.6.4. AERO Proxy Behavior 803 When a Proxy enables an AERO interface, it maintains per-Client proxy 804 neighbor cache entries based on control message exchanges. Proxies 805 forward packets between their associated Clients and the Clients' 806 associated Servers. 808 When the Proxy receives an RS message from a Client in the secured 809 enclave, it creates an incomplete proxy neighbor cache entry and 810 forwards the message to a Server selected by the Client while using 811 its own link-layer address as the source address. When the Server 812 returns an RA message, the Proxy completes the proxy neighbor cache 813 entry based on autoconfiguration information in the RA and forwards 814 the RA to the Client while using its own link-layer address as the 815 source address. The Client, Server and Proxy will then have the 816 necessary state for managing the proxyed neighbor association. 818 3.7. AERO Interface Neighbor Cache Maintenance 820 Each AERO interface maintains a conceptual neighbor cache that 821 includes an entry for each neighbor it communicates with on the AERO 822 link, the same as for any IPv6 interface [RFC4861]. AERO interface 823 neighbor cache entries are said to be one of "permanent", "static", 824 "proxy" or "dynamic". 826 Permanent neighbor cache entries are created through explicit 827 administrative action; they have no timeout values and remain in 828 place until explicitly deleted. AERO Relays maintain permanent 829 neighbor cache entries for Servers on the link, and AERO Servers 830 maintain permanent neighbor cache entries for Relays. Each entry 831 maintains the mapping between the neighbor's fe80::ID network-layer 832 address and corresponding link-layer address. 834 Static neighbor cache entries are created and maintained through ND/ 835 PD exchanges as specified in Section 3.14, and remain in place for 836 durations bounded by ND/PD lifetimes. AERO Servers maintain static 837 neighbor cache entries for each of their associated Clients, and AERO 838 Clients maintain static neighbor cache entries for each of their 839 associated Servers. 841 Proxy neighbor cache entries are created and maintained by AERO 842 Proxies by gleaning information from Client/Server ND/PD exchanges, 843 and remain in place for durations bounded by ND/PD lifetimes. AERO 844 Proxies maintain proxy neighbor cache entries for each of their 845 associated Clients, and include pointers to the Client's current set 846 of Servers. 848 Dynamic neighbor cache entries are created or updated based on 849 receipt of route optimization messages as specified in Section 3.15, 850 and are garbage-collected when keepalive timers expire. AERO nodes 851 maintain dynamic neighbor cache entries for each of their active 852 correspondents with lifetimes based on ND messaging constants. 854 When a target AERO node receives a valid NS message with an AERO 855 source address, it returns an NA message and also creates or updates 856 a dynamic neighbor cache entry for the source network-layer and link- 857 layer addresses. The node then sets an "AcceptTime" variable in the 858 neighbor cache entry to ACCEPT_TIME seconds and uses this value to 859 determine whether packets received from the correspondent can be 860 accepted. The node resets AcceptTime when it receives a new ND 861 message, and otherwise decrements AcceptTime while no ND messages 862 have been received. It is RECOMMENDED that ACCEPT_TIME be set to the 863 default constant value 40 seconds to allow a 10 second window so that 864 the AERO route optimization procedure can converge before AcceptTime 865 decrements below FORWARD_TIME (see below). 867 When a source AERO node receives a valid NA message with an AERO 868 source address that matches its NS message, it creates or updates a 869 dynamic neighbor cache entry for the target network-layer and link- 870 layer addresses. The node then sets a "ForwardTime" variable in the 871 neighbor cache entry to FORWARD_TIME seconds and uses this value to 872 determine whether packets can be forwarded directly to the 873 correspondent, i.e., instead of via a default route. The node resets 874 ForwardTime when it receives a new NA, and otherwise decrements 875 ForwardTime while no further NA messages have been received. It is 876 RECOMMENDED that FORWARD_TIME be set to the default constant value 30 877 seconds to match the default REACHABLE_TIME value specified in 878 [RFC4861]. 880 The node also sets a "MaxRetry" variable to MAX_RETRY to limit the 881 number of keepalives sent when a correspondent may have gone 882 unreachable. It is RECOMMENDED that MAX_RETRY be set to 3 the same 883 as described for address resolution in Section 7.3.3 of [RFC4861]. 885 Different values for ACCEPT_TIME, FORWARD_TIME and MAX_RETRY MAY be 886 administratively set, if necessary, to better match the AERO link's 887 performance characteristics; however, if different values are chosen, 888 all nodes on the link MUST consistently configure the same values. 889 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 890 sufficiently longer than FORWARD_TIME to allow the AERO route 891 optimization procedure to converge. 893 When there may be a NAT between the Client and the Server, or if the 894 path from the Client to the Server should be tested for reachability, 895 the Client can send periodic RS messages to the Server without a PD 896 option to receive RA replies. The RS/RA messaging will keep NAT 897 state alive and test Server reachability without disturbing the PD 898 service. 900 3.8. AERO Interface Forwarding Algorithm 902 IP packets enter a node's AERO interface either from the network 903 layer (i.e., from a local application or the IP forwarding system) or 904 from the link layer (i.e., from the AERO tunnel virtual link). 905 Packets that enter the AERO interface from the network layer are 906 encapsulated and forwarded into the AERO link, i.e., they are 907 tunneled to an AERO interface neighbor. Packets that enter the AERO 908 interface from the link layer are either re-admitted into the AERO 909 link or forwarded to the network layer where they are subject to 910 either local delivery or IP forwarding. In all cases, the AERO 911 interface itself MUST NOT decrement the network layer TTL/Hop-count 912 since its forwarding actions occur below the network layer. 914 AERO interfaces may have multiple underlying interfaces and/or 915 neighbor cache entries for neighbors with multiple Interface ID 916 registrations (see Section 3.5). The AERO node uses each packet's 917 DSCP value to select an outgoing underlying interface based on the 918 node's own QoS preferences, and also to select a destination link- 919 layer address based on the neighbor's underlying interface with the 920 highest preference. If multiple outgoing interfaces and/or neighbor 921 interfaces have a preference of "high", the AERO node sends one copy 922 of the packet via each of the (outgoing / neighbor) interface pairs; 923 otherwise, the node sends a single copy of the packet via the 924 interface with the highest preference. AERO nodes keep track of 925 which underlying interfaces are currently "reachable" or 926 "unreachable", and only use "reachable" interfaces for forwarding 927 purposes. 929 The following sections discuss the AERO interface forwarding 930 algorithms for Clients, Proxies, Servers and Relays. In the 931 following discussion, a packet's destination address is said to 932 "match" if it is a non-link-local address with a prefix covered by an 933 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 934 the same as an administratively-provisioned link-local address. 936 3.8.1. Client Forwarding Algorithm 938 When an IP packet enters a Client's AERO interface from the network 939 layer the Client searches for a dynamic neighbor cache entry that 940 matches the destination. If there is a match, the Client uses one or 941 more "reachable" link-layer addresses in the entry as the link-layer 942 addresses for encapsulation and admits the packet into the AERO link. 943 Otherwise, the Client uses the link-layer address in a static 944 neighbor cache entry for a Server as the encapsulation address 945 (noting that there may be a Proxy on the path to the real Server). 947 When an IP packet enters a Client's AERO interface from the link- 948 layer, if the destination matches one of the Client's ACPs or link- 949 local addresses the Client decapsulates the packet and delivers it to 950 the network layer. Otherwise, the Client drops the packet and MAY 951 return a network-layer ICMP Destination Unreachable message subject 952 to rate limiting (see: Section 3.13). 954 3.8.2. Proxy Forwarding Algorithm 956 When the Proxy receives a packet from a Client within the secured 957 enclave, the Proxy searches for a dynamic neighbor cache entry that 958 matches the destination. If there is a match, the Proxy uses one or 959 more "reachable" link-layer addresses in the entry as the link-layer 960 addresses for encapsulation and admits the packet into the AERO link. 961 Otherwise, the Proxy uses the link-layer address for one of the 962 Client's Servers as the encapsulation address. 964 When the Proxy receives a packet from an AERO interface neighbor, it 965 searches for a proxy neighbor cache entry for a Client within the 966 secured enclave that matches the destination. If there is a match, 967 the Proxy forwards the packet to the Client. Otherwise, the Proxy 968 returns the packet to the neighbor, i.e., by reversing the source and 969 destination link-layer addresses. 971 3.8.3. Server Forwarding Algorithm 973 When an IP packet enters a Server's AERO interface from the network 974 layer, the Server searches for a static neighbor cache entry for a 975 Client that matches the destination. If there is a match, the Server 976 uses one or more link-layer addresses in the entry as the link-layer 977 addresses for encapsulation and admits the packet into the AERO link. 978 Otherwise, the Server uses the link-layer address in a permanent 979 neighbor cache entry for a Relay (selected through longest-prefix 980 match) as the link-layer address for encapsulation. 982 When an IP packet enters a Server's AERO interface from the link 983 layer, the Server processes the packet according to the network-layer 984 destination address as follows: 986 o if the destination matches one of the Server's own addresses the 987 Server decapsulates the packet and forwards it to the network 988 layer for local delivery. 990 o else, if the destination matches a static neighbor cache entry for 991 a Client the Server first determines whether the neighbor is the 992 same as the one it received the packet from. If so, the Server 993 drops the packet silently to avoid looping; otherwise, the Server 994 uses the neighbor's link-layer address(es) as the destination for 995 encapsulation and re-admits the packet into the AERO link. 997 o else, the Server uses the link-layer address in a neighbor cache 998 entry for a Relay (selected through longest-prefix match) as the 999 link-layer address for encapsulation. 1001 3.8.4. Relay Forwarding Algorithm 1003 When an IP packet enters a Relay's AERO interface from the network 1004 layer, the Relay searches its IP forwarding table for an ACP entry 1005 that matches the destination the same as for any IP router. If there 1006 is a match, the Relay uses the link-layer address in the 1007 corresponding neighbor cache entry as the link-layer address for 1008 encapsulation and forwards the packet to the AERO neighbor. 1009 Otherwise, the Relay drops the packet and returns a network-layer 1010 ICMP Destination Unreachable message subject to rate limiting (see: 1011 Section 3.13). 1013 When an IP packet enters a Relay's AERO interface from the link- 1014 layer, the Relay processes the packet as follows: 1016 o if the destination does not match an ASP, or if the destination 1017 matches one of the Relay's own addresses, the Relay decapsulates 1018 the packet and forwards it to the network layer where it will be 1019 subject to either IP forwarding or local delivery. 1021 o else, if the destination matches an ACP entry in the IP forwarding 1022 table the Relay first determines whether the neighbor is the same 1023 as the one it received the packet from. If so the Relay MUST drop 1024 the packet silently to avoid looping; otherwise, the Relay uses 1025 the neighbor's link-layer address as the destination for 1026 encapsulation and re-admits the packet into the AERO link. 1028 o else, the Relay drops the packet and returns an ICMP Destination 1029 Unreachable message subject to rate limiting (see: Section 3.13). 1031 3.8.5. Processing Return Packets 1033 When an AERO node receives a return packet such as generated by an 1034 AERO Proxy (see Section 3.8.2), it proceeds according to the AERO 1035 link trust basis. Namely, the return packets have the same trust 1036 profile as for link-layer Destination Unreachable messages. If the 1037 node has sufficient trust basis to accept link-layer Destination 1038 Unreachable messages, it can then process the return packet as 1039 described in the following paragraph. Otherwise, the node SHOULD 1040 drop the packet and treat it as an indication that a path may be 1041 failing, and MAY use NUD to test the path for reachability. 1043 If the node has sufficient trust basis to accept return packets, it 1044 searches for a dynamic neighbor cache entry that matches the 1045 destination. If there is a match, the neighbor marks the 1046 corresponding link-layer address as "unreachable", selects the next- 1047 highest priority "reachable" link-layer address in the entry as the 1048 link-layer address for encapsulation then (re)admits the packet into 1049 the AERO link. If there are no "reachable" link-layer addresses, the 1050 neighbor instead sets FowardTime in the dynamic neighbor cache entry 1051 to 0. If the source address corresponds to one of the neighbor's own 1052 addresses, the neighbor also forwards the packet to the corresponding 1053 Server; otherwise, it drops the packet. 1055 3.9. AERO Interface Encapsulation and Re-encapsulation 1057 AERO interfaces encapsulate IP packets according to whether they are 1058 entering the AERO interface from the network layer or if they are 1059 being re-admitted into the same AERO link they arrived on. This 1060 latter form of encapsulation is known as "re-encapsulation". 1062 The AERO interface encapsulates packets per the Generic UDP 1063 Encapsulation (GUE) procedures in 1064 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 1065 an alternate encapsulation format (see: Appendix A). For packets 1066 entering the AERO interface from the network layer, the AERO 1067 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 1068 [RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion 1069 Experienced" [RFC3168] values in the packet's IP header into the 1070 corresponding fields in the encapsulation IP header. For packets 1071 undergoing re-encapsulation, the AERO interface instead copies these 1072 values from the original encapsulation IP header into the new 1073 encapsulation header, i.e., the values are transferred between 1074 encapsulation headers and *not* copied from the encapsulated packet's 1075 network-layer header. (Note especially that by copying the TTL/Hop 1076 Limit between encapsulation headers the value will eventually 1077 decrement to 0 if there is a (temporary) routing loop.) For IPv4 1078 encapsulation/re-encapsulation, the AERO interface sets the DF bit as 1079 discussed in Section 3.12. 1081 When GUE encapsulation is used, the AERO interface next sets the UDP 1082 source port to a constant value that it will use in each successive 1083 packet it sends, and sets the UDP length field to the length of the 1084 encapsulated packet plus 8 bytes for the UDP header itself plus the 1085 length of the GUE header (or 0 if GUE direct IP encapsulation is 1086 used). For packets sent to a Server or Relay, the AERO interface 1087 sets the UDP destination port to 8060, i.e., the IANA-registered port 1088 number for AERO. For packets sent to a Client, the AERO interface 1089 sets the UDP destination port to the port value stored in the 1090 neighbor cache entry for this Client. The AERO interface then either 1091 includes or omits the UDP checksum according to the GUE 1092 specification. 1094 Clients normally use the IP address of the underlying interface as 1095 the encapsulation source address. If the underlying interface does 1096 not have an IP address, however, the Client uses an IP address taken 1097 from an ACP as the encapsulation source address (assuming the node 1098 has some way of injecting the ACP into the underlying network routing 1099 system). For IPv6 addresses, the Client normally uses the ACP Subnet 1100 Router Anycast address [RFC4291]. 1102 Encapsulation between Servers and Relays can use standard mechanisms 1103 such as Generic Routing Encapsulation (GRE) [RFC2784] and IPSec 1104 [RFC4301] so that Relays can be standard IP routers. The 1105 encapsulation format used for Server-to-Client and Client-to-Client 1106 tunneling can therefore be different than that used for Server-to- 1107 Relay tunneling. 1109 3.10. AERO Interface Decapsulation 1111 AERO interfaces decapsulate packets destined either to the AERO node 1112 itself or to a destination reached via an interface other than the 1113 AERO interface the packet was received on. Decapsulation is per the 1114 procedures specified for the appropriate encapsulation format. 1116 3.11. AERO Interface Data Origin Authentication 1118 AERO nodes employ simple data origin authentication procedures for 1119 encapsulated packets they receive from other nodes on the AERO link. 1120 In particular: 1122 o AERO Relays and Servers accept encapsulated packets with a link- 1123 layer source address that matches a permanent neighbor cache 1124 entry. 1126 o AERO Servers accept authentic encapsulated ND messages from 1127 Clients, and create or update a static neighbor cache entry for 1128 the Client based on the specific message type. 1130 o AERO Clients and Servers accept encapsulated packets if there is a 1131 static neighbor cache entry with a link-layer address that matches 1132 the packet's link-layer source address. 1134 o AERO Clients and Servers accept encapsulated packets if there is a 1135 dynamic neighbor cache entry with an AERO address that matches the 1136 packet's network-layer source address, with a link-layer address 1137 that matches the packet's link-layer source address, and with a 1138 non-zero AcceptTime. 1140 o AERO Proxies accept encapsulated packets if there is a proxy 1141 neighbor cache entry that matches the packet's network-layer 1142 destination address (i.e., the address of the Client) and link- 1143 layer source address (i.e., the address of one of the Client's 1144 Servers). When the proxy is configured to accept packets 1145 originating from any address in the open Internetwork however 1146 (e.g., from another Proxy), it omits the source address check. 1148 Note that this simple data origin authentication is effective in 1149 environments in which link-layer addresses cannot be spoofed. In 1150 other environments, each AERO message must include a signature that 1151 the recipient can use to authenticate the message origin, e.g., as 1152 for common VPN systems such as OpenVPN [OVPN]. In environments where 1153 end systems use end-to-end security, however, it may be sufficient to 1154 require signatures only for ND and ICMP control plane messages and 1155 omit signatures for data plane messages. 1157 3.12. AERO Interface Packet Size Issues 1159 The AERO interface is the node's attachment to the AERO link. The 1160 AERO interface acts as a tunnel ingress when it sends a packet to an 1161 AERO link neighbor and as a tunnel egress when it receives a packet 1162 from an AERO link neighbor. AERO interfaces observe the packet 1163 sizing considerations for tunnels discussed in 1164 [I-D.ietf-intarea-tunnels] and as specified below. 1166 The Internet Protocol expects that IP packets will either be 1167 delivered to the destination or a suitable Packet Too Big (PTB) 1168 message returned to support the process known as IP Path MTU 1169 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1170 crafted for malicious purposes such as denial of service, or lost in 1171 the network [RFC2923]. This can be especially problematic for 1172 tunnels, where a condition known as a PMTUD "black hole" can result. 1173 For these reasons, AERO interfaces employ operational procedures that 1174 avoid interactions with PMTUD, including the use of fragmentation 1175 when necessary. 1177 AERO interfaces observe two different types of fragmentation. Source 1178 fragmentation occurs when the AERO interface (acting as a tunnel 1179 ingress) fragments the encapsulated packet into multiple fragments 1180 before admitting each fragment into the tunnel. Network 1181 fragmentation occurs when an encapsulated packet admitted into the 1182 tunnel by the ingress is fragmented by an IPv4 router on the path to 1183 the egress. Note that a packet that incurs source fragmentation may 1184 also incur network fragmentation. 1186 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1187 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1188 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1189 for IPv4 even if encapsulated packets may incur network 1190 fragmentation. 1192 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1193 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1194 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1195 than the IPv4 minimum). 1197 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1198 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1199 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1200 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1201 configure a Maximum Segment Unit (MSU) as the maximum-sized 1202 encapsulated packet that the ingress can inject into the tunnel 1203 without source fragmentation. The MSU value MUST NOT be larger than 1204 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1205 operational assurance that a larger size can traverse the link along 1206 all paths. 1208 All AERO nodes MUST configure the same MTU/MSU values for reasons 1209 cited in [RFC3819][RFC4861]; in particular, multicast support 1210 requires a common MTU value among all nodes on the link. All AERO 1211 nodes MUST configure an MRU large enough to reassemble packets up to 1212 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1213 enough MRU MUST NOT enable an AERO interface. 1215 The network layer proceeds as follow when it presents an IP packet to 1216 the AERO interface. For each IPv4 packet that is larger than the 1217 AERO interface MTU and with the DF bit set to 0, the network layer 1218 uses IPv4 fragmentation to break the packet into a minimum number of 1219 non-overlapping fragments where the first fragment is no larger than 1220 the MTU and the remaining fragments are no larger than the first. 1221 For all other IP packets, if the packet is larger than the AERO 1222 interface MTU, the network layer drops the packet and returns a PTB 1223 message to the original source. Otherwise, the network layer admits 1224 each IP packet or fragment into the AERO interface. 1226 For each IP packet admitted into the AERO interface, the interface 1227 (acting as a tunnel ingress) encapsulates the packet. If the 1228 encapsulated packet is larger than the AERO interface MSU the ingress 1229 source-fragments the encapsulated packet into a minimum number of 1230 non-overlapping fragments where the first fragment is no larger than 1231 the MSU and the remaining fragments are no larger than the first. 1232 The ingress then admits each encapsulated packet or fragment into the 1233 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1234 header in case any network fragmentation is necessary. The 1235 encapsulated packets will be delivered to the egress, which 1236 reassembles them into a whole packet if necessary. 1238 Several factors must be considered when fragmentation is needed. For 1239 AERO links over IPv4, the IP ID field is only 16 bits in length, 1240 meaning that fragmentation at high data rates could result in data 1241 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1242 AERO links over both IPv4 and IPv6, studies have also shown that IP 1243 fragments are dropped unconditionally over some network paths [I- 1244 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1245 issues could result in operational problems, the ingress SHOULD 1246 employ intermediate-layer source fragmentation (see: [RFC2764] and 1247 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1248 encapsulation headers to each fragment. Since the encapsulation 1249 fragment header reduces the room available for packet data, but the 1250 original source has no way to control its insertion, the ingress MUST 1251 include the fragment header length in the ENCAPS length even for 1252 packets in which the header is absent. 1254 3.13. AERO Interface Error Handling 1256 When an AERO node admits encapsulated packets into the AERO 1257 interface, it may receive link-layer or network-layer error 1258 indications. 1260 A link-layer error indication is an ICMP error message generated by a 1261 router in the underlying network on the path to the neighbor or by 1262 the neighbor itself. The message includes an IP header with the 1263 address of the node that generated the error as the source address 1264 and with the link-layer address of the AERO node as the destination 1265 address. 1267 The IP header is followed by an ICMP header that includes an error 1268 Type, Code and Checksum. Valid type values include "Destination 1269 Unreachable", "Time Exceeded" and "Parameter Problem" 1270 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1271 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1272 only emit packets that are guaranteed to be no larger than the IP 1273 minimum link MTU as discussed in Section 3.12.) 1275 The ICMP header is followed by the leading portion of the packet that 1276 generated the error, also known as the "packet-in-error". For 1277 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1278 much of invoking packet as possible without the ICMPv6 packet 1279 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1280 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1281 "Internet Header + 64 bits of Original Data Datagram", however 1282 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1283 ICMP datagram SHOULD contain as much of the original datagram as 1284 possible without the length of the ICMP datagram exceeding 576 1285 bytes". 1287 The link-layer error message format is shown in Figure 3 (where, "L2" 1288 and "L3" refer to link-layer and network-layer, respectively): 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 ~ ~ 1292 | L2 IP Header of | 1293 | error message | 1294 ~ ~ 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | L2 ICMP Header | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1298 ~ ~ P 1299 | IP and other encapsulation | a 1300 | headers of original L3 packet | c 1301 ~ ~ k 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1303 ~ ~ t 1304 | IP header of | 1305 | original L3 packet | i 1306 ~ ~ n 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 ~ ~ e 1309 | Upper layer headers and | r 1310 | leading portion of body | r 1311 | of the original L3 packet | o 1312 ~ ~ r 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1315 Figure 3: AERO Interface Link-Layer Error Message Format 1317 The AERO node rules for processing these link-layer error messages 1318 are as follows: 1320 o When an AERO node receives a link-layer Parameter Problem message, 1321 it processes the message the same as described as for ordinary 1322 ICMP errors in the normative references [RFC0792][RFC4443]. 1324 o When an AERO node receives persistent link-layer Time Exceeded 1325 messages, the IP ID field may be wrapping before earlier fragments 1326 awaiting reassembly have been processed. In that case, the node 1327 SHOULD begin including integrity checks and/or institute rate 1328 limits for subsequent packets. 1330 o When an AERO node receives persistent link-layer Destination 1331 Unreachable messages in response to encapsulated packets that it 1332 sends to one of its dynamic neighbor correspondents, the node 1333 SHOULD process the message as an indication that a path may be 1334 failing, and MAY initiate NUD over that path. If it receives 1335 Destination Unreachable messages on many or all paths, the node 1336 SHOULD set ForwardTime for the corresponding dynamic neighbor 1337 cache entry to 0 and allow future packets destined to the 1338 correspondent to flow through a default route. 1340 o When an AERO Client receives persistent link-layer Destination 1341 Unreachable messages in response to encapsulated packets that it 1342 sends to one of its static neighbor Servers, the Client SHOULD 1343 math the path as unusable and use another path. If it receives 1344 Destination Unreachable messages on many or all paths, the Client 1345 SHOULD associate with a new Server and send a PD "Release" message 1346 to the old Server as specified in Section 3.17.6. 1348 o When an AERO Server receives persistent link-layer Destination 1349 Unreachable messages in response to encapsulated packets that it 1350 sends to one of its static neighbor Clients, the Server SHOULD 1351 mark the path as unusable and use another path. If it receives 1352 Destination Unreachable messages on multiple paths, the Server 1353 should take no further actions unless it receives a PD "Release" 1354 message or if the PD lifetime expires. In that case, the Server 1355 MUST release the Client's delegated ACP, withdraw the ACP from the 1356 AERO routing system and delete the neighbor cache entry. 1358 o When an AERO Relay or Server receives link-layer Destination 1359 Unreachable messages in response to an encapsulated packet that it 1360 sends to one of its permanent neighbors, it treats the messages as 1361 an indication that the path to the neighbor may be failing. 1362 However, the dynamic routing protocol should soon reconverge and 1363 correct the temporary outage. 1365 When an AERO Relay receives a packet for which the network-layer 1366 destination address is covered by an ASP, if there is no more- 1367 specific routing information for the destination the Relay drops the 1368 packet and returns a network-layer Destination Unreachable message 1369 subject to rate limiting. The Relay writes the network-layer source 1370 address of the original packet as the destination address and uses 1371 one of its non link-local addresses as the source address of the 1372 message. 1374 When an AERO node receives an encapsulated packet for which the 1375 reassembly buffer it too small, it drops the packet and returns a 1376 network-layer Packet Too Big (PTB) message. The node first writes 1377 the MRU value into the PTB message MTU field, writes the network- 1378 layer source address of the original packet as the destination 1379 address of the message and determines the next hop to the 1380 destination. If the next hop is reached via the AERO interface, the 1381 node uses the IPv6 address "::" or the IPv4 address "0.0.0.0" as the 1382 source address of the message, then encapsulates the message and 1383 forwards it to the next hop within the AERO interface. Otherwise, 1384 the node uses one of its non link-local addresses as the source 1385 address of the message and forwards it via a link outside the AERO 1386 interface. 1388 When an AERO node receives any network-layer error message via the 1389 AERO interface, it examines the network-layer destination address. 1390 If the next hop toward the destination is via the AERO interface, the 1391 node re-encapsulates and forwards the message to the next hop within 1392 the AERO interface. Otherwise, if the network-layer source address 1393 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1394 writes one of its non link-local addresses as the source address, 1395 recalculates the IP and/or ICMP checksums then forwards the message 1396 via a link outside the AERO interface. 1398 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1400 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1401 coordinated as discussed in the following Sections. 1403 3.14.1. AERO ND/PD Service Model 1405 Each AERO Server configures a PD service to facilitate Client 1406 requests. Each Server is provisioned with a database of ACP-to- 1407 Client ID mappings for all Clients enrolled in the AERO system, as 1408 well as any information necessary to authenticate each Client. The 1409 Client database is maintained by a central administrative authority 1410 for the AERO link and securely distributed to all Servers, e.g., via 1411 the Lightweight Directory Access Protocol (LDAP) [RFC4511], via 1412 static configuration, etc. Therefore, no Server-to-Server PD state 1413 synchronization is necessary, and Clients can optionally hold 1414 separate PDs for the same ACPs from multiple Servers. In this way, 1415 Clients can associate with multiple Servers, and can receive new PDs 1416 from new Servers before releasing PDs received from existing Servers. 1417 This provides the Client with a natural fault-tolerance and/or load 1418 balancing profile. 1420 AERO Clients and Servers use ND messages to maintain neighbor cache 1421 entries. AERO Servers configure their AERO interfaces as advertising 1422 interfaces, and therefore send unicast RA messages with configuration 1423 information in response to a Client's RS message. The RS/RA 1424 messaging is conducted in the same fashion as specified in [RFC5214]. 1426 AERO Clients and Servers include PD messages as options in the RS/RA 1427 messages they exchange (see: [I-D.templin-6man-dhcpv6-ndopt]). 1428 Client-initiated PD options are included in RS messages, and Server- 1429 initiated PD options are included in RA messages. The unified ND/PD 1430 messages are exchanged between Client and Server according to the 1431 prefix management schedule determined by the PD service. The unified 1432 messages can be protected using SEcure Neighbor Discovery (SEND) 1433 [RFC3971]. 1435 On Some AERO links, PD arrangements may be through some out-of-band 1436 service such as network management, static configuration, etc. In 1437 those cases, AERO nodes can use simple RS/RA message exchanges with 1438 no explicit PD options. Instead, the RS/RA messages use AERO 1439 addresses as a means of representing the delegated prefixes, e.g., if 1440 a message includes a source address of "fe80::2001:db8:1:2" then the 1441 recipient can infer that the sender holds the prefix delegation 1442 "2001:db8:1:2::/64". 1444 The following sections specify the Client and Server behavior. 1446 3.14.2. AERO Client Behavior 1448 AERO Clients discover the link-layer addresses of AERO Servers via 1449 static configuration (e.g., from a flat-file map of Server addresses 1450 and locations), or through an automated means such as Domain Name 1451 System (DNS) name resolution [RFC1035]. In the absence of other 1452 information, the Client resolves the DNS Fully-Qualified Domain Name 1453 (FQDN) "linkupnetworks.[domainname]" where "linkupnetworks" is a 1454 constant text string and "[domainname]" is a DNS suffix for the 1455 Client's underlying interface (e.g., "example.com"). After 1456 discovering the link-layer addresses, the Client associates with one 1457 or more of the corresponding Servers. 1459 To associate with a Server, the Client acts as a requesting router to 1460 request ACPs through a combined ND/PD message exchange. The Client 1461 includes a PD "Solicit" message as an ND option in an RS message with 1462 the prefix-solicitation address as the IPv6 source address, all- 1463 routers multicast as the IPv6 destination address, the address of the 1464 Client's underlying interface as the link-layer source address and 1465 the link-layer address of the Server as the link-layer destination 1466 address. (If the Client's underlying interface does not have an IP 1467 address, the Client can use the ACP's Subnet Router Anycast address 1468 as the link-layer source address.) 1469 The Client next includes a "Client Identifier" and an "IA_PD" (i.e., 1470 prefix request) code in the PD "Solicit" message. If the Client is 1471 pre-provisioned with ACPs associated with the AERO service, it MAY 1472 also include the ACPs in the "IA_PD" option to indicate its 1473 preferences to the Server. The Client finally includes any 1474 additional PD codes (e.g., "Rapid Commit"). 1476 The Client next includes one or more SLLAOs in the RS message 1477 formatted as described in Section 3.5 to register its link-layer 1478 address(es) with the Server. The first SLLAO MUST correspond to the 1479 underlying interface over which the Client will send the RS message. 1480 The Client MAY include additional SLLAOs specific to other underlying 1481 interfaces, but if so it MUST have assurance that there will be no 1482 NATs or Proxies on the paths to the Server via those interfaces. 1483 (Otherwise, the Client can register additional link-layer addresses 1484 with the Server by sending subsequent NS/RS messages via different 1485 underlying interfaces after the initial RS/RA exchange). 1487 The Client then sends the RS message to the AERO Server and waits for 1488 an RA message reply (see Section 3.14.3) while retrying MAX_RETRY 1489 times until an RA is received. If no RA is received, or if it 1490 receives an RA with Router Lifetime set to 0 and/or a "Reply" with no 1491 ACPs, the Client SHOULD discontinue autoconfiguration attempts 1492 through this Server and try another Server. Otherwise, the Client 1493 processes the ACPs in the embedded "Reply" message. 1495 Next, the Client creates a static neighbor cache entry with the 1496 Server's link-local address as the network-layer address and the 1497 Server's encapsulation source address as the link-layer address. The 1498 Client then autoconfigures AERO addresses for each of the delegated 1499 ACPs and assigns them to the AERO interface. 1501 The Client next examines the P bit in the RA message flags field 1502 [RFC5175]. If the P bit value was 1, the Client assumes that there 1503 is a NAT or Proxy on the path to the Server via the interface over 1504 which it sent the RS message. In that case, the Client sets UDP Port 1505 Number and IP Address to 0 in the S/TLLAOs of any subsequent ND 1506 messages it sends to the Server over that link. 1508 The Client also caches any ASPs included in Route Information Options 1509 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1510 the MTU/MSU values in the MTU options to its AERO interface while 1511 configuring an appropriate MRU. This configuration information 1512 applies to the AERO link as a whole, and all AERO nodes will receive 1513 the same values. 1515 Following autoconfiguration, the Client sub-delegates the ACPs to its 1516 attached EUNs and/or the Client's own internal virtual interfaces as 1517 described in [I-D.templin-v6ops-pdhost]. The Client subsequently 1518 maintains its ACP delegations through each of its Servers by sending 1519 RS "Renew", "Rebind", and/or "Release" messages. The Server will in 1520 turn send RA "Reply" messages. 1522 After the Client registers its Interface IDs and their associated 1523 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1524 Interface ID registrations, e.g., if an underlying interface changes 1525 address or becomes unavailable, if QoS preferences change, etc. To 1526 do so, the Client prepares an unsolicited NA message to send over any 1527 available underlying interface. The source and target address of the 1528 NA message are set to the Client's AERO address, and the destination 1529 address is set to all-nodes multicast. The NA MUST include a TLLAO 1530 specific to the selected available underlying interface as the first 1531 TLLAO and MAY include any additional TLLAOs specific to other 1532 underlying interfaces. The Client includes fresh 'P(i)' values in 1533 each TLLAO to update the Server's neighbor cache entry. If the 1534 Client wishes to update 'P(i)' values without updating the link-layer 1535 address, it sets the UDP Port Number and IP Address fields to 0. If 1536 the Client wishes to disable the interface, it sets all 'P(i)' values 1537 to '0' ("disabled"). 1539 If the Client wishes to discontinue use of a Server it issues an RS 1540 "Release" message. When the Server processes the message, it 1541 releases the ACP, deletes its neighbor cache entry for the Client, 1542 withdraws the IP route from the routing system and returns an RA 1543 "Reply". 1545 3.14.3. AERO Server Behavior 1547 AERO Servers act as IPv6 routers and support a PD service on their 1548 AERO links. AERO Servers arrange to add their encapsulation layer IP 1549 addresses (i.e., their link-layer addresses) to a static map of 1550 Server addresses for the link and/or the DNS resource records for the 1551 FQDN "linkupnetworks.[domainname]" before entering service. 1553 When an AERO Server receives a prospective Client's RS "Solicit" 1554 message on its AERO interface, and the Server is too busy, it SHOULD 1555 return an immediate RA "Reply" message with no ACPs and with Router 1556 Lifetime set to 0. Otherwise, the Server authenticates the RS 1557 message and processes the embedded "Solicit" option. The Server 1558 first determines the correct ACPs to delegate to the Client by 1559 searching the Client database. When the Server delegates the ACPs, 1560 it also creates an IP forwarding table entry for each ACP so that the 1561 AERO BGP-based routing system will propagate the ACPs to the Relays 1562 that aggregate the corresponding ASP (see: Section 3.3). 1564 Next, the Server prepares an RA "Reply" message that includes the 1565 delegated ACPs. For IPv4 ACPs, the ACP is in IPv4-mapped IPv6 1566 address format and with prefix length set as specified in 1567 Section 3.4. The Server then prepares an RA "Reply" message using 1568 its link-local address (i.e., fe80::ID) as the network-layer source 1569 address, the Client's base AERO address from the first ACP as the 1570 network-layer destination address, the Server's link-layer address as 1571 the source link-layer address, and the source link-layer address of 1572 the RS message as the destination link-layer address. The Server 1573 next sets the P flag in the RA message flags field [RFC5175] to 1 if 1574 the source link-layer address in the RS message was different than 1575 the address in the first SLLAO to indicate that there is a NAT or 1576 Proxy on the path; otherwise it sets P to 0. The Server then 1577 includes one or more RIOs that encode the ASPs for the AERO link. 1578 The Server also includes two MTU options - the first MTU option 1579 includes the MTU for the link and the second MTU option includes the 1580 MSU for the link (see Section 3.12). The Server finally sends the RA 1581 "Reply" message to the Client. 1583 The Server next creates a static neighbor cache entry for the Client 1584 using the base AERO address as the network-layer address and with 1585 lifetime set to no more than the smallest PD lifetime. Next, the 1586 Server updates the neighbor cache entry link-layer address(es) by 1587 recording the information in each SLLAO option indexed by the 1588 Interface ID and including the UDP port number, IP address and P(i) 1589 values. For the first SLLAO in the list, however, the Server records 1590 the actual encapsulation source UDP and IP addresses instead of those 1591 that appear in the SLLAO in case there was a NAT or Proxy in the 1592 path. 1594 After the initial RS/RA exchange, the AERO Server maintains the 1595 neighbor cache entry for the Client until the PD lifetimes expire. 1596 If the Client issues an RS "Renew", the Server extends the PD 1597 lifetimes. If the Client issues an RS "Release", or if the Client 1598 does not issue a "Renew" before the lifetime expires, the Server 1599 deletes the neighbor cache entry for the Client and withdraws the IP 1600 routes from the AERO routing system. The Server processes these and 1601 any other Client PD messages, and returns an RA "Reply". The Server 1602 may also issue an unsolicited RA "Reconfigure" message to inform the 1603 Client that it needs to renegotiate its PDs. 1605 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1607 When DHCPv6 is used as the PD service, AERO Clients and Servers are 1608 always on the same link (i.e., the AERO link) from the perspective of 1609 DHCPv6. However, in some implementations the DHCPv6 server and ND 1610 function may be located in separate modules. In that case, the 1611 Server's AERO interface driver module can act as a Lightweight DHCPv6 1612 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from the 1613 DHCPv6 server module. 1615 When the LDRA receives an authentic RS message, it extracts the PD 1616 message option and wraps it in IPv6/UDP headers. It sets the IPv6 1617 source address to the source address of the RS message, sets the IPv6 1618 destination address to 'All_DHCP_Relay_Agents_and_Servers' and sets 1619 the UDP fields to values that will be understood by the DHCPv6 1620 server. 1622 The LDRA then wraps the message in a Relay-Forward message header and 1623 includes an Interface-ID option that includes enough information to 1624 allow the LDRA to forward the resulting Reply message back to the 1625 Client (e.g., the Client's link-layer addresses, a security 1626 association identifier, etc.). The LDRA also wraps the information 1627 in all of the SLLAO options from the RS message into the Interface-ID 1628 option, then forwards the message to the DHCPv6 server. 1630 When the DHCPv6 server prepares a Reply message, it wraps the message 1631 in a Relay-Reply message and echoes the Interface-ID option. The 1632 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1633 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1634 delivers the DHCPv6 message to be wrapped into an RA response to the 1635 Client. The Server uses the information in the Interface ID option 1636 to prepare the RA message and to cache the link-layer addresses taken 1637 from the SLLAOs echoed in the Interface-ID option. 1639 3.15. AERO Interface Route Optimization 1641 When a source Client forwards packets to a prospective correspondent 1642 Client within the same AERO link domain (i.e., one for which the 1643 packet's destination address is covered by an ASP), the source Client 1644 MAY initiate an AERO link route optimization procedure on behalf of 1645 any of its native underlying interfaces. The procedure is based on 1646 an exchange of IPv6 ND messages using a chain of AERO Servers and 1647 Relays as a trust basis. 1649 Although the Client is responsible for initiating route optimization, 1650 the Server is the policy enforcement point that determines whether 1651 route optimization is permitted. For example, on some AERO links 1652 route optimization would allow traffic to circumvent critical 1653 network-based traffic inspection points. In those cases, the Server 1654 can simply discard any route optimization messages instead of 1655 forwarding them. 1657 The following sections specify the AERO link route optimization 1658 procedure. 1660 3.15.1. Reference Operational Scenario 1662 Figure 4 depicts the AERO link route optimization reference 1663 operational scenario, using IPv6 addressing as the example (while not 1664 shown, a corresponding example for IPv4 addressing can be easily 1665 constructed). The figure shows an AERO Relay ('R1'), two AERO 1666 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1667 IPv6 hosts ('H1', 'H2'): 1669 +--------------+ +--------------+ +--------------+ 1670 | Server S1 | | Relay R1 | | Server S2 | 1671 +--------------+ +--------------+ +--------------+ 1672 fe80::2 fe80::1 fe80::3 1673 L2(S1) L2(R1) L2(S2) 1674 | | | 1675 X-----+-----+------------------+-----------------+----+----X 1676 | AERO Link | 1677 L2(C1) L2(C2) 1678 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1679 +--------------+ +--------------+ 1680 |AERO Client C1| |AERO Client C2| 1681 +--------------+ +--------------+ 1682 2001:DB8:0::/48 2001:DB8:1::/48 1683 | | 1684 .-. .-. 1685 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1686 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 1687 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 1688 `-(______)-' +-------+ +-------+ `-(______)-' 1690 Figure 4: AERO Reference Operational Scenario 1692 In Figure 4, Relay ('R1') assigns the administratively-provisioned 1693 link-local address fe80::1 to its AERO interface with link-layer 1694 address L2(R1), Server ('S1') assigns the address fe80::2 with link- 1695 layer address L2(S1), and Server ('S2') assigns the address fe80::3 1696 with link-layer address L2(S2). Servers ('S1') and ('S2') next 1697 arrange to add their link-layer addresses to a published list of 1698 valid Servers for the AERO link. 1700 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in an ND/PD 1701 exchange via AERO Server ('S1') then assigns the address 1702 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1703 L2(C1). Client ('C1') configures a default route and neighbor cache 1704 entry via the AERO interface with next-hop address fe80::2 and link- 1705 layer address L2(S1), then sub-delegates the ACP to its attached 1706 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1707 address 2001:db8:0::1. 1709 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in an ND/PD 1710 exchange via AERO Server ('S2') then assigns the address 1711 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1712 L2(C2). Client ('C2') configures a default route and neighbor cache 1713 entry via the AERO interface with next-hop address fe80::3 and link- 1714 layer address L2(S2), then sub-delegates the ACP to its attached 1715 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1716 address 2001:db8:1::1. 1718 3.15.2. Concept of Operations 1720 Again, with reference to Figure 4, when source host ('H1') sends a 1721 packet to destination host ('H2'), the packet is first forwarded over 1722 the source host's attached EUN to Client ('C1'). Client ('C1') then 1723 forwards the packet via its AERO interface to Server ('S1') and also 1724 sends an NS message toward Client ('C2') via Server ('S1'). 1726 Server ('S1') then forwards both the packet and the NS message out 1727 the same AERO interface toward Client ('C2') via Relay ('R1'). When 1728 Relay ('R1') receives the packet and NS message, it consults its 1729 forwarding table to discover Server ('S2') as the next hop toward 1730 Client ('C2'). Relay ('R1') then forwards both the packet and the NS 1731 message to Server ('S2'), which then forwards them to Client ('C2'). 1733 After Client ('C2') receives the NS message, it process the message 1734 and creates or updates a dynamic neighbor cache entry for Client 1735 ('C1'), then sends the NA response to the link-layer address of 1736 Server ('S2'). When Server ('S2') receives the NA message it 1737 forwards the NA on to Relay ('R1'), which forwards the message on to 1738 Server ('S1') which forwards the message on to Client ('C1'). 1740 After Client ('C1') receives the NA message, it processes the message 1741 and creates or updates a dynamic neighbor cache entry for Client 1742 ('C2'). Thereafter, forwarding of packets from Client ('C1') to 1743 Client ('C2') without involving any intermediate nodes is enabled. 1744 The mechanisms that support this exchange are specified in the 1745 following sections. 1747 3.15.3. Sending NS Messages 1749 When a Client forwards a packet with a source address from one of its 1750 ACPs toward a destination address covered by an ASP (i.e., toward 1751 another AERO Client connected to the same AERO link), the source 1752 Client MAY send an NS message forward toward the destination Client 1753 via the Server. 1755 In the reference operational scenario, when Client ('C1') forwards a 1756 packet toward Client ('C2'), it MAY also send an NS message forward 1757 toward Client ('C2'), subject to rate limiting (see Section 8.2 of 1758 [RFC4861]). Client ('C1') prepares the NS message as follows: 1760 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1761 layer address of Client ('C1')). 1763 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1764 link-layer address of Server ('S1')). 1766 o the network-layer source address is set to fe80::2001:db8:0:0 1767 (i.e., the base AERO address of Client ('C1')). 1769 o the network-layer destination address is set to the AERO address 1770 corresponding to the destination address of Client ('C2'). 1772 o the Type is set to 135. 1774 o the Target Address is set to the destination address of the packet 1775 that triggered route optimization. 1777 o the message includes one or more SLLAOs set to appropriate values 1778 for Client ('C1')'s native underlying interfaces. 1780 o the message includes one or more RIOs that include Client ('C1')'s 1781 ACPs [I-D.templin-6man-rio-redirect]. 1783 o the message SHOULD include a Timestamp option and a Nonce option. 1785 Note that the act of sending NS messages is cited as "MAY", since 1786 Client ('C1') may have advanced knowledge that the direct path to 1787 Client ('C2') would be unusable or otherwise undesirable. If the 1788 direct path later becomes unusable after the initial route 1789 optimization, Client ('C1') simply allows packets to again flow 1790 through Server ('S1'). 1792 3.15.4. Re-encapsulating and Relaying the NS 1794 When Server ('S1') receives an NS message from Client ('C1'), it 1795 first verifies that the SLLAOs in the NS are a proper subset of the 1796 link-layer addresses in Client ('C1')'s neighbor cache entry. If the 1797 Client's SLLAOs are not acceptable, Server ('S1') discards the 1798 message. Otherwise, Server ('S1') verifies that Client ('C1') is 1799 authorized to use the ACPs encoded in the RIOs of the NS and discards 1800 the NS if verification fails. 1802 Server ('S1') then examines the network-layer destination address of 1803 the NS to determine the next hop toward Client ('C2') by searching 1804 for the AERO address in the neighbor cache. Since Client ('C2') is 1805 not one of its neighbors, Server ('S1') then inserts an additional 1806 layer of encapsulation between the outer IP header and the NS message 1807 body. This new "mid-layer" IP header uses the AERO Server Subnet 1808 Router Anycast address as the source address and the Subnet Router 1809 Anycast address corresponding to the Client ("C2")'s AERO address as 1810 the destination address (in this case, C2's Subnet Router Anycast 1811 address if 2001:db8:1:0::). The Server then relays this double- 1812 encapsulated NS message via Relay ('R1') by changing the link-layer 1813 source address of the message to 'L2(S1)' and changing the link-layer 1814 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1815 re-encapsulated message to Relay ('R1') without decrementing the 1816 network-layer TTL/Hop Limit field. 1818 When Relay ('R1') receives the double-encapsulated NS message from 1819 Server ('S1') it discards the outer IP header and determines that 1820 Server ('S2') is the next hop toward Client ('C2') by consulting its 1821 standard IP forwarding table for the Subnet Router Anycast 1822 destination address. Relay ('R1') then encapsulates and forwards the 1823 message to Server ('S2') the same as for any IP router. 1825 When Server ('S2') receives the double-encapsulated NS message from 1826 Relay ('R1') it removes the mid-layer IP header and determines that 1827 Client ('C2') is a neighbor by consulting its neighbor cache for 1828 Client ('C2')'s AERO address. Server ('S2') then re-encapsulates the 1829 NS while changing the link-layer source address to 'L2(S2)' and 1830 changing the link-layer destination address to 'L2(C2)'. Server 1831 ('S2') then forwards the message to Client ('C2'). 1833 3.15.5. Processing NSs and Sending NAs 1835 When Client ('C2') receives the NS message, it accepts the NS only if 1836 the message has a link-layer source address of one of its Servers 1837 (e.g., L2(S2)). Client ('C2') further accepts the message only if it 1838 is willing to serve as a route optimization target. 1840 In the reference operational scenario, when Client ('C2') receives a 1841 valid NS message, it either creates or updates a dynamic neighbor 1842 cache entry that stores the source address of the message as the 1843 network-layer address of Client ('C1') , stores the link-layer 1844 addresses found in the SLLAOs as the link-layer addresses of Client 1845 ('C1'), and stores the ACPs encoded in the RIOs of the NS as the ACPs 1846 for Client ('C1'). Client ('C2') then sets AcceptTime for the 1847 neighbor cache entry to ACCEPT_TIME. 1849 After processing the message, Client ('C2') prepares an NA message 1850 response as follows: 1852 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1853 layer address of Client ('C2')). 1855 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1856 link-layer address of Server ('S2')). 1858 o the network-layer source address is set to fe80::2001:db8:1:0 1859 (i.e., the base AERO address of Client ('C2')). 1861 o the network-layer destination address is set to fe80::2001:db8:0:0 1862 (i.e., the base AERO address of Client ('C1')). 1864 o the Type is set to 136. 1866 o The Target Address is set to the Target Address field in the NS 1867 message. 1869 o the message includes one or more TLLAOs set to appropriate values 1870 for Client ('C2')'s native underlying interfaces. 1872 o the message includes one or more RIOs that include Client ('C2')'s 1873 ACPs [I-D.templin-6man-rio-redirect]. 1875 o the message SHOULD include a Timestamp option and MUST echo the 1876 Nonce option received in the NS (i.e., if a Nonce option is 1877 included). 1879 Client ('C2') then sends the NA message to Server ('S2'). 1881 3.15.6. Re-encapsulating and Relaying NAs 1883 When Server ('S2') receives an NA message from Client ('C2'), it 1884 first verifies that the TLLAOs in the NA are a proper subset of the 1885 Interface IDs in Client ('C2')'s neighbor cache entry. If the 1886 Client's TLLAOs are not acceptable, Server ('S2') discards the 1887 message. Otherwise, Server ('S2') verifies that Client ('C2') is 1888 authorized to use the ACPs encoded in the RIOs of the NA message. If 1889 validation fails, Server ('S2') discards the NA. 1891 Server ('S2') then examines the network-layer destination address of 1892 the NA to determine the next hop toward Client ('C1') by searching 1893 for the AERO address in the neighbor cache. Since Client ('C1') is 1894 not one of its neighbors, Server ('S2') then inserts an additional 1895 layer of encapsulation between the outer IP header and the NA message 1896 body. This new "mid-layer" IP header uses the AERO Server Subnet 1897 Router Anycast address as the source address and the Subnet Router 1898 Anycast address corresponding to the Client ("C1")'s AERO address as 1899 the destination address (in this case, C1's Subnet Router Anycast 1900 address if 2001:db8:0:0::). The Server then relays this double- 1901 encapsulated NA message via Relay ('R1') by changing the link-layer 1902 source address of the message to 'L2(S2)' and changing the link-layer 1903 destination address to 'L2(R1)'. Server ('S2') finally forwards the 1904 re-encapsulated message to Relay ('R1') without decrementing the 1905 network-layer TTL/Hop Limit field. 1907 When Relay ('R1') receives the double-encapsulated NA message from 1908 Server ('S2') it discards the outer IP header and determines that 1909 Server ('S1') is the next hop toward Client ('C1') by consulting its 1910 standard IP forwarding table for the Subnet Router Anycast 1911 destination address. Relay ('R1') then encapsulates and forwards the 1912 message to Server ('S1') the same as for any IP router. 1914 When Server ('S1') receives the double-encapsulated NS message from 1915 Relay ('R1') it removes the mid-layer IP header and determines that 1916 Client ('C1') is a neighbor by consulting its neighbor cache for 1917 Client ('C1')'s AERO address. Server ('S1') then re-encapsulates the 1918 NA while changing the link-layer source address to 'L2(S1)' and 1919 changing the link-layer destination address to 'L2(C1)'. Server 1920 ('S1') then forwards the message to Client ('C1'). 1922 3.15.7. Processing NAs 1924 When Client ('C1') receives the NA message, it first verifies the 1925 Nonce value matches the value that it included in its NS message (if 1926 any). If the Nonce values match, Client ('C1') then processes the 1927 message as follows. 1929 In the reference operational scenario, when Client ('C1') receives 1930 the NA message, it either creates or updates a dynamic neighbor cache 1931 entry that stores the source address of the message as the network- 1932 layer address of Client ('C2'), stores the link-layer addresses found 1933 in the TLLAOs as the link-layer addresses of Client ('C2') and stores 1934 the ACPs encoded in the RIOs of the NA as the ACPs for Client ('C2'). 1935 Client ('C1') then sets ForwardTime for the neighbor cache entry to 1936 FORWARD_TIME. 1938 Now, Client ('C1') has a neighbor cache entry with a valid 1939 ForwardTime value, while Client ('C2') has a neighbor cache entry 1940 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 1941 ordinary network-layer data packets directly to Client ('C2') without 1942 involving any intermediate nodes, and Client ('C2') can verify that 1943 the packets came from an acceptable source. (In order for Client 1944 ('C2') to forward packets to Client ('C1'), a corresponding NS/NA 1945 message exchange is required in the reverse direction; hence, the 1946 mechanism is asymmetric.) 1948 3.15.8. Server and Proxy Extended Route Optimization 1950 Route optimization may be initiated by the source Client by sending 1951 NS messages with SLLAOs corresponding to its native underlying 1952 interfaces. Route optimization for the source Client's other 1953 interfaces may be initiated by Servers and/or Proxies. Each node 1954 initiates route optimization by sending NS messages with SLLAOs only 1955 for those underlying interfaces they are authoritative for. Each 1956 node MUST consistently use the same Interface ID values to denote the 1957 same interfaces. The Interface IDs are established and maintained by 1958 the source Client's RS/RA exchanges. 1960 The target Client's Server serves as a route optimization target if 1961 some or all of the target Client's underlying interfaces connect via 1962 NATs, Proxies and/or VPNs. In that case, when the source sends an NS 1963 message the target Server both forwards the NS toward native 1964 underlying interfaces of the target Client (if any) and prepares an 1965 NA response the same as if it were the target Client (see: 1966 Section 3.15.5). (This means that the source may receive multiple NA 1967 messages - one from the target Server and additional messages from 1968 the target Client. The source must accept the union of the 1969 information from all messages.) 1971 For non-native underlying interfaces, the target Server includes a 1972 first TLLAO option in the NA with Interface ID set to 255 and 1973 includes any additional TLLAOs corresponding to the Client's NATed, 1974 Proxyed and/or VPNed underlying interfaces. The Server writes its 1975 own link-layer address in TLLAOs corresponding to NATed and VPNed 1976 underlying interfaces, and writes the link-layer address of the Proxy 1977 in TLLAOs corresponding to Proxyed underlying interfaces (while also 1978 setting the X flag). The Interface ID and QoS Preference values in 1979 the TLLAOs are those supplied by the Client during the initial RS/RA 1980 exchange and updated by any ensuing NS/NA messages. The target 1981 Server must then maintain a dynamic neighbor cache entry for the 1982 Client, but MUST NOT send BGP updates for Clients discovered through 1983 dynamic route optimization. 1985 Thereafter, if the target Client moves to a new Server, the old 1986 Server sends unsolicited NA messages with no TLLAOs (subject to rate 1987 limiting) back to the source in response to data packets received 1988 from a correspondent node while forwarding the packets themselves to 1989 a Relay. The Relay will then either forward the packets to the new 1990 Server if the target Client has moved, or drop the packets if the 1991 target Client is no longer in the network. The source then allows 1992 future packets destined to the target Client to again flow through 1993 its own Server (or Relay). Note however that the old Server retains 1994 the neighbor cache entry with its associated AcceptTime since there 1995 may be many packets in flight. AcceptTime will then eventually 1996 decrement to 0 once the correspondent node processes and acts on the 1997 unsolicited NAs. 1999 When the target Client (or Proxy) sends unsolicited NA messages to 2000 the target Server to update link-layer address and/or QoS 2001 preferences, the target Server repeats the messages to any of its 2002 dynamic neighbors while using its own link-layer and link-local 2003 addresses as the source addresses. In this way, the target Server 2004 acts as a link-scoped multicast repeater on behalf of the target 2005 Client (or Proxy). 2007 (Note that instead of serving as the route optimization target for 2008 Proxy interfaces, the target Server could instead forward the 2009 source's NS messages and allow the Proxies to return NA messages, 2010 i.e., the same as for Clients on native interfaces. That would mean 2011 that the source could receive multiple NA messages from multiple 2012 Proxies and, if some or all NA messages are lost, the source would 2013 not be able to determine the full picture of the Client's Proxy 2014 affiliations. If this alternate architecture is deemed appropriate 2015 in some use cases, then the AERO Proxies could be employed to serve 2016 as route optimization targets instead of depending on the Servers to 2017 do so.) 2019 3.16. Neighbor Unreachability Detection (NUD) 2021 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 2022 NS messages to elicit solicited NA messages from neighbors the same 2023 as described in [RFC4861]. NUD is performed either reactively in 2024 response to persistent link-layer errors (see Section 3.13) or 2025 proactively to update neighbor cache entry timers and/or link-layer 2026 address information. (NS messages may include SLLAOs and NA messages 2027 may include TLLAOs in order to update link-layer address 2028 information.) 2030 When an AERO node sends an NS/NA message, it uses one of its link- 2031 local addresses as the IPv6 source address and a link-local address 2032 of the neighbor as the IPv6 destination address. When route 2033 optimization directs a source AERO node to a target AERO node, the 2034 source node SHOULD proactively test the direct path by sending an 2035 initial NS message to elicit a solicited NA response. While testing 2036 the path, the source node can optionally continue sending packets via 2037 its default router, maintain a small queue of packets until target 2038 reachability is confirmed, or (optimistically) allow packets to flow 2039 directly to the target. 2041 While data packets are still flowing, the source node thereafter 2042 periodically tests the direct path to the target node (see 2043 Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache 2044 entries alive. When the target node receives a valid NS message, it 2045 resets AcceptTime to ACCEPT_TIME and updates its cached link-layer 2046 addresses (if necessary). When the source node receives a solicited 2047 NA message, it resets ForwardTime to FORWARD_TIME and updates its 2048 cached link-layer addresses (if necessary). If the source node is 2049 unable to elicit a solicited NA response from the target node after 2050 MaxRetry attempts, it SHOULD set ForwardTime to 0. Otherwise, the 2051 source node considers the path usable and SHOULD thereafter process 2052 any link-layer errors as an indication that the direct path to the 2053 target node has either failed or has become intermittent. 2055 When ForwardTime for a dynamic neighbor cache entry expires, the 2056 source node resumes sending any subsequent packets via a Server (or 2057 Relay) and may (eventually) attempt to re-initiate the AERO route 2058 optimization process. When AcceptTime for a dynamic neighbor cache 2059 entry expires, the target node discards any subsequent packets 2060 received directly from the source node. When both ForwardTime and 2061 AcceptTime for a dynamic neighbor cache entry expire, the node 2062 deletes the neighbor cache entry. 2064 Note that an AERO node may have multiple underlying interface paths 2065 toward the target neighbor. In that case, the node SHOULD perform 2066 NUD over each underlying interface and only consider the neighbor 2067 unreachable if NUD fails over multiple underlying interface paths. 2069 3.17. Mobility Management and Quality of Service (QoS) 2071 AERO is an example of a Distributed Mobility Management (DMM) 2072 service. Each AERO Server is responsible for only a subset of the 2073 Clients on the AERO link, as opposed to a Centralized Mobility 2074 Management (CMM) service where there is a single network service for 2075 all Clients. AERO Clients coordinate with their regional Servers via 2076 RS/RA exchanges to maintain the DMM profile, and the AERO routing 2077 system tracks the current AERO Client/Server peering relationships. 2079 AERO interfaces accommodate mobility management by sending 2080 unsolicited NA messages the same as for announcing link-layer address 2081 changes for any interface that implements IPv6 ND [RFC4861]. (In 2082 environments where reliability is a concern, AERO interfaces can send 2083 immediate NS messages to receive solicited NA messages, i.e., they 2084 can skip the unreliable unsolicited NA messaging step and move 2085 directly to a reliable NS/NA exchange. This comes at a penalty of at 2086 least one round trip.) 2088 When a node sends an unsolicited NA message, it sets the IPv6 source 2089 to its own link-local address, sets the IPv6 destination address to 2090 all-nodes multicast, sets the link-layer source address to its own 2091 address and sets the link-layer destination address to either a 2092 multicast address or the unicast link-layer address of a neighbor. 2093 If the unsolicited NA message must be received by multiple neighbors, 2094 the node sends multiple copies of the NA using a different unicast 2095 link-layer destination address for each neighbor. Mobility 2096 management considerations are specified in the following sections. 2098 3.17.1. Forwarding Packets on Behalf of Departed Clients 2100 When a Server receives packets with destination addresses that do not 2101 match one of its static neighbor cache Clients, it forwards the 2102 packets to a Relay and also returns an unsolicited NA message to the 2103 sender with no TLLAOs. The packets will be delivered to the target 2104 Client's new location, and the sender will realize that it needs to 2105 deprecate its routing information that associated the target with 2106 this Server. 2108 3.17.2. Announcing Link-Layer Address and QoS Preference Changes 2110 When a Client needs to change its link-layer addresses, e.g., due to 2111 a mobility event, it sends unsolicited NAs to its neighbors using the 2112 new link-layer address as the source address and with TLLAOs that 2113 include the new Client UDP Port Number, IP Address and P(i) values. 2114 If the Client sends the NA solely for the purpose of updating QoS 2115 preferences without updating the link-layer address, the Client sets 2116 the UDP Port Number and IP Address to 0. 2118 The Client MAY send up to MaxRetry unsolicited NA messages in 2119 parallel with sending actual data packets in case one or more NAs are 2120 lost. If all NAs are lost, the neighbor will eventually invoke NUD 2121 by sending NS messages that include SLLAOs. 2123 3.17.3. Bringing New Links Into Service 2125 When a Client needs to bring new underlying interfaces into service 2126 (e.g., when it activates a new data link), it sends unsolicited NAs 2127 to its neighbors using the new link-layer address as the source 2128 address and with TLLAOs that include the new Client link-layer 2129 information. 2131 3.17.4. Removing Existing Links from Service 2133 When a Client needs to remove existing underlying interfaces from 2134 service (e.g., when it de-activates an existing data link), it sends 2135 unsolicited NAs to its neighbors with TLLAOs with all P(i) values set 2136 to 0. 2138 If the Client needs to send the unsolicited NAs over an underlying 2139 interface other than the one being removed from service, it MUST 2140 include a current TLLAO for the sending interface as the first TLLAO 2141 and include TLLAOs for any underlying interface being removed from 2142 service as additional TLLAOs. 2144 3.17.5. Implicit Mobility Management 2146 AERO interface neighbors MAY provide a configuration option that 2147 allows them to perform implicit mobility management in which no ND 2148 messaging is used. In that case, the Client only transmits packets 2149 over a single interface at a time, and the neighbor always observes 2150 packets arriving from the Client from the same link-layer source 2151 address. 2153 If the Client's underlying interface address changes (either due to a 2154 readdressing of the original interface or switching to a new 2155 interface) the neighbor immediately updates the neighbor cache entry 2156 for the Client and begins accepting and sending packets to the 2157 Client's new link-layer address. This implicit mobility method 2158 applies to use cases such as cellphones with both WiFi and Cellular 2159 interfaces where only one of the interfaces is active at a given 2160 time, and the Client automatically switches over to the backup 2161 interface if the primary interface fails. 2163 3.17.6. Moving to a New Server 2165 When a Client associates with a new Server, it performs the Client 2166 procedures specified in Section 3.14.2. 2168 When a Client disassociates with an existing Server, it sends an RS 2169 "Release" message via a new Server with its base AERO address as the 2170 network-layer source address and the (administratively-provisioned) 2171 link-local address of the old Server as the network-layer destination 2172 address. The new Server then caches the Client's AERO address and 2173 "Release" message parameters (e.g., "transaction ID") and writes its 2174 own administratively-provisioned link-local address as the network- 2175 layer source address. The new Server then forwards the message to a 2176 Relay, which forwards the message to the old Server. 2178 When the old Server receives the "Release", it releases the Client's 2179 ACP prefix delegations and routes. The old Server then deletes the 2180 Client's neighbor cache entry so that any in-flight packets will be 2181 forwarded via a Relay to the new Server, which will forward them to 2182 the Client. The old Server finally returns a "Reply" message via a 2183 Relay to the new Server, which will decapsulate the "Reply" message 2184 and forward it as an RA "Reply" to the Client. 2186 When the new Server forwards the "Reply" message, the Client can 2187 delete both the default route and the neighbor cache entry for the 2188 old Server. (Note that since messages may be lost in the network the 2189 Client SHOULD retry until it gets an RA "Reply" indicating that the 2190 RS "Release" was successful. If the Client does not receive a 2191 "Reply" after MaxRetry attempts, the old Server may have failed and 2192 the Client should discontinue its "Release" attempts.) 2194 Finally, Clients SHOULD NOT move rapidly between Servers in order to 2195 avoid causing excessive oscillations in the AERO routing system. 2196 Such oscillations could result in intermittent reachability for the 2197 Client itself, while causing little harm to the network. Examples of 2198 when a Client might wish to change to a different Server include a 2199 Server that has gone unreachable, topological movements of 2200 significant distance, etc. 2202 3.18. Multicast Considerations 2204 When the underlying network does not support multicast, AERO Clients 2205 map link-scoped multicast addresses to the link-layer address of a 2206 Server, which acts as a multicast forwarding agent. The AERO Client 2207 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2208 applications per [RFC4605] while using the link-layer address of the 2209 Server as the link-layer address for all multicast packets. 2211 When the underlying network supports multicast, AERO nodes use the 2212 multicast address mapping specification found in [RFC2529] for IPv4 2213 underlying networks and use a TBD site-scoped multicast mapping for 2214 IPv6 underlying networks. In that case, border routers must ensure 2215 that the encapsulated site-scoped multicast packets do not leak 2216 outside of the site spanned by the AERO link. 2218 4. The AERO Proxy 2220 In some deployments, AERO Clients may be located in secured enclaves 2221 (e.g., a corporate enterprise network, a radio access network, etc.) 2222 that do not allow direct communications from the Client to a Server 2223 in the outside Internetwork. In that case, the secured enclave can 2224 employ an AERO Proxy. 2226 The AERO Proxy is located at the secured enclave perimeter and 2227 listens for RS messages originating from or RA messages destined to 2228 AERO Clients located within the enclave. The Proxy acts on these 2229 control messages as follows: 2231 o when the Proxy receives an RS message from a Client within the 2232 secured enclave, it first authenticates the message then creates a 2233 proxy neighbor cache entry for the Client in the INCOMPLETE State 2234 and caches the Client and Server link-layer address along with any 2235 identifying information including PD "transaction IDs", "Client 2236 Identifiers", etc. and/or ND Nonce values. The Proxy then re- 2237 encapsulates the message and sets a flag in the encapsulation 2238 header to inform the Server that there is a Proxy on the path. 2239 The Proxy then forwards the message to the Server indicated by the 2240 destination link-layer address in the packet while substituting 2241 its own external address as the source link-layer address. 2243 o when the Proxy receives an RA message from the Server, it matches 2244 the message with the (INCOMPLETE) proxy neighbor cache entry. The 2245 Proxy then caches the route information in the message as a 2246 mapping from the Client's ACPs to the Client's address within the 2247 secured enclave, and sets the neighbor cache entry state to 2248 REACHABLE. The Proxy then re-encapsulates the message and 2249 forwards it to the Client. 2251 After the initial RS/RA handshake, the Proxy can send unsolicited NA 2252 messages to the Client's Server(s) to update Server neighbor cache 2253 entries on behalf of the Client. (For example, the Proxy can send NA 2254 messages with a TLLAO with UDP Port Number and IP Address set to 0 2255 and with valid P(i) values to update the Server(s) with the Client's 2256 new QoS preferences for that link). The Proxy also forwards any 2257 unsolicited NA messages originating from the Client to the Client's 2258 Server(s) (e.g. if the Client needs to announce new QoS preferences 2259 on its own behalf), and forwards any data packets originating from 2260 the Client to the Client's primary Server. 2262 At the same time, for data packets originating from a Client within 2263 the enclave with destination addresses that match an ASP, the Proxy 2264 can initiate route optimization by sending an NS message via the 2265 Server to solicit an NA message from a target node on the path to the 2266 destination Client the same as discussed in Section 3.15. The target 2267 must deliver the NA message directly to the Proxy, i.e., instead of 2268 relaying through the backward chain of Relays and Servers, since the 2269 backward chain could deliver the NA to a different Proxy besides the 2270 one that produced the NS. For this reason, the Proxy prepares an NS 2271 message as specified in Section 3.15.3, but with its own link-layer 2272 address as the link-layer source address and with a single SLLAO 2273 containing its link-layer address and with the X flag set to indicate 2274 that direct delivery is required. 2276 When the target receives the NS message, it creates a dynamic 2277 neighbor cache entry in the ACCEPT state and returns an NA message 2278 directly to the Proxy. When the target is a Client, it includes 2279 TLLAOs in the NA message with link-layer addresses corresponding to 2280 its native underling interfaces. When the target is a Server, it 2281 includes a first TLLAO in the NA message with Interface ID set to 255 2282 and with its own link-layer address information, and also includes 2283 additional TLLAOs corresponding to the destination Client's Proxyed, 2284 NATed or VPNed underlying interfaces. (For NATed or VPNed underlying 2285 interfaces the server writes its own link-layer address in the TLLAO, 2286 and for Proxyed interfaces it writes the link-layer address of the 2287 Proxy.) When the source Proxy receives the NA message, it creates a 2288 dynamic neighbor cache entry in the FORWARD state that associates the 2289 TLLAOs of the NA message as the next-hop toward the routes advertised 2290 in the NA RIOs. 2292 When a source Proxy sends route optimization NS messages toward the 2293 target, it can include RIOs to assert specific routes, and the target 2294 will only accept packets from the source Proxy with matching source 2295 addresses. If the source Proxy wishes to assert a "wildcard" route, 2296 it includes an RIO in the NS message with Prefix and Prefix Length 2297 set to 0. In that case, the target will either accept or ignore the 2298 NS based on its configured trust policy. If the target accepts the 2299 NS, it will accept all packets originating from the source Proxy 2300 regardless of their source address. 2302 After the initial NS/NA exchange, the target may need to update the 2303 neighbor cache entries for any source Proxies for which it holds a 2304 dynamic neighbor cache entry in the ACCEPT state. The target 2305 therefore sends unsolicited NA messages to announce any link layer 2306 changes. As a result: 2308 o the source Proxy may receive unsolicited NA messages with TLLAOs 2309 with new UDP Port Number, IP Address and/or QoS preferences from 2310 the target. In that case, the Proxy updates its neighbor cache 2311 entry and forwards future outbound packets based on the new link 2312 layer information. 2314 o the source Proxy may receive reflected packets destined to the 2315 link-layer address of a departed Client. In that case, the Proxy 2316 proceeds as discussed in Section 3.8.5. 2318 o the source Proxy may receive link-layer Destination Unreachable 2319 messages in response to data packets it sends to one of the target 2320 link-layer addresses. In that case, the Proxy processes the link- 2321 layer error messages as an indication that the path may be failing 2322 and proceeds as discussed in Section 3.13. 2324 After the NS/NA exchange, while data packets are still flowing the 2325 source Proxy sends additional NS messages to the target using the 2326 address in the target's first TLLAO as the destination. The NS 2327 message will update the target's AcceptTime timer, and the resulting 2328 NA reply will update the source Proxy's ForwardTime timer in their 2329 respective neighbor cache entries. 2331 If at some later time the target Client departs from its secured 2332 enclave, the Proxy sends unsolicited NAs to the Client's Servers to 2333 announce the departure. 2335 5. Direct Underlying Interfaces 2337 When a Client's AERO interface is configured over a direct underlying 2338 interface, the neighbor at the other end of the direct link can 2339 receive packets without any encapsulation. In that case, the Client 2340 sends packets over the direct link according to the QoS preferences 2341 associated with its underling interfaces. If the direct underlying 2342 interface has the highest QoS preference, then the Client's IP 2343 packets are transmitted directly to the peer without going through an 2344 underlying network. If other underlying interfaces have higher QoS 2345 preferences, then the Client's IP packets are transmitted via a 2346 different underlying interface, which may result in the inclusion of 2347 AERO Proxies, Servers and Relays in the communications path. Direct 2348 underlying interfaces must be tested periodically for reachability, 2349 e.g., via NUD, via periodic unsolicited NAs, etc. 2351 6. Operation on AERO Links with /64 ASPs 2353 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2354 length /64 or shorter. However, in some cases it may be desirable to 2355 use AERO over links that have only a /64 ASP. This can be 2356 accommodated by treating all Clients on the AERO link as simple hosts 2357 that receive /128 prefix delegations. 2359 In that case, the Client sends an RS message to the Server the same 2360 as for ordinary AERO links. The Server responds with an RA message 2361 that includes one or more /128 prefixes (i.e., singleton addresses) 2362 that include the /64 ASP prefix along with an interface identifier 2363 portion to be assigned to the Client. The Client and Server then 2364 configure their AERO addresses based on the interface identifier 2365 portions of the /128s (i.e., the lower 64 bits) and not based on the 2366 /64 prefix (i.e., the upper 64 bits). 2368 For example, if the ASP for the host-only IPv6 AERO link is 2369 2001:db8:1000:2000::/64, each Client will receive one or more /128 2370 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2371 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2372 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2373 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2374 /128s) to either the AERO interface or an internal virtual interface 2375 such as a loopback. In this arrangement, the Client conducts route 2376 optimization in the same sense as discussed in Section 3.15. 2378 This specification has applicability for nodes that act as a Client 2379 on an "upstream" AERO link, but also act as a Server on "downstream" 2380 AERO links. More specifically, if the node acts as a Client to 2381 receive a /64 prefix from the upstream AERO link it can then act as a 2382 Server to provision /128s to Clients on downstream AERO links. 2384 7. Implementation Status 2386 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2387 announced on the v6ops mailing list on January 10, 2018. The latest 2388 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2389 1.2.tgz. 2391 An initial public release of the AERO proof-of-concept source code 2392 was announced on the intarea mailing list on August 21, 2015. The 2393 latest version is available at: http://linkupnetworks.net/aero/aero- 2394 4.0.0.tgz. 2396 8. IANA Considerations 2398 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2399 AERO in the "enterprise-numbers" registry. 2401 The IANA has assigned the UDP port number "8060" for an earlier 2402 experimental version of AERO [RFC6706]. This document obsoletes 2403 [RFC6706] and claims the UDP port number "8060" for all future use. 2405 No further IANA actions are required. 2407 9. Security Considerations 2409 AERO link security considerations are the same as for standard IPv6 2410 Neighbor Discovery [RFC4861] except that AERO improves on some 2411 aspects. In particular, AERO uses a trust basis between Clients and 2412 Servers, where the Clients only engage in the AERO mechanism when it 2413 is facilitated by a trusted Server. 2415 NS and NA messages SHOULD include a Timestamp option (see Section 5.3 2416 of [RFC3971]) that other AERO nodes can use to verify the message 2417 time of origin. NS and RS messages SHOULD include a Nonce option 2418 (see Section 5.3 of [RFC3971]) that recipients echo back in 2419 corresponding responses. In cases where spoofing cannot be mitigated 2420 through other means, however, all AERO IPv6 ND messages should employ 2421 SEND [RFC3971], which also protects the PD information embedded in 2422 RS/RA message options. 2424 AERO links must be protected against link-layer address spoofing 2425 attacks in which an attacker on the link pretends to be a trusted 2426 neighbor. Links that provide link-layer securing mechanisms (e.g., 2427 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2428 enterprise network wired LANs) provide a first line of defense, 2429 however AERO nodes SHOULD also use securing services such as SEND for 2430 Client authentication and network admission control. Following 2431 authenticated Client admission and prefix delegation procedures, AERO 2432 nodes MUST ensure that the source of data packets corresponds to the 2433 node to which the prefixes were delegated. 2435 AERO Clients MUST ensure that their connectivity is not used by 2436 unauthorized nodes on their EUNs to gain access to a protected 2437 network, i.e., AERO Clients that act as routers MUST NOT provide 2438 routing services for unauthorized nodes. (This concern is no 2439 different than for ordinary hosts that receive an IP address 2440 delegation but then "share" the address with other nodes via some 2441 form of Internet connection sharing such as tethering.) 2443 AERO Clients, Servers and Relays on the open Internet are susceptible 2444 to the same attack profiles as for any Internet nodes. For this 2445 reason, IP security SHOULD be used when AERO is employed over 2446 unmanaged/unsecured links using securing mechanisms such as IPsec 2447 [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, 2448 however, the use of end-to-end security from Clients to correspondent 2449 nodes (i.e., other Clients and/or Internet nodes) could obviate the 2450 need for IP security between AERO Clients, Servers and Relays. 2452 AERO Servers and Relays present targets for traffic amplification DoS 2453 attacks. This concern is no different than for widely-deployed VPN 2454 security gateways in the Internet, where attackers could send spoofed 2455 packets to the gateways at high data rates. This can be mitigated by 2456 connecting Relays and Servers over dedicated links with no 2457 connections to the Internet and/or when connections to the Internet 2458 are only permitted through well-managed firewalls. 2460 Traffic amplification DoS attacks can also target an AERO Client's 2461 low data rate links. This is a concern not only for Clients located 2462 on the open Internet but also for Clients in secured enclaves. AERO 2463 Servers can institute rate limits that protect Clients from receiving 2464 packet floods that could DoS low data rate links. 2466 AERO Relays and Servers MUST discard packets with a Unique Local IPv6 2467 source address (i.e., from the prefix "fc00::/7") originating from 2468 any node other than a permanent neighbor. This is to avoid a message 2469 injection spoofing attack from an off-link attacker. 2471 Security considerations for accepting link-layer ICMP messages and 2472 reflected packets are discussed throughout the document. 2474 10. Acknowledgements 2476 Discussions in the IETF, aviation standards communities and private 2477 exchanges helped shape some of the concepts in this work. 2478 Individuals who contributed insights include Mikael Abrahamsson, Mark 2479 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2480 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2481 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2482 Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, Satoru 2483 Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet Saikaya, 2484 Michal Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, 2485 Lloyd Wood and James Woodyatt. Members of the IESG also provided 2486 valuable input during their review process that greatly improved the 2487 document. Special thanks go to Stewart Bryant, Joel Halpern and 2488 Brian Haberman for their shepherding guidance during the publication 2489 of the AERO first edition. 2491 This work has further been encouraged and supported by Boeing 2492 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2493 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2494 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gene 2495 MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian 2496 Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie Wulff, 2497 Yueli Yang, Eric Yeh and other members of the BR&T and BIT mobile 2498 networking teams. Kyle Bae, Wayne Benson and Eric Yeh are especially 2499 acknowledged for implementing the AERO functions as extensions to the 2500 public domain OpenVPN distribution. 2502 Earlier works on NBMA tunneling approaches are found in 2503 [RFC2529][RFC5214][RFC5569]. 2505 Many of the constructs presented in this second edition of AERO are 2506 based on the author's earlier works, including: 2508 o The Internet Routing Overlay Network (IRON) 2509 [RFC6179][I-D.templin-ironbis] 2511 o Virtual Enterprise Traversal (VET) 2512 [RFC5558][I-D.templin-intarea-vet] 2514 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2515 [RFC5320][I-D.templin-intarea-seal] 2517 o AERO, First Edition [RFC6706] 2519 Note that these works cite numerous earlier efforts that are not also 2520 cited here due to space limitations. The authors of those earlier 2521 works are acknowledged for their insights. 2523 This work is aligned with the NASA Safe Autonomous Systems Operation 2524 (SASO) program under NASA contract number NNA16BD84C. 2526 This work is aligned with the FAA as per the SE2025 contract number 2527 DTFAWA-15-D-00030. 2529 This work is aligned with the Boeing Information Technology (BIT) 2530 MobileNet program. 2532 This work is aligned with the Boeing Research and Technology (BR&T) 2533 autonomous systems networking program. 2535 11. References 2537 11.1. Normative References 2539 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2540 DOI 10.17487/RFC0768, August 1980, 2541 . 2543 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2544 DOI 10.17487/RFC0791, September 1981, 2545 . 2547 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2548 RFC 792, DOI 10.17487/RFC0792, September 1981, 2549 . 2551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2552 Requirement Levels", BCP 14, RFC 2119, 2553 DOI 10.17487/RFC2119, March 1997, 2554 . 2556 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2557 "Definition of the Differentiated Services Field (DS 2558 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2559 DOI 10.17487/RFC2474, December 1998, 2560 . 2562 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2563 C., and M. Carney, "Dynamic Host Configuration Protocol 2564 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2565 2003, . 2567 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2568 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2569 DOI 10.17487/RFC3633, December 2003, 2570 . 2572 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2573 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2574 DOI 10.17487/RFC3971, March 2005, 2575 . 2577 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2578 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2579 November 2005, . 2581 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2582 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2583 . 2585 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2586 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2587 DOI 10.17487/RFC4861, September 2007, 2588 . 2590 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2591 Address Autoconfiguration", RFC 4862, 2592 DOI 10.17487/RFC4862, September 2007, 2593 . 2595 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2596 Advertisement Flags Option", RFC 5175, 2597 DOI 10.17487/RFC5175, March 2008, 2598 . 2600 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2601 (IPv6) Specification", STD 86, RFC 8200, 2602 DOI 10.17487/RFC8200, July 2017, 2603 . 2605 11.2. Informative References 2607 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2608 2016. 2610 [I-D.ietf-intarea-gue] 2611 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2612 Encapsulation", draft-ietf-intarea-gue-06 (work in 2613 progress), August 2018. 2615 [I-D.ietf-intarea-gue-extensions] 2616 Herbert, T., Yong, L., and F. Templin, "Extensions for 2617 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2618 extensions-05 (work in progress), August 2018. 2620 [I-D.ietf-intarea-tunnels] 2621 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2622 Architecture", draft-ietf-intarea-tunnels-09 (work in 2623 progress), July 2018. 2625 [I-D.templin-6man-dhcpv6-ndopt] 2626 Templin, F., "A Unified Stateful/Stateless 2627 Autoconfiguration Service for IPv6", draft-templin-6man- 2628 dhcpv6-ndopt-05 (work in progress), July 2018. 2630 [I-D.templin-6man-rio-redirect] 2631 Templin, F. and j. woodyatt, "Route Information Options in 2632 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2633 redirect-06 (work in progress), May 2018. 2635 [I-D.templin-atn-bgp] 2636 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2637 Moreno, "A Simple BGP-based Mobile Routing System for the 2638 Aeronautical Telecommunications Network", draft-templin- 2639 atn-bgp-08 (work in progress), August 2018. 2641 [I-D.templin-intarea-grefrag] 2642 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2643 templin-intarea-grefrag-04 (work in progress), July 2016. 2645 [I-D.templin-intarea-seal] 2646 Templin, F., "The Subnetwork Encapsulation and Adaptation 2647 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2648 progress), January 2014. 2650 [I-D.templin-intarea-vet] 2651 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2652 templin-intarea-vet-40 (work in progress), May 2013. 2654 [I-D.templin-ironbis] 2655 Templin, F., "The Interior Routing Overlay Network 2656 (IRON)", draft-templin-ironbis-16 (work in progress), 2657 March 2014. 2659 [I-D.templin-v6ops-pdhost] 2660 Templin, F., "Multi-Addressing Considerations for IPv6 2661 Prefix Delegation", draft-templin-v6ops-pdhost-21 (work in 2662 progress), June 2018. 2664 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2666 [RFC1035] Mockapetris, P., "Domain names - implementation and 2667 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2668 November 1987, . 2670 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2671 Communication Layers", STD 3, RFC 1122, 2672 DOI 10.17487/RFC1122, October 1989, 2673 . 2675 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2676 DOI 10.17487/RFC1191, November 1990, 2677 . 2679 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2680 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2681 . 2683 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2684 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2685 1996, . 2687 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2688 DOI 10.17487/RFC2003, October 1996, 2689 . 2691 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2692 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2693 . 2695 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2696 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2697 December 1998, . 2699 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2700 Domains without Explicit Tunnels", RFC 2529, 2701 DOI 10.17487/RFC2529, March 1999, 2702 . 2704 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2705 Malis, "A Framework for IP Based Virtual Private 2706 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2707 . 2709 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2710 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2711 DOI 10.17487/RFC2784, March 2000, 2712 . 2714 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2715 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2716 . 2718 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2719 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2720 . 2722 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2723 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2724 . 2726 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2727 of Explicit Congestion Notification (ECN) to IP", 2728 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2729 . 2731 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2732 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2733 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2734 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2735 . 2737 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2738 for IPv6 Hosts and Routers", RFC 4213, 2739 DOI 10.17487/RFC4213, October 2005, 2740 . 2742 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2743 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2744 DOI 10.17487/RFC4271, January 2006, 2745 . 2747 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2748 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2749 2006, . 2751 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2752 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2753 December 2005, . 2755 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2756 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2757 2006, . 2759 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2760 Control Message Protocol (ICMPv6) for the Internet 2761 Protocol Version 6 (IPv6) Specification", STD 89, 2762 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2763 . 2765 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2766 Protocol (LDAP): The Protocol", RFC 4511, 2767 DOI 10.17487/RFC4511, June 2006, 2768 . 2770 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2771 "Internet Group Management Protocol (IGMP) / Multicast 2772 Listener Discovery (MLD)-Based Multicast Forwarding 2773 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2774 August 2006, . 2776 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2777 Errors at High Data Rates", RFC 4963, 2778 DOI 10.17487/RFC4963, July 2007, 2779 . 2781 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2782 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2783 DOI 10.17487/RFC5214, March 2008, 2784 . 2786 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2787 (TLS) Protocol Version 1.2", RFC 5246, 2788 DOI 10.17487/RFC5246, August 2008, 2789 . 2791 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2792 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2793 February 2010, . 2795 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2796 Route Optimization Requirements for Operational Use in 2797 Aeronautics and Space Exploration Mobile Networks", 2798 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2799 . 2801 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2802 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2803 . 2805 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2806 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2807 January 2010, . 2809 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2810 Global Enterprise Recursion (RANGER)", RFC 5720, 2811 DOI 10.17487/RFC5720, February 2010, 2812 . 2814 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2815 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2816 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2817 . 2819 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2820 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2821 . 2823 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2824 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2825 DOI 10.17487/RFC6221, May 2011, 2826 . 2828 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2829 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2830 . 2832 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2833 for Equal Cost Multipath Routing and Link Aggregation in 2834 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2835 . 2837 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2838 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2839 . 2841 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2842 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2843 . 2845 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2846 October 2014. 2848 Appendix A. AERO Alternate Encapsulations 2850 When GUE encapsulation is not needed, AERO can use common 2851 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2852 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2853 encapsulation is therefore only differentiated from non-AERO tunnels 2854 through the application of AERO control messaging and not through, 2855 e.g., a well-known UDP port number. 2857 As for GUE encapsulation, alternate AERO encapsulation formats may 2858 require encapsulation layer fragmentation. For simple IP-in-IP 2859 encapsulation, an IPv6 fragment header is inserted directly between 2860 the inner and outer IP headers when needed, i.e., even if the outer 2861 header is IPv4. The IPv6 Fragment Header is identified to the outer 2862 IP layer by its IP protocol number, and the Next Header field in the 2863 IPv6 Fragment Header identifies the inner IP header version. For GRE 2864 encapsulation, a GRE fragment header is inserted within the GRE 2865 header [I-D.templin-intarea-grefrag]. 2867 Figure 5 shows the AERO IP-in-IP encapsulation format before any 2868 fragmentation is applied: 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 | Outer IPv4 Header | | Outer IPv6 Header | 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 | Inner IP Header | | Inner IP Header | 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2877 | | | | 2878 ~ ~ ~ ~ 2879 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2880 ~ ~ ~ ~ 2881 | | | | 2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2886 Figure 5: Minimal Encapsulation Format using IP-in-IP 2888 Figure 6 shows the AERO GRE encapsulation format before any 2889 fragmentation is applied: 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 | Outer IP Header | 2893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 | GRE Header | 2895 | (with checksum, key, etc..) | 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 | GRE Fragment Header (optional)| 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 | Inner IP Header | 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 | | 2902 ~ ~ 2903 ~ Inner Packet Body ~ 2904 ~ ~ 2905 | | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 Figure 6: Minimal Encapsulation Using GRE 2910 Alternate encapsulation may be preferred in environments where GUE 2911 encapsulation would add unnecessary overhead. For example, certain 2912 low-bandwidth wireless data links may benefit from a reduced 2913 encapsulation overhead. 2915 GUE encapsulation can traverse network paths that are inaccessible to 2916 non-UDP encapsulations, e.g., for crossing Network Address 2917 Translators (NATs). More and more, network middleboxes are also 2918 being configured to discard packets that include anything other than 2919 a well-known IP protocol such as UDP and TCP. It may therefore be 2920 necessary to determine the potential for middlebox filtering before 2921 enabling alternate encapsulation in a given environment. 2923 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2924 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 2925 messaging and route determination occur before security encapsulation 2926 is applied for outgoing packets and after security decapsulation is 2927 applied for incoming packets. 2929 AERO is especially well suited for use with VPN system encapsulations 2930 such as OpenVPN [OVPN]. 2932 Appendix B. When to Insert an Encapsulation Fragment Header 2934 An encapsulation fragment header is inserted when the AERO tunnel 2935 ingress needs to apply fragmentation to accommodate packets that must 2936 be delivered without loss due to a size restriction. Fragmentation 2937 is performed on the inner packet while encapsulating each inner 2938 packet fragment in outer IP and encapsulation layer headers that 2939 differ only in the fragment header fields. 2941 The fragment header can also be inserted in order to include a 2942 coherent Identification value with each packet, e.g., to aid in 2943 Duplicate Packet Detection (DPD). In this way, network nodes can 2944 cache the Identification values of recently-seen packets and use the 2945 cached values to determine whether a newly-arrived packet is in fact 2946 a duplicate. The Identification value within each packet could 2947 further provide a rough indicator of packet reordering, e.g., in 2948 cases when the tunnel egress wishes to discard packets that are 2949 grossly out of order. 2951 In some use cases, there may be operational assurance that no 2952 fragmentation of any kind will be necessary, or that only occasional 2953 large control messages will require fragmentation. In that case, the 2954 encapsulation fragment header can be omitted and ordinary 2955 fragmentation of the outer IP protocol version can be applied when 2956 necessary. 2958 Appendix C. Autoconfiguration for Constrained Platforms 2960 On some platforms (e.g., popular cell phone operating systems), the 2961 act of assigning a default IPv6 route and/or assigning an address to 2962 an interface may not be permitted from a user application due to 2963 security policy. Typically, those platforms include a TUN/TAP 2964 interface [TUNTAP] that acts as a point-to-point conduit between user 2965 applications and the AERO interface. In that case, the Client can 2966 instead generate a "synthesized RA" message. The message conforms to 2967 [RFC4861] and is prepared as follows: 2969 o the IPv6 source address is the Client's AERO address 2971 o the IPv6 destination address is all-nodes multicast 2973 o the Router Lifetime is set to a time that is no longer than the 2974 ACP DHCPv6 lifetime 2976 o the message does not include a Source Link Layer Address Option 2977 (SLLAO) 2979 o the message includes a Prefix Information Option (PIO) with a /64 2980 prefix taken from the ACP as the prefix for autoconfiguration 2982 The Client then sends the synthesized RA message via the TUN/TAP 2983 interface, where the operating system kernel will interpret it as 2984 though it were generated by an actual router. The operating system 2985 will then install a default route and use StateLess Address 2986 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 2987 interface. Methods for similarly installing an IPv4 default route 2988 and IPv4 address on the TUN/TAP interface are based on synthesized 2989 DHCPv4 messages [RFC2131]. 2991 Appendix D. Operational Deployment Alternatives 2993 AERO can be used in many different variations based on the specific 2994 use case. The following sections discuss variations that adhere to 2995 the AERO principles while allowing selective application of AERO 2996 components. 2998 D.1. Operation on AERO Links Without DHCPv6 Services 3000 When Servers on the AERO link do not provide DHCPv6 services, 3001 operation can still be accommodated through administrative 3002 configuration of ACPs on AERO Clients. In that case, administrative 3003 configurations of AERO interface neighbor cache entries on both the 3004 Server and Client are also necessary. However, this may interfere 3005 with the ability for Clients to dynamically change to new Servers, 3006 and can expose the AERO link to misconfigurations unless the 3007 administrative configurations are carefully coordinated. 3009 D.2. Operation on Server-less AERO Links 3011 In some AERO link scenarios, there may be no Servers on the link and/ 3012 or no need for Clients to use a Server as an intermediary trust 3013 anchor. In that case, each Client acts as a Server unto itself to 3014 establish neighbor cache entries by performing direct Client-to- 3015 Client IPv6 ND message exchanges, and some other form of trust basis 3016 must be applied so that each Client can verify that the prospective 3017 neighbor is authorized to use its claimed ACP. 3019 When there is no Server on the link, Clients must arrange to receive 3020 ACPs and publish them via a secure alternate PD authority through 3021 some means outside the scope of this document. 3023 D.3. Operation on Client-less AERO Links 3025 In some environments, the AERO service may be useful for mobile nodes 3026 that do not implement the AERO Client function and do not perform 3027 encapsulation. For example, if the mobile node has a way of 3028 injecting its ACP into the access subnetwork routing system an AERO 3029 Server connected to the same access network can accept the ACP prefix 3030 injection as an indication that a new mobile node has come onto the 3031 subnetwork. The Server can then inject the ACP into the BGP routing 3032 system the same as if an AERO Client/Server DHCPv6 PD exchange had 3033 occurred. If the mobile node subsequently withdraws the ACP from the 3034 access network routing system, the Server can then withdraw the ACP 3035 from the BGP routing system. 3037 In this arrangement, AERO Servers and Relays are used in exactly the 3038 same ways as for environments where DHCPv6 Client/Server exchanges 3039 are supported. However, the access subnetwork routing systems must 3040 be capable of accommodating rapid ACP injections and withdrawals from 3041 mobile nodes with the understanding that the information must be 3042 propagated to all routers in the system. Operational experience has 3043 shown that this kind of routing system "churn" can lead to overall 3044 instability and routing system inconsistency. 3046 D.4. Manually-Configured AERO Tunnels 3048 In addition to the dynamic neighbor discovery procedures for AERO 3049 link neighbors described above, AERO encapsulation can be applied to 3050 manually-configured tunnels. In that case, the tunnel endpoints use 3051 an administratively-provisioned link-local address and exchange NS/NA 3052 messages the same as for dynamically-established tunnels. 3054 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links 3056 In some environments, AERO Servers and Relays may be connected by 3057 dedicated point-to-point links, e.g., high speed fiberoptic leased 3058 lines. In that case, the Servers and Relays can participate in the 3059 AERO link the same as specified above but can avoid encapsulation 3060 over the dedicated links. In that case, however, the links would be 3061 dedicated for AERO and could not be multiplexed for both AERO and 3062 non-AERO communications. 3064 D.6. Encapsulation Protocol Version Considerations 3066 A source Client may connect only to an IPvX underlying network, while 3067 the target Client connects only to an IPvY underlying network. In 3068 that case, the target and source Clients have no means for reaching 3069 each other directly (since they connect to underlying networks of 3070 different IP protocol versions) and so must ignore any route 3071 optimization messages and continue to send packets via their Servers. 3073 D.7. Extending AERO Links Through Security Gateways 3075 When an enterprise mobile node moves from a campus LAN connection to 3076 a public Internet link, it must re-enter the enterprise via a 3077 security gateway that has both a physical interface connection to the 3078 Internet and a physical interface connection to the enterprise 3079 internetwork. This most often entails the establishment of a Virtual 3080 Private Network (VPN) link over the public Internet from the mobile 3081 node to the security gateway. During this process, the mobile node 3082 supplies the security gateway with its public Internet address as the 3083 link-layer address for the VPN. The mobile node then acts as an AERO 3084 Client to negotiate with the security gateway to obtain its ACP. 3086 In order to satisfy this need, the security gateway also operates as 3087 an AERO Server with support for AERO Client proxying. In particular, 3088 when a mobile node (i.e., the Client) connects via the security 3089 gateway (i.e., the Server), the Server provides the Client with an 3090 ACP in a DHCPv6 PD exchange the same as if it were attached to an 3091 enterprise campus access link. The Server then replaces the Client's 3092 link-layer source address with the Server's enterprise-facing link- 3093 layer address in all AERO messages the Client sends toward neighbors 3094 on the AERO link. The AERO messages are then delivered to other 3095 nodes on the AERO link as if they were originated by the security 3096 gateway instead of by the AERO Client. In the reverse direction, the 3097 AERO messages sourced by nodes within the enterprise network can be 3098 forwarded to the security gateway, which then replaces the link-layer 3099 destination address with the Client's link-layer address and replaces 3100 the link-layer source address with its own (Internet-facing) link- 3101 layer address. 3103 After receiving the ACP, the Client can send IP packets that use an 3104 address taken from the ACP as the network layer source address, the 3105 Client's link-layer address as the link-layer source address, and the 3106 Server's Internet-facing link-layer address as the link-layer 3107 destination address. The Server will then rewrite the link-layer 3108 source address with the Server's own enterprise-facing link-layer 3109 address and rewrite the link-layer destination address with the 3110 target AERO node's link-layer address, and the packets will enter the 3111 enterprise network as though they were sourced from a node located 3112 within the enterprise. In the reverse direction, when a packet 3113 sourced by a node within the enterprise network uses a destination 3114 address from the Client's ACP, the packet will be delivered to the 3115 security gateway which then rewrites the link-layer destination 3116 address to the Client's link-layer address and rewrites the link- 3117 layer source address to the Server's Internet-facing link-layer 3118 address. The Server then delivers the packet across the VPN to the 3119 AERO Client. In this way, the AERO virtual link is essentially 3120 extended *through* the security gateway to the point at which the VPN 3121 link and AERO link are effectively grafted together by the link-layer 3122 address rewriting performed by the security gateway. All AERO 3123 messaging services (including route optimization and mobility 3124 signaling) are therefore extended to the Client. 3126 In order to support this virtual link grafting, the security gateway 3127 (acting as an AERO Server) must keep static neighbor cache entries 3128 for all of its associated Clients located on the public Internet. 3129 The neighbor cache entry is keyed by the AERO Client's AERO address 3130 the same as if the Client were located within the enterprise 3131 internetwork. The neighbor cache is then managed in all ways as 3132 though the Client were an ordinary AERO Client. This includes the 3133 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 3134 Unreachability Detection. 3136 Note that the main difference between a security gateway acting as an 3137 AERO Server and an enterprise-internal AERO Server is that the 3138 security gateway has at least one enterprise-internal physical 3139 interface and at least one public Internet physical interface. 3140 Conversely, the enterprise-internal AERO Server has only enterprise- 3141 internal physical interfaces. For this reason security gateway 3142 proxying is needed to ensure that the public Internet link-layer 3143 addressing space is kept separate from the enterprise-internal link- 3144 layer addressing space. This is afforded through a natural extension 3145 of the security association caching already performed for each VPN 3146 client by the security gateway. 3148 Appendix E. Change Log 3150 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 3151 6706bis-00: 3153 o Document use of NUD (NS/NA) for reliable link-layer address 3154 updates as an alternative to unreliable unsolicited NA. 3155 Consistent with Section 7.2.6 of RFC4861. 3157 o Server adds additional layer of encapsulation between outer and 3158 inner headers of NS/NA messages for transmission through Relays 3159 that act as vanilla IPv6 routers. The messages include the AERO 3160 Server Subnet Router Anycast address as the source and the Subnet 3161 Router Anycast address corresponding to the Client's ACP as the 3162 destination. 3164 o Clients use Subnet Router Anycsat address as the encapsulation 3165 source address when the access network does not provide a 3166 topologically-fixed address. 3168 o 3170 Author's Address 3171 Fred L. Templin (editor) 3172 Boeing Research & Technology 3173 P.O. Box 3707 3174 Seattle, WA 98124 3175 USA 3177 Email: fltemplin@acm.org