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