idnits 2.17.1 draft-templin-intarea-6706bis-03.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 (December 17, 2018) is 1928 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 2426, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2472, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2704, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2723, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-06 == Outdated reference: A later version (-06) exists of draft-ietf-intarea-gue-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-25) exists of draft-ietf-rtgwg-atn-bgp-00 == Outdated reference: A later version (-05) exists of draft-templin-6man-aeroaddr-03 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-06 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-06 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-21 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 14 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, December 17, 2018 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: June 20, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-03.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 June 20, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 7 68 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 7 69 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 71 3.4. AERO 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 . . . . . . . . . . . . . 20 82 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 21 83 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 21 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 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. Processing NAs . . . . . . . . . . . . . . . . . . . 40 102 3.15.7. Server-Based Route Optimization . . . . . . . . . . 40 103 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 42 104 3.17. Mobility Management and Quality of Service (QoS) . . . . 43 105 3.17.1. Forwarding Packets on Behalf of Departed Clients . . 44 106 3.17.2. Announcing Link-Layer Address and/or QoS Preference 107 Changes . . . . . . . . . . . . . . . . . . . . . . 44 108 3.17.3. Bringing New Links Into Service . . . . . . . . . . 44 109 3.17.4. Removing Existing Links from Service . . . . . . . . 45 110 3.17.5. Implicit Mobility Management . . . . . . . . . . . . 45 111 3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 45 112 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 46 113 4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 46 114 5. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 48 115 6. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 48 116 7. SEcure Neighbor Discovery (SEND) . . . . . . . . . . . . . . 49 117 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 118 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 119 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 120 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 121 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 122 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 123 12.2. Informative References . . . . . . . . . . . . . . . . . 54 124 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 59 125 Appendix B. When to Insert an Encapsulation Fragment Header . . 61 126 Appendix C. Autoconfiguration for Constrained Platforms . . . . 62 127 Appendix D. Operational Deployment Alternatives . . . . . . . . 62 128 D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 62 129 D.2. Operation on Server-less AERO Links . . . . . . . . . . . 63 130 D.3. Operation on Client-less AERO Links . . . . . . . . . . . 63 131 D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 63 132 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 64 133 D.6. Encapsulation Protocol Version Considerations . . . . . . 64 134 D.7. Extending AERO Links Through Security Gateways . . . . . 64 135 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 66 136 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 67 138 1. Introduction 140 This document specifies the operation of IP over tunnel virtual links 141 using Asymmetric Extended Route Optimization (AERO). The AERO link 142 can be used for tunneling between neighboring nodes over either IPv6 143 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 144 equivalent links for tunneling. Nodes attached to AERO links can 145 exchange packets via trusted intermediate routers that provide 146 forwarding services to reach off-link destinations and route 147 optimization services for improved performance [RFC5522]. 149 AERO provides an IPv6 link-local address format that supports 150 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 151 links ND to IP forwarding. Dynamic link selection, mobility 152 management, quality of service (QoS) signaling and route optimization 153 are naturally supported through dynamic neighbor cache updates, while 154 IPv6 Prefix Delegation (PD) is supported by network services such as 155 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 156 [RFC3315][RFC3633]. 158 A node's AERO interface can be configured over multiple underlying 159 interfaces. From the standpoint of ND, AERO interface neighbors 160 therefore may appear to have multiple link-layer addresses (i.e., the 161 IP 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 following sections present 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 alternate services (e.g., based on ND messaging) are also 191 in scope 192 [I-D.templin-v6ops-pdhost][I-D.templin-6man-dhcpv6-ndopt]. 194 (native) Internetwork 195 a connected IP network topology over which the AERO link virtual 196 overlay is configured and native peer-to-peer communications are 197 supported. Example Internetworks include the global public 198 Internet, private enterprise networks, aviation networks, etc. 200 AERO link 201 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 202 configured over an underlying Internetwork. 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 207 tunneling 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 PDs from one or more AERO Servers. Following 225 PD, the Client assigns a Client AERO address to the AERO interface 226 for use in ND exchanges with other AERO nodes. A node that acts 227 as an AERO Client on one AERO interface can also act as an AERO 228 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 AERO address to the AERO interface to 234 support the operation of the ND/PD services. An AERO Server can 235 also act as an AERO Relay. 237 AERO Relay ("Relay") 238 an IP router that can relay IP packets between AERO Servers and/or 239 forward IP packets between the AERO link and the native 240 Internetwork. AERO Relays are standard IP routers that do not 241 require any AERO-specific functions. 243 AERO Proxy ("Proxy") 244 a node that provides proxying services, e.g., when the Client is 245 located in a secured internal enclave and the Server is located in 246 the external Internetwork. The AERO Proxy is a conduit between 247 the secured enclave and the external Internetwork in the same 248 manner as for common web proxies, and behaves in a similar fashion 249 as for ND proxies [RFC4389]. 251 ingress tunnel endpoint (ITE) 252 an AERO interface endpoint that injects encapsulated packets into 253 an AERO link. 255 egress tunnel endpoint (ETE) 256 an AERO interface endpoint that receives encapsulated packets from 257 an AERO link. 259 underlying network 260 the same as defined for Internetwork. 262 underlying link 263 a link that connects an AERO node to the underlying network. 265 underlying interface 266 an AERO node's interface point of attachment to an underlying 267 link. 269 link-layer address 270 an IP address assigned to an AERO node's underlying interface. 271 When UDP encapsulation is used, the UDP port number is also 272 considered as part of the link-layer address. Packets transmitted 273 over an AERO interface use link-layer addresses as encapsulation 274 header source and destination addresses. Destination link-layer 275 addresses can be either "reachable" or "unreachable" based on 276 dynamically-changing network conditions. 278 network layer address 279 the source or destination address of an encapsulated IP packet. 281 end user network (EUN) 282 an internal virtual or external edge IP network that an AERO 283 Client connects to the rest of the network via the AERO interface. 284 The Client sees each EUN as a "downstream" network and sees the 285 AERO interface as its point of attachment to the "upstream" 286 network. 288 AERO Service Prefix (ASP) 289 an IP prefix associated with the AERO link and from which more- 290 specific AERO Client Prefixes (ACPs) are derived. 292 AERO Client Prefix (ACP) 293 an IP prefix derived from an ASP and delegated to a Client, where 294 the ACP prefix length must be no shorter than the ASP prefix 295 length. 297 base AERO address 298 the lowest-numbered AERO address from the first ACP delegated to 299 the Client (see Section 3.4). 301 Throughout the document, the simple terms "Client", "Server", "Relay" 302 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 303 "AERO Proxy", respectively. Capitalization is used to distinguish 304 these terms from DHCPv6 client/server/relay [RFC3315]. 306 The terminology of DHCPv6 [RFC3315][RFC3633] and IPv6 ND [RFC4861] 307 (including the names of node variables, messages and protocol 308 constants) is used throughout this document. Also, the term "IP" is 309 used to generically refer to either Internet Protocol version, i.e., 310 IPv4 [RFC0791] or IPv6 [RFC8200]. 312 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 313 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 314 document are to be interpreted as described in [RFC2119]. Lower case 315 uses of these words are not to be interpreted as carrying RFC2119 316 significance. 318 3. Asymmetric Extended Route Optimization (AERO) 320 The following sections specify the operation of IP over Asymmetric 321 Extended Route Optimization (AERO) links: 323 3.1. AERO Link Reference Model 324 .-(::::::::) 325 .-(::::::::::::)-. 326 (:: Internetwork ::) 327 `-(::::::::::::)-' 328 `-(::::::)-' 329 | 330 +--------------+ +--------+-------+ +--------------+ 331 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 332 | Nbr: C1, R1 | | Nbr: S1, S2 | | Nbr: C2, R1 | 333 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 334 | X1->C1 | | ASP A1 | | X2->C2 | 335 +-------+------+ +--------+-------+ +------+-------+ 336 | AERO Link | | 337 X---+---+-------------------+-+----------------+---+---X 338 | | | 339 +-----+--------+ +----------+------+ +--------+-----+ 340 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 341 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 342 | default->S1 | +--------+--------+ | default->S2 | 343 | ACP X1 | | | ACP X2 | 344 +------+-------+ .--------+------. +-----+--------+ 345 | (- Proxyed Clients -) | 346 .-. `---------------' .-. 347 ,-( _)-. ,-( _)-. 348 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 349 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 350 `-(______)-' +-------+ +-------+ `-(______)-' 352 Figure 1: AERO Link Reference Model 354 Figure 1 presents the AERO link reference model. In this model: 356 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 357 default router for its associated Servers (S1 and S2), and 358 connects the AERO link to the rest of the Internetwork. 360 o AERO Servers S1 and S2 associate with Relay R1 and also act as 361 default routers for their associated Clients C1 and C2. 363 o AERO Clients C1 and C2 associate with Servers S1 and S2, 364 respectively. They receive AERO Client Prefix (ACP) delegations 365 X1 and X2, and also act as default routers for their associated 366 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 367 to the EUNs served by Clients C1 and C2, respectively. 369 o AERO Proxy P1 provides proxy services for AERO Clients in secured 370 enclaves that cannot associate directly with other AERO link 371 neighbors. 373 Each node on the AERO link maintains an AERO interface neighbor cache 374 and an IP forwarding table the same as for any link. Although the 375 figure shows a limited deployment, in common operational practice 376 there may be many additional Relays, Servers, Clients and Proxies. 378 3.2. AERO Node Types 380 AERO Relays are standard IP routers that provide default forwarding 381 services to AERO Servers. Each Relay also peers with Servers and 382 other Relays in a dynamic routing protocol instance to discover the 383 list of active ACPs (see Section 3.3). Relays forward packets 384 between neighbors connected to the same AERO link and also forward 385 packets between the AERO link and the native Internetwork. Relays 386 present the AERO link to the native Internetwork as a set of one or 387 more AERO Service Prefixes (ASPs) and serve as a gateway between the 388 AERO link and the Internetwork. Relays maintain tunnels with 389 neighboring Servers, and maintain an IP forwarding table entry for 390 each AERO Client Prefix (ACP). 392 AERO Servers provide default forwarding services to AERO Clients. 393 Each Server also peers with Relays in a dynamic routing protocol 394 instance to advertise its list of associated ACPs (see Section 3.3). 395 Servers facilitate PD exchanges with Clients, where each delegated 396 prefix becomes an ACP taken from an ASP. Servers forward packets 397 between AERO interface neighbors, and maintain AERO interface 398 neighbor cache entries for Relays. They also maintain both neighbor 399 cache entries and IP forwarding table entries for each of their 400 associated Clients. 402 AERO Clients act as requesting routers to receive ACPs through PD 403 exchanges with AERO Servers over the AERO link. Each Client can 404 associate with a single Server or with multiple Servers, e.g., for 405 fault tolerance, load balancing, etc. Each IPv6 Client receives at 406 least a /64 IPv6 ACP, and may receive even shorter prefixes. 407 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 408 singleton IPv4 address), and may receive even shorter prefixes. 409 Clients maintain an AERO interface neighbor cache entry for each of 410 their associated Servers as well as for each of their correspondent 411 Clients. 413 AERO Proxies provide a transparent conduit for AERO Clients connected 414 to secured enclaves to associate with AERO link Servers. The Client 415 sends all of its control plane messages to the Server's link-layer 416 address and the Proxy intercepts them before they leave the secured 417 enclave. The Proxy forwards the Client's control and data plane 418 messages to and from the Client's current Server(s). The Proxy may 419 also discover a more direct route toward a target destination via 420 AERO route optimization, in which case future outbound data packets 421 would be forwarded via the more direct route. The Proxy function is 422 specified in Section 4. 424 3.3. AERO Routing System 426 The AERO routing system comprises a private instance of the Border 427 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 428 and Servers and does not interact with either the public Internet BGP 429 routing system or the native Internetwork routing system. Relays 430 advertise only a small and unchanging set of ASPs to the native 431 Internetwork routing system instead of the full dynamically changing 432 set of ACPs. 434 In a reference deployment, each AERO Server is configured as an 435 Autonomous System Border Router (ASBR) for a stub Autonomous System 436 (AS) using an AS Number (ASN) that is unique within the BGP instance, 437 and each Server further uses eBGP to peer with one or more Relays but 438 does not peer with other Servers. All Relays are members of the same 439 hub AS using a common ASN, and use iBGP to maintain a consistent view 440 of all active ACPs currently in service. 442 Each Server maintains a working set of associated ACPs, and 443 dynamically announces new ACPs and withdraws departed ACPs in its 444 eBGP updates to Relays. Clients are expected to remain associated 445 with their current Servers for extended timeframes, however Servers 446 SHOULD selectively suppress updates for impatient Clients that 447 repeatedly associate and disassociate with them in order to dampen 448 routing churn. 450 Each Relay configures a black-hole route for each of its ASPs. By 451 black-holing the ASPs, the Relay will maintain forwarding table 452 entries only for the ACPs that are currently active, and packets 453 destined to all other ACPs will correctly incur Destination 454 Unreachable messages due to the black hole route. Relays do not send 455 eBGP updates for ACPs to Servers, but instead only originate a 456 default route. In this way, Servers have only partial topology 457 knowledge (i.e., they know only about the ACPs of their directly 458 associated Clients) and they forward all other packets to Relays 459 which have full topology knowledge. 461 Scaling properties of the AERO routing system are limited by the 462 number of BGP routes that can be carried by Relays. As of 2015, the 463 global public Internet BGP routing system manages more than 500K 464 routes with linear growth and no signs of router resource exhaustion 465 [BGP]. More recent network emulation studies have also shown that a 466 single Relay can accommodate at least 1M dynamically changing BGP 467 routes even on a lightweight virtual machine, i.e., and without 468 requiring high-end dedicated router hardware. 470 Therefore, assuming each Relay can carry 1M or more routes, this 471 means that at least 1M Clients can be serviced by a single set of 472 Relays. A means of increasing scaling would be to assign a different 473 set of Relays for each set of ASPs. In that case, each Server still 474 peers with one or more Relays, but the Server institutes route 475 filters so that it only sends BGP updates to the specific set of 476 Relays that aggregate the ASP. For example, if the ASP for the AERO 477 link is 2001:db8::/32, a first set of Relays could service the ASP 478 segment 2001:db8::/40, a second set of Relays could service 479 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 480 etc. 482 Assuming up to 1K sets of Relays, the AERO routing system can then 483 accommodate 1B or more ACPs with no additional overhead for Servers 484 and Relays (for example, it should be possible to service 1B /64 ACPs 485 taken from a /34 ASP and even more for shorter prefixes). In this 486 way, each set of Relays services a specific set of ASPs that they 487 advertise to the native Internetwork routing system, and each Server 488 configures ASP-specific routes that list the correct set of Relays as 489 next hops. This arrangement also allows for natural incremental 490 deployment, and can support small scale initial deployments followed 491 by dynamic deployment of additional Clients, Servers and Relays 492 without disturbing the already-deployed base. 494 In an alternate routing arrangement, each set of Relays could 495 advertise an aggregated ASP for the link into the native Internetwork 496 routing system even though each Relay services only smaller segments 497 of the ASP. In that case, a Relay upon receiving a packet with a 498 destination address covered by the ASP segment of another Relay can 499 simply tunnel the packet to the other Relay. The tradeoff then is 500 the penalty for Relay-to-Relay tunneling compared with reduced 501 routing information in the native routing system. 503 A full discussion of the BGP-based routing system used by AERO is 504 found in [I-D.ietf-rtgwg-atn-bgp]. 506 3.4. AERO Addresses 508 A Client's AERO address is an IPv6 link-local address with an 509 interface identifier based on the Client's delegated ACP. Relay and 510 Server AERO addresses are assigned from the range fe80::/96 and 511 include an administratively-provisioned value in the lower 32 bits. 513 For IPv6, Client AERO addresses begin with the prefix fe80::/64 and 514 include in the interface identifier (i.e., the lower 64 bits) a 515 64-bit prefix taken from one of the Client's IPv6 ACPs. For example, 516 if the AERO Client receives the IPv6 ACP: 518 2001:db8:1000:2000::/56 520 it constructs its corresponding AERO addresses as: 522 fe80::2001:db8:1000:2000 524 fe80::2001:db8:1000:2001 526 fe80::2001:db8:1000:2002 528 ... etc. ... 530 fe80::2001:db8:1000:20ff 532 For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6 533 address formed from an IPv4 ACP and with a Prefix Length of 96 plus 534 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 535 the IPv4-mapped IPv6 ACP is: 537 0:0:0:0:0:FFFF:192.0.2.16/124 539 The Client then constructs its AERO addresses with the prefix 540 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 541 in the interface identifier as: 543 fe80::FFFF:192.0.2.16 545 fe80::FFFF:192.0.2.17 547 fe80::FFFF:192.0.2.18 549 ... etc. ... 551 fe80:FFFF:192.0.2.31 553 Relay and Server AERO addresses are allocated from the range 554 fe80::/96, and MUST be managed for uniqueness by the administrative 555 authority for the link. For interfaces that assign static IPv4 556 addresses, the lower 32 bits of the AERO address includes the IPv4 557 address, e.g., for the IPv4 address 192.0.2.1 the corresponding AERO 558 address is fe80::192.0.2.1. For other interfaces, the lower 32 bits 559 of the AERO address includes a unique integer value, e.g., fe80::1, 560 fe80::2, fe80::3, etc. (Note that the address fe80:: is reserved as 561 the IPv6 link-local Subnet Router Anycast address [RFC4291], and the 562 address fe80::ffff:ffff is reserved as the prefix solicitation 563 address; hence, these values are not available for administrative 564 assignment.) 565 When the Server delegates ACPs to the Client, the lowest-numbered 566 AERO address from the first ACP delegation serves as the "base" AERO 567 address (for example, for the ACP 2001:db8:1000:2000::/56 the base 568 AERO address is fe80::2001:db8:1000:2000). The Client then assigns 569 the base AERO address to the AERO interface and uses it for the 570 purpose of maintaining the neighbor cache entry. The Server likewise 571 uses the AERO address as its index into the neighbor cache for this 572 Client. 574 If the Client has multiple AERO addresses (i.e., when there are 575 multiple ACPs and/or ACPs with prefix lengths shorter than /64), the 576 Client originates ND messages using the base AERO address as the 577 source address and accepts and responds to ND messages destined to 578 any of its AERO addresses as equivalent to the base AERO address. In 579 this way, the Client maintains a single neighbor cache entry that may 580 be indexed by multiple AERO addresses. 582 AERO addresses that embed an IPv6 prefix can be statelessly 583 transformed into an IPv6 Subnet Router Anycast address and vice- 584 versa. For example, for the AERO address fe80::2001:db8:2000:3000 585 the corresponding Subnet Router Anycast address is 586 2001:db8:2000:3000::. In the same way, for the IPv6 Subnet Router 587 Anycast address 2001:db8:1:2:: the corresponding AERO address is 588 fe80::2001:db8:1:2. In other words, the low-order 64 bits of an AERO 589 address can be used as the high-order 64 bits of a Subnet Router 590 Anycast address, and vice-versa. 592 AERO links additionally reserve an IPv6 prefix to support IPv6 ND 593 message exchanges between Servers on the link. Although any non- 594 link-local IPv6 prefix could be reserved for this purpose, a Unique 595 Local Address (ULA) prefix [RFC4389] would be a good candidate since 596 it is not routable outside of the AERO link. For example, if the 597 reserved (ULA) prefix is fd00:db8::/64 the AERO Server Subnet Router 598 Anycast Address is fd00:db8::. 600 A full discussion of the AERO addressing service is found in 601 [I-D.templin-6man-aeroaddr]. 603 3.5. AERO Interface Characteristics 605 AERO interfaces use encapsulation (see: Section 3.9) to exchange 606 packets with neighbors attached to the AERO link. 608 AERO interfaces maintain a neighbor cache for tracking per-neighbor 609 state the same as for any interface. AERO interfaces use ND messages 610 including Router Solicitation (RS), Router Advertisement (RA), 611 Neighbor Solicitation (NS), Neighbor Advertisement (NA) and Redirect 612 for neighbor cache management. 614 AERO interface ND messages include one or more Source/Target Link- 615 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Length = 5 | Reserved | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Interface ID | UDP Port Number | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | | 625 + + 626 | | 627 + IP Address + 628 | | 629 + + 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 642 Format 644 In this format: 646 o Type is set to '1' for SLLAO or '2' for TLLAO. 648 o Length is set to the constant value '5' (i.e., 5 units of 8 649 octets). 651 o Reserved is set to the value '0' on transmission and ignored on 652 receipt. 654 o Interface ID is set to a 16-bit integer value corresponding to an 655 underlying interface of the AERO node. Once the node has assigned 656 an Interface ID to an underlyng interface, the assignment must 657 remain unchanged until the node fully detaches from the AERO link. 659 o UDP Port Number and IP Address are set to the addresses used by 660 the AERO node when it sends encapsulated packets over the 661 specified underlying interface (or to '0' when the addresses are 662 left unspecified). When UDP is not used as part of the 663 encapsulation, UDP Port Number is set to '0'. When the 664 encapsulation IP address family is IPv4, IP Address is formed as 665 an IPv4-mapped IPv6 address as specified in Section 3.4. 667 o P(i) is a set of Preferences that correspond to the 64 668 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 669 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 670 ("medium") or '3' ("high") to indicate a QoS preference level for 671 packet forwarding purposes. 673 AERO interfaces may be configured over multiple underlying interface 674 connections to underlying links. For example, common mobile handheld 675 devices have both wireless local area network ("WLAN") and cellular 676 wireless links. These links are typically used "one at a time" with 677 low-cost WLAN preferred and highly-available cellular wireless as a 678 standby. In a more complex example, aircraft frequently have many 679 wireless data link types (e.g. satellite-based, cellular, 680 terrestrial, air-to-air directional, etc.) with diverse performance 681 and cost properties. 683 A Client's underlying interfaces are classified as follows: 685 o Native interfaces connect to the open Internetwork, and have a 686 global IP address that is reachable from any open Internetwork 687 correspondent. 689 o NATed interfaces connect to a closed network that is separated 690 from the open Internetwork by a Network Address Translator (NAT). 691 The NAT does not participate in any AERO control message 692 signaling, but the AERO Server can issue control messages on 693 behalf of the Client. 695 o VPNed interfaces use security encapsulation over the Internetwork 696 to a Virtual Private Network (VPN) gateway that also acts as an 697 AERO Server. As with NATed links, the AERO Server can issue 698 control messages on behalf of the Client. 700 o Proxyed interfaces connect to a closed network that is separated 701 from the open Internetwork by an AERO Proxy. Unlike NATed and 702 VPNed interfaces, the AERO Proxy can also issue control messages 703 on behalf of the Client. 705 o Direct interfaces connect the Client directly to a neighbor 706 without crossing any networked paths. An example is a line-of- 707 sight link between a remote pilot and an unmanned aircraft. 709 If a Client's multiple underlying interfaces are used "one at a time" 710 (i.e., all other interfaces are in standby mode while one interface 711 is active), then ND messages include only a single S/TLLAO with 712 Interface ID set to a constant value. In that case, the Client would 713 appear to have a single underlying interface but with a dynamically 714 changing link-layer address. 716 If the Client has multiple active underlying interfaces, then from 717 the perspective of ND it would appear to have multiple link-layer 718 addresses. In that case, ND messages MAY include multiple S/TLLAOs 719 -- each with an Interface ID that corresponds to a specific 720 underlying interface of the AERO node. 722 When the Client includes an S/TLLAO for an underlying interface for 723 which it is aware that there is a NAT or Proxy on the path to the 724 Server, or when a node includes an S/TLLAO solely for the purpose of 725 announcing new QoS preferences, the node sets both UDP Port Number 726 and IP Address to 0 to indicate that the addresses are unspecified at 727 the network layer and must instead be derived from the link-layer 728 encapsulation headers. 730 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 731 correspond to the AERO node's underlying interface used to transmit 732 the message. 734 3.6. AERO Interface Initialization 736 3.6.1. AERO Relay Behavior 738 When a Relay enables an AERO interface, it first assigns an 739 administratively-provisioned AERO address fe80::ID to the interface. 740 Each fe80::ID address MUST be unique among all AERO nodes on the 741 link. The Relay then engages in a dynamic routing protocol session 742 with one or more Servers and all other Relays on the link (see: 743 Section 3.3), and advertises its assigned ASPs into the native 744 Internetwork. Each Relay subsequently maintains an IP forwarding 745 table entry for each active ACP covered by its ASP(s). 747 3.6.2. AERO Server Behavior 749 When a Server enables an AERO interface, it assigns an 750 administratively-provisioned AERO address fe80::ID the same as for 751 Relays. The Server further configures a service to facilitate ND/PD 752 exchanges with AERO Clients. The Server maintains neighbor cache 753 entries for one or more Relays on the link, and manages per-Client 754 neighbor cache entries and IP forwarding table entries based on 755 control message exchanges. The Server also engages in a dynamic 756 routing protocol with its neighboring Relays (see: Section 3.3). 758 When the Server receives an NS/RS message on the AERO interface it 759 authenticates the message and returns an NA/RA message. (When the 760 Server receives an unsolicited NA message, it likewise authenticates 761 the message and processes it locally.) The Server further provides a 762 simple link-layer conduit between AERO interface neighbors. In 763 particular, when a packet sent by a source Client arrives on the 764 Server's AERO interface and is destined to another AERO node, the 765 Server forwards the packet from within the AERO interface at the link 766 layer without ever disturbing the network layer. 768 3.6.3. AERO Client Behavior 770 When a Client enables an AERO interface, it sends RS messages with 771 ND/PD parameters over an underlying interface to one or more AERO 772 Servers, which return RA messages with corresponding PD parameters. 773 See [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters 774 that can be included in the RS/RA message exchanges. 776 After the initial ND/PD message exchange, the Client assigns AERO 777 addresses to the AERO interface based on the delegated prefix(es). 778 The Client can then register additional underlying interfaces with 779 the Server by sending a simple RS message (i.e., one with no PD 780 parameters) over each underlying interface using its base AERO 781 address as the source network layer address. The Server will update 782 its neighbor cache entry for the Client and return a simple RA 783 message. 785 The Client maintains a neighbor cache entry for each of its Servers 786 and each of its active correspondent Clients. When the Client 787 receives ND messages on the AERO interface it updates or creates 788 neighbor cache entries, including link-layer address and QoS 789 preferences. 791 3.6.4. AERO Proxy Behavior 793 When a Proxy enables an AERO interface, it maintains per-Client proxy 794 neighbor cache entries based on control message exchanges. Proxies 795 forward packets between their associated Clients and each Client's 796 associated Servers. 798 When the Proxy receives an RS message from a Client in the secured 799 enclave, it creates an incomplete proxy neighbor cache entry and 800 sends a proxyed RS message to a Server selected by the Client while 801 using its own link-layer address as the source address. When the 802 Server returns an RA message, the Proxy completes the proxy neighbor 803 cache entry based on autoconfiguration information in the RA and 804 sends a proxyed RA to the Client while using its own link-layer 805 address as the source address. The Client, Server and Proxy will 806 then have the necessary state for managing the proxy neighbor 807 association. 809 3.7. AERO Interface Neighbor Cache Maintenance 811 Each AERO interface maintains a conceptual neighbor cache that 812 includes an entry for each neighbor it communicates with on the AERO 813 link, the same as for any IPv6 interface [RFC4861]. AERO interface 814 neighbor cache entries are said to be one of "permanent", "static", 815 "proxy" or "dynamic". 817 Permanent neighbor cache entries are created through explicit 818 administrative action; they have no timeout values and remain in 819 place until explicitly deleted. AERO Relays maintain permanent 820 neighbor cache entries for their associated Relays and Servers on the 821 link, and AERO Servers maintain permanent neighbor cache entries for 822 their associated Relays. Each entry maintains the mapping between 823 the neighbor's fe80::ID network-layer address and corresponding link- 824 layer address. 826 Static neighbor cache entries are created and maintained through ND/ 827 PD exchanges as specified in Section 3.14, and remain in place for 828 durations bounded by ND/PD lifetimes. AERO Servers maintain static 829 neighbor cache entries for each of their associated Clients, and AERO 830 Clients maintain static neighbor cache entries for each of their 831 associated Servers. 833 Proxy neighbor cache entries are created and maintained by AERO 834 Proxies when they process Client/Server ND/PD exchanges, and remain 835 in place for durations bounded by ND/PD lifetimes. AERO Proxies 836 maintain proxy neighbor cache entries for each of their associated 837 Clients. 839 Dynamic neighbor cache entries are created or updated based on 840 receipt of route optimization messages as specified in Section 3.15, 841 and are garbage-collected when keepalive timers expire. AERO nodes 842 maintain dynamic neighbor cache entries for each of their active 843 correspondents with lifetimes based on ND messaging constants. 845 When a target AERO node receives a valid NS message used for route 846 optimization, it returns an NA message and also creates or updates a 847 dynamic neighbor cache entry for the source network-layer and link- 848 layer addresses. The node then sets a "ReportTime" variable in the 849 neighbor cache entry to REPORT_TIME seconds. The node resets 850 ReportTime when it receives a new NS message, and otherwise 851 decrements ReportTime while no NS messages have been received. It is 852 RECOMMENDED that REPORT_TIME be set to the default constant value 40 853 seconds to allow a 10 second window so that the AERO route 854 optimization procedure can converge before ReportTime decrements 855 below FORWARD_TIME (see below). 857 When a source AERO node receives a valid NA message response to its 858 NS message, it creates or updates a dynamic neighbor cache entry for 859 the target network-layer and link-layer addresses. The node then 860 sets a "ForwardTime" variable in the neighbor cache entry to 861 FORWARD_TIME seconds and uses this value to determine whether packets 862 can be forwarded directly to the correspondent, i.e., instead of via 863 a default route. The node resets ForwardTime when it receives a new 864 NA, and otherwise decrements ForwardTime while no further NA messages 865 arrive. It is RECOMMENDED that FORWARD_TIME be set to the default 866 constant value 30 seconds to match the default REACHABLE_TIME value 867 specified in [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 REPORT_TIME, FORWARD_TIME and MAX_RETRY MAY be 875 administratively set; however, if different values are chosen, all 876 nodes on the link MUST consistently configure the same values. Most 877 importantly, REPORT_TIME SHOULD be set to a value that is 878 sufficiently longer than FORWARD_TIME to allow the AERO route 879 optimization procedure to converge. 881 When there may be a NAT or Proxy between the Client and the Server, 882 or if the path from the Client to the Server should be tested for 883 reachability, the Client can send periodic RS messages to the Server 884 without PD parameters to receive RA replies. The RS/RA messaging 885 will keep NAT/Proxy state alive and test Server reachability without 886 disturbing the PD service. 888 3.8. AERO Interface Forwarding Algorithm 890 IP packets enter a node's AERO interface either from the network 891 layer (i.e., from a local application or the IP forwarding system) or 892 from the link layer (i.e., from the AERO tunnel virtual link). 893 Packets that enter the AERO interface from the network layer are 894 encapsulated and forwarded into the AERO link, i.e., they are 895 tunneled to an AERO interface neighbor. Packets that enter the AERO 896 interface from the link layer are either re-admitted into the AERO 897 link or forwarded to the network layer where they are subject to 898 either local delivery or IP forwarding. In all cases, the AERO 899 interface itself MUST NOT decrement the network layer TTL/Hop-count 900 since its forwarding actions occur below the network layer. 902 AERO interfaces may have multiple underlying interfaces and/or 903 neighbor cache entries for neighbors with multiple Interface ID 904 registrations (see Section 3.5). The AERO node uses each packet's 905 DSCP value to select an outgoing underlying interface based on the 906 node's own QoS preferences, and also to select a destination link- 907 layer address based on the neighbor's underlying interface with the 908 highest preference. If multiple outgoing interfaces and/or neighbor 909 interfaces have a preference of "high", the AERO node sends one copy 910 of the packet via each of the (outgoing / neighbor) interface pairs; 911 otherwise, the node sends a single copy of the packet via the 912 interface with the highest preference. AERO nodes keep track of 913 which underlying interfaces are currently "reachable" or 914 "unreachable", and only use "reachable" interfaces for forwarding 915 purposes. 917 The following sections discuss the AERO interface forwarding 918 algorithms for Clients, Proxies, Servers and Relays. In the 919 following discussion, a packet's destination address is said to 920 "match" if it is a non-link-local address with a prefix covered by an 921 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 922 the same as an administratively-provisioned AERO address. 924 3.8.1. Client Forwarding Algorithm 926 When an IP packet enters a Client's AERO interface from the network 927 layer the Client searches for a dynamic neighbor cache entry that 928 matches the destination. If there is a match, the Client uses one or 929 more "reachable" link-layer addresses in the entry as the link-layer 930 addresses for encapsulation and admits the packet into the AERO link. 931 Otherwise, the Client uses the link-layer address in a static 932 neighbor cache entry for a Server as the encapsulation address 933 (noting that there may be a Proxy on the path to the real Server). 935 When an IP packet enters a Client's AERO interface from the link- 936 layer, if the destination matches one of the Client's ACPs or link- 937 local addresses the Client decapsulates the packet and delivers it to 938 the network layer. Otherwise, the Client drops the packet and MAY 939 return a network-layer ICMP Destination Unreachable message subject 940 to rate limiting (see: Section 3.13). 942 3.8.2. Proxy Forwarding Algorithm 944 When the Proxy receives a packet from a Client within the secured 945 enclave, the Proxy searches for a dynamic neighbor cache entry that 946 matches the destination. If there is a match, the Proxy uses one or 947 more "reachable" link-layer addresses in the entry as the link-layer 948 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 and re-admitting the packet into the 959 AERO link. 961 3.8.3. Server Forwarding Algorithm 963 When an IP packet enters a Server's AERO interface from the network 964 layer, the Server searches for a static neighbor cache entry for a 965 Client that matches the destination. If there is a match, the Server 966 uses one or more link-layer addresses in the entry as the link-layer 967 addresses for encapsulation and admits the packet into the AERO link. 968 Otherwise, the Server uses the link-layer address in a permanent 969 neighbor cache entry for a Relay (selected through longest-prefix 970 match) as the link-layer address for encapsulation. 972 When an IP packet enters a Server's AERO interface from the link 973 layer, the Server processes the packet according to the network-layer 974 destination address as follows: 976 o if the destination matches one of the Server's own addresses the 977 Server decapsulates the packet and forwards it to the network 978 layer for local delivery. 980 o else, if the destination matches a static neighbor cache entry for 981 a Client the Server first determines whether the neighbor is the 982 same as the one it received the packet from. If so, the Server 983 drops the packet silently to avoid looping; otherwise, the Server 984 uses the neighbor's link-layer address(es) as the destination for 985 encapsulation and re-admits the packet into the AERO link. 987 o else, the Server uses the link-layer address in a neighbor cache 988 entry for a Relay (selected through longest-prefix match) as the 989 link-layer address for encapsulation. 991 3.8.4. Relay Forwarding Algorithm 993 When an IP packet enters a Relay's AERO interface from the network 994 layer, the Relay searches its IP forwarding table for an ACP entry 995 that matches the destination the same as for any IP router. If there 996 is a match, the Relay uses the link-layer address in the 997 corresponding neighbor cache entry as the link-layer address for 998 encapsulation and forwards the packet to the AERO neighbor. 999 Otherwise, the Relay drops the packet and returns a network-layer 1000 ICMP Destination Unreachable message subject to rate limiting (see: 1001 Section 3.13). 1003 When an IP packet enters a Relay's AERO interface from the link- 1004 layer, (i.e., when it receives an encapsulated packet from a Server) 1005 the Relay processes the packet as follows: 1007 o if the destination does not match an ASP, or if the destination 1008 matches one of the Relay's own addresses, the Relay decapsulates 1009 the packet and forwards it to the network layer where it will be 1010 subject to either IP forwarding or local delivery. 1012 o else, if the destination matches an ACP entry in the IP forwarding 1013 table the Relay first determines whether the neighbor is the same 1014 as the one it received the packet from. If so the Relay MUST drop 1015 the packet silently to avoid looping; otherwise, the Relay uses 1016 the neighbor's link-layer address as the destination for 1017 encapsulation and re-admits the packet into the AERO link. 1019 o else, the Relay drops the packet and returns an ICMP Destination 1020 Unreachable message subject to rate limiting (see: Section 3.13). 1022 3.8.5. Processing Return Packets 1024 When an AERO Server receives a return packet from an AERO Proxy (see 1025 Section 3.8.2), it proceeds according to the AERO link trust basis. 1026 Namely, the return packets have the same trust profile as for link- 1027 layer Destination Unreachable messages. If the Server has sufficient 1028 trust basis to accept link-layer Destination Unreachable messages, it 1029 can then process the return packet by searching for a dynamic 1030 neighbor cache entry that matches the destination. If there is a 1031 match, the Server marks the corresponding link-layer address as 1032 "unreachable", selects the next-highest priority "reachable" link- 1033 layer address in the entry as the link-layer address for 1034 encapsulation then (re)admits the packet into the AERO link. If 1035 there are no "reachable" link-layer addresses, the Server instead 1036 sets ForwardTime in the dynamic neighbor cache entry to 0 (noting 1037 that ReportTime may still be non-zero). Otherwise, the Server SHOULD 1038 drop the packet and treat it as an indication that a path may be 1039 failing, and MAY use Neighbor Unreachability Detection (NUD) (see: 1040 Section 3.13) to test the path for reachability. 1042 When an AERO Relay receives a return packet from an AERO Server, it 1043 searches its routing table for an entry that matches the inner 1044 destination address. If there is a routing table entry that lists a 1045 different Server as the next hop, the Relay forwards the packet to 1046 the different Server; otherwise, the Relay 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 (e.g., see: Appendix A, [RFC2784], 1059 [RFC8086], [RFC4301], etc.). For packets entering the AERO interface 1060 from the network layer, the AERO interface copies the "TTL/Hop 1061 Limit", "Type of Service/Traffic Class" [RFC2983], "Flow 1062 Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168] 1063 values in the packet's IP header into the corresponding fields in the 1064 encapsulation IP header. For packets undergoing re-encapsulation, 1065 the AERO interface instead copies these values from the original 1066 encapsulation IP header into the new encapsulation header, i.e., the 1067 values are transferred between encapsulation headers and *not* copied 1068 from the encapsulated packet's network-layer header. (Note 1069 especially that by copying the TTL/Hop Limit between encapsulation 1070 headers the value will eventually decrement to 0 if there is a 1071 (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation, 1072 the AERO interface sets the DF bit as 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 When GUE encapsulation is not available, encapsulation between 1096 Servers and Relays can use standard mechanisms such as Generic 1097 Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec 1098 [RFC4301] so that Relays can be standard IP routers with no AERO- 1099 specific mechanisms. 1101 3.10. AERO Interface Decapsulation 1103 AERO interfaces decapsulate packets destined either to the AERO node 1104 itself or to a destination reached via an interface other than the 1105 AERO interface the packet was received on. Decapsulation is per the 1106 procedures specified for the appropriate encapsulation format. 1108 3.11. AERO Interface Data Origin Authentication 1110 AERO nodes employ simple data origin authentication procedures for 1111 encapsulated packets they receive from other nodes on the AERO link. 1112 In particular: 1114 o AERO Relays and Servers accept encapsulated packets with a link- 1115 layer source address that matches a permanent neighbor cache 1116 entry. 1118 o AERO Servers accept authentic encapsulated ND messages from 1119 Clients (either directly or via a Proxy), and create or update a 1120 static neighbor cache entry for the Client based on the specific 1121 message type. 1123 o AERO Clients and Servers accept encapsulated packets if there is a 1124 static neighbor cache entry with a link-layer address that matches 1125 the packet's link-layer source address. 1127 o AERO Proxies accept encapsulated packets if there is a proxy 1128 neighbor cache entry that matches the packet's network-layer 1129 address. 1131 Each packet should include a signature that the recipient can use to 1132 authenticate the message origin, e.g., as for common VPN systems such 1133 as OpenVPN [OVPN]. In some environments, however, it may be 1134 sufficient to require signatures only for ND control plane messages 1135 (see: Section 10) and omit signatures for data plane messages. 1137 3.12. AERO Interface Packet Size Issues 1139 The AERO interface is the node's attachment to the AERO link. The 1140 AERO interface acts as a tunnel ingress when it sends a packet to an 1141 AERO link neighbor and as a tunnel egress when it receives a packet 1142 from an AERO link neighbor. AERO interfaces observe the packet 1143 sizing considerations for tunnels discussed in 1144 [I-D.ietf-intarea-tunnels] and as specified below. 1146 The Internet Protocol expects that IP packets will either be 1147 delivered to the destination or a suitable Packet Too Big (PTB) 1148 message returned to support the process known as IP Path MTU 1149 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1150 crafted for malicious purposes such as denial of service, or lost in 1151 the network [RFC2923]. This can be especially problematic for 1152 tunnels, where a condition known as a PMTUD "black hole" can result. 1153 For these reasons, AERO interfaces employ operational procedures that 1154 avoid interactions with PMTUD, including the use of fragmentation 1155 when necessary. 1157 AERO interfaces observe two different types of fragmentation. Source 1158 fragmentation occurs when the AERO interface (acting as a tunnel 1159 ingress) fragments the encapsulated packet into multiple fragments 1160 before admitting each fragment into the tunnel. Network 1161 fragmentation occurs when an encapsulated packet admitted into the 1162 tunnel by the ingress is fragmented by an IPv4 router on the path to 1163 the egress. Note that a packet that incurs source fragmentation may 1164 also incur network fragmentation. 1166 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1167 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1168 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1169 for IPv4 even if encapsulated packets may incur network 1170 fragmentation. 1172 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1173 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1174 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1175 than the IPv4 minimum). 1177 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1178 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1179 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1180 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1181 configure a Maximum Segment Unit (MSU) as the maximum-sized 1182 encapsulated packet that the ingress can inject into the tunnel 1183 without source fragmentation. The MSU value MUST NOT be larger than 1184 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1185 operational assurance that a larger size can traverse the link along 1186 all paths. 1188 All AERO nodes MUST configure the same MTU/MSU values for reasons 1189 cited in [RFC3819][RFC4861]; in particular, multicast support 1190 requires a common MTU value among all nodes on the link. All AERO 1191 nodes MUST configure an MRU large enough to reassemble packets up to 1192 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1193 enough MRU MUST NOT enable an AERO interface. 1195 The network layer proceeds as follow when it presents an IP packet to 1196 the AERO interface. For each IPv4 packet that is larger than the 1197 AERO interface MTU and with the DF bit set to 0, the network layer 1198 uses IPv4 fragmentation to break the packet into a minimum number of 1199 non-overlapping fragments where the first fragment is no larger than 1200 the MTU and the remaining fragments are no larger than the first. 1201 For all other IP packets, if the packet is larger than the AERO 1202 interface MTU, the network layer drops the packet and returns a PTB 1203 message to the original source. Otherwise, the network layer admits 1204 each IP packet or fragment into the AERO interface. 1206 For each IP packet admitted into the AERO interface, the interface 1207 (acting as a tunnel ingress) encapsulates the packet. If the 1208 encapsulated packet is larger than the AERO interface MSU the ingress 1209 source-fragments the encapsulated packet into a minimum number of 1210 non-overlapping fragments where the first fragment is no larger than 1211 the MSU and the remaining fragments are no larger than the first. 1212 The ingress then admits each encapsulated packet or fragment into the 1213 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1214 header in case any network fragmentation is necessary. The 1215 encapsulated packets will be delivered to the egress, which 1216 reassembles them into a whole packet if necessary. 1218 Several factors must be considered when fragmentation is needed. For 1219 AERO links over IPv4, the IP ID field is only 16 bits in length, 1220 meaning that fragmentation at high data rates could result in data 1221 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1222 AERO links over both IPv4 and IPv6, studies have also shown that IP 1223 fragments are dropped unconditionally over some network paths [I- 1224 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1225 issues could result in operational problems, the ingress SHOULD 1226 employ intermediate-layer source fragmentation (see: [RFC2764] and 1227 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1228 encapsulation headers to each fragment. Since the encapsulation 1229 fragment header reduces the room available for packet data, but the 1230 original source has no way to control its insertion, the ingress MUST 1231 include the fragment header length in the ENCAPS length even for 1232 packets in which the header is absent. 1234 3.13. AERO Interface Error Handling 1236 When an AERO node admits encapsulated packets into the AERO 1237 interface, it may receive link-layer or network-layer error 1238 indications. 1240 A link-layer error indication is an ICMP error message generated by a 1241 router in the underlying network on the path to the neighbor or by 1242 the neighbor itself. The message includes an IP header with the 1243 address of the node that generated the error as the source address 1244 and with the link-layer address of the AERO node as the destination 1245 address. 1247 The IP header is followed by an ICMP header that includes an error 1248 Type, Code and Checksum. Valid type values include "Destination 1249 Unreachable", "Time Exceeded" and "Parameter Problem" 1250 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1251 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1252 only emit packets that are guaranteed to be no larger than the IP 1253 minimum link MTU as discussed in Section 3.12.) 1255 The ICMP header is followed by the leading portion of the packet that 1256 generated the error, also known as the "packet-in-error". For 1257 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1258 much of invoking packet as possible without the ICMPv6 packet 1259 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1260 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1261 "Internet Header + 64 bits of Original Data Datagram", however 1262 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1263 ICMP datagram SHOULD contain as much of the original datagram as 1264 possible without the length of the ICMP datagram exceeding 576 1265 bytes". 1267 The link-layer error message format is shown in Figure 3 (where, "L2" 1268 and "L3" refer to link-layer and network-layer, respectively): 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 ~ ~ 1272 | L2 IP Header of | 1273 | error message | 1274 ~ ~ 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | L2 ICMP Header | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1278 ~ ~ P 1279 | IP and other encapsulation | a 1280 | headers of original L3 packet | c 1281 ~ ~ k 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1283 ~ ~ t 1284 | IP header of | 1285 | original L3 packet | i 1286 ~ ~ n 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 ~ ~ e 1289 | Upper layer headers and | r 1290 | leading portion of body | r 1291 | of the original L3 packet | o 1292 ~ ~ r 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1295 Figure 3: AERO Interface Link-Layer Error Message Format 1297 The AERO node rules for processing these link-layer error messages 1298 are as follows: 1300 o When an AERO node receives a link-layer Parameter Problem message, 1301 it processes the message the same as described as for ordinary 1302 ICMP errors in the normative references [RFC0792][RFC4443]. 1304 o When an AERO node receives persistent link-layer Time Exceeded 1305 messages, the IP ID field may be wrapping before earlier fragments 1306 awaiting reassembly have been processed. In that case, the node 1307 SHOULD begin including integrity checks and/or institute rate 1308 limits for subsequent packets. 1310 o When an AERO node receives persistent link-layer Destination 1311 Unreachable messages in response to encapsulated packets that it 1312 sends to one of its dynamic neighbor correspondents, the node 1313 SHOULD process the message as an indication that a path may be 1314 failing, and MAY initiate NUD over that path. If it receives 1315 Destination Unreachable messages on many or all paths, the node 1316 SHOULD set ForwardTime for the corresponding dynamic neighbor 1317 cache entry to 0 and allow future packets destined to the 1318 correspondent to flow through a default route. 1320 o When an AERO Client receives persistent link-layer Destination 1321 Unreachable messages in response to encapsulated packets that it 1322 sends to one of its static neighbor Servers, the Client SHOULD 1323 mark the path as unusable and use another path. If it receives 1324 Destination Unreachable messages on many or all paths, the Client 1325 SHOULD associate with a new Server and release its association 1326 with the old Server as specified in Section 3.17.6. 1328 o When an AERO Server receives persistent link-layer Destination 1329 Unreachable messages in response to encapsulated packets that it 1330 sends to one of its static neighbor Clients, the Server SHOULD 1331 mark the underlying path as unusable and use another underlying 1332 path. If it receives Destination Unreachable messages on multiple 1333 paths, the Server should take no further actions unless it 1334 receives an explicit ND/PD release message or if the PD lifetime 1335 expires. In that case, the Server MUST release the Client's 1336 delegated ACP, withdraw the ACP from the AERO routing system and 1337 delete the neighbor cache entry. 1339 o When an AERO Relay or Server receives link-layer Destination 1340 Unreachable messages in response to an encapsulated packet that it 1341 sends to one of its permanent neighbors, it treats the messages as 1342 an indication that the path to the neighbor may be failing. 1343 However, the dynamic routing protocol should soon reconverge and 1344 correct the temporary outage. 1346 When an AERO Relay receives a packet for which the network-layer 1347 destination address is covered by an ASP, if there is no more- 1348 specific routing information for the destination the Relay drops the 1349 packet and returns a network-layer Destination Unreachable message 1350 subject to rate limiting. The Relay writes the network-layer source 1351 address of the original packet as the destination address and uses 1352 one of its non link-local addresses as the source address of the 1353 message. 1355 When an AERO node receives an encapsulated packet for which the 1356 reassembly buffer it too small, it drops the packet and returns a 1357 network-layer Packet Too Big (PTB) message. The node first writes 1358 the MRU value into the PTB message MTU field, writes the network- 1359 layer source address of the original packet as the destination 1360 address and writes one of its non link-local addresses as the source 1361 address. 1363 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1365 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1366 coordinated as discussed in the following Sections. 1368 3.14.1. AERO ND/PD Service Model 1370 Each AERO Server configures a PD service to facilitate Client 1371 requests. Each Server is provisioned with a database of ACP-to- 1372 Client ID mappings for all Clients enrolled in the AERO system, as 1373 well as any information necessary to authenticate each Client. The 1374 Client database is maintained by a central administrative authority 1375 for the AERO link and securely distributed to all Servers, e.g., via 1376 the Lightweight Directory Access Protocol (LDAP) [RFC4511], via 1377 static configuration, etc. Therefore, no Server-to-Server PD state 1378 synchronization is necessary, and Clients can optionally hold 1379 separate PDs for the same ACPs from multiple Servers. In this way, 1380 Clients can associate with multiple Servers, and can receive new PDs 1381 from new Servers before releasing PDs received from existing Servers. 1382 This provides the Client with a natural fault-tolerance and/or load 1383 balancing profile. 1385 AERO Clients and Servers use ND messages to maintain neighbor cache 1386 entries. AERO Servers configure their AERO interfaces as advertising 1387 interfaces, and therefore send unicast RA messages with configuration 1388 information in response to a Client's RS message. Thereafter, 1389 Clients send additional RS messages to the Server's unicast address 1390 to refresh prefix and/or router lifetimes. 1392 AERO Clients and Servers include PD parameters in the RS/RA messages 1393 they exchange (see: [I-D.templin-6man-dhcpv6-ndopt]). The unified 1394 ND/PD messages are exchanged between Client and Server according to 1395 the prefix management schedule required by the PD service. 1397 On Some AERO links, PD arrangements may be through some out-of-band 1398 service such as network management, static configuration, etc. In 1399 those cases, AERO nodes can use simple RS/RA message exchanges with 1400 no explicit PD options. Instead, the RS/RA messages use AERO 1401 addresses as a means of representing the delegated prefixes, e.g., if 1402 a message includes a source address of "fe80::2001:db8:1:2" then the 1403 recipient can infer that the sender holds the prefix delegation 1404 "2001:db8:1:2::/N" (where 'N' is the prefix length common to all ACPs 1405 for the link). 1407 The following sections specify the Client and Server behavior. 1409 3.14.2. AERO Client Behavior 1411 AERO Clients discover the link-layer addresses of AERO Servers via 1412 static configuration (e.g., from a flat-file map of Server addresses 1413 and locations), or through an automated means such as Domain Name 1414 System (DNS) name resolution [RFC1035]. In the absence of other 1415 information, the Client resolves the DNS Fully-Qualified Domain Name 1416 (FQDN) "linkupnetworks.[domainname]" where "linkupnetworks" is a 1417 constant text string and "[domainname]" is a DNS suffix for the 1418 Client's underlying interface (e.g., "example.com"). After 1419 discovering the link-layer addresses, the Client associates with one 1420 or more of the corresponding Servers. 1422 To associate with a Server, the Client acts as a requesting router to 1423 request ACPs through an ND/PD message exchange. The Client sends an 1424 RS message with PD parameters and with all-routers multicast as the 1425 IPv6 destination address, the address of the Client's underlying 1426 interface as the link-layer source address and the link-layer address 1427 of the Server as the link-layer destination address. If the Client 1428 already knows its own AERO address, it uses the AERO address as the 1429 IPv6 source address; otherwise, it uses the prefix-solicitation 1430 address as the source address. If the Client's underlying interface 1431 connects to a subnetwork that supports ACP injection, the Client can 1432 use the ACP's Subnet Router Anycast address as the link-layer source 1433 address. 1435 The Client next includes one or more SLLAOs in the RS message 1436 formatted as described in Section 3.5 to register its link-layer 1437 address(es) with the Server. The first SLLAO MUST correspond to the 1438 underlying interface over which the Client will send the RS message. 1439 The Client MAY include additional SLLAOs specific to other underlying 1440 interfaces, but if so it sets their UDP Port Number and IP Address 1441 fields to 0. The Client can instead register additional link-layer 1442 addresses with the Server by sending additional RS messages including 1443 SLLAOs via other underlying interfaces after the initial RS/RA 1444 exchange. 1446 The Client then sends the RS message to the AERO Server and waits for 1447 an RA message reply (see Section 3.14.3) while retrying MAX_RETRY 1448 times until an RA is received. If the Client receives no RAs, or if 1449 it receives an RA with Router Lifetime set to 0 and/or with no ACP PD 1450 parameters, the Client SHOULD discontinue autoconfiguration attempts 1451 through this Server and try another Server. Otherwise, the Client 1452 processes the ACPs found in the RA message. 1454 Next, the Client creates a static neighbor cache entry with the 1455 Server's link-local address as the network-layer address and the 1456 Server's encapsulation source address as the link-layer address. The 1457 Client then autoconfigures AERO addresses for each of the delegated 1458 ACPs and assigns them to the AERO interface. 1460 The Client next examines the P bit in the RA message flags field 1461 [RFC5175]. If the P bit value was 1, the Client infers that there is 1462 a NAT or Proxy on the path to the Server via the interface over which 1463 it sent the RS message. In that case, the Client sets UDP Port 1464 Number and IP Address to 0 in the S/TLLAOs of any subsequent ND 1465 messages it sends to the Server over that link. 1467 The Client also caches any ASPs included in Route Information Options 1468 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1469 the MTU/MSU values in the MTU options to its AERO interface while 1470 configuring an appropriate MRU. This configuration information 1471 applies to the AERO link as a whole, and all AERO nodes will receive 1472 the same values. 1474 Following autoconfiguration, the Client sub-delegates the ACPs to its 1475 attached EUNs and/or the Client's own internal virtual interfaces as 1476 described in [I-D.templin-v6ops-pdhost] to support the Client's 1477 downstream attached "Internet of Things (IoT)". The Client 1478 subsequently maintains its ACP delegations through each of its 1479 Servers by sending RS messages with PD parameters to receive 1480 corresponding RA messages. 1482 After the Client registers its Interface IDs and their associated 1483 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1484 Interface ID registrations, e.g., if an underlying interface changes 1485 address or becomes unavailable, if QoS preferences change, etc. To 1486 do so, the Client prepares an unsolicited NA message to send over any 1487 available underlying interface. The target address of the NA message 1488 is set to the Client's link-local address, and the destination 1489 address is set to all-nodes multicast. The NA MUST include a TLLAO 1490 specific to the selected available underlying interface as the first 1491 TLLAO and MAY include any additional TLLAOs specific to other 1492 underlying interfaces. The Client includes fresh 'P(i)' values in 1493 each TLLAO to update the Server's neighbor cache entry. If the 1494 Client wishes to update 'P(i)' values without updating the link-layer 1495 address, it sets the UDP Port Number and IP Address fields to 0. If 1496 the Client wishes to disable the interface, it sets all 'P(i)' values 1497 to '0' ("disabled"). 1499 If the Client wishes to discontinue use of a Server it issues an RS 1500 message with PD parameters that will cause the Server to release the 1501 Client. When the Server processes the message, it releases the ACP, 1502 deletes its neighbor cache entry for the Client, withdraws the IP 1503 route from the routing system and returns an RA reply containing any 1504 necessary PD parameters. 1506 3.14.3. AERO Server Behavior 1508 AERO Servers act as IPv6 routers and support a PD service for 1509 Clients. AERO Servers arrange to add their encapsulation layer IP 1510 addresses (i.e., their link-layer addresses) to a static map of 1511 Server addresses for the link and/or the DNS resource records for the 1512 FQDN "linkupnetworks.[domainname]" before entering service. 1514 When an AERO Server receives a prospective Client's RS message with 1515 PD parameters on its AERO interface, and the Server is too busy, it 1516 SHOULD return an immediate RA reply with no ACPs and with Router 1517 Lifetime set to 0. Otherwise, the Server authenticates the RS 1518 message and processes the PD parameters. The Server first determines 1519 the correct ACPs to delegate to the Client by searching the Client 1520 database. When the Server delegates the ACPs, it also creates an IP 1521 forwarding table entry for each ACP so that the AERO BGP-based 1522 routing system will propagate the ACPs to the Relays that aggregate 1523 the corresponding ASP (see: Section 3.3). 1525 Next, the Server prepares an RA message that includes the delegated 1526 ACPs and any other PD parameters. The Server then returns the RA 1527 message using its link-local address as the network-layer source 1528 address, the network-layer source address of the RS message as the 1529 network-layer destination address, the Server's link-layer address as 1530 the source link-layer address, and the source link-layer address of 1531 the RS message as the destination link-layer address. The Server 1532 next sets the P flag in the RA message flags field [RFC5175] to 1 if 1533 the source link-layer address in the RS message was different than 1534 the address in the first SLLAO to indicate that there is a NAT or 1535 Proxy on the path; otherwise it sets P to 0. The Server then 1536 includes one or more RIOs that encode the ASPs for the AERO link. 1537 The Server also includes two MTU options - the first MTU option 1538 includes the MTU for the link and the second MTU option includes the 1539 MSU for the link (see Section 3.12). The Server finally sends the RA 1540 message to the Client. 1542 The Server next creates a static neighbor cache entry for the Client 1543 using the base AERO address as the network-layer address and with 1544 lifetime set to no more than the smallest PD lifetime. Next, the 1545 Server updates the neighbor cache entry link-layer address(es) by 1546 recording the information in each SLLAO option indexed by the 1547 Interface ID and including the UDP port number, IP address and P(i) 1548 values. For the first SLLAO in the list, however, the Server records 1549 the actual encapsulation source UDP and IP addresses instead of those 1550 that appear in the SLLAO in case there was a NAT or Proxy in the 1551 path. 1553 After the initial RS/RA exchange, the AERO Server maintains the 1554 neighbor cache entry for the Client until the PD lifetimes expire. 1555 If the Client issues additional RS messages with PD renewal 1556 parameters, the Server extends the PD lifetimes. If the Client 1557 issues an RS with PD release parameters, or if the Client does not 1558 issue a renewal before the lifetime expires, the Server deletes the 1559 neighbor cache entry for the Client and withdraws the IP routes from 1560 the AERO routing system. The Server processes these and any other 1561 Client PD messages, and returns an RA reply. The Server may also 1562 issue an unsolicited RA message with PD reconfigure parameters to 1563 inform the Client that it needs to renegotiate its PDs. 1565 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1567 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 1568 Servers are always on the same link (i.e., the AERO link) from the 1569 perspective of DHCPv6. However, in some implementations the DHCPv6 1570 server and ND function may be located in separate modules. In that 1571 case, the Server's AERO interface module can act as a Lightweight 1572 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 1573 the DHCPv6 server module. 1575 When the LDRA receives an authentic RS message, it extracts the PD 1576 message parameters and uses them to fabricate an IPv6/UDP/DHCPv6 1577 message. It sets the IPv6 source address to the source address of 1578 the RS message, sets the IPv6 destination address to 1579 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 1580 that will be understood by the DHCPv6 server. 1582 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 1583 header and includes an 'Interface-Id' option that includes enough 1584 information to allow the LDRA to forward the resulting Reply message 1585 back to the Client (e.g., the Client's link-layer addresses, a 1586 security association identifier, etc.). The LDRA also wraps the 1587 information in all of the SLLAO options from the RS message into the 1588 Interface-Id option, then forwards the message to the DHCPv6 server. 1590 When the DHCPv6 server prepares a Reply message, it wraps the message 1591 in a 'Relay-Reply' message and echoes the Interface-Id option. The 1592 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1593 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1594 uses the DHCPv6 message to fabricate an RA response to the Client. 1595 The Server uses the information in the Interface-Id option to prepare 1596 the RA message and to cache the link-layer addresses taken from the 1597 SLLAOs echoed in the Interface-Id option. 1599 3.15. AERO Route Optimization 1601 When a source Client forwards packets to a prospective correspondent 1602 Client within the same AERO link domain (i.e., one for which the 1603 packet's destination address is covered by an ASP), the source Client 1604 MAY initiate an AERO link route optimization procedure. The 1605 procedure is based on an exchange of IPv6 ND messages using a chain 1606 of AERO Servers and Relays as a trust basis. 1608 Although the Client is responsible for initiating route optimization, 1609 the Server is the policy enforcement point that determines whether 1610 route optimization is permitted. For example, on some AERO links 1611 route optimization would allow traffic to circumvent critical 1612 network-based traffic inspection points. In those cases, the Server 1613 can simply discard any route optimization messages instead of 1614 forwarding them. 1616 The following sections specify the AERO route optimization procedure. 1618 3.15.1. Reference Operational Scenario 1620 Figure 4 depicts the AERO route optimization reference operational 1621 scenario, using IPv6 addressing as the example (while not shown, a 1622 corresponding example for IPv4 addressing can be easily constructed). 1623 The figure shows an AERO Relay ('R1'), two AERO Servers ('S1', 'S2'), 1624 two AERO Clients ('C1', 'C2') and two ordinary IPv6 hosts ('H1', 1625 'H2'): 1627 +--------------+ +--------------+ +--------------+ 1628 | Server S1 | | Relay R1 | | Server S2 | 1629 +--------------+ +--------------+ +--------------+ 1630 fe80::2 fe80::1 fe80::3 1631 L2(S1) L2(R1) L2(S2) 1632 | | | 1633 X-----+-----+------------------+-----------------+----+----X 1634 | AERO Link | 1635 L2(C1) L2(C2) 1636 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1637 +--------------+ +--------------+ 1638 |AERO Client C1| |AERO Client C2| 1639 +--------------+ +--------------+ 1640 2001:DB8:0::/48 2001:DB8:1::/48 1641 | | 1642 .-. .-. 1643 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1644 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 1645 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 1646 `-(______)-' +-------+ +-------+ `-(______)-' 1648 Figure 4: AERO Reference Operational Scenario 1650 In Figure 4, Relay ('R1') assigns the administratively-provisioned 1651 AERO address fe80::1 to its AERO interface with link-layer address 1652 L2(R1), Server ('S1') assigns the address fe80::2 with link-layer 1653 address L2(S1), and Server ('S2') assigns the address fe80::3 with 1654 link-layer address L2(S2). Servers ('S1') and ('S2') next arrange to 1655 add their link-layer addresses to a published list of valid Servers 1656 for the AERO link. 1658 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in an ND/PD 1659 exchange via AERO Server ('S1') then assigns the address 1660 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1661 L2(C1). Client ('C1') configures a default route and neighbor cache 1662 entry via the AERO interface with next-hop address fe80::2 and link- 1663 layer address L2(S1), then sub-delegates the ACP to its attached 1664 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1665 address 2001:db8:0::1. 1667 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in an ND/PD 1668 exchange via AERO Server ('S2') then assigns the address 1669 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1670 L2(C2). Client ('C2') configures a default route and neighbor cache 1671 entry via the AERO interface with next-hop address fe80::3 and link- 1672 layer address L2(S2), then sub-delegates the ACP to its attached 1673 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1674 address 2001:db8:1::1. 1676 3.15.2. Concept of Operations 1678 Again, with reference to Figure 4, when source host ('H1') sends a 1679 packet to destination host ('H2'), the packet is first forwarded over 1680 the source host's attached EUN to Client ('C1'). Client ('C1') then 1681 forwards the packet via its AERO interface to Server ('S1') and also 1682 sends an NS message toward Client ('C2') via Server ('S1'). 1684 Server ('S1') then forwards both the packet and the NS message out 1685 the same AERO interface toward Client ('C2') via Relay ('R1'). When 1686 Relay ('R1') receives the packet and NS message, it consults its 1687 forwarding table to discover Server ('S2') as the next hop toward 1688 Client ('C2'). Relay ('R1') then forwards both the packet and the NS 1689 message to Server ('S2'), which then forwards them to Client ('C2'). 1691 After Client ('C2') receives the NS message, it process the message 1692 and creates or updates a dynamic neighbor cache entry for Client 1693 ('C1'), then sends the NA response to the link-layer address of 1694 Client ('C1'). 1696 After Client ('C1') receives the NA message, it processes the message 1697 and creates or updates a dynamic neighbor cache entry for Client 1698 ('C2'). Thereafter, forwarding of packets from Client ('C1') to 1699 Client ('C2') without involving any intermediate nodes is enabled. 1700 The mechanisms that support this exchange are specified in the 1701 following sections. 1703 3.15.3. Sending NS Messages 1705 When a Client forwards a packet with a source address from one of its 1706 ACPs toward a destination address covered by an ASP (i.e., toward 1707 another AERO Client connected to the same AERO link), the source 1708 Client MAY send an NS message forward toward the destination Client 1709 via the Server. 1711 In the reference operational scenario, when Client ('C1') forwards a 1712 packet toward Client ('C2'), it MAY also send an NS message forward 1713 toward Client ('C2'), subject to rate limiting (see Section 8.2 of 1714 [RFC4861]). Client ('C1') prepares the NS message as follows: 1716 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1717 layer address of Client ('C1')). 1719 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1720 link-layer address of Server ('S1')). 1722 o the network-layer source address is set to fe80::2001:db8:0:0 1723 (i.e., the base AERO address of Client ('C1')). 1725 o the network-layer destination address is set to the AERO address 1726 corresponding to the destination address of Client ('C2'). 1728 o the Type is set to 135. 1730 o the Target Address is set to the destination address of the packet 1731 that triggered route optimization. 1733 o the message includes SLLAOs set to appropriate values for the 1734 Client ('C1')'s underlying interfaces The first SLLAO serves as 1735 the "Report-To" address for the Client, which is the address to 1736 which the target will announce mobility events and/or other 1737 dynamic updates. 1739 o the message includes one or more RIOs that include Client ('C1')'s 1740 ACPs [I-D.templin-6man-rio-redirect]. 1742 o the message SHOULD include a Timestamp option and a Nonce option. 1744 Note that the act of sending NS messages is cited as "MAY", since 1745 Client ('C1') may have advanced knowledge that the direct path to 1746 Client ('C2') would be unusable or otherwise undesirable. If the 1747 direct path later becomes unusable after the initial route 1748 optimization, Client ('C1') simply allows packets to again flow 1749 through Server ('S1'). 1751 3.15.4. Re-encapsulating and Relaying the NS 1753 When Server ('S1') receives an NS message from Client ('C1'), it 1754 first verifies that the SLLAOs in the NS are a proper subset of the 1755 link-layer addresses in Client ('C1')'s neighbor cache entry. If the 1756 Client's SLLAOs are not acceptable, Server ('S1') discards the 1757 message. 1759 Server ('S1') then examines the network-layer destination address of 1760 the NS to determine the next hop toward Client ('C2') by searching 1761 for the AERO address in the neighbor cache. Since Client ('C2') is 1762 not one of its neighbors, Server ('S1') then inserts an additional 1763 layer of encapsulation between the outer IP header and the NS 1764 message. This mid-layer IP header uses the AERO Server Subnet Router 1765 Anycast address as the source address and the Subnet Router Anycast 1766 address corresponding to Client ("C2")'s AERO address as the 1767 destination address (in this case, C2's Subnet Router Anycast address 1768 is 2001:db8:1:0::). The Server then forwards this double- 1769 encapsulated NS message to Relay ('R1') by changing the link-layer 1770 source address of the message to 'L2(S1)' and changing the link-layer 1771 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1772 message to Relay ('R1') without decrementing the network-layer TTL/ 1773 Hop Limit field. 1775 When Relay ('R1') receives the double-encapsulated NS message from 1776 Server ('S1') it discards the outer IP header and determines that 1777 Server ('S2') is the next hop toward Client ('C2') by consulting its 1778 standard IP forwarding table for the Client Subnet Router Anycast 1779 destination address. Relay ('R1') then encapsulates and forwards the 1780 message to Server ('S2') the same as for any IP router. 1782 When Server ('S2') receives the double-encapsulated NS message from 1783 Relay ('R1') it removes the mid-layer IP header and determines that 1784 Client ('C2') is a neighbor on a native underlying interface by 1785 consulting its neighbor cache for Client ('C2')'s AERO address. 1786 Server ('S2') then re-encapsulates the NS while changing the link- 1787 layer source address to 'L2(S2)' and changing the link-layer 1788 destination address to 'L2(C2)'. Server ('S2') then forwards the 1789 message to Client ('C2'). 1791 3.15.5. Processing NSs and Sending NAs 1793 When Client ('C2') receives the NS message, it accepts the NS only if 1794 the message has a link-layer source address of one of its Servers 1795 (e.g., L2(S2)). Client ('C2') further accepts the message only if it 1796 is willing to serve as a route optimization target. 1798 In the reference operational scenario, when Client ('C2') receives a 1799 valid NS message, it either creates or updates a dynamic neighbor 1800 cache entry that stores the source address of the message as the 1801 network-layer address of Client ('C1') and stores the link-layer 1802 addresses found in the SLLAOs as the link-layer addresses of Client 1803 ('C1'). Client ('C2') then sets ReportTime for the neighbor cache 1804 entry to REPORT_TIME. 1806 After processing the message, Client ('C2') prepares an NA message 1807 response as follows: 1809 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1810 layer address of Client ('C2')). 1812 o the link-layer destination address is set to 'L2(C1)' (i.e., the 1813 link-layer address of Client ('C1')). 1815 o the network-layer source address is set to fe80::2001:db8:1:0 1816 (i.e., the base AERO address of Client ('C2')). 1818 o the network-layer destination address is set to fe80::2001:db8:0:0 1819 (i.e., the base AERO address of Client ('C1')). 1821 o the Type is set to 136. 1823 o the Target Address is set to the Target Address field in the NS 1824 message. 1826 o the message includes one or more TLLAOs set to appropriate values 1827 for Client ('C2')'s native underlying interfaces. 1829 o the message includes one or more RIOs that include Client ('C2')'s 1830 ACPs [I-D.templin-6man-rio-redirect]. 1832 o the message SHOULD include a Timestamp option and MUST echo the 1833 Nonce option received in the NS (i.e., if a Nonce option was 1834 present). 1836 Client ('C2') then sends the NA message to Client ('C1'). 1838 3.15.6. Processing NAs 1840 When Client ('C1') receives the NA message, it first verifies that 1841 the NA matches the original NS message. Client ('C1') then processes 1842 the message as follows. 1844 In the reference operational scenario, when Client ('C1') receives 1845 the NA message, it either creates or updates a dynamic neighbor cache 1846 entry that stores the source address of the message as the network- 1847 layer address of Client ('C2'), stores the link-layer addresses found 1848 in the TLLAOs as the link-layer addresses of Client ('C2') and stores 1849 the ACPs encoded in the RIOs of the NA as the ACPs for Client ('C2'). 1850 Client ('C1') then sets ForwardTime for the neighbor cache entry to 1851 FORWARD_TIME. 1853 Now, Client ('C1') has a neighbor cache entry with a valid 1854 ForwardTime value, while Client ('C2') has a neighbor cache entry 1855 with a valid ReportTime value. Thereafter, Client ('C1') may forward 1856 ordinary network-layer data packets directly to Client ('C2') without 1857 involving any intermediate nodes, and Client ('C2') can dynamically 1858 report any changes in link-layer information by sending unsolicited 1859 NA messages. (In order for Client ('C2') to forward packets to 1860 Client ('C1'), a corresponding NS/NA message exchange is required in 1861 the reverse direction; hence, the mechanism is asymmetric.) 1863 3.15.7. Server-Based Route Optimization 1865 The source Client itself may initiate route optimization if the 1866 Client has only native interfaces. If the source Client has Direct, 1867 NATed, Proxyed or VPNed interfaces, route optimization must instead 1868 be initiated by the source Server. The source Server MUST include an 1869 SLLAO with a "Report-To" address in the route optimization NS 1870 messages it sends. The "Report-To" address must be one of the source 1871 Server's globally routable IP addresses. 1873 In the same way, the target Client may serve as a route optimization 1874 target if it has only native interfaces. If some or all of the 1875 target Client's underlying interfaces are Direct, NATed, Proxyed or 1876 VPNed the target Server must instead serve as the route optimization 1877 target. In that case, when the source Server sends an NS message the 1878 target Server prepares an NA response the same as if it were the 1879 target Client (see: Section 3.15.5) and does not forward the NS. 1881 When the target Server sends an NA response to a route optimization 1882 NS, it includes a Timestamp option, any necessary security options, 1883 and TLLAOs corresponding to the target Client's underlying 1884 interfaces. The target Server writes the link-layer address of the 1885 Client in TLLAOs corresponding to native underlying interfaces, 1886 writes the link-layer address of the Proxy in TLLAOs corresponding to 1887 Proxyed underlying interfaces and writes its own link-layer address 1888 in TLLAOs corresponding to other interfaces. The Interface ID and 1889 QoS Preference values in the TLLAOs are those supplied by the target 1890 Client during ND exchanges with the target Server. The target Server 1891 then establishes a dynamic neighbor cache entry for the source with 1892 ReportTime set to REPORT_TIME seconds and with a "Report-To" address 1893 set to the address of the source. 1895 When the source Server receives the NA response, it creates or 1896 updates a dynamic neighbor cache entry for the target with 1897 ForwardTime set to FORWARD_TIME seconds and with the information 1898 provided in the TLLAOs as the link-layer addresses and preference 1899 values for the target. The source Server then translates the 1900 solicited NA message into an unsolicited NA message by changing the 1901 source address to its own link-local address, changing the 1902 destination address to all-nodes multicast, recalculating checksums 1903 and any security options, and including the Timestamp option as it 1904 appeared in the original solicited NA. The source Server then 1905 retains this message for subsequent on-demand transmission to any 1906 source neighbors that send packets to the target within the current 1907 ForwardTime window. 1909 While ForwardTime is greater than 0, the source Server sends 1910 unsolicited NA messages (subject to rate limiting) in response to 1911 data packets from source Clients or Proxies that are destined to the 1912 target Client. The unsolicited NA messages update source Client and 1913 Proxy dynamic neighbor cache entries with ForwardTime set to 1914 FORWARD_TIME minus the difference between the current time and the NA 1915 Timestamp. Subsequent packets from the source destined to the target 1916 Client then travel via the route-optimized path instead of through 1917 the dogleg path through Servers and Relays. 1919 Following route optimization, when the target Client (or Proxy) sends 1920 unsolicited NA messages to the target Server to update link-layer 1921 addresses and/or QoS preferences, the target Server translates the 1922 messages the same as described above and repeats them to any of its 1923 neighbors with non-zero ReportTime. The source Server in turn 1924 translates the messages and repeats them to any of their source 1925 Clients or Proxys to which they recently sent NAs. 1927 If the target Client moves to a new Server, the old Server sends 1928 immediate unsolicited NA messages with no TLLAOs to any of its 1929 dynamic neighbors with non-zero ReportTime, and retains the dynamic 1930 neighbor cache entry until ReportTime expires. While ReportTime is 1931 non-zero, the old Server sends unsolicited NA messages with no TLLAOs 1932 (subject to rate limiting) back to the source in response to data 1933 packets received from a correspondent node while forwarding the 1934 packets themselves to a Relay. The Relay will then either forward 1935 the packets to the new Server if the target Client has moved, or drop 1936 the packets if the target Client is no longer in the network. When 1937 the source receives the unsolicited NAs with no TLLAOs, it allows 1938 future packets destined to the target Client to again flow through 1939 its own Server (or Relay). 1941 3.16. Neighbor Unreachability Detection (NUD) 1943 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1944 NS messages to elicit solicited NA messages from neighbors the same 1945 as described in [RFC4861]. NUD is performed either reactively in 1946 response to persistent link-layer errors (see Section 3.13) or 1947 proactively to update neighbor cache entry timers and/or link-layer 1948 address information. (NS messages may include SLLAOs and NA messages 1949 may include TLLAOs in order to update link-layer address 1950 information.) 1952 When an AERO node sends an NS/NA message, it uses one of its link- 1953 local addresses as the IPv6 source address and a link-local address 1954 of the neighbor as the IPv6 destination address. When route 1955 optimization directs a source AERO node to a target AERO node, the 1956 source node SHOULD proactively test the direct path by sending an 1957 initial NS message to elicit a solicited NA response. While testing 1958 the path, the source node can optionally continue sending packets via 1959 its default router, maintain a small queue of packets until target 1960 reachability is confirmed, or (optimistically) allow packets to flow 1961 directly to the target. 1963 While data packets are still flowing, the source node thereafter 1964 periodically tests the direct path to the target node (see 1965 Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache 1966 entries alive. When the target node receives a valid NS message, it 1967 resets ReportTime to REPORT_TIME and updates its cached link-layer 1968 addresses (if necessary). When the source node receives a 1969 corresponding NA message, it resets ForwardTime to FORWARD_TIME and 1970 updates its cached link-layer addresses (if necessary). If the 1971 source node is unable to elicit an NA response from the target node 1972 after MaxRetry attempts, it SHOULD set ForwardTime to 0. Otherwise, 1973 the source node considers the path usable and SHOULD thereafter 1974 process any link-layer errors as an indication that the direct path 1975 to the target node may be failing. 1977 When ForwardTime for a dynamic neighbor cache entry expires, the 1978 source node resumes sending any subsequent packets via a Server (or 1979 Relay) and may (eventually) attempt to re-initiate the AERO route 1980 optimization process. When ReportTime for a dynamic neighbor cache 1981 entry expires, the target node ceases to send dynamic mobility and 1982 QoS updates to the source node. When both ForwardTime and ReportTime 1983 for a dynamic neighbor cache entry expire, the node deletes the 1984 neighbor cache entry. 1986 Note that an AERO node may have multiple underlying interface paths 1987 toward the target neighbor. In that case, the node SHOULD perform 1988 NUD over each underlying interface individually and only consider the 1989 neighbor unreachable if NUD fails over multiple underlying interface 1990 paths. 1992 3.17. Mobility Management and Quality of Service (QoS) 1994 AERO is an example of a Distributed Mobility Management (DMM) 1995 service. Each AERO Server is responsible for only a subset of the 1996 Clients on the AERO link, as opposed to a Centralized Mobility 1997 Management (CMM) service where there is a single network mobility 1998 service for all Clients. AERO Clients coordinate with their 1999 associated AERO Servers via RS/RA exchanges to maintain the DMM 2000 profile, and the AERO routing system tracks the current AERO Client/ 2001 Server peering relationships. 2003 AERO interfaces accommodate mobility management by sending 2004 unsolicited NA messages the same as for announcing link-layer address 2005 changes for any interface that implements IPv6 ND [RFC4861]. (In 2006 environments where reliability is a concern, AERO interfaces can send 2007 immediate NS messages to receive solicited NA messages, i.e., they 2008 can skip the unreliable unsolicited NA messaging step and move 2009 directly to a reliable NS/NA exchange.) 2010 When a node sends an unsolicited NA message, it sets the IPv6 source 2011 to its own link-local address, sets the IPv6 destination address to 2012 all-nodes multicast, sets the link-layer source address to its own 2013 address and sets the link-layer destination address to either a 2014 multicast address or the unicast link-layer address of a neighbor. 2015 In the latter case, if the unsolicited NA message must be received by 2016 multiple neighbors, the node sends multiple copies of the NA using a 2017 different unicast link-layer destination address for each neighbor. 2018 Mobility management considerations are specified in the following 2019 sections. 2021 3.17.1. Forwarding Packets on Behalf of Departed Clients 2023 When a Server receives packets with destination addresses that do not 2024 match one of its static neighbor cache Clients, it forwards the 2025 packets to a Relay which delivers them to the target Client's current 2026 location. If the source is not one of its static neighbor Clients, 2027 the Server also returns an unsolicited NA message to the sender with 2028 no TLLAOs - the sender will then realize that it needs to delete its 2029 neighbor cache entry that associated the target with this Server. 2031 3.17.2. Announcing Link-Layer Address and/or QoS Preference Changes 2033 When a Client needs to change its link-layer addresses, e.g., due to 2034 a mobility event, it sends unsolicited NAs to its neighbors using the 2035 new link-layer address as the source address and with TLLAOs that 2036 include the new Client UDP Port Number, IP Address and P(i) values. 2037 (For neighbors that are Servers, the Client can instead initiate an 2038 RS/RA exchange.) If the Client sends the NA solely for the purpose 2039 of updating QoS preferences without updating the link-layer address, 2040 the Client sets the UDP Port Number and IP Address to 0. 2042 The Client MAY send up to MaxRetry unsolicited NA messages in 2043 parallel with sending actual data packets in case one or more NAs are 2044 lost. If all NAs are lost, the neighbor will eventually invoke NUD 2045 by sending NS messages that include SLLAOs. 2047 3.17.3. Bringing New Links Into Service 2049 When a Client needs to bring new underlying interfaces into service 2050 (e.g., when it activates a new data link), it sends unsolicited NAs 2051 to its neighbors using the new link-layer address as the source 2052 address and with TLLAOs that include the new Client link-layer 2053 information. (For neighbors that are Servers, the Client can instead 2054 initiate an RS/RA exchange.) 2056 3.17.4. Removing Existing Links from Service 2058 When a Client needs to remove existing underlying interfaces from 2059 service (e.g., when it de-activates an existing data link), it sends 2060 unsolicited NAs to its neighbors with TLLAOs with all P(i) values set 2061 to 0. (For neighbors that are Servers, the Client can instead 2062 initiate an RS/RA exchange.) 2064 If the Client needs to send ND messages over an underlying interface 2065 other than the one being removed from service, it MUST include a 2066 current TLLAO for the sending interface as the first TLLAO and 2067 include TLLAOs for any underlying interface being removed from 2068 service as additional TLLAOs. 2070 3.17.5. Implicit Mobility Management 2072 AERO interface neighbors MAY provide a configuration option that 2073 allows them to perform implicit mobility management in which no ND 2074 messaging is used. In that case, the Client only transmits packets 2075 over a single interface at a time, and the neighbor always observes 2076 packets arriving from the Client from the same link-layer source 2077 address. 2079 If the Client's underlying interface address changes (either due to a 2080 readdressing of the original interface or switching to a new 2081 interface) the neighbor immediately updates the neighbor cache entry 2082 for the Client and begins accepting and sending packets to the 2083 Client's new link-layer address. This implicit mobility method 2084 applies to use cases such as cellphones with both WiFi and Cellular 2085 interfaces where only one of the interfaces is active at a given 2086 time, and the Client automatically switches over to the backup 2087 interface if the primary interface fails. 2089 3.17.6. Moving to a New Server 2091 When a Client associates with a new Server, it performs the Client 2092 procedures specified in Section 3.14.2. The Client then sends RS 2093 messages with PD release parameters to the old Server to release 2094 itself from that Server's domain. If the Client does not receive an 2095 RA reply after MaxRetry attempts, the old Server may have failed and 2096 the Client should discontinue its release attempts. 2098 Clients SHOULD NOT move rapidly between Servers in order to avoid 2099 causing excessive oscillations in the AERO routing system. Such 2100 oscillations could result in intermittent reachability for the Client 2101 itself, while causing no harm to the network. Examples of when a 2102 Client might wish to change to a different Server include a Server 2103 that has gone unreachable, topological movements of significant 2104 distance, movement to a new geographic region, etc. 2106 3.18. Multicast Considerations 2108 When the underlying network does not support multicast, AERO Clients 2109 map link-scoped multicast addresses to the link-layer address of a 2110 Server, which acts as a multicast forwarding agent. The AERO Client 2111 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2112 applications per [RFC4605] while using the link-layer address of the 2113 Server as the link-layer address for all multicast packets. 2115 When the underlying network supports multicast, AERO nodes use the 2116 multicast address mapping specification found in [RFC2529] for IPv4 2117 underlying networks and use a TBD site-scoped multicast mapping for 2118 IPv6 underlying networks. In that case, border routers must ensure 2119 that the encapsulated site-scoped multicast packets do not leak 2120 outside of the site spanned by the AERO link. 2122 4. The AERO Proxy 2124 In some environments, AERO Clients may be located in secured 2125 subnetwork enclaves (e.g., corporate enterprise networks, radio 2126 access networks, cellular service provider networks, etc.) that do 2127 not allow direct communications from the Client to a Server in the 2128 outside Internetwork. In that case, the secured enclave can employ 2129 an AERO Proxy. 2131 The AERO Proxy is located at the secured enclave perimeter and 2132 listens for encapsulated RS messages originating from or RA messages 2133 destined to AERO Clients located within the enclave. The Proxy acts 2134 on these control messages as follows: 2136 o when the Proxy receives an RS message from a Client within the 2137 secured enclave, it first authenticates the message then creates a 2138 proxy neighbor cache entry for the Client in the INCOMPLETE State 2139 and caches the Client and Server link-layer addresses along with 2140 any identifying information including Transaction IDs, Client 2141 Identifiers, Nonce values, etc. The Proxy then re-encapsulates 2142 the RS message using its own external address as the source link- 2143 layer address and forwards the message to the Server. 2145 o when the Server receives the RS message, it authenticates the 2146 message then creates a static neighbor cache entry for the Client 2147 with the Proxy's address as the link-layer address. The Server 2148 then sends an RA message back to the Proxy. 2150 o when the Proxy receives the RA message, it matches the message 2151 with the RS that created the (INCOMPLETE) proxy neighbor cache 2152 entry. The Proxy then caches the route information in the message 2153 as a mapping from the Client's ACPs to the Client's address within 2154 the secured enclave, and sets the neighbor cache entry state to 2155 REACHABLE. The Proxy then re-encapsulates the RA message using 2156 its own internal address as the source link-layer address and 2157 forwards the message to the Client. 2159 After the initial RS/RA handshake, the Proxy forwards data packets 2160 between the Client and Server with the Server acting as the Client's 2161 default router. The Proxy can send ND messages to the Client's 2162 Server(s) to update Server neighbor cache entries on behalf of the 2163 Client. (For example, the Proxy can send unsolicited NA messages 2164 with a TLLAO with UDP Port Number and IP Address set to 0 and with 2165 valid P(i) values to update the Server(s) with the Client's new QoS 2166 preferences for the path that traverses the Proxy). The Proxy also 2167 forwards any control and data messages originating from the Client to 2168 the Client's primary Server. 2170 At some time after data packets have been flowing from the Client to 2171 the Server, the Proxy may receive unsolicited NA messages from the 2172 Server with TLLAOs corresponding to a target Client. The Proxy 2173 establishes a dynamic neighbor cache entry for the target with 2174 ForwardTime set to FORWARD_TIME and allows future data packets 2175 destined to the target to flow directly according to the link-layer 2176 address information instead of through the Server. The Proxy may at 2177 some later point receive additional NA messages with TLLAOs, and if 2178 so resets ForwardTime and updates its cached link-layer address 2179 information. If the Proxy receives no further NA messages, or if it 2180 receives NA messages with no TLLAOs, it deletes the dynamic neighbor 2181 cache entry. 2183 In some subnetworks that employ a Proxy, the Client's ACP can be 2184 injected into the underlying network routing system. In that case, 2185 the Client can send data messages without encapsulation so that the 2186 native underlying network routing system transports the 2187 unencapsulated packets to the Proxy. This can be very beneficial, 2188 e.g., if the Client connects to the network via low-end data links 2189 such as some aviation wireless links. In that case, however, the 2190 Client's control messages are still sent encapsulated so as to supply 2191 the Proxy with the address of the Server and to transport IPv6 ND 2192 messages without decrementing the hop-count. In summary, the 2193 interface becomes one where control messages are encapsulated while 2194 data messages are either unencapsulated or encapsulated according to 2195 the specific use case. This encapsulation avoidance represents a 2196 form of "header compression", meaning that the MTU should be sized 2197 based on the size of full encapsulated messages even if most messages 2198 are sent unencapsulated. 2200 5. Direct Underlying Interfaces 2202 When a Client's AERO interface is configured over a Direct underlying 2203 interface, the neighbor at the other end of the Direct link can 2204 receive packets without any encapsulation. In that case, the Client 2205 sends packets over the Direct link according to the QoS preferences 2206 associated with its underling interfaces. If the Direct underlying 2207 interface has the highest QoS preference, then the Client's IP 2208 packets are transmitted directly to the peer without going through an 2209 underlying network. If other underlying interfaces have higher QoS 2210 preferences, then the Client's IP packets are transmitted via a 2211 different underlying interface, which may result in the inclusion of 2212 AERO Proxies, Servers and Relays in the communications path. Direct 2213 underlying interfaces must be tested periodically for reachability, 2214 e.g., via NUD, via periodic unsolicited NAs, etc. 2216 6. Operation on AERO Links with /64 ASPs 2218 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2219 length /64 or shorter. However, in some cases it may be desirable to 2220 use AERO over links that have only a /64 ASP. This can be 2221 accommodated by treating all Clients on the AERO link as simple hosts 2222 that receive /128 prefix delegations. 2224 In that case, the Client sends an RS message to the Server the same 2225 as for ordinary AERO links. The Server responds with an RA message 2226 that includes one or more /128 prefixes (i.e., singleton addresses) 2227 that include the /64 ASP prefix along with an interface identifier 2228 portion to be assigned to the Client. The Client and Server then 2229 configure their AERO addresses based on the interface identifier 2230 portions of the /128s (i.e., the lower 64 bits) and not based on the 2231 /64 prefix (i.e., the upper 64 bits). 2233 For example, if the ASP for the host-only IPv6 AERO link is 2234 2001:db8:1000:2000::/64, each Client will receive one or more /128 2235 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2236 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2237 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2238 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2239 /128s) to either the AERO interface or an internal virtual interface 2240 such as a loopback. In this arrangement, the Client conducts route 2241 optimization in the same sense as discussed in Section 3.15. 2243 This specification has applicability for nodes that act as a Client 2244 on an "upstream" AERO link, but also act as a Server on "downstream" 2245 AERO links. More specifically, if the node acts as a Client to 2246 receive a /64 prefix from the upstream AERO link it can then act as a 2247 Server to provision /128s to Clients on downstream AERO links. 2249 7. SEcure Neighbor Discovery (SEND) 2251 In environments where ND message spoofing is considered a threat, 2252 AERO nodes SHOULD employ SEcure Neighbor Discovery (SEND) [RFC3971] 2253 with Cryptographically Generated Addresses (CGAs) [RFC3972]. SEND 2254 also protects the PD information embedded in RS/RA message options. 2256 When the source AERO node computes the CGA, it writes the interface 2257 identifier of the AERO address (i.e., instead of fe80::/64) in the 2258 CGA parameters Subnet Prefix field. When the neighbor receives the 2259 ND message, it first verifies the message checksum and CGA/SEND 2260 parameters while using the value fe80::/64 (i.e., instead of the 2261 value in the Subnet Prefix field) to match against the IPv6 source 2262 address of the ND message. 2264 The neighbor then derives the AERO address of the source by using the 2265 value in the Subnet Prefix field as the interface identifier of an 2266 AERO link-local address. For example, if the Subnet Prefix field 2267 contains 2001:db8:1:2, the neighbor constructs the AERO address as 2268 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 2269 neighbor cache entry it creates for the source, and uses the AERO 2270 address as the IPv6 destination address of any ND message replies. 2272 8. Implementation Status 2274 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2275 announced on the v6ops mailing list on January 10, 2018. The latest 2276 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2277 2.0.tgz. 2279 An initial public release of the AERO proof-of-concept source code 2280 was announced on the intarea mailing list on August 21, 2015. The 2281 latest version is available at: http://linkupnetworks.net/aero/aero- 2282 4.0.0.tgz. 2284 A survey of public domain and commercial SEND implementations is 2285 available at https://www.ietf.org/mail-archive/web/its/current/ 2286 msg02758.html. 2288 9. IANA Considerations 2290 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2291 AERO in the "enterprise-numbers" registry. 2293 The IANA has assigned the UDP port number "8060" for an earlier 2294 experimental version of AERO [RFC6706]. This document obsoletes 2295 [RFC6706] and claims the UDP port number "8060" for all future use. 2297 No further IANA actions are required. 2299 10. Security Considerations 2301 AERO link security considerations are the same as for standard IPv6 2302 Neighbor Discovery [RFC4861] except that AERO improves on some 2303 aspects. In particular, AERO uses a trust basis between Clients and 2304 Servers, where the Clients only engage in the AERO mechanism when it 2305 is facilitated by a trusted Server. 2307 AERO links must be protected against spoofing attacks in which an 2308 attacker on the link pretends to be a trusted neighbor. Links that 2309 provide link-layer securing mechanisms (e.g., IEEE 802.1X WLANs) and 2310 links that provide physical security (e.g., enterprise network wired 2311 LANs) provide a first line of defense. In environments where link- 2312 layer security alone is insufficient to address all spoofing threats, 2313 AERO nodes SHOULD employ SEND/CGA as discussed in Section 7. 2315 Regardless of whether the full SEND protocol is used, AERO nodes 2316 SHOULD include Timestamp and Nonce options in ND messages where 2317 appropriate. The Nonce option sent in RS/NS messages can then serve 2318 as a transaction ID for matching corresponding RA/NA messsages. 2320 AERO Clients MUST ensure that their connectivity is not used by 2321 unauthorized nodes on their EUNs to gain access to a protected 2322 network, i.e., AERO Clients that act as routers MUST NOT provide 2323 routing services for unauthorized nodes. (This concern is no 2324 different than for ordinary hosts that receive an IP address 2325 delegation but then "share" the address with other nodes via some 2326 form of Internet connection sharing such as tethering.) 2328 AERO Clients, Servers and Relays on the open Internet are susceptible 2329 to the same attack profiles as for any Internet nodes. For this 2330 reason, IP security SHOULD be used when AERO is employed over 2331 unmanaged/unsecured links using securing mechanisms such as IPsec 2332 [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, 2333 however, the use of application-layer security from Clients to 2334 correspondent nodes (i.e., other Clients and/or Internet nodes) could 2335 obviate the need for IP security between AERO Clients, Servers and 2336 Relays. 2338 AERO Servers and Relays present targets for traffic amplification 2339 Denial of Service (DoS) attacks. This concern is no different than 2340 for widely-deployed VPN security gateways in the Internet, where 2341 attackers could send spoofed packets to the gateways at high data 2342 rates. This can be mitigated by connecting Relays and Servers over 2343 dedicated links with no connections to the Internet and/or when 2344 connections to the Internet are only permitted through well-managed 2345 firewalls. 2347 Traffic amplification DoS attacks can also target an AERO Client's 2348 low data rate links. This is a concern not only for Clients located 2349 on the open Internet but also for Clients in secured enclaves. AERO 2350 Servers can institute rate limits that protect Clients from receiving 2351 packet floods that could DoS low data rate links. 2353 AERO Relays and Servers MUST discard packets with AERO Server Subnet 2354 Router Anycast as the source address originating from any node other 2355 than a permanent neighbor. This is to avoid a message injection 2356 spoofing attack from an off-link attacker. 2358 Security considerations for accepting link-layer ICMP messages and 2359 reflected packets are discussed throughout the document. 2361 11. Acknowledgements 2363 Discussions in the IETF, aviation standards communities and private 2364 exchanges helped shape some of the concepts in this work. 2365 Individuals who contributed insights include Mikael Abrahamsson, Mark 2366 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2367 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2368 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2369 Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, Satoru 2370 Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet Saikaya, 2371 Michal Skorepa, Joe Touch, Bernie Volz, Ryuji Wakikawa, Tony Whyman, 2372 Lloyd Wood and James Woodyatt. Members of the IESG also provided 2373 valuable input during their review process that greatly improved the 2374 document. Special thanks go to Stewart Bryant, Joel Halpern and 2375 Brian Haberman for their shepherding guidance during the publication 2376 of the AERO first edition. 2378 This work has further been encouraged and supported by Boeing 2379 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2380 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2381 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2382 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, 2383 Brian Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie 2384 Wulff, Yueli Yang, Eric Yeh and other members of the BR&T and BIT 2385 mobile networking teams. Kyle Bae, Wayne Benson and Eric Yeh are 2386 especially acknowledged for implementing the AERO functions as 2387 extensions to the public domain OpenVPN distribution. 2389 Earlier works on NBMA tunneling approaches are found in 2390 [RFC2529][RFC5214][RFC5569]. 2392 Many of the constructs presented in this second edition of AERO are 2393 based on the author's earlier works, including: 2395 o The Internet Routing Overlay Network (IRON) 2396 [RFC6179][I-D.templin-ironbis] 2398 o Virtual Enterprise Traversal (VET) 2399 [RFC5558][I-D.templin-intarea-vet] 2401 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2402 [RFC5320][I-D.templin-intarea-seal] 2404 o AERO, First Edition [RFC6706] 2406 Note that these works cite numerous earlier efforts that are not also 2407 cited here due to space limitations. The authors of those earlier 2408 works are acknowledged for their insights. 2410 This work is aligned with the NASA Safe Autonomous Systems Operation 2411 (SASO) program under NASA contract number NNA16BD84C. 2413 This work is aligned with the FAA as per the SE2025 contract number 2414 DTFAWA-15-D-00030. 2416 This work is aligned with the Boeing Information Technology (BIT) 2417 MobileNet program. 2419 This work is aligned with the Boeing Research and Technology (BR&T) 2420 autonomous systems networking program. 2422 12. References 2424 12.1. Normative References 2426 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2427 DOI 10.17487/RFC0768, August 1980, 2428 . 2430 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2431 DOI 10.17487/RFC0791, September 1981, 2432 . 2434 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2435 RFC 792, DOI 10.17487/RFC0792, September 1981, 2436 . 2438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2439 Requirement Levels", BCP 14, RFC 2119, 2440 DOI 10.17487/RFC2119, March 1997, 2441 . 2443 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2444 "Definition of the Differentiated Services Field (DS 2445 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2446 DOI 10.17487/RFC2474, December 1998, 2447 . 2449 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2450 C., and M. Carney, "Dynamic Host Configuration Protocol 2451 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2452 2003, . 2454 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2455 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2456 DOI 10.17487/RFC3633, December 2003, 2457 . 2459 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2460 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2461 DOI 10.17487/RFC3971, March 2005, 2462 . 2464 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2465 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2466 . 2468 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2469 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2470 November 2005, . 2472 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2473 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2474 . 2476 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2477 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2478 DOI 10.17487/RFC4861, September 2007, 2479 . 2481 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2482 Address Autoconfiguration", RFC 4862, 2483 DOI 10.17487/RFC4862, September 2007, 2484 . 2486 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2487 Advertisement Flags Option", RFC 5175, 2488 DOI 10.17487/RFC5175, March 2008, 2489 . 2491 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2492 (IPv6) Specification", STD 86, RFC 8200, 2493 DOI 10.17487/RFC8200, July 2017, 2494 . 2496 12.2. Informative References 2498 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2499 2016. 2501 [I-D.ietf-intarea-gue] 2502 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2503 Encapsulation", draft-ietf-intarea-gue-06 (work in 2504 progress), August 2018. 2506 [I-D.ietf-intarea-gue-extensions] 2507 Herbert, T., Yong, L., and F. Templin, "Extensions for 2508 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2509 extensions-05 (work in progress), August 2018. 2511 [I-D.ietf-intarea-tunnels] 2512 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2513 Architecture", draft-ietf-intarea-tunnels-09 (work in 2514 progress), July 2018. 2516 [I-D.ietf-rtgwg-atn-bgp] 2517 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2518 Moreno, "A Simple BGP-based Mobile Routing System for the 2519 Aeronautical Telecommunications Network", draft-ietf- 2520 rtgwg-atn-bgp-00 (work in progress), August 2018. 2522 [I-D.templin-6man-aeroaddr] 2523 Templin, F., "The AERO Address", draft-templin-6man- 2524 aeroaddr-03 (work in progress), November 2018. 2526 [I-D.templin-6man-dhcpv6-ndopt] 2527 Templin, F., "A Unified Stateful/Stateless 2528 Autoconfiguration Service for IPv6", draft-templin-6man- 2529 dhcpv6-ndopt-06 (work in progress), September 2018. 2531 [I-D.templin-6man-rio-redirect] 2532 Templin, F. and j. woodyatt, "Route Information Options in 2533 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2534 redirect-06 (work in progress), May 2018. 2536 [I-D.templin-intarea-grefrag] 2537 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2538 templin-intarea-grefrag-04 (work in progress), July 2016. 2540 [I-D.templin-intarea-seal] 2541 Templin, F., "The Subnetwork Encapsulation and Adaptation 2542 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2543 progress), January 2014. 2545 [I-D.templin-intarea-vet] 2546 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2547 templin-intarea-vet-40 (work in progress), May 2013. 2549 [I-D.templin-ironbis] 2550 Templin, F., "The Interior Routing Overlay Network 2551 (IRON)", draft-templin-ironbis-16 (work in progress), 2552 March 2014. 2554 [I-D.templin-v6ops-pdhost] 2555 Templin, F., "Multi-Addressing Considerations for IPv6 2556 Prefix Delegation", draft-templin-v6ops-pdhost-21 (work in 2557 progress), June 2018. 2559 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2561 [RFC1035] Mockapetris, P., "Domain names - implementation and 2562 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2563 November 1987, . 2565 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2566 Communication Layers", STD 3, RFC 1122, 2567 DOI 10.17487/RFC1122, October 1989, 2568 . 2570 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2571 DOI 10.17487/RFC1191, November 1990, 2572 . 2574 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2575 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2576 . 2578 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2579 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2580 1996, . 2582 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2583 DOI 10.17487/RFC2003, October 1996, 2584 . 2586 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2587 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2588 . 2590 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2591 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2592 December 1998, . 2594 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2595 Domains without Explicit Tunnels", RFC 2529, 2596 DOI 10.17487/RFC2529, March 1999, 2597 . 2599 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2600 Malis, "A Framework for IP Based Virtual Private 2601 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2602 . 2604 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2605 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2606 DOI 10.17487/RFC2784, March 2000, 2607 . 2609 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2610 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2611 . 2613 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2614 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2615 . 2617 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2618 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2619 . 2621 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2622 of Explicit Congestion Notification (ECN) to IP", 2623 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2624 . 2626 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2627 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2628 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2629 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2630 . 2632 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2633 for IPv6 Hosts and Routers", RFC 4213, 2634 DOI 10.17487/RFC4213, October 2005, 2635 . 2637 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2638 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2639 DOI 10.17487/RFC4271, January 2006, 2640 . 2642 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2643 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2644 2006, . 2646 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2647 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2648 December 2005, . 2650 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2651 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2652 2006, . 2654 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2655 Control Message Protocol (ICMPv6) for the Internet 2656 Protocol Version 6 (IPv6) Specification", STD 89, 2657 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2658 . 2660 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2661 Protocol (LDAP): The Protocol", RFC 4511, 2662 DOI 10.17487/RFC4511, June 2006, 2663 . 2665 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2666 "Internet Group Management Protocol (IGMP) / Multicast 2667 Listener Discovery (MLD)-Based Multicast Forwarding 2668 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2669 August 2006, . 2671 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2672 Errors at High Data Rates", RFC 4963, 2673 DOI 10.17487/RFC4963, July 2007, 2674 . 2676 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2677 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2678 DOI 10.17487/RFC5214, March 2008, 2679 . 2681 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2682 (TLS) Protocol Version 1.2", RFC 5246, 2683 DOI 10.17487/RFC5246, August 2008, 2684 . 2686 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2687 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2688 February 2010, . 2690 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2691 Route Optimization Requirements for Operational Use in 2692 Aeronautics and Space Exploration Mobile Networks", 2693 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2694 . 2696 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2697 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2698 . 2700 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2701 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2702 January 2010, . 2704 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2705 Global Enterprise Recursion (RANGER)", RFC 5720, 2706 DOI 10.17487/RFC5720, February 2010, 2707 . 2709 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2710 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2711 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2712 . 2714 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2715 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2716 . 2718 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2719 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2720 DOI 10.17487/RFC6221, May 2011, 2721 . 2723 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2724 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2725 . 2727 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2728 for Equal Cost Multipath Routing and Link Aggregation in 2729 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2730 . 2732 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2733 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2734 . 2736 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2737 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2738 . 2740 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2741 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2742 March 2017, . 2744 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2745 October 2014. 2747 Appendix A. AERO Alternate Encapsulations 2749 When GUE encapsulation is not needed, AERO can use common 2750 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2751 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2752 encapsulation is therefore only differentiated from non-AERO tunnels 2753 through the application of AERO control messaging and not through, 2754 e.g., a well-known UDP port number. 2756 As for GUE encapsulation, alternate AERO encapsulation formats may 2757 require encapsulation layer fragmentation. For simple IP-in-IP 2758 encapsulation, an IPv6 fragment header is inserted directly between 2759 the inner and outer IP headers when needed, i.e., even if the outer 2760 header is IPv4. The IPv6 Fragment Header is identified to the outer 2761 IP layer by its IP protocol number, and the Next Header field in the 2762 IPv6 Fragment Header identifies the inner IP header version. For GRE 2763 encapsulation, a GRE fragment header is inserted within the GRE 2764 header [I-D.templin-intarea-grefrag]. 2766 Figure 5 shows the AERO IP-in-IP encapsulation format before any 2767 fragmentation is applied: 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | Outer IPv4 Header | | Outer IPv6 Header | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | Inner IP Header | | Inner IP Header | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 | | | | 2777 ~ ~ ~ ~ 2778 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2779 ~ ~ ~ ~ 2780 | | | | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2785 Figure 5: Minimal Encapsulation Format using IP-in-IP 2787 Figure 6 shows the AERO GRE encapsulation format before any 2788 fragmentation is applied: 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | Outer IP Header | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 | GRE Header | 2794 | (with checksum, key, etc..) | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | GRE Fragment Header (optional)| 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | Inner IP Header | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 | | 2801 ~ ~ 2802 ~ Inner Packet Body ~ 2803 ~ ~ 2804 | | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2807 Figure 6: Minimal Encapsulation Using GRE 2809 Alternate encapsulation may be preferred in environments where GUE 2810 encapsulation would add unnecessary overhead. For example, certain 2811 low-bandwidth wireless data links may benefit from a reduced 2812 encapsulation overhead. 2814 GUE encapsulation can traverse network paths that are inaccessible to 2815 non-UDP encapsulations, e.g., for crossing Network Address 2816 Translators (NATs). More and more, network middleboxes are also 2817 being configured to discard packets that include anything other than 2818 a well-known IP protocol such as UDP and TCP. It may therefore be 2819 necessary to determine the potential for middlebox filtering before 2820 enabling alternate encapsulation in a given environment. 2822 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2823 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 2824 messaging and route determination occur before security encapsulation 2825 is applied for outgoing packets and after security decapsulation is 2826 applied for incoming packets. 2828 AERO is especially well suited for use with VPN system encapsulations 2829 such as OpenVPN [OVPN]. 2831 Appendix B. When to Insert an Encapsulation Fragment Header 2833 An encapsulation fragment header is inserted when the AERO tunnel 2834 ingress needs to apply fragmentation to accommodate packets that must 2835 be delivered without loss due to a size restriction. Fragmentation 2836 is performed on the inner packet while encapsulating each inner 2837 packet fragment in outer IP and encapsulation layer headers that 2838 differ only in the fragment header fields. 2840 The fragment header can also be inserted in order to include a 2841 coherent Identification value with each packet, e.g., to aid in 2842 Duplicate Packet Detection (DPD). In this way, network nodes can 2843 cache the Identification values of recently-seen packets and use the 2844 cached values to determine whether a newly-arrived packet is in fact 2845 a duplicate. The Identification value within each packet could 2846 further provide a rough indicator of packet reordering, e.g., in 2847 cases when the tunnel egress wishes to discard packets that are 2848 grossly out of order. 2850 In some use cases, there may be operational assurance that no 2851 fragmentation of any kind will be necessary, or that only occasional 2852 large control messages will require fragmentation. In that case, the 2853 encapsulation fragment header can be omitted and ordinary 2854 fragmentation of the outer IP protocol version can be applied when 2855 necessary. 2857 Appendix C. Autoconfiguration for Constrained Platforms 2859 On some platforms (e.g., popular cell phone operating systems), the 2860 act of assigning a default IPv6 route and/or assigning an address to 2861 an interface may not be permitted from a user application due to 2862 security policy. Typically, those platforms include a TUN/TAP 2863 interface [TUNTAP] that acts as a point-to-point conduit between user 2864 applications and the AERO interface. In that case, the Client can 2865 instead generate a "synthesized RA" message. The message conforms to 2866 [RFC4861] and is prepared as follows: 2868 o the IPv6 source address is the Client's AERO address 2870 o the IPv6 destination address is all-nodes multicast 2872 o the Router Lifetime is set to a time that is no longer than the 2873 ACP DHCPv6 lifetime 2875 o the message does not include a Source Link Layer Address Option 2876 (SLLAO) 2878 o the message includes a Prefix Information Option (PIO) with a /64 2879 prefix taken from the ACP as the prefix for autoconfiguration 2881 The Client then sends the synthesized RA message via the TUN/TAP 2882 interface, where the operating system kernel will interpret it as 2883 though it were generated by an actual router. The operating system 2884 will then install a default route and use StateLess Address 2885 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 2886 interface. Methods for similarly installing an IPv4 default route 2887 and IPv4 address on the TUN/TAP interface are based on synthesized 2888 DHCPv4 messages [RFC2131]. 2890 Appendix D. Operational Deployment Alternatives 2892 AERO can be used in many different variations based on the specific 2893 use case. The following sections discuss variations that adhere to 2894 the AERO principles while allowing selective application of AERO 2895 components. 2897 D.1. Operation on AERO Links Without DHCPv6 Services 2899 When Servers on the AERO link do not provide DHCPv6 services, 2900 operation can still be accommodated through administrative 2901 configuration of ACPs on AERO Clients. In that case, administrative 2902 configurations of AERO interface neighbor cache entries on both the 2903 Server and Client are also necessary. However, this may interfere 2904 with the ability for Clients to dynamically change to new Servers, 2905 and can expose the AERO link to misconfigurations unless the 2906 administrative configurations are carefully coordinated. 2908 D.2. Operation on Server-less AERO Links 2910 In some AERO link scenarios, there may be no Servers on the link and/ 2911 or no need for Clients to use a Server as an intermediary trust 2912 anchor. In that case, each Client acts as a Server unto itself to 2913 establish neighbor cache entries by performing direct Client-to- 2914 Client IPv6 ND message exchanges, and some other form of trust basis 2915 must be applied so that each Client can verify that the prospective 2916 neighbor is authorized to use its claimed ACP. 2918 When there is no Server on the link, Clients must arrange to receive 2919 ACPs and publish them via a secure alternate PD authority through 2920 some means outside the scope of this document. 2922 D.3. Operation on Client-less AERO Links 2924 In some environments, the AERO service may be useful for mobile nodes 2925 that do not implement the AERO Client function and do not perform 2926 encapsulation. For example, if the mobile node has a way of 2927 injecting its ACP into the access subnetwork routing system an AERO 2928 Server connected to the same access network can accept the ACP prefix 2929 injection as an indication that a new mobile node has come onto the 2930 subnetwork. The Server can then inject the ACP into the BGP routing 2931 system the same as if an AERO Client/Server PD exchange had occurred. 2932 If the mobile node subsequently withdraws the ACP from the access 2933 network routing system, the Server can then withdraw the ACP from the 2934 BGP routing system. 2936 In this arrangement, AERO Servers and Relays are used in exactly the 2937 same ways as for environments where DHCPv6 Client/Server exchanges 2938 are supported. However, the access subnetwork routing systems must 2939 be capable of accommodating rapid ACP injections and withdrawals from 2940 mobile nodes with the understanding that the information must be 2941 propagated to all routers in the system. Operational experience has 2942 shown that this kind of routing system "churn" can lead to overall 2943 instability and routing system inconsistency. 2945 D.4. Manually-Configured AERO Tunnels 2947 In addition to the dynamic neighbor discovery procedures for AERO 2948 link neighbors described above, AERO encapsulation can be applied to 2949 manually-configured tunnels. In that case, the tunnel endpoints use 2950 an administratively-provisioned AERO address and exchange NS/NA 2951 messages the same as for dynamically-established tunnels. 2953 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links 2955 In some environments, AERO Servers and Relays may be connected by 2956 dedicated point-to-point links, e.g., high speed fiberoptic leased 2957 lines. In that case, the Servers and Relays can participate in the 2958 AERO link the same as specified above but can avoid encapsulation 2959 over the dedicated links. In that case, however, the links would be 2960 dedicated for AERO and could not be multiplexed for both AERO and 2961 non-AERO communications. 2963 D.6. Encapsulation Protocol Version Considerations 2965 A source Client may connect only to an IPvX underlying network, while 2966 the target Client connects only to an IPvY underlying network. In 2967 that case, the target and source Clients have no means for reaching 2968 each other directly (since they connect to underlying networks of 2969 different IP protocol versions) and so must ignore any route 2970 optimization messages and continue to send packets via their Servers. 2972 D.7. Extending AERO Links Through Security Gateways 2974 When an enterprise mobile node moves from a campus LAN connection to 2975 a public Internet link, it must re-enter the enterprise via a 2976 security gateway that has both a physical interface connection to the 2977 Internet and a physical interface connection to the enterprise 2978 internetwork. This most often entails the establishment of a Virtual 2979 Private Network (VPN) link over the public Internet from the mobile 2980 node to the security gateway. During this process, the mobile node 2981 supplies the security gateway with its public Internet address as the 2982 link-layer address for the VPN. The mobile node then acts as an AERO 2983 Client to negotiate with the security gateway to obtain its ACP. 2985 In order to satisfy this need, the security gateway also operates as 2986 an AERO Server with support for AERO Client proxying. In particular, 2987 when a mobile node (i.e., the Client) connects via the security 2988 gateway (i.e., the Server), the Server provides the Client with an 2989 ACP in a PD exchange the same as if it were attached to an enterprise 2990 campus access link. The Server then replaces the Client's link-layer 2991 source address with the Server's enterprise-facing link-layer address 2992 in all AERO messages the Client sends toward neighbors on the AERO 2993 link. The AERO messages are then delivered to other nodes on the 2994 AERO link as if they were originated by the security gateway instead 2995 of by the AERO Client. In the reverse direction, the AERO messages 2996 sourced by nodes within the enterprise network can be forwarded to 2997 the security gateway, which then replaces the link-layer destination 2998 address with the Client's link-layer address and replaces the link- 2999 layer source address with its own (Internet-facing) link-layer 3000 address. 3002 After receiving the ACP, the Client can send IP packets that use an 3003 address taken from the ACP as the network layer source address, the 3004 Client's link-layer address as the link-layer source address, and the 3005 Server's Internet-facing link-layer address as the link-layer 3006 destination address. The Server will then rewrite the link-layer 3007 source address with the Server's own enterprise-facing link-layer 3008 address and rewrite the link-layer destination address with the 3009 target AERO node's link-layer address, and the packets will enter the 3010 enterprise network as though they were sourced from a node located 3011 within the enterprise. In the reverse direction, when a packet 3012 sourced by a node within the enterprise network uses a destination 3013 address from the Client's ACP, the packet will be delivered to the 3014 security gateway which then rewrites the link-layer destination 3015 address to the Client's link-layer address and rewrites the link- 3016 layer source address to the Server's Internet-facing link-layer 3017 address. The Server then delivers the packet across the VPN to the 3018 AERO Client. In this way, the AERO virtual link is essentially 3019 extended *through* the security gateway to the point at which the VPN 3020 link and AERO link are effectively grafted together by the link-layer 3021 address rewriting performed by the security gateway. All AERO 3022 messaging services (including route optimization and mobility 3023 signaling) are therefore extended to the Client. 3025 In order to support this virtual link grafting, the security gateway 3026 (acting as an AERO Server) must keep static neighbor cache entries 3027 for all of its associated Clients located on the public Internet. 3028 The neighbor cache entry is keyed by the AERO Client's AERO address 3029 the same as if the Client were located within the enterprise 3030 internetwork. The neighbor cache is then managed in all ways as 3031 though the Client were an ordinary AERO Client. This includes the 3032 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 3033 Unreachability Detection. 3035 Note that the main difference between a security gateway acting as an 3036 AERO Server and an enterprise-internal AERO Server is that the 3037 security gateway has at least one enterprise-internal physical 3038 interface and at least one public Internet physical interface. 3039 Conversely, the enterprise-internal AERO Server has only enterprise- 3040 internal physical interfaces. For this reason security gateway 3041 proxying is needed to ensure that the public Internet link-layer 3042 addressing space is kept separate from the enterprise-internal link- 3043 layer addressing space. This is afforded through a natural extension 3044 of the security association caching already performed for each VPN 3045 client by the security gateway. 3047 Appendix E. Change Log 3049 << RFC Editor - remove prior to publication >> 3051 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 3052 intrea-6706bis-03: 3054 o Added new section on SEND. 3056 o Clarifications on "AERO Address" section. 3058 o Updated references and added new reference for RFC8086. 3060 o Security considerations updates. 3062 o General text clarifications and cleanup. 3064 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 3065 intrea-6706bis-02: 3067 o Note on encapsulation avoidance in Section 4. 3069 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 3070 intrea-6706bis-01: 3072 o Remove DHCPv6 Server Release procedures that leveraged the old way 3073 Relays used to "route" between Server link-local addresses 3075 o Remove all text relating to Relays needing to do any AERO-specific 3076 operations 3078 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 3079 as source addresses, and destination address of RA reply is to the 3080 AERO address corresponding to the Client's ACP. 3082 o Proxy uses SEND to protect RS and authenticate RA (Client does not 3083 use SEND, but rather relies on subnetwork security. When the 3084 Proxy receives an RS from the Client, it creates a new RS using 3085 its own addresses as the source and uses SEND with CGAs to send a 3086 new RS to the Server. 3088 o Emphasize distributed mobility management 3090 o AERO address-based RS injection of ACP into underlying routing 3091 system. 3093 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 3094 6706bis-00: 3096 o Document use of NUD (NS/NA) for reliable link-layer address 3097 updates as an alternative to unreliable unsolicited NA. 3098 Consistent with Section 7.2.6 of RFC4861. 3100 o Server adds additional layer of encapsulation between outer and 3101 inner headers of NS/NA messages for transmission through Relays 3102 that act as vanilla IPv6 routers. The messages include the AERO 3103 Server Subnet Router Anycast address as the source and the Subnet 3104 Router Anycast address corresponding to the Client's ACP as the 3105 destination. 3107 o Clients use Subnet Router Anycast address as the encapsulation 3108 source address when the access network does not provide a 3109 topologically-fixed address. 3111 Author's Address 3113 Fred L. Templin (editor) 3114 Boeing Research & Technology 3115 P.O. Box 3707 3116 Seattle, WA 98124 3117 USA 3119 Email: fltemplin@acm.org