idnits 2.17.1 draft-templin-intarea-6706bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2019) is 1900 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 2457, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 2493, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2746, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 2751, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2774, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-dmm-distributed-mobility-anchoring-12 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-06 == Outdated reference: A later version (-06) exists of draft-ietf-intarea-gue-extensions-05 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-26) exists of draft-ietf-rtgwg-atn-bgp-01 == Outdated reference: A later version (-05) exists of draft-templin-6man-aeroaddr-04 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-07 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-07 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-23 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc5320, rfc5558, rfc5720, February 13, 2019 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: August 17, 2019 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-intarea-6706bis-05.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 August 17, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 8 68 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 8 69 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 71 3.4. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 12 72 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 14 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 17 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 17 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 17 76 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 18 77 3.6.4. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 18 78 3.7. AERO Interface Neighbor Cache Maintenance . . . . . . . . 19 79 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 20 80 3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 21 81 3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 21 82 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 22 83 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 22 84 3.8.5. Processing Return Packets . . . . . . . . . . . . . . 23 85 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 24 86 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 25 87 3.11. AERO Interface Data Origin Authentication . . . . . . . . 25 88 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 26 89 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 28 90 3.14. AERO Router Discovery, Prefix Delegation and 91 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 31 92 3.14.1. AERO ND/PD Service Model . . . . . . . . . . . . . . 31 93 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 32 94 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 34 95 3.15. AERO Route Optimization . . . . . . . . . . . . . . . . . 36 96 3.15.1. Reference Operational Scenario . . . . . . . . . . . 36 97 3.15.2. Concept of Operations . . . . . . . . . . . . . . . 38 98 3.15.3. Sending NS Messages . . . . . . . . . . . . . . . . 38 99 3.15.4. Re-encapsulating and Relaying the NS . . . . . . . . 39 100 3.15.5. Processing NSs and Sending NAs . . . . . . . . . . . 40 101 3.15.6. Processing NAs . . . . . . . . . . . . . . . . . . . 41 102 3.15.7. Server-Based Route Optimization . . . . . . . . . . 41 103 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 43 104 3.17. Mobility Management and Quality of Service (QoS) . . . . 44 105 3.17.1. Forwarding Packets on Behalf of Departed Clients . . 45 106 3.17.2. Announcing Link-Layer Address and/or QoS Preference 107 Changes . . . . . . . . . . . . . . . . . . . . . . 45 108 3.17.3. Bringing New Links Into Service . . . . . . . . . . 45 109 3.17.4. Removing Existing Links from Service . . . . . . . . 46 110 3.17.5. Implicit Mobility Management . . . . . . . . . . . . 46 111 3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 46 112 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 47 113 4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 47 114 5. Direct Underlying Interfaces . . . . . . . . . . . . . . . . 49 115 6. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 49 116 7. AERO Adaptations for SEcure Neighbor Discovery (SEND) . . . . 50 117 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 118 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 119 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 120 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 121 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 122 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 123 12.2. Informative References . . . . . . . . . . . . . . . . . 55 124 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 60 125 Appendix B. When to Insert an Encapsulation Fragment Header . . 62 126 Appendix C. Autoconfiguration for Constrained Platforms . . . . 63 127 Appendix D. Operational Deployment Alternatives . . . . . . . . 64 128 D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 64 129 D.2. Operation on Server-less AERO Links . . . . . . . . . . . 64 130 D.3. Operation on Client-less AERO Links . . . . . . . . . . . 64 131 D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 65 132 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 65 133 D.6. Encapsulation Protocol Version Considerations . . . . . . 65 134 D.7. Extending AERO Links Through Security Gateways . . . . . 65 135 Appendix E. S/TLLAO Extensions for Special-Purpose Links . . . . 67 136 Appendix F. Change Log . . . . . . . . . . . . . . . . . . . . . 68 137 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 70 139 1. Introduction 141 This document specifies the operation of IP over tunnel virtual links 142 using Asymmetric Extended Route Optimization (AERO). The AERO link 143 can be used for tunneling between neighboring nodes over either IPv6 144 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 145 equivalent links for tunneling. Nodes attached to AERO links can 146 exchange packets via trusted intermediate routers that provide 147 forwarding services to reach off-link destinations and route 148 optimization services for improved performance [RFC5522]. 150 AERO provides an IPv6 link-local address format that supports 151 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 152 links ND to IP forwarding. Dynamic link selection, mobility 153 management, quality of service (QoS) signaling and route optimization 154 are naturally supported through dynamic neighbor cache updates, while 155 IPv6 Prefix Delegation (PD) is supported by network services such as 156 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415]. 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 numbered sections present the AERO specification. The 176 appendices at the end of the document are non-normative. 178 2. Terminology 180 The terminology in the normative references applies; the following 181 terms are defined within the scope of this document: 183 IPv6 Neighbor Discovery (ND) 184 an IPv6 control message service for coordinating neighbor 185 relationships between nodes connected to a common link. The ND 186 service used by AERO is specified in [RFC4861]. 188 IPv6 Prefix Delegation (PD) 189 a networking service for delegating IPv6 prefixes to nodes on the 190 link. The nominal PD service is DHCPv6 [RFC8415], however 191 alternate services (e.g., based on ND messaging) are also 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 secured enclave 302 a private access network (e.g., a corporate enterprise network, 303 radio access network, cellular service provider network, etc.) 304 with secured links and perimeters. Link-layer security services 305 such as IEEE 802.1X and physical-layer security such as campus 306 wired LANs prevent unauthorized access from within the enclave, 307 while border network-layer security services such as firewalls and 308 proxies prevent unauthorized access from the external 309 Internetwork. 311 Potential Router List (PRL) 312 a geographically and/or topologicallly referenced list of IP 313 addresses of Servers for the AERO link. 315 Throughout the document, the simple terms "Client", "Server", "Relay" 316 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 317 "AERO Proxy", respectively. Capitalization is used to distinguish 318 these terms from DHCPv6 client/server/relay [RFC8415]. 320 The terminology of DHCPv6 [RFC8415] and IPv6 ND [RFC4861] (including 321 the names of node variables, messages and protocol constants) is used 322 throughout this document. Also, the term "IP" is used to generically 323 refer to either Internet Protocol version, i.e., IPv4 [RFC0791] or 324 IPv6 [RFC8200]. 326 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 327 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 328 document are to be interpreted as described in [RFC2119]. Lower case 329 uses of these words are not to be interpreted as carrying RFC2119 330 significance. 332 3. Asymmetric Extended Route Optimization (AERO) 334 The following sections specify the operation of IP over Asymmetric 335 Extended Route Optimization (AERO) links: 337 3.1. AERO Link Reference Model 339 .-(::::::::) 340 .-(::::::::::::)-. 341 (:: Internetwork ::) 342 `-(::::::::::::)-' 343 `-(::::::)-' 344 | 345 +--------------+ +--------+-------+ +--------------+ 346 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 347 | Nbr: C1, R1 | | Nbr: S1, S2 | | Nbr: C2, R1 | 348 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 349 | X1->C1 | | ASP A1 | | X2->C2 | 350 +-------+------+ +--------+-------+ +------+-------+ 351 | AERO Link | | 352 X---+---+-------------------+-+----------------+---+---X 353 | | | 354 +-----+--------+ +----------+------+ +--------+-----+ 355 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 356 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 357 | default->S1 | +--------+--------+ | default->S2 | 358 | ACP X1 | | | ACP X2 | 359 +------+-------+ .--------+------. +-----+--------+ 360 | (- Proxyed Clients -) | 361 .-. `---------------' .-. 362 ,-( _)-. ,-( _)-. 363 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 364 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 365 `-(______)-' +-------+ +-------+ `-(______)-' 367 Figure 1: AERO Link Reference Model 369 Figure 1 presents the AERO link reference model. In this model: 371 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 372 default router for its associated Servers (S1 and S2), and 373 connects the AERO link to the rest of the Internetwork. 375 o AERO Servers S1 and S2 associate with Relay R1 and also act as 376 default routers for their associated Clients C1 and C2. 378 o AERO Clients C1 and C2 associate with Servers S1 and S2, 379 respectively. They receive AERO Client Prefix (ACP) delegations 380 X1 and X2, and also act as default routers for their associated 381 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 382 to the EUNs served by Clients C1 and C2, respectively. 384 o AERO Proxy P1 provides proxy services for AERO Clients in secured 385 enclaves that cannot associate directly with other AERO link 386 neighbors. 388 Each node on the AERO link maintains an AERO interface neighbor cache 389 and an IP forwarding table the same as for any link. Although the 390 figure shows a limited deployment, in common operational practice 391 there may be many additional Relays, Servers, Clients and Proxies. 393 3.2. AERO Node Types 395 AERO Relays are standard IP routers that provide default forwarding 396 services for AERO Servers. Each Relay also peers with Servers and 397 other Relays in a dynamic routing protocol instance to discover the 398 list of active ACPs (see Section 3.3). Relays forward packets 399 between neighbors connected to the same AERO link and also forward 400 packets between the AERO link and the native Internetwork. Relays 401 present the AERO link to the native Internetwork as a set of one or 402 more AERO Service Prefixes (ASPs) and serve as a gateway between the 403 AERO link and the Internetwork. Relays maintain tunnels with 404 neighboring Servers, and maintain an IP forwarding table entry for 405 each AERO Client Prefix (ACP). 407 AERO Servers provide default forwarding services for AERO Clients. 408 Each Server also peers with Relays in a dynamic routing protocol 409 instance to advertise its list of associated ACPs (see Section 3.3). 410 Servers facilitate PD exchanges with Clients, where each delegated 411 prefix becomes an ACP taken from an ASP. Servers forward packets 412 between AERO interface neighbors, and maintain AERO interface 413 neighbor cache entries for Relays. They also maintain both neighbor 414 cache entries and IP forwarding table entries for each of their 415 associated Clients. 417 AERO Clients act as requesting routers to receive ACPs through PD 418 exchanges with AERO Servers over the AERO link. Each Client can 419 associate with a single Server or with multiple Servers, e.g., for 420 fault tolerance, load balancing, etc. Each IPv6 Client receives at 421 least a /64 IPv6 ACP, and may receive even shorter prefixes. 422 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 423 singleton IPv4 address), and may receive even shorter prefixes. 424 Clients maintain an AERO interface neighbor cache entry for each of 425 their associated Servers as well as for each of their correspondent 426 Clients. 428 AERO Proxies provide a transparent conduit for AERO Clients connected 429 to secured enclaves to associate with AERO link Servers. The Client 430 sends all of its control plane messages to the Server's link-layer 431 address and the Proxy intercepts them before they leave the secured 432 enclave. The Proxy forwards the Client's control and data plane 433 messages to and from the Client's current Server(s). The Proxy may 434 also discover a more direct route toward a target destination via 435 AERO route optimization, in which case future outbound data packets 436 would be forwarded via the more direct route. The Proxy function is 437 specified in Section 4. 439 AERO Relays, Servers and Proxies are critical infrastructure elements 440 in fixed (i.e., non-mobile) deployments. AERO Relays and Servers 441 must use public link-layer addresses that do not change and can be 442 reached from any correspondent in the underlying Internetwork (i.e., 443 in the same fashion as for popular Internet services). AERO Clients 444 may be mobile, and may not have any public link-layer addresses, 445 e.g., if they are located behind NATs or Proxies. 447 3.3. AERO Routing System 449 The AERO routing system comprises a private instance of the Border 450 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 451 and Servers and does not interact with either the public Internet BGP 452 routing system or the native Internetwork routing system. Relays 453 advertise only a small and unchanging set of ASPs to the native 454 Internetwork routing system instead of the full dynamically changing 455 set of ACPs. 457 In a reference deployment, each AERO Server is configured as an 458 Autonomous System Border Router (ASBR) for a stub Autonomous System 459 (AS) using an AS Number (ASN) that is unique within the BGP instance, 460 and each Server further uses eBGP to peer with one or more Relays but 461 does not peer with other Servers. All Relays are members of the same 462 hub AS using a common ASN, and use iBGP to maintain a consistent view 463 of all active ACPs currently in service. 465 Each Server maintains a working set of associated ACPs, and 466 dynamically announces new ACPs and withdraws departed ACPs in its 467 eBGP updates to Relays. Clients are expected to remain associated 468 with their current Servers for extended timeframes, however Servers 469 SHOULD selectively suppress updates for impatient Clients that 470 repeatedly associate and disassociate with them in order to dampen 471 routing churn. 473 Each Relay configures a black-hole route for each of its ASPs. By 474 black-holing the ASPs, the Relay will maintain forwarding table 475 entries only for the ACPs that are currently active, and packets 476 destined to all other ACPs will correctly incur Destination 477 Unreachable messages due to the black hole route. Relays do not send 478 eBGP updates for ACPs to Servers, but instead only originate a 479 default route. In this way, Servers have only partial topology 480 knowledge (i.e., they know only about the ACPs of their directly 481 associated Clients) and they forward all other packets to Relays 482 which have full topology knowledge. 484 Scaling properties of the AERO routing system are limited by the 485 number of BGP routes that can be carried by Relays. As of 2015, the 486 global public Internet BGP routing system manages more than 500K 487 routes with linear growth and no signs of router resource exhaustion 488 [BGP]. More recent network emulation studies have also shown that a 489 single Relay can accommodate at least 1M dynamically changing BGP 490 routes even on a lightweight virtual machine, i.e., and without 491 requiring high-end dedicated router hardware. 493 Therefore, assuming each Relay can carry 1M or more routes, this 494 means that at least 1M Clients can be serviced by a single set of 495 Relays. A means of increasing scaling would be to assign a different 496 set of Relays for each set of ASPs. In that case, each Server still 497 peers with one or more Relays, but the Server institutes route 498 filters so that it only sends BGP updates to the specific set of 499 Relays that aggregate the ASP. For example, if the ASP for the AERO 500 link is 2001:db8::/32, a first set of Relays could service the ASP 501 segment 2001:db8::/40, a second set of Relays could service 502 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 503 etc. 505 Assuming up to 1K sets of Relays, the AERO routing system can then 506 accommodate 1B or more ACPs with no additional overhead for Servers 507 and Relays (for example, it should be possible to service 1B /64 ACPs 508 taken from a /34 ASP and even more for shorter prefixes). In this 509 way, each set of Relays services a specific set of ASPs that they 510 advertise to the native Internetwork routing system, and each Server 511 configures ASP-specific routes that list the correct set of Relays as 512 next hops. This arrangement also allows for natural incremental 513 deployment, and can support small scale initial deployments followed 514 by dynamic deployment of additional Clients, Servers and Relays 515 without disturbing the already-deployed base. 517 In an alternate routing arrangement, each set of Relays could 518 advertise an aggregated ASP for the link into the native Internetwork 519 routing system even though each Relay services only smaller segments 520 of the ASP. In that case, a Relay upon receiving a packet with a 521 destination address covered by the ASP segment of another Relay can 522 simply tunnel the packet to the other Relay. The tradeoff then is 523 the penalty for Relay-to-Relay tunneling compared with reduced 524 routing information in the native routing system. 526 A full discussion of the BGP-based routing system used by AERO is 527 found in [I-D.ietf-rtgwg-atn-bgp]. The system provides for 528 Distributed Mobility Management (DMM) per the distributed mobility 529 anchoring architecture [I-D.ietf-dmm-distributed-mobility-anchoring]. 531 3.4. AERO Addresses 533 A Client's AERO address is an IPv6 link-local address with an 534 interface identifier based on the Client's delegated ACP. Relay and 535 Server AERO addresses are assigned from the range fe80::/96 and 536 include an administratively-provisioned value in the lower 32 bits. 538 For IPv6, Client AERO addresses begin with the prefix fe80::/64 and 539 include in the interface identifier (i.e., the lower 64 bits) a 540 64-bit prefix taken from one of the Client's IPv6 ACPs. For example, 541 if the AERO Client receives the IPv6 ACP: 543 2001:db8:1000:2000::/56 545 it constructs its corresponding AERO addresses as: 547 fe80::2001:db8:1000:2000 549 fe80::2001:db8:1000:2001 551 fe80::2001:db8:1000:2002 553 ... etc. ... 555 fe80::2001:db8:1000:20ff 557 For IPv4, Client AERO addresses are based on an IPv4-mapped IPv6 558 address formed from an IPv4 ACP and with a Prefix Length of 96 plus 559 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 560 the IPv4-mapped IPv6 ACP is: 562 0:0:0:0:0:FFFF:192.0.2.16/124 564 The Client then constructs its AERO addresses with the prefix 565 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 566 in the interface identifier as: 568 fe80::FFFF:192.0.2.16 570 fe80::FFFF:192.0.2.17 571 fe80::FFFF:192.0.2.18 573 ... etc. ... 575 fe80:FFFF:192.0.2.31 577 Relay and Server AERO addresses are allocated from the range 578 fe80::/96, and MUST be managed for uniqueness by the administrative 579 authority for the link. For interfaces that assign static IPv4 580 addresses, the lower 32 bits of the AERO address includes the IPv4 581 address, e.g., for the IPv4 address 192.0.2.1 the corresponding AERO 582 address is fe80::192.0.2.1. For other interfaces, the lower 32 bits 583 of the AERO address includes a unique integer value, e.g., fe80::1, 584 fe80::2, fe80::3, etc. (Note that the address fe80:: is reserved as 585 the IPv6 link-local Subnet Router Anycast address [RFC4291], and the 586 address fe80::ffff:ffff is reserved as the prefix solicitation 587 address; hence, these values are not available for administrative 588 assignment.) 590 When the Server delegates ACPs to the Client, the lowest-numbered 591 AERO address from the first ACP delegation serves as the "base" AERO 592 address (for example, for the ACP 2001:db8:1000:2000::/56 the base 593 AERO address is fe80::2001:db8:1000:2000). The Client then assigns 594 the base AERO address to the AERO interface and uses it for the 595 purpose of maintaining the neighbor cache entry. The Server likewise 596 uses the AERO address as its index into the neighbor cache for this 597 Client. 599 If the Client has multiple AERO addresses (i.e., when there are 600 multiple ACPs and/or ACPs with prefix lengths shorter than /64), the 601 Client originates ND messages using the base AERO address as the 602 source address and accepts and responds to ND messages destined to 603 any of its AERO addresses as equivalent to the base AERO address. In 604 this way, the Client maintains a single neighbor cache entry that may 605 be indexed by multiple AERO addresses. 607 AERO addresses that embed an IPv6 prefix can be statelessly 608 transformed into an IPv6 Subnet Router Anycast address and vice- 609 versa. For example, for the AERO address fe80::2001:db8:2000:3000 610 the corresponding Subnet Router Anycast address is 611 2001:db8:2000:3000::. In the same way, for the IPv6 Subnet Router 612 Anycast address 2001:db8:1:2:: the corresponding AERO address is 613 fe80::2001:db8:1:2. In other words, the low-order 64 bits of an AERO 614 address can be used as the high-order 64 bits of a Subnet Router 615 Anycast address, and vice-versa. 617 AERO links additionally reserve an IPv6 prefix to support 618 encapsulated forwarding of IPv6 ND messages between Servers on the 619 link. Although any non-link-local IPv6 prefix could be reserved for 620 this purpose, a Unique Local Address (ULA) prefix [RFC4389] would be 621 a good candidate since it is not routable outside of the AERO link. 622 For example, if the reserved (ULA) prefix is fd00:db8::/64 the AERO 623 Server Subnet Router Anycast Address is fd00:db8::. 625 A full discussion of the AERO addressing service is found in 626 [I-D.templin-6man-aeroaddr]. 628 3.5. AERO Interface Characteristics 630 AERO interfaces use encapsulation (see: Section 3.9) to exchange 631 packets with neighbors attached to the AERO link. 633 AERO interfaces maintain a neighbor cache for tracking per-neighbor 634 state the same as for any interface. AERO interfaces use ND messages 635 including Router Solicitation (RS), Router Advertisement (RA), 636 Neighbor Solicitation (NS), Neighbor Advertisement (NA) and Redirect 637 for neighbor cache management. 639 AERO interface ND messages include one or more Source/Target Link- 640 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type | Length = 5 | Reserved | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Interface ID | UDP Port Number | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 + + 651 | | 652 + IP Address + 653 | | 654 + + 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 667 Format 669 In this format: 671 o Type is set to '1' for SLLAO or '2' for TLLAO. 673 o Length is set to the constant value '5' (i.e., 5 units of 8 674 octets). 676 o Reserved is set to the value '0' on transmission and ignored on 677 receipt. 679 o Interface ID is set to a 16-bit integer value corresponding to an 680 underlying interface of the AERO node. Once the node has assigned 681 an Interface ID to an underlying interface, the assignment must 682 remain unchanged until the node fully detaches from the AERO link. 684 o UDP Port Number and IP Address are set to the addresses used by 685 the AERO node when it sends encapsulated packets over the 686 specified underlying interface (or to '0' when the addresses are 687 left unspecified). When UDP is not used as part of the 688 encapsulation, UDP Port Number is set to '0'. When the 689 encapsulation IP address family is IPv4, IP Address is formed as 690 an IPv4-mapped IPv6 address as specified in Section 3.4. 692 o P(i) is a set of Preferences that correspond to the 64 693 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 694 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 695 ("medium") or '3' ("high") to indicate a QoS preference level for 696 packet forwarding purposes. 698 AERO interfaces may be configured over multiple underlying interface 699 connections to underlying links. For example, common mobile handheld 700 devices have both wireless local area network ("WLAN") and cellular 701 wireless links. These links are typically used "one at a time" with 702 low-cost WLAN preferred and highly-available cellular wireless as a 703 standby. In a more complex example, aircraft frequently have many 704 wireless data link types (e.g. satellite-based, cellular, 705 terrestrial, air-to-air directional, etc.) with diverse performance 706 and cost properties. 708 A Client's underlying interfaces are classified as follows: 710 o Native interfaces connect to the open Internetwork, and have a 711 global IP address that is reachable from any open Internetwork 712 correspondent. 714 o NATed interfaces connect to a closed network that is separated 715 from the open Internetwork by a Network Address Translator (NAT). 716 The NAT does not participate in any AERO control message 717 signaling, but the AERO Server can issue control messages on 718 behalf of the Client. 720 o VPNed interfaces use security encapsulation over the Internetwork 721 to a Virtual Private Network (VPN) gateway that also acts as an 722 AERO Server. As with NATed links, the AERO Server can issue 723 control messages on behalf of the Client. 725 o Proxyed interfaces connect to a closed network that is separated 726 from the open Internetwork by an AERO Proxy. Unlike NATed and 727 VPNed interfaces, the AERO Proxy can also issue control messages 728 on behalf of the Client. 730 o Direct interfaces connect the Client directly to a neighbor 731 without crossing any networked paths. An example is a line-of- 732 sight link between a remote pilot and an unmanned aircraft. 734 If a Client's multiple underlying interfaces are used "one at a time" 735 (i.e., all other interfaces are in standby mode while one interface 736 is active), then ND messages include only a single S/TLLAO with 737 Interface ID set to a constant value. In that case, the Client would 738 appear to have a single underlying interface but with a dynamically 739 changing link-layer address. 741 If the Client has multiple active underlying interfaces, then from 742 the perspective of ND it would appear to have multiple link-layer 743 addresses. In that case, ND messages MAY include multiple S/TLLAOs 744 -- each with an Interface ID that corresponds to a specific 745 underlying interface of the AERO node. 747 When the Client includes an S/TLLAO for an underlying interface for 748 which it is aware that there is a NAT or Proxy on the path to the 749 Server, or when a node includes an S/TLLAO solely for the purpose of 750 announcing new QoS preferences, the node sets both UDP Port Number 751 and IP Address to 0 to indicate that the addresses are unspecified at 752 the network layer and must instead be derived from the link-layer 753 encapsulation headers. 755 When an ND message includes multiple S/TLLAOs, the first S/TLLAO MUST 756 correspond to the AERO node's underlying interface used to transmit 757 the message. 759 3.6. AERO Interface Initialization 761 3.6.1. AERO Relay Behavior 763 When a Relay enables an AERO interface, it first assigns an 764 administratively-provisioned AERO address fe80::ID to the interface. 765 Each fe80::ID address MUST be unique among all AERO nodes on the 766 link. The Relay then engages in a dynamic routing protocol session 767 with one or more Servers and all other Relays on the link (see: 768 Section 3.3), and advertises its assigned ASPs into the native 769 Internetwork. Each Relay subsequently maintains an IP forwarding 770 table entry for each active ACP covered by its ASP(s). 772 3.6.2. AERO Server Behavior 774 When a Server enables an AERO interface, it assigns an 775 administratively-provisioned AERO address fe80::ID the same as for 776 Relays. The Server further configures a service to facilitate ND/PD 777 exchanges with AERO Clients. The Server maintains neighbor cache 778 entries for one or more Relays on the link, and manages per-Client 779 neighbor cache entries and IP forwarding table entries based on 780 control message exchanges. The Server also engages in a dynamic 781 routing protocol with its neighboring Relays (see: Section 3.3). 783 When the Server receives an NS/RS message on the AERO interface it 784 authenticates the message and returns an NA/RA message. (When the 785 Server receives an unsolicited NA message, it likewise authenticates 786 the message and processes it locally.) The Server further provides a 787 simple link-layer conduit between AERO interface neighbors. In 788 particular, when a packet sent by a source Client arrives on the 789 Server's AERO interface and is destined to another AERO node, the 790 Server forwards the packet from within the AERO interface at the link 791 layer without ever disturbing the network layer. 793 3.6.3. AERO Client Behavior 795 When a Client enables an AERO interface, it sends RS messages with 796 ND/PD parameters over an underlying interface to one or more AERO 797 Servers, which return RA messages with corresponding PD parameters. 798 See [I-D.templin-6man-dhcpv6-ndopt] for the types of ND/PD parameters 799 that can be included in the RS/RA message exchanges. 801 After the initial ND/PD message exchange, the Client assigns AERO 802 addresses to the AERO interface based on the delegated prefix(es). 803 The Client can then register additional underlying interfaces with 804 the Server by sending a simple RS message (i.e., one with no PD 805 parameters) over each underlying interface using its base AERO 806 address as the source network layer address. The Server will update 807 its neighbor cache entry for the Client and return a simple RA 808 message. 810 The Client maintains a neighbor cache entry for each of its Servers 811 and each of its active correspondent Clients. When the Client 812 receives ND messages on the AERO interface it updates or creates 813 neighbor cache entries, including link-layer address and QoS 814 preferences. 816 3.6.4. AERO Proxy Behavior 818 When a Proxy enables an AERO interface, it maintains per-Client proxy 819 neighbor cache entries based on control message exchanges. Proxies 820 forward packets between their associated Clients and each Client's 821 associated Servers. 823 When the Proxy receives an RS message from a Client in the secured 824 enclave, it creates an incomplete proxy neighbor cache entry and 825 sends a proxyed RS message to a Server selected by the Client while 826 using its own link-layer address as the source address. When the 827 Server returns an RA message, the Proxy completes the proxy neighbor 828 cache entry based on autoconfiguration information in the RA and 829 sends a proxyed RA to the Client while using its own link-layer 830 address as the source address. The Client, Server and Proxy will 831 then have the necessary state for managing the proxy neighbor 832 association. 834 3.7. AERO Interface Neighbor Cache Maintenance 836 Each AERO interface maintains a conceptual neighbor cache that 837 includes an entry for each neighbor it communicates with on the AERO 838 link, the same as for any IPv6 interface [RFC4861]. AERO interface 839 neighbor cache entries are said to be one of "permanent", "static", 840 "proxy" or "dynamic". 842 Permanent neighbor cache entries are created through explicit 843 administrative action; they have no timeout values and remain in 844 place until explicitly deleted. AERO Relays maintain permanent 845 neighbor cache entries for their associated Relays and Servers on the 846 link, and AERO Servers maintain permanent neighbor cache entries for 847 their associated Relays. Each entry maintains the mapping between 848 the neighbor's fe80::ID network-layer address and corresponding link- 849 layer address. 851 Static neighbor cache entries are created and maintained through ND/ 852 PD exchanges as specified in Section 3.14, and remain in place for 853 durations bounded by ND/PD lifetimes. AERO Servers maintain static 854 neighbor cache entries for each of their associated Clients, and AERO 855 Clients maintain static neighbor cache entries for each of their 856 associated Servers. 858 Proxy neighbor cache entries are created and maintained by AERO 859 Proxies when they process Client/Server ND/PD exchanges, and remain 860 in place for durations bounded by ND/PD lifetimes. AERO Proxies 861 maintain proxy neighbor cache entries for each of their associated 862 Clients. 864 Dynamic neighbor cache entries are created or updated based on 865 receipt of route optimization messages as specified in Section 3.15, 866 and are garbage-collected when keepalive timers expire. AERO nodes 867 maintain dynamic neighbor cache entries for each of their active 868 correspondents with lifetimes based on ND messaging constants. 870 When a target AERO node receives a valid NS message used for route 871 optimization, it returns an NA message and also creates or updates a 872 dynamic neighbor cache entry for the source network-layer and link- 873 layer addresses. The node then sets a "ReportTime" variable in the 874 neighbor cache entry to REPORT_TIME seconds. The node resets 875 ReportTime when it receives a new NS message, and otherwise 876 decrements ReportTime while no NS messages have been received. It is 877 RECOMMENDED that REPORT_TIME be set to the default constant value 40 878 seconds to allow a 10 second window so that the AERO route 879 optimization procedure can converge before ReportTime decrements 880 below FORWARD_TIME (see below). 882 When a source AERO node receives a valid NA message response to its 883 NS message, it creates or updates a dynamic neighbor cache entry for 884 the target network-layer and link-layer addresses. The node then 885 sets a "ForwardTime" variable in the neighbor cache entry to 886 FORWARD_TIME seconds and uses this value to determine whether packets 887 can be forwarded directly to the correspondent, i.e., instead of via 888 a default route. The node resets ForwardTime when it receives a new 889 NA, and otherwise decrements ForwardTime while no further NA messages 890 arrive. It is RECOMMENDED that FORWARD_TIME be set to the default 891 constant value 30 seconds to match the default REACHABLE_TIME value 892 specified in [RFC4861]. 894 The node also sets a "MaxRetry" variable to MAX_RETRY to limit the 895 number of keepalives sent when a correspondent may have gone 896 unreachable. It is RECOMMENDED that MAX_RETRY be set to 3 the same 897 as described for address resolution in Section 7.3.3 of [RFC4861]. 899 Different values for REPORT_TIME, FORWARD_TIME and MAX_RETRY MAY be 900 administratively set; however, if different values are chosen, all 901 nodes on the link MUST consistently configure the same values. Most 902 importantly, REPORT_TIME SHOULD be set to a value that is 903 sufficiently longer than FORWARD_TIME to allow the AERO route 904 optimization procedure to converge. 906 When there may be a NAT or Proxy between the Client and the Server, 907 or if the path from the Client to the Server should be tested for 908 reachability, the Client can send periodic RS messages to the Server 909 without PD parameters to receive RA replies. The RS/RA messaging 910 will keep NAT/Proxy state alive and test Server reachability without 911 disturbing the PD service. 913 3.8. AERO Interface Forwarding Algorithm 915 IP packets enter a node's AERO interface either from the network 916 layer (i.e., from a local application or the IP forwarding system) or 917 from the link layer (i.e., from the AERO tunnel virtual link). 918 Packets that enter the AERO interface from the network layer are 919 encapsulated and forwarded into the AERO link, i.e., they are 920 tunneled to an AERO interface neighbor. Packets that enter the AERO 921 interface from the link layer are either re-admitted into the AERO 922 link or forwarded to the network layer where they are subject to 923 either local delivery or IP forwarding. In all cases, the AERO 924 interface itself MUST NOT decrement the network layer TTL/Hop-count 925 since its forwarding actions occur below the network layer. 927 AERO interfaces may have multiple underlying interfaces and/or 928 neighbor cache entries for neighbors with multiple Interface ID 929 registrations (see Section 3.5). The AERO node uses each packet's 930 DSCP value to select an outgoing underlying interface based on the 931 node's own QoS preferences, and also to select a destination link- 932 layer address based on the neighbor's underlying interface with the 933 highest preference. AERO implementations SHOULD allow for QoS 934 preference values to be modified at runtime through network 935 management. 937 If multiple outgoing interfaces and/or neighbor interfaces have a 938 preference of "high", the AERO node sends one copy of the packet via 939 each of the (outgoing / neighbor) interface pairs; otherwise, the 940 node sends a single copy of the packet via the interface with the 941 highest preference. AERO nodes keep track of which underlying 942 interfaces are currently "reachable" or "unreachable", and only use 943 "reachable" interfaces for forwarding purposes. 945 The following sections discuss the AERO interface forwarding 946 algorithms for Clients, Proxies, Servers and Relays. In the 947 following discussion, a packet's destination address is said to 948 "match" if it is a non-link-local address with a prefix covered by an 949 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 950 the same as an administratively-provisioned AERO address. 952 3.8.1. Client Forwarding Algorithm 954 When an IP packet enters a Client's AERO interface from the network 955 layer the Client searches for a dynamic neighbor cache entry that 956 matches the destination. If there is a match, the Client uses one or 957 more "reachable" link-layer addresses in the entry as the link-layer 958 addresses for encapsulation and admits the packet into the AERO link. 959 Otherwise, the Client uses the link-layer address in a static 960 neighbor cache entry for a Server as the encapsulation address 961 (noting that there may be a Proxy on the path to the real Server). 963 When an IP packet enters a Client's AERO interface from the link- 964 layer, if the destination matches one of the Client's ACPs or link- 965 local addresses the Client decapsulates the packet and delivers it to 966 the network layer. Otherwise, the Client drops the packet and MAY 967 return a network-layer ICMP Destination Unreachable message subject 968 to rate limiting (see: Section 3.13). 970 3.8.2. Proxy Forwarding Algorithm 972 When the Proxy receives a packet from a Client within the secured 973 enclave, the Proxy searches for a dynamic neighbor cache entry that 974 matches the destination. If there is a match, the Proxy uses one or 975 more "reachable" link-layer addresses in the entry as the link-layer 976 addresses for encapsulation and admits the packet into the AERO link. 978 Otherwise, the Proxy uses the link-layer address for one of the 979 Client's Servers as the encapsulation address. 981 When the Proxy receives a packet from an AERO interface neighbor, it 982 searches for a proxy neighbor cache entry for a Client within the 983 secured enclave that matches the destination. If there is a match, 984 the Proxy forwards the packet to the Client. Otherwise, the Proxy 985 returns the packet to the neighbor, i.e., by reversing the source and 986 destination link-layer addresses and re-admitting the packet into the 987 AERO link. 989 3.8.3. Server Forwarding Algorithm 991 When an IP packet enters a Server's AERO interface from the network 992 layer, the Server searches for a static neighbor cache entry for a 993 Client that matches the destination. If there is a match, the Server 994 uses one or more link-layer addresses in the entry as the link-layer 995 addresses for encapsulation and admits the packet into the AERO link. 996 Otherwise, the Server uses the link-layer address in a permanent 997 neighbor cache entry for a Relay (selected through longest-prefix 998 match) as the link-layer address for encapsulation. 1000 When an IP packet enters a Server's AERO interface from the link 1001 layer, the Server processes the packet according to the network-layer 1002 destination address as follows: 1004 o if the destination matches one of the Server's own addresses the 1005 Server decapsulates the packet and forwards it to the network 1006 layer for local delivery. 1008 o else, if the destination matches a static neighbor cache entry for 1009 a Client the Server first determines whether the neighbor is the 1010 same as the one it received the packet from. If so, the Server 1011 drops the packet silently to avoid looping; otherwise, the Server 1012 uses the neighbor's link-layer address(es) as the destination for 1013 encapsulation and re-admits the packet into the AERO link. 1015 o else, the Server uses the link-layer address in a neighbor cache 1016 entry for a Relay (selected through longest-prefix match) as the 1017 link-layer address for encapsulation. 1019 3.8.4. Relay Forwarding Algorithm 1021 When an IP packet enters a Relay's AERO interface from the network 1022 layer, the Relay searches its IP forwarding table for an ACP entry 1023 that matches the destination the same as for any IP router. If there 1024 is a match, the Relay uses the link-layer address in the 1025 corresponding neighbor cache entry as the link-layer address for 1026 encapsulation and forwards the packet to the AERO neighbor. 1027 Otherwise, the Relay drops the packet and returns a network-layer 1028 ICMP Destination Unreachable message subject to rate limiting (see: 1029 Section 3.13). 1031 When an IP packet enters a Relay's AERO interface from the link- 1032 layer, (i.e., when it receives an encapsulated packet from a Server) 1033 the Relay processes the packet as follows: 1035 o if the destination does not match an ASP, or if the destination 1036 matches one of the Relay's own addresses, the Relay decapsulates 1037 the packet and forwards it to the network layer where it will be 1038 subject to either IP forwarding or local delivery. 1040 o else, if the destination matches an ACP entry in the IP forwarding 1041 table the Relay first determines whether the neighbor is the same 1042 as the one it received the packet from. If so the Relay MUST drop 1043 the packet silently to avoid looping; otherwise, the Relay uses 1044 the neighbor's link-layer address as the destination for 1045 encapsulation and re-admits the packet into the AERO link. 1047 o else, the Relay drops the packet and returns an ICMP Destination 1048 Unreachable message subject to rate limiting (see: Section 3.13). 1050 3.8.5. Processing Return Packets 1052 When an AERO Server receives a return packet from an AERO Proxy (see 1053 Section 3.8.2), it proceeds according to the AERO link trust basis. 1054 Namely, the return packets have the same trust profile as for link- 1055 layer Destination Unreachable messages. If the Server has sufficient 1056 trust basis to accept link-layer Destination Unreachable messages, it 1057 can then process the return packet by searching for a dynamic 1058 neighbor cache entry that matches the destination. If there is a 1059 match, the Server marks the corresponding link-layer address as 1060 "unreachable", selects the next-highest priority "reachable" link- 1061 layer address in the entry as the link-layer address for 1062 encapsulation then (re)admits the packet into the AERO link. If 1063 there are no "reachable" link-layer addresses, the Server instead 1064 sets ForwardTime in the dynamic neighbor cache entry to 0 (noting 1065 that ReportTime may still be non-zero). Otherwise, the Server SHOULD 1066 drop the packet and treat it as an indication that a path may be 1067 failing, and MAY use Neighbor Unreachability Detection (NUD) (see: 1068 Section 3.13) to test the path for reachability. 1070 When an AERO Relay receives a return packet from an AERO Server, it 1071 searches its routing table for an entry that matches the inner 1072 destination address. If there is a routing table entry that lists a 1073 different Server as the next hop, the Relay forwards the packet to 1074 the different Server; otherwise, the Relay drops the packet. 1076 3.9. AERO Interface Encapsulation and Re-encapsulation 1078 AERO interfaces encapsulate IP packets according to whether they are 1079 entering the AERO interface from the network layer or if they are 1080 being re-admitted into the same AERO link they arrived on. This 1081 latter form of encapsulation is known as "re-encapsulation". 1083 The AERO interface encapsulates packets per the Generic UDP 1084 Encapsulation (GUE) procedures in 1085 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 1086 an alternate encapsulation format (e.g., see: Appendix A, [RFC2784], 1087 [RFC8086], [RFC4301], etc.). For packets entering the AERO interface 1088 from the network layer, the AERO interface copies the "TTL/Hop 1089 Limit", "Type of Service/Traffic Class" [RFC2983], "Flow 1090 Label"[RFC6438] (for IPv6) and "Congestion Experienced" [RFC3168] 1091 values in the packet's IP header into the corresponding fields in the 1092 encapsulation IP header. For packets undergoing re-encapsulation, 1093 the AERO interface instead copies these values from the original 1094 encapsulation IP header into the new encapsulation header, i.e., the 1095 values are transferred between encapsulation headers and *not* copied 1096 from the encapsulated packet's network-layer header. (Note 1097 especially that by copying the TTL/Hop Limit between encapsulation 1098 headers the value will eventually decrement to 0 if there is a 1099 (temporary) routing loop.) For IPv4 encapsulation/re-encapsulation, 1100 the AERO interface sets the DF bit as discussed in Section 3.12. 1102 When GUE encapsulation is used, the AERO interface next sets the UDP 1103 source port to a constant value that it will use in each successive 1104 packet it sends, and sets the UDP length field to the length of the 1105 encapsulated packet plus 8 bytes for the UDP header itself plus the 1106 length of the GUE header (or 0 if GUE direct IP encapsulation is 1107 used). For packets sent to a Server or Relay, the AERO interface 1108 sets the UDP destination port to 8060, i.e., the IANA-registered port 1109 number for AERO. For packets sent to a Client, the AERO interface 1110 sets the UDP destination port to the port value stored in the 1111 neighbor cache entry for this Client. The AERO interface then either 1112 includes or omits the UDP checksum according to the GUE 1113 specification. 1115 Clients normally use the IP address of the underlying interface as 1116 the encapsulation source address. If the underlying interface does 1117 not have an IP address, however, the Client uses an IP address taken 1118 from an ACP as the encapsulation source address (assuming the node 1119 has some way of injecting the ACP into the underlying network routing 1120 system). For IPv6 addresses, the Client normally uses the ACP Subnet 1121 Router Anycast address [RFC4291]. 1123 When GUE encapsulation is not available, encapsulation between 1124 Servers and Relays can use standard mechanisms such as Generic 1125 Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP [RFC8086] and IPSec 1126 [RFC4301] so that Relays can be standard IP routers with no AERO- 1127 specific mechanisms. 1129 3.10. AERO Interface Decapsulation 1131 AERO interfaces decapsulate packets destined either to the AERO node 1132 itself or to a destination reached via an interface other than the 1133 AERO interface the packet was received on. Decapsulation is per the 1134 procedures specified for the appropriate encapsulation format. 1136 3.11. AERO Interface Data Origin Authentication 1138 AERO nodes employ simple data origin authentication procedures for 1139 encapsulated packets they receive from other nodes on the AERO link. 1140 In particular: 1142 o AERO Relays and Servers accept encapsulated packets with a link- 1143 layer source address that matches a permanent neighbor cache 1144 entry. 1146 o AERO Servers accept authentic encapsulated ND messages from 1147 Clients (either directly or via a Proxy), and create or update a 1148 static neighbor cache entry for the Client based on the specific 1149 message type. 1151 o AERO Clients and Servers accept encapsulated packets if there is a 1152 static neighbor cache entry with a link-layer address that matches 1153 the packet's link-layer source address. 1155 o AERO Proxies accept encapsulated packets if there is a proxy 1156 neighbor cache entry that matches the packet's network-layer 1157 address. 1159 Each packet should include a signature that the recipient can use to 1160 authenticate the message origin, e.g., as for common VPN systems such 1161 as OpenVPN [OVPN]. In some environments, however, it may be 1162 sufficient to require signatures only for ND control plane messages 1163 (see: Section 10) and omit signatures for data plane messages. 1165 3.12. AERO Interface Packet Size Issues 1167 The AERO interface is the node's attachment to the AERO link. The 1168 AERO interface acts as a tunnel ingress when it sends a packet to an 1169 AERO link neighbor and as a tunnel egress when it receives a packet 1170 from an AERO link neighbor. AERO interfaces observe the packet 1171 sizing considerations for tunnels discussed in 1172 [I-D.ietf-intarea-tunnels] and as specified below. 1174 The Internet Protocol expects that IP packets will either be 1175 delivered to the destination or a suitable Packet Too Big (PTB) 1176 message returned to support the process known as IP Path MTU 1177 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1178 crafted for malicious purposes such as denial of service, or lost in 1179 the network [RFC2923]. This can be especially problematic for 1180 tunnels, where a condition known as a PMTUD "black hole" can result. 1181 For these reasons, AERO interfaces employ operational procedures that 1182 avoid interactions with PMTUD, including the use of fragmentation 1183 when necessary. 1185 AERO interfaces observe two different types of fragmentation. Source 1186 fragmentation occurs when the AERO interface (acting as a tunnel 1187 ingress) fragments the encapsulated packet into multiple fragments 1188 before admitting each fragment into the tunnel. Network 1189 fragmentation occurs when an encapsulated packet admitted into the 1190 tunnel by the ingress is fragmented by an IPv4 router on the path to 1191 the egress. Note that a packet that incurs source fragmentation may 1192 also incur network fragmentation. 1194 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1195 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1196 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1197 for IPv4 even if encapsulated packets may incur network 1198 fragmentation. 1200 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1201 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1202 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1203 than the IPv4 minimum). 1205 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1206 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1207 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1208 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1209 configure a Maximum Segment Unit (MSU) as the maximum-sized 1210 encapsulated packet that the ingress can inject into the tunnel 1211 without source fragmentation. The MSU value MUST NOT be larger than 1212 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1213 operational assurance that a larger size can traverse the link along 1214 all paths. 1216 All AERO nodes MUST configure the same MTU/MSU values for reasons 1217 cited in [RFC3819][RFC4861]; in particular, multicast support 1218 requires a common MTU value among all nodes on the link. All AERO 1219 nodes MUST configure an MRU large enough to reassemble packets up to 1220 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1221 enough MRU MUST NOT enable an AERO interface. 1223 The network layer proceeds as follow when it presents an IP packet to 1224 the AERO interface. For each IPv4 packet that is larger than the 1225 AERO interface MTU and with the DF bit set to 0, the network layer 1226 uses IPv4 fragmentation to break the packet into a minimum number of 1227 non-overlapping fragments where the first fragment is no larger than 1228 the MTU and the remaining fragments are no larger than the first. 1229 For all other IP packets, if the packet is larger than the AERO 1230 interface MTU, the network layer drops the packet and returns a PTB 1231 message to the original source. Otherwise, the network layer admits 1232 each IP packet or fragment into the AERO interface. 1234 For each IP packet admitted into the AERO interface, the interface 1235 (acting as a tunnel ingress) encapsulates the packet. If the 1236 encapsulated packet is larger than the AERO interface MSU the ingress 1237 source-fragments the encapsulated packet into a minimum number of 1238 non-overlapping fragments where the first fragment is no larger than 1239 the MSU and the remaining fragments are no larger than the first. 1240 The ingress then admits each encapsulated packet or fragment into the 1241 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1242 header in case any network fragmentation is necessary. The 1243 encapsulated packets will be delivered to the egress, which 1244 reassembles them into a whole packet if necessary. 1246 Several factors must be considered when fragmentation is needed. For 1247 AERO links over IPv4, the IP ID field is only 16 bits in length, 1248 meaning that fragmentation at high data rates could result in data 1249 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1250 AERO links over both IPv4 and IPv6, studies have also shown that IP 1251 fragments are dropped unconditionally over some network paths [I- 1252 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1253 issues could result in operational problems, the ingress SHOULD 1254 employ intermediate-layer source fragmentation (see: [RFC2764] and 1255 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1256 encapsulation headers to each fragment. Since the encapsulation 1257 fragment header reduces the room available for packet data, but the 1258 original source has no way to control its insertion, the ingress MUST 1259 include the fragment header length in the ENCAPS length even for 1260 packets in which the header is absent. 1262 3.13. AERO Interface Error Handling 1264 When an AERO node admits encapsulated packets into the AERO 1265 interface, it may receive link-layer or network-layer error 1266 indications. 1268 A link-layer error indication is an ICMP error message generated by a 1269 router in the underlying network on the path to the neighbor or by 1270 the neighbor itself. The message includes an IP header with the 1271 address of the node that generated the error as the source address 1272 and with the link-layer address of the AERO node as the destination 1273 address. 1275 The IP header is followed by an ICMP header that includes an error 1276 Type, Code and Checksum. Valid type values include "Destination 1277 Unreachable", "Time Exceeded" and "Parameter Problem" 1278 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1279 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1280 only emit packets that are guaranteed to be no larger than the IP 1281 minimum link MTU as discussed in Section 3.12.) 1283 The ICMP header is followed by the leading portion of the packet that 1284 generated the error, also known as the "packet-in-error". For 1285 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1286 much of invoking packet as possible without the ICMPv6 packet 1287 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1288 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1289 "Internet Header + 64 bits of Original Data Datagram", however 1290 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1291 ICMP datagram SHOULD contain as much of the original datagram as 1292 possible without the length of the ICMP datagram exceeding 576 1293 bytes". 1295 The link-layer error message format is shown in Figure 3 (where, "L2" 1296 and "L3" refer to link-layer and network-layer, respectively): 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 ~ ~ 1300 | L2 IP Header of | 1301 | error message | 1302 ~ ~ 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | L2 ICMP Header | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1306 ~ ~ P 1307 | IP and other encapsulation | a 1308 | headers of original L3 packet | c 1309 ~ ~ k 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1311 ~ ~ t 1312 | IP header of | 1313 | original L3 packet | i 1314 ~ ~ n 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 ~ ~ e 1317 | Upper layer headers and | r 1318 | leading portion of body | r 1319 | of the original L3 packet | o 1320 ~ ~ r 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1323 Figure 3: AERO Interface Link-Layer Error Message Format 1325 The AERO node rules for processing these link-layer error messages 1326 are as follows: 1328 o When an AERO node receives a link-layer Parameter Problem message, 1329 it processes the message the same as described as for ordinary 1330 ICMP errors in the normative references [RFC0792][RFC4443]. 1332 o When an AERO node receives persistent link-layer Time Exceeded 1333 messages, the IP ID field may be wrapping before earlier fragments 1334 awaiting reassembly have been processed. In that case, the node 1335 SHOULD begin including integrity checks and/or institute rate 1336 limits for subsequent packets. 1338 o When an AERO node receives persistent link-layer Destination 1339 Unreachable messages in response to encapsulated packets that it 1340 sends to one of its dynamic neighbor correspondents, the node 1341 SHOULD process the message as an indication that a path may be 1342 failing, and MAY initiate NUD over that path. If it receives 1343 Destination Unreachable messages on many or all paths, the node 1344 SHOULD set ForwardTime for the corresponding dynamic neighbor 1345 cache entry to 0 and allow future packets destined to the 1346 correspondent to flow through a default route. 1348 o When an AERO Client receives persistent link-layer Destination 1349 Unreachable messages in response to encapsulated packets that it 1350 sends to one of its static neighbor Servers, the Client SHOULD 1351 mark the path as unusable and use another path. If it receives 1352 Destination Unreachable messages on many or all paths, the Client 1353 SHOULD associate with a new Server and release its association 1354 with the old Server as specified in Section 3.17.6. 1356 o When an AERO Server receives persistent link-layer Destination 1357 Unreachable messages in response to encapsulated packets that it 1358 sends to one of its static neighbor Clients, the Server SHOULD 1359 mark the underlying path as unusable and use another underlying 1360 path. If it receives Destination Unreachable messages on multiple 1361 paths, the Server should take no further actions unless it 1362 receives an explicit ND/PD release message or if the PD lifetime 1363 expires. In that case, the Server MUST release the Client's 1364 delegated ACP, withdraw the ACP from the AERO routing system and 1365 delete the neighbor cache entry. 1367 o When an AERO Relay or Server receives link-layer Destination 1368 Unreachable messages in response to an encapsulated packet that it 1369 sends to one of its permanent neighbors, it treats the messages as 1370 an indication that the path to the neighbor may be failing. 1371 However, the dynamic routing protocol should soon reconverge and 1372 correct the temporary outage. 1374 When an AERO Relay receives a packet for which the network-layer 1375 destination address is covered by an ASP, if there is no more- 1376 specific routing information for the destination the Relay drops the 1377 packet and returns a network-layer Destination Unreachable message 1378 subject to rate limiting. The Relay writes the network-layer source 1379 address of the original packet as the destination address and uses 1380 one of its non link-local addresses as the source address of the 1381 message. 1383 When an AERO node receives an encapsulated packet for which the 1384 reassembly buffer it too small, it drops the packet and returns a 1385 network-layer Packet Too Big (PTB) message. The node first writes 1386 the MRU value into the PTB message MTU field, writes the network- 1387 layer source address of the original packet as the destination 1388 address and writes one of its non link-local addresses as the source 1389 address. 1391 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1393 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1394 coordinated as discussed in the following Sections. 1396 3.14.1. AERO ND/PD Service Model 1398 Each AERO Server configures a PD service to facilitate Client 1399 requests. Each Server is provisioned with a database of ACP-to- 1400 Client ID mappings for all Clients enrolled in the AERO system, as 1401 well as any information necessary to authenticate each Client. The 1402 Client database is maintained by a central administrative authority 1403 for the AERO link and securely distributed to all Servers, e.g., via 1404 the Lightweight Directory Access Protocol (LDAP) [RFC4511], via 1405 static configuration, etc. Therefore, no Server-to-Server PD state 1406 synchronization is necessary, and Clients can optionally hold 1407 separate PDs for the same ACPs from multiple Servers. In this way, 1408 Clients can associate with multiple Servers, and can receive new PDs 1409 from new Servers before releasing PDs received from existing Servers. 1410 This provides the Client with a natural fault-tolerance and/or load 1411 balancing profile. 1413 AERO Clients and Servers use ND messages to maintain neighbor cache 1414 entries. AERO Servers configure their AERO interfaces as advertising 1415 interfaces, and therefore send unicast RA messages with configuration 1416 information in response to a Client's RS message. Thereafter, 1417 Clients send additional RS messages to the Server's unicast address 1418 to refresh prefix and/or router lifetimes. 1420 AERO Clients and Servers include PD parameters in the RS/RA messages 1421 they exchange (see: [I-D.templin-6man-dhcpv6-ndopt]). The unified 1422 ND/PD messages are exchanged between Client and Server according to 1423 the prefix management schedule required by the PD service. 1425 On Some AERO links, PD arrangements may be through some out-of-band 1426 service such as network management, static configuration, etc. In 1427 those cases, AERO nodes can use simple RS/RA message exchanges with 1428 no explicit PD options. Instead, the RS/RA messages use AERO 1429 addresses as a means of representing the delegated prefixes, e.g., if 1430 a message includes a source address of "fe80::2001:db8:1:2" then the 1431 recipient can infer that the sender holds the prefix delegation 1432 "2001:db8:1:2::/N" (where 'N' is the prefix length common to all ACPs 1433 for the link). 1435 The following sections specify the Client and Server behavior. 1437 3.14.2. AERO Client Behavior 1439 AERO Clients discover the link-layer addresses of AERO Servers in the 1440 Potential Router List (PRL) via static configuration (e.g., from a 1441 flat-file map of Server addresses and locations), or through an 1442 automated means such as Domain Name System (DNS) name resolution 1443 [RFC1035]. In the absence of other information, the Client resolves 1444 the DNS Fully-Qualified Domain Name (FQDN) 1445 "linkupnetworks.[domainname]" where "linkupnetworks" is a constant 1446 text string and "[domainname]" is a DNS suffix for the Client's 1447 underlying interface (e.g., "example.com"). After discovering the 1448 link-layer addresses, the Client associates with one or more of the 1449 corresponding Servers. 1451 To associate with a Server, the Client acts as a requesting router to 1452 request ACPs through an ND/PD message exchange. The Client sends an 1453 RS message with PD parameters and with all-routers multicast as the 1454 IPv6 destination address, the address of the Client's underlying 1455 interface as the link-layer source address and the link-layer address 1456 of the Server as the link-layer destination address. If the Client 1457 already knows its own AERO address, it uses the AERO address as the 1458 IPv6 source address; otherwise, it uses the prefix-solicitation 1459 address as the source address. If the Client's underlying interface 1460 connects to a subnetwork that supports ACP injection, the Client can 1461 use the ACP's Subnet Router Anycast address as the link-layer source 1462 address. 1464 The Client next includes one or more SLLAOs in the RS message 1465 formatted as described in Section 3.5 to register its link-layer 1466 address(es) with the Server. The first SLLAO MUST correspond to the 1467 underlying interface over which the Client will send the RS message. 1468 The Client MAY include additional SLLAOs specific to other underlying 1469 interfaces, but if so it sets their UDP Port Number and IP Address 1470 fields to 0. The Client can instead register additional link-layer 1471 addresses with the Server by sending additional RS messages including 1472 SLLAOs via other underlying interfaces after the initial RS/RA 1473 exchange. 1475 The Client then sends the RS message to the AERO Server and waits for 1476 an RA message reply (see Section 3.14.3) while retrying MAX_RETRY 1477 times until an RA is received. If the Client receives no RAs, or if 1478 it receives an RA with Router Lifetime set to 0 and/or with no ACP PD 1479 parameters, the Client SHOULD discontinue autoconfiguration attempts 1480 through this Server and try another Server. Otherwise, the Client 1481 processes the ACPs found in the RA message. 1483 Next, the Client creates a static neighbor cache entry with the 1484 Server's link-local address as the network-layer address and the 1485 Server's encapsulation source address as the link-layer address. The 1486 Client then autoconfigures AERO addresses for each of the delegated 1487 ACPs and assigns them to the AERO interface. 1489 The Client next examines the P bit in the RA message flags field 1490 [RFC5175]. If the P bit value was 1, the Client infers that there is 1491 a NAT or Proxy on the path to the Server via the interface over which 1492 it sent the RS message. In that case, the Client sets UDP Port 1493 Number and IP Address to 0 in the S/TLLAOs of any subsequent ND 1494 messages it sends to the Server over that link. 1496 The Client also caches any ASPs included in Route Information Options 1497 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1498 the MTU/MSU values in the MTU options to its AERO interface while 1499 configuring an appropriate MRU. This configuration information 1500 applies to the AERO link as a whole, and all AERO nodes will receive 1501 the same values. 1503 Following autoconfiguration, the Client sub-delegates the ACPs to its 1504 attached EUNs and/or the Client's own internal virtual interfaces as 1505 described in [I-D.templin-v6ops-pdhost] to support the Client's 1506 downstream attached "Internet of Things (IoT)". The Client 1507 subsequently maintains its ACP delegations through each of its 1508 Servers by sending RS messages with PD parameters to receive 1509 corresponding RA messages. 1511 After the Client registers its Interface IDs and their associated 1512 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1513 Interface ID registrations, e.g., if an underlying interface changes 1514 address or becomes unavailable, if QoS preferences change, etc. To 1515 do so, the Client prepares an unsolicited NA message to send over any 1516 available underlying interface. The target address of the NA message 1517 is set to the Client's link-local address, and the destination 1518 address is set to all-nodes multicast. The NA MUST include a TLLAO 1519 specific to the selected available underlying interface as the first 1520 TLLAO and MAY include any additional TLLAOs specific to other 1521 underlying interfaces. The Client includes fresh 'P(i)' values in 1522 each TLLAO to update the Server's neighbor cache entry. If the 1523 Client wishes to update 'P(i)' values without updating the link-layer 1524 address, it sets the UDP Port Number and IP Address fields to 0. If 1525 the Client wishes to disable the interface, it sets all 'P(i)' values 1526 to '0' ("disabled"). 1528 If the Client wishes to discontinue use of a Server it issues an RS 1529 message with PD parameters that will cause the Server to release the 1530 Client. When the Server processes the message, it releases the ACP, 1531 deletes its neighbor cache entry for the Client, withdraws the IP 1532 route from the routing system and returns an RA reply containing any 1533 necessary PD parameters. 1535 3.14.3. AERO Server Behavior 1537 AERO Servers act as IPv6 routers and support a PD service for 1538 Clients. AERO Servers arrange to add their encapsulation layer IP 1539 addresses (i.e., their link-layer addresses) to a static map of 1540 Server addresses for the link and/or the DNS resource records for the 1541 FQDN "linkupnetworks.[domainname]" before entering service. The list 1542 of Server addresses should be geographically and/or topologically 1543 referenced, and forms the Potential Router List (PRL) for the AERO 1544 link. 1546 When an AERO Server receives a prospective Client's RS message with 1547 PD parameters on its AERO interface, and the Server is too busy, it 1548 SHOULD return an immediate RA reply with no ACPs and with Router 1549 Lifetime set to 0. Otherwise, the Server authenticates the RS 1550 message and processes the PD parameters. The Server first determines 1551 the correct ACPs to delegate to the Client by searching the Client 1552 database. When the Server delegates the ACPs, it also creates an IP 1553 forwarding table entry for each ACP so that the AERO BGP-based 1554 routing system will propagate the ACPs to the Relays that aggregate 1555 the corresponding ASP (see: Section 3.3). 1557 Next, the Server prepares an RA message that includes the delegated 1558 ACPs and any other PD parameters. The Server then returns the RA 1559 message using its link-local address as the network-layer source 1560 address, the network-layer source address of the RS message as the 1561 network-layer destination address, the Server's link-layer address as 1562 the source link-layer address, and the source link-layer address of 1563 the RS message as the destination link-layer address. The Server 1564 next sets the P flag in the RA message flags field [RFC5175] to 1 if 1565 the source link-layer address in the RS message was different than 1566 the address in the first SLLAO to indicate that there is a NAT or 1567 Proxy on the path; otherwise it sets P to 0. The Server then 1568 includes one or more RIOs that encode the ASPs for the AERO link. 1569 The Server also includes two MTU options - the first MTU option 1570 includes the MTU for the link and the second MTU option includes the 1571 MSU for the link (see Section 3.12). The Server finally sends the RA 1572 message to the Client. 1574 The Server next creates a static neighbor cache entry for the Client 1575 using the base AERO address as the network-layer address and with 1576 lifetime set to no more than the smallest PD lifetime. Next, the 1577 Server updates the neighbor cache entry link-layer address(es) by 1578 recording the information in each SLLAO option indexed by the 1579 Interface ID and including the UDP port number, IP address and P(i) 1580 values. For the first SLLAO in the list, however, the Server records 1581 the actual encapsulation source UDP and IP addresses instead of those 1582 that appear in the SLLAO in case there was a NAT or Proxy in the 1583 path. 1585 After the initial RS/RA exchange, the AERO Server maintains the 1586 neighbor cache entry for the Client until the PD lifetimes expire. 1587 If the Client issues additional RS messages with PD renewal 1588 parameters, the Server extends the PD lifetimes. If the Client 1589 issues an RS with PD release parameters, or if the Client does not 1590 issue a renewal before the lifetime expires, the Server deletes the 1591 neighbor cache entry for the Client and withdraws the IP routes from 1592 the AERO routing system. The Server processes these and any other 1593 Client PD messages, and returns an RA reply. The Server may also 1594 issue an unsolicited RA message with PD reconfigure parameters to 1595 inform the Client that it needs to renegotiate its PDs. 1597 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1599 When DHCPv6 is used as the ND/PD service back end, AERO Clients and 1600 Servers are always on the same link (i.e., the AERO link) from the 1601 perspective of DHCPv6. However, in some implementations the DHCPv6 1602 server and ND function may be located in separate modules. In that 1603 case, the Server's AERO interface module can act as a Lightweight 1604 DHCPv6 Relay Agent (LDRA)[RFC6221] to relay PD messages to and from 1605 the DHCPv6 server module. 1607 When the LDRA receives an authentic RS message, it extracts the PD 1608 message parameters and uses them to fabricate an IPv6/UDP/DHCPv6 1609 message. It sets the IPv6 source address to the source address of 1610 the RS message, sets the IPv6 destination address to 1611 'All_DHCP_Relay_Agents_and_Servers' and sets the UDP fields to values 1612 that will be understood by the DHCPv6 server. 1614 The LDRA then wraps the message in a DHCPv6 'Relay-Forward' message 1615 header and includes an 'Interface-Id' option that includes enough 1616 information to allow the LDRA to forward the resulting Reply message 1617 back to the Client (e.g., the Client's link-layer addresses, a 1618 security association identifier, etc.). The LDRA also wraps the 1619 information in all of the SLLAO options from the RS message into the 1620 Interface-Id option, then forwards the message to the DHCPv6 server. 1622 When the DHCPv6 server prepares a Reply message, it wraps the message 1623 in a 'Relay-Reply' message and echoes the Interface-Id option. The 1624 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1625 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1626 uses the DHCPv6 message to fabricate an RA response to the Client. 1627 The Server uses the information in the Interface-Id option to prepare 1628 the RA message and to cache the link-layer addresses taken from the 1629 SLLAOs echoed in the Interface-Id option. 1631 3.15. AERO Route Optimization 1633 When a source Client forwards packets to a prospective correspondent 1634 Client within the same AERO link domain (i.e., one for which the 1635 packet's destination address is covered by an ASP), the source Client 1636 MAY initiate an AERO link route optimization procedure. The 1637 procedure is based on an exchange of IPv6 ND messages using a chain 1638 of AERO Servers and Relays as a trust basis. 1640 Although the Client is responsible for initiating route optimization, 1641 the Server is the policy enforcement point that determines whether 1642 route optimization is permitted. For example, on some AERO links 1643 route optimization would allow traffic to circumvent critical 1644 network-based traffic inspection points. In those cases, the Server 1645 can simply discard any route optimization messages instead of 1646 forwarding them. 1648 The following sections specify the AERO route optimization procedure. 1650 3.15.1. Reference Operational Scenario 1652 Figure 4 depicts the AERO route optimization reference operational 1653 scenario, using IPv6 addressing as the example (while not shown, a 1654 corresponding example for IPv4 addressing can be easily constructed). 1655 The figure shows an AERO Relay ('R1'), two AERO Servers ('S1', 'S2'), 1656 two AERO Clients ('C1', 'C2') and two ordinary IPv6 hosts ('H1', 1657 'H2'): 1659 +--------------+ +--------------+ +--------------+ 1660 | Server S1 | | Relay R1 | | Server S2 | 1661 +--------------+ +--------------+ +--------------+ 1662 fe80::2 fe80::1 fe80::3 1663 L2(S1) L2(R1) L2(S2) 1664 | | | 1665 X-----+-----+------------------+-----------------+----+----X 1666 | AERO Link | 1667 L2(C1) L2(C2) 1668 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1669 +--------------+ +--------------+ 1670 |AERO Client C1| |AERO Client C2| 1671 +--------------+ +--------------+ 1672 2001:DB8:0::/48 2001:DB8:1::/48 1673 | | 1674 .-. .-. 1675 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1676 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 1677 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 1678 `-(______)-' +-------+ +-------+ `-(______)-' 1680 Figure 4: AERO Reference Operational Scenario 1682 In Figure 4, Relay ('R1') assigns the administratively-provisioned 1683 AERO address fe80::1 to its AERO interface with link-layer address 1684 L2(R1), Server ('S1') assigns the address fe80::2 with link-layer 1685 address L2(S1), and Server ('S2') assigns the address fe80::3 with 1686 link-layer address L2(S2). Servers ('S1') and ('S2') next arrange to 1687 add their link-layer addresses to a published list of valid Servers 1688 for the AERO link. 1690 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in an ND/PD 1691 exchange via AERO Server ('S1') then assigns the address 1692 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1693 L2(C1). Client ('C1') configures a default route and neighbor cache 1694 entry via the AERO interface with next-hop address fe80::2 and link- 1695 layer address L2(S1), then sub-delegates the ACP to its attached 1696 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1697 address 2001:db8:0::1. 1699 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in an ND/PD 1700 exchange via AERO Server ('S2') then assigns the address 1701 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1702 L2(C2). Client ('C2') configures a default route and neighbor cache 1703 entry via the AERO interface with next-hop address fe80::3 and link- 1704 layer address L2(S2), then sub-delegates the ACP to its attached 1705 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1706 address 2001:db8:1::1. 1708 3.15.2. Concept of Operations 1710 Again, with reference to Figure 4, when source host ('H1') sends a 1711 packet to destination host ('H2'), the packet is first forwarded over 1712 the source host's attached EUN to Client ('C1'). Client ('C1') then 1713 forwards the packet via its AERO interface to Server ('S1') and also 1714 sends an NS message toward Client ('C2') via Server ('S1'). 1716 Server ('S1') then forwards both the packet and the NS message out 1717 the same AERO interface toward Client ('C2') via Relay ('R1'). When 1718 Relay ('R1') receives the packet and NS message, it consults its 1719 forwarding table to discover Server ('S2') as the next hop toward 1720 Client ('C2'). Relay ('R1') then forwards both the packet and the NS 1721 message to Server ('S2'), which then forwards them to Client ('C2'). 1723 After Client ('C2') receives the NS message, it process the message 1724 and creates or updates a dynamic neighbor cache entry for Client 1725 ('C1'), then sends the NA response to the link-layer address of 1726 Client ('C1'). 1728 After Client ('C1') receives the NA message, it processes the message 1729 and creates or updates a dynamic neighbor cache entry for Client 1730 ('C2'). Thereafter, forwarding of packets from Client ('C1') to 1731 Client ('C2') without involving any intermediate nodes is enabled. 1732 The mechanisms that support this exchange are specified in the 1733 following sections. 1735 3.15.3. Sending NS Messages 1737 When a Client forwards a packet with a source address from one of its 1738 ACPs toward a destination address covered by an ASP (i.e., toward 1739 another AERO Client connected to the same AERO link), the source 1740 Client MAY send an NS message forward toward the destination Client 1741 via the Server. 1743 In the reference operational scenario, when Client ('C1') forwards a 1744 packet toward Client ('C2'), it MAY also send an NS message forward 1745 toward Client ('C2'), subject to rate limiting (see Section 8.2 of 1746 [RFC4861]). Client ('C1') prepares the NS message as follows: 1748 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1749 layer address of Client ('C1')). 1751 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1752 link-layer address of Server ('S1')). 1754 o the network-layer source address is set to fe80::2001:db8:0:0 1755 (i.e., the base AERO address of Client ('C1')). 1757 o the network-layer destination address is set to the AERO address 1758 corresponding to the destination address of Client ('C2'). 1760 o the Type is set to 135. 1762 o the Target Address is set to the destination address of the packet 1763 that triggered route optimization. 1765 o the message includes SLLAOs set to appropriate values for the 1766 Client ('C1')'s underlying interfaces The first SLLAO serves as 1767 the "Report-To" address for the Client, which is the address to 1768 which the target will announce mobility events and/or other 1769 dynamic updates. 1771 o the message includes one or more RIOs that include Client ('C1')'s 1772 ACPs [I-D.templin-6man-rio-redirect]. 1774 o the message SHOULD include a Timestamp option and a Nonce option. 1776 Note that the act of sending NS messages is cited as "MAY", since 1777 Client ('C1') may have advanced knowledge that the direct path to 1778 Client ('C2') would be unusable or otherwise undesirable. If the 1779 direct path later becomes unusable after the initial route 1780 optimization, Client ('C1') simply allows packets to again flow 1781 through Server ('S1'). 1783 3.15.4. Re-encapsulating and Relaying the NS 1785 When Server ('S1') receives an NS message from Client ('C1'), it 1786 first verifies that the SLLAOs in the NS are a proper subset of the 1787 link-layer addresses in Client ('C1')'s neighbor cache entry. If the 1788 Client's SLLAOs are not acceptable, Server ('S1') discards the 1789 message. 1791 Server ('S1') then examines the network-layer destination address of 1792 the NS to determine the next hop toward Client ('C2') by searching 1793 for the AERO address in the neighbor cache. Since Client ('C2') is 1794 not one of its neighbors, Server ('S1') then inserts an additional 1795 layer of encapsulation between the outer IP header and the NS 1796 message. This mid-layer IP header uses the AERO Server Subnet Router 1797 Anycast address as the source address and the Subnet Router Anycast 1798 address corresponding to Client ("C2")'s AERO address as the 1799 destination address (in this case, C2's Subnet Router Anycast address 1800 is 2001:db8:1:0::). The Server then forwards this double- 1801 encapsulated NS message to Relay ('R1') by changing the link-layer 1802 source address of the message to 'L2(S1)' and changing the link-layer 1803 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1804 message to Relay ('R1') without decrementing the network-layer TTL/ 1805 Hop Limit field. 1807 When Relay ('R1') receives the double-encapsulated NS message from 1808 Server ('S1') it discards the outer IP header and determines that 1809 Server ('S2') is the next hop toward Client ('C2') by consulting its 1810 standard IP forwarding table for the Client Subnet Router Anycast 1811 destination address. Relay ('R1') then encapsulates and forwards the 1812 message to Server ('S2') the same as for any IP router. 1814 When Server ('S2') receives the double-encapsulated NS message from 1815 Relay ('R1') it removes the mid-layer IP header and determines that 1816 Client ('C2') is a neighbor on a native underlying interface by 1817 consulting its neighbor cache for Client ('C2')'s AERO address. 1818 Server ('S2') then re-encapsulates the NS while changing the link- 1819 layer source address to 'L2(S2)' and changing the link-layer 1820 destination address to 'L2(C2)'. Server ('S2') then forwards the 1821 message to Client ('C2'). 1823 3.15.5. Processing NSs and Sending NAs 1825 When Client ('C2') receives the NS message, it accepts the NS only if 1826 the message has a link-layer source address of one of its Servers 1827 (e.g., L2(S2)). Client ('C2') further accepts the message only if it 1828 is willing to serve as a route optimization target. 1830 In the reference operational scenario, when Client ('C2') receives a 1831 valid NS message, it either creates or updates a dynamic neighbor 1832 cache entry that stores the source address of the message as the 1833 network-layer address of Client ('C1') and stores the link-layer 1834 addresses found in the SLLAOs as the link-layer addresses of Client 1835 ('C1'). Client ('C2') then sets ReportTime for the neighbor cache 1836 entry to REPORT_TIME. 1838 After processing the message, Client ('C2') prepares an NA message 1839 response as follows: 1841 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1842 layer address of Client ('C2')). 1844 o the link-layer destination address is set to 'L2(C1)' (i.e., the 1845 link-layer address of Client ('C1')). 1847 o the network-layer source address is set to fe80::2001:db8:1:0 1848 (i.e., the base AERO address of Client ('C2')). 1850 o the network-layer destination address is set to fe80::2001:db8:0:0 1851 (i.e., the base AERO address of Client ('C1')). 1853 o the Type is set to 136. 1855 o the Target Address is set to the Target Address field in the NS 1856 message. 1858 o the message includes one or more TLLAOs set to appropriate values 1859 for Client ('C2')'s native underlying interfaces. 1861 o the message includes one or more RIOs that include Client ('C2')'s 1862 ACPs [I-D.templin-6man-rio-redirect]. 1864 o the message SHOULD include a Timestamp option and MUST echo the 1865 Nonce option received in the NS (i.e., if a Nonce option was 1866 present). 1868 Client ('C2') then sends the NA message to Client ('C1'). 1870 3.15.6. Processing NAs 1872 When Client ('C1') receives the NA message, it first verifies that 1873 the NA matches the original NS message. Client ('C1') then processes 1874 the message as follows. 1876 In the reference operational scenario, when Client ('C1') receives 1877 the NA message, it either creates or updates a dynamic neighbor cache 1878 entry that stores the source address of the message as the network- 1879 layer address of Client ('C2'), stores the link-layer addresses found 1880 in the TLLAOs as the link-layer addresses of Client ('C2') and stores 1881 the ACPs encoded in the RIOs of the NA as the ACPs for Client ('C2'). 1882 Client ('C1') then sets ForwardTime for the neighbor cache entry to 1883 FORWARD_TIME. 1885 Now, Client ('C1') has a neighbor cache entry with a valid 1886 ForwardTime value, while Client ('C2') has a neighbor cache entry 1887 with a valid ReportTime value. Thereafter, Client ('C1') may forward 1888 ordinary network-layer data packets directly to Client ('C2') without 1889 involving any intermediate nodes, and Client ('C2') can dynamically 1890 report any changes in link-layer information by sending unsolicited 1891 NA messages. (In order for Client ('C2') to forward packets to 1892 Client ('C1'), a corresponding NS/NA message exchange is required in 1893 the reverse direction; hence, the mechanism is asymmetric.) 1895 3.15.7. Server-Based Route Optimization 1897 The source Client itself may initiate route optimization if it has 1898 only native interfaces. If the source Client has Direct, NATed, 1899 Proxyed or VPNed interfaces, route optimization must instead be 1900 initiated by the source Server. The source Server MUST include an 1901 SLLAO with a "Report-To" address in the route optimization NS 1902 messages it sends. The "Report-To" address must be one of the source 1903 Server's globally routable IP addresses. 1905 In the same way, the target Client may serve as a route optimization 1906 target if it has only native interfaces. If some or all of the 1907 target Client's underlying interfaces are Direct, NATed, Proxyed or 1908 VPNed the target Server must instead serve as the route optimization 1909 target. In that case, when the source sends an NS message the target 1910 Server prepares an NA response the same as if it were the target 1911 Client (see: Section 3.15.5) and does not forward the NS. 1913 When the target Server sends an NA response to a route optimization 1914 NS, it includes a Timestamp option, any necessary security options, 1915 and TLLAOs corresponding to the target Client's underlying 1916 interfaces. The target Server writes the link-layer address of the 1917 Client in TLLAOs corresponding to native underlying interfaces, 1918 writes the link-layer address of the Proxy in TLLAOs corresponding to 1919 Proxyed underlying interfaces and writes its own link-layer address 1920 in TLLAOs corresponding to other interfaces. The Interface ID and 1921 QoS Preference values in the TLLAOs are those supplied by the target 1922 Client during ND exchanges with the target Server. The target Server 1923 then establishes a dynamic neighbor cache entry for the source with 1924 ReportTime set to REPORT_TIME seconds and with a "Report-To" address 1925 set to the address of the source. 1927 When the source Server receives the NA response, it creates or 1928 updates a dynamic neighbor cache entry for the target with 1929 ForwardTime set to FORWARD_TIME seconds and with the information 1930 provided in the TLLAOs as the link-layer addresses and preference 1931 values for the target. The source Server then translates the 1932 solicited NA message into an unsolicited NA message by changing the 1933 source address to its own link-local address, changing the 1934 destination address to all-nodes multicast, recalculating checksums 1935 and any security options, and including the Timestamp option as it 1936 appeared in the original solicited NA. The source Server then 1937 retains this message for subsequent on-demand transmission to any 1938 source neighbors that send packets to the target within the current 1939 ForwardTime window. 1941 While ForwardTime is greater than 0, the source Server sends 1942 unsolicited NA messages (subject to rate limiting) in response to 1943 data packets from source Clients or Proxies that are destined to the 1944 target Client. The unsolicited NA messages update source Client and 1945 Proxy dynamic neighbor cache entries with ForwardTime set to 1946 FORWARD_TIME minus the difference between the current time and the NA 1947 Timestamp. Subsequent packets from the source destined to the target 1948 Client then travel via the route-optimized path instead of through 1949 the dogleg path through Servers and Relays. 1951 Following route optimization, when the target Client (or Proxy) sends 1952 unsolicited NA messages to the target Server to update link-layer 1953 addresses and/or QoS preferences, the target Server translates the 1954 messages the same as described above and repeats them to any of its 1955 neighbors with non-zero ReportTime. The source Server in turn 1956 translates the messages and repeats them to any of their source 1957 Clients or Proxys to which they recently sent NAs. 1959 If the target Client moves to a new Server, the old Server sends 1960 immediate unsolicited NA messages with no TLLAOs to any of its 1961 dynamic neighbors with non-zero ReportTime, and retains the dynamic 1962 neighbor cache entry until ReportTime expires. While ReportTime is 1963 non-zero, the old Server sends unsolicited NA messages with no TLLAOs 1964 (subject to rate limiting) back to the source in response to data 1965 packets received from a correspondent node while forwarding the 1966 packets themselves to a Relay. The Relay will then either forward 1967 the packets to the new Server if the target Client has moved, or drop 1968 the packets if the target Client is no longer in the network. When 1969 the source receives the unsolicited NAs with no TLLAOs, it allows 1970 future packets destined to the target Client to again flow through 1971 its own Server (or Relay). 1973 3.16. Neighbor Unreachability Detection (NUD) 1975 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1976 NS messages to elicit solicited NA messages from neighbors the same 1977 as described in [RFC4861]. NUD is performed either reactively in 1978 response to persistent link-layer errors (see Section 3.13) or 1979 proactively to update neighbor cache entry timers and/or link-layer 1980 address information. (NS messages may include SLLAOs and NA messages 1981 may include TLLAOs in order to update link-layer address 1982 information.) 1984 When an AERO node sends an NS/NA message, it uses one of its link- 1985 local addresses as the IPv6 source address and a link-local address 1986 of the neighbor as the IPv6 destination address. When route 1987 optimization directs a source AERO node to a target AERO node, the 1988 source node SHOULD proactively test the direct path by sending an 1989 initial NS message to elicit a solicited NA response. While testing 1990 the path, the source node can optionally continue sending packets via 1991 its default router, maintain a small queue of packets until target 1992 reachability is confirmed, or (optimistically) allow packets to flow 1993 directly to the target. 1995 While data packets are still flowing, the source node thereafter 1996 periodically tests the direct path to the target node (see 1997 Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache 1998 entries alive. When the target node receives a valid NS message, it 1999 resets ReportTime to REPORT_TIME and updates its cached link-layer 2000 addresses (if necessary). When the source node receives a 2001 corresponding NA message, it resets ForwardTime to FORWARD_TIME and 2002 updates its cached link-layer addresses (if necessary). If the 2003 source node is unable to elicit an NA response from the target node 2004 after MaxRetry attempts, it SHOULD set ForwardTime to 0. Otherwise, 2005 the source node considers the path usable and SHOULD thereafter 2006 process any link-layer errors as an indication that the direct path 2007 to the target node may be failing. 2009 When ForwardTime for a dynamic neighbor cache entry expires, the 2010 source node resumes sending any subsequent packets via a Server (or 2011 Relay) and may (eventually) attempt to re-initiate the AERO route 2012 optimization process. When ReportTime for a dynamic neighbor cache 2013 entry expires, the target node ceases to send dynamic mobility and 2014 QoS updates to the source node. When both ForwardTime and ReportTime 2015 for a dynamic neighbor cache entry expire, the node deletes the 2016 neighbor cache entry. 2018 Note that an AERO node may have multiple underlying interface paths 2019 toward the target neighbor. In that case, the node SHOULD perform 2020 NUD over each underlying interface individually and only consider the 2021 neighbor unreachable if NUD fails over multiple underlying interface 2022 paths. 2024 3.17. Mobility Management and Quality of Service (QoS) 2026 AERO is an example of a Distributed Mobility Management (DMM) 2027 service. Each AERO Server is responsible for only a subset of the 2028 Clients on the AERO link, as opposed to a Centralized Mobility 2029 Management (CMM) service where there is a single network mobility 2030 service for all Clients. AERO Clients coordinate with their 2031 associated AERO Servers via RS/RA exchanges to maintain the DMM 2032 profile, and the AERO routing system tracks the current AERO Client/ 2033 Server peering relationships. 2035 AERO interfaces accommodate mobility management by sending 2036 unsolicited NA messages the same as for announcing link-layer address 2037 changes for any interface that implements IPv6 ND [RFC4861]. (In 2038 environments where reliability is a concern, AERO interfaces can send 2039 immediate NS messages to receive solicited NA messages, i.e., they 2040 can skip the unreliable unsolicited NA messaging step and move 2041 directly to a reliable NS/NA exchange.) 2042 When a node sends an unsolicited NA message, it sets the IPv6 source 2043 to its own link-local address, sets the IPv6 destination address to 2044 all-nodes multicast, sets the link-layer source address to its own 2045 address and sets the link-layer destination address to either a 2046 multicast address or the unicast link-layer address of a neighbor. 2047 In the latter case, if the unsolicited NA message must be received by 2048 multiple neighbors, the node sends multiple copies of the NA using a 2049 different unicast link-layer destination address for each neighbor. 2050 Mobility management considerations are specified in the following 2051 sections. 2053 3.17.1. Forwarding Packets on Behalf of Departed Clients 2055 When a Server receives packets with destination addresses that do not 2056 match one of its static neighbor cache Clients, it forwards the 2057 packets to a Relay which delivers them to the target Client's current 2058 location. If the source is not one of its static neighbor Clients, 2059 the Server also returns an unsolicited NA message to the sender with 2060 no TLLAOs - the sender will then realize that it needs to delete its 2061 neighbor cache entry that associated the target with this Server. 2063 3.17.2. Announcing Link-Layer Address and/or QoS Preference Changes 2065 When a Client needs to change its link-layer addresses, e.g., due to 2066 a mobility event, it sends unsolicited NAs to its neighbors using the 2067 new link-layer address as the source address and with TLLAOs that 2068 include the new Client UDP Port Number, IP Address and P(i) values. 2069 (For neighbors that are Servers, the Client can instead initiate an 2070 RS/RA exchange.) If the Client sends the NA solely for the purpose 2071 of updating QoS preferences without updating the link-layer address, 2072 the Client sets the UDP Port Number and IP Address to 0. 2074 The Client MAY send up to MaxRetry unsolicited NA messages in 2075 parallel with sending actual data packets in case one or more NAs are 2076 lost. If all NAs are lost, the neighbor will eventually invoke NUD 2077 by sending NS messages that include SLLAOs. 2079 3.17.3. Bringing New Links Into Service 2081 When a Client needs to bring new underlying interfaces into service 2082 (e.g., when it activates a new data link), it sends unsolicited NAs 2083 to its neighbors using the new link-layer address as the source 2084 address and with TLLAOs that include the new Client link-layer 2085 information. (For neighbors that are Servers, the Client can instead 2086 initiate an RS/RA exchange.) 2088 3.17.4. Removing Existing Links from Service 2090 When a Client needs to remove existing underlying interfaces from 2091 service (e.g., when it de-activates an existing data link), it sends 2092 unsolicited NAs to its neighbors with TLLAOs with all P(i) values set 2093 to 0. (For neighbors that are Servers, the Client can instead 2094 initiate an RS/RA exchange.) 2096 If the Client needs to send ND messages over an underlying interface 2097 other than the one being removed from service, it MUST include a 2098 current TLLAO for the sending interface as the first TLLAO and 2099 include TLLAOs for any underlying interface being removed from 2100 service as additional TLLAOs. 2102 3.17.5. Implicit Mobility Management 2104 AERO interface neighbors MAY provide a configuration option that 2105 allows them to perform implicit mobility management in which no ND 2106 messaging is used. In that case, the Client only transmits packets 2107 over a single interface at a time, and the neighbor always observes 2108 packets arriving from the Client from the same link-layer source 2109 address. 2111 If the Client's underlying interface address changes (either due to a 2112 readdressing of the original interface or switching to a new 2113 interface) the neighbor immediately updates the neighbor cache entry 2114 for the Client and begins accepting and sending packets to the 2115 Client's new link-layer address. This implicit mobility method 2116 applies to use cases such as cellphones with both WiFi and Cellular 2117 interfaces where only one of the interfaces is active at a given 2118 time, and the Client automatically switches over to the backup 2119 interface if the primary interface fails. 2121 3.17.6. Moving to a New Server 2123 When a Client associates with a new Server, it performs the Client 2124 procedures specified in Section 3.14.2. The Client then sends RS 2125 messages with PD release parameters to the old Server to release 2126 itself from that Server's domain. If the Client does not receive an 2127 RA reply after MaxRetry attempts, the old Server may have failed and 2128 the Client should discontinue its release attempts. 2130 Clients SHOULD NOT move rapidly between Servers in order to avoid 2131 causing excessive oscillations in the AERO routing system. Such 2132 oscillations could result in intermittent reachability for the Client 2133 itself, while causing no harm to the network. Examples of when a 2134 Client might wish to change to a different Server include a Server 2135 that has gone unreachable, topological movements of significant 2136 distance, movement to a new geographic region, etc. 2138 3.18. Multicast Considerations 2140 When the underlying network does not support multicast, AERO Clients 2141 map link-scoped multicast addresses to the link-layer address of a 2142 Server, which acts as a multicast forwarding agent. The AERO Client 2143 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2144 applications per [RFC4605] while using the link-layer address of the 2145 Server as the link-layer address for all multicast packets. 2147 When the underlying network supports multicast, AERO nodes use the 2148 multicast address mapping specification found in [RFC2529] for IPv4 2149 underlying networks and use a TBD site-scoped multicast mapping for 2150 IPv6 underlying networks. In that case, border routers must ensure 2151 that the encapsulated site-scoped multicast packets do not leak 2152 outside of the site spanned by the AERO link. 2154 4. The AERO Proxy 2156 In some environments, AERO Clients may be located in secured 2157 subnetwork enclaves that do not allow direct communications from the 2158 Client to a Server in the outside Internetwork. In that case, the 2159 secured enclave can employ an AERO Proxy. 2161 The AERO Proxy is located at the secured enclave perimeter and 2162 listens for encapsulated RS messages originating from or RA messages 2163 destined to AERO Clients located within the enclave. The Proxy acts 2164 on these control messages as follows: 2166 o when the Proxy receives an RS message from a Client within the 2167 secured enclave, it first authenticates the message then creates a 2168 proxy neighbor cache entry for the Client in the INCOMPLETE State 2169 and caches the Client and Server link-layer addresses along with 2170 any identifying information including Transaction IDs, Client 2171 Identifiers, Nonce values, etc. The Proxy then re-encapsulates 2172 the RS message using its own external address as the source link- 2173 layer address and forwards the message to the Server. 2175 o when the Server receives the RS message, it authenticates the 2176 message then creates a static neighbor cache entry for the Client 2177 with the Proxy's address as the link-layer address. The Server 2178 then sends an RA message back to the Proxy. 2180 o when the Proxy receives the RA message, it matches the message 2181 with the RS that created the (INCOMPLETE) proxy neighbor cache 2182 entry. The Proxy then caches the route information in the message 2183 as a mapping from the Client's ACPs to the Client's address within 2184 the secured enclave, and sets the neighbor cache entry state to 2185 REACHABLE. The Proxy then re-encapsulates the RA message using 2186 its own internal address as the source link-layer address and 2187 forwards the message to the Client. 2189 After the initial RS/RA exchange, the Proxy forwards data packets 2190 between the Client and Server with the Server acting as the Client's 2191 default router. The Proxy can send ND messages to the Client's 2192 Server(s) to update Server neighbor cache entries on behalf of the 2193 Client. (For example, the Proxy can send unsolicited NA messages 2194 with a TLLAO with UDP Port Number and IP Address set to 0 and with 2195 valid P(i) values to update the Server(s) with the Client's new QoS 2196 preferences for the path that traverses the Proxy). The Proxy also 2197 forwards any control and data messages originating from the Client to 2198 the Client's primary Server. 2200 At some time after data packets have been flowing from the Client to 2201 the Server, the Proxy may receive unsolicited NA messages from the 2202 Server with TLLAOs corresponding to a target Client. The Proxy 2203 establishes a dynamic neighbor cache entry for the target with 2204 ForwardTime set to FORWARD_TIME and allows future data packets 2205 destined to the target to flow directly according to the link-layer 2206 address information instead of through the Server. The Proxy may at 2207 some later point receive additional NA messages with TLLAOs, and if 2208 so resets ForwardTime and updates its cached link-layer address 2209 information. If the Proxy receives no further NA messages, or if it 2210 receives NA messages with no TLLAOs, it deletes the dynamic neighbor 2211 cache entry. 2213 In some subnetworks that employ a Proxy, the Client's ACP can be 2214 injected into the underlying network routing system. In that case, 2215 the Client can send data messages without encapsulation so that the 2216 native underlying network routing system transports the 2217 unencapsulated packets to the Proxy. This can be very beneficial, 2218 e.g., if the Client connects to the network via low-end data links 2219 such as some aviation wireless links. In that case, however, the 2220 Client's control messages are still sent encapsulated so as to supply 2221 the Proxy with the address of the Server and to transport IPv6 ND 2222 messages without decrementing the hop-count. In summary, the 2223 interface becomes one where control messages are encapsulated while 2224 data messages are either unencapsulated or encapsulated according to 2225 the specific use case. This encapsulation avoidance represents a 2226 form of "header compression", meaning that the MTU should be sized 2227 based on the size of full encapsulated messages even if most messages 2228 are sent unencapsulated. 2230 5. Direct Underlying Interfaces 2232 When a Client's AERO interface is configured over a Direct underlying 2233 interface, the neighbor at the other end of the Direct link can 2234 receive packets without any encapsulation. In that case, the Client 2235 sends packets over the Direct link according to the QoS preferences 2236 associated with its underling interfaces. If the Direct underlying 2237 interface has the highest QoS preference, then the Client's IP 2238 packets are transmitted directly to the peer without going through an 2239 underlying network. If other underlying interfaces have higher QoS 2240 preferences, then the Client's IP packets are transmitted via a 2241 different underlying interface, which may result in the inclusion of 2242 AERO Proxies, Servers and Relays in the communications path. Direct 2243 underlying interfaces must be tested periodically for reachability, 2244 e.g., via NUD, via periodic unsolicited NAs, etc. 2246 6. Operation on AERO Links with /64 ASPs 2248 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2249 length /64 or shorter. However, in some cases it may be desirable to 2250 use AERO over links that have only a /64 ASP. This can be 2251 accommodated by treating all Clients on the AERO link as simple hosts 2252 that receive /128 prefix delegations. 2254 In that case, the Client sends an RS message to the Server the same 2255 as for ordinary AERO links. The Server responds with an RA message 2256 that includes one or more /128 prefixes (i.e., singleton addresses) 2257 that include the /64 ASP prefix along with an interface identifier 2258 portion to be assigned to the Client. The Client and Server then 2259 configure their AERO addresses based on the interface identifier 2260 portions of the /128s (i.e., the lower 64 bits) and not based on the 2261 /64 prefix (i.e., the upper 64 bits). 2263 For example, if the ASP for the host-only IPv6 AERO link is 2264 2001:db8:1000:2000::/64, each Client will receive one or more /128 2265 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2266 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2267 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2268 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2269 /128s) to either the AERO interface or an internal virtual interface 2270 such as a loopback. In this arrangement, the Client conducts route 2271 optimization in the same sense as discussed in Section 3.15. 2273 This specification has applicability for nodes that act as a Client 2274 on an "upstream" AERO link, but also act as a Server on "downstream" 2275 AERO links. More specifically, if the node acts as a Client to 2276 receive a /64 prefix from the upstream AERO link it can then act as a 2277 Server to provision /128s to Clients on downstream AERO links. 2279 7. AERO Adaptations for SEcure Neighbor Discovery (SEND) 2281 SEcure Neighbor Discovery (SEND) [RFC3971] and Cryptographically 2282 Generated Addresses (CGAs) [RFC3972] were designed to secure IPv6 ND 2283 messaging in environments where symmetric network and/or transport- 2284 layer security services are impractical (see: Section 10). AERO 2285 nodes that use SEND/CGA employ the following adaptations. 2287 When a source AERO node prepares a SEND-protected ND message, it uses 2288 a link-local CGA as the IPv6 source address and writes the prefix 2289 embedded in its AERO address (i.e., instead of fe80::/64) in the CGA 2290 parameters Subnet Prefix field. When the neighbor receives the ND 2291 message, it first verifies the message checksum and SEND/CGA 2292 parameters while using the link-local prefix fe80::/64 (i.e., instead 2293 of the value in the Subnet Prefix field) to match against the IPv6 2294 source address of the ND message. 2296 The neighbor then derives the AERO address of the source by using the 2297 value in the Subnet Prefix field as the interface identifier of an 2298 AERO address. For example, if the Subnet Prefix field contains 2299 2001:db8:1:2, the neighbor constructs the AERO address as 2300 fe80::2001:db8:1:2. The neighbor then caches the AERO address in the 2301 neighbor cache entry it creates for the source, and uses the AERO 2302 address as the IPv6 destination address of any ND message replies. 2304 8. Implementation Status 2306 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2307 announced on the v6ops mailing list on January 10, 2018. The latest 2308 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2309 2.0.tgz. 2311 An initial public release of the AERO proof-of-concept source code 2312 was announced on the intarea mailing list on August 21, 2015. The 2313 latest version is available at: http://linkupnetworks.net/aero/aero- 2314 4.0.0.tgz. 2316 A survey of public domain and commercial SEND implementations is 2317 available at https://www.ietf.org/mail-archive/web/its/current/ 2318 msg02758.html. 2320 9. IANA Considerations 2322 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2323 AERO in the "enterprise-numbers" registry. 2325 The IANA has assigned the UDP port number "8060" for an earlier 2326 experimental version of AERO [RFC6706]. This document obsoletes 2327 [RFC6706] and claims the UDP port number "8060" for all future use. 2329 No further IANA actions are required. 2331 10. Security Considerations 2333 AERO link security considerations include considerations for both the 2334 data plane and the control plane. 2336 Data plane security considerations are the same as for ordinary 2337 Internet communications. Application endpoints in AERO Clients and 2338 their EUNs SHOULD use application-layer security services such as 2339 TLS/SSL [RFC5246], DTLS [RFC6347] and SSH [RFC4251] to assure the 2340 same level of protection as for critical secured Internet services 2341 such as online banking. AERO Clients that require VPN access to 2342 enterprise networks SHOULD use symmetric network and/or transport 2343 layer security services such as TLS/SSL, DTLS, IPsec [RFC4301], etc. 2345 Control plane security considerations are the same as for standard 2346 IPv6 Neighbor Discovery [RFC4861], except that the PRL also provides 2347 AERO Clients with a list of trusted Servers. As fixed infrastructure 2348 elements, AERO Proxys and Servers SHOULD pre-configure security 2349 associations for one another (e.g., using pre-placed keys) and use 2350 symmetric network and/or transport layer security services such as 2351 IPsec, TLS/SSL or DTLS to secure ND messages. AERO Clients that 2352 connect to secured enclaves need not apply security to their ND 2353 messages, since the messages will be intercepted by an enclave 2354 perimeter Proxy. AERO Clients located outside of secured enclaves 2355 SHOULD use symmetric network and/or transport layer security to 2356 secure their ND exchanges with Servers, but when there are many 2357 prospective neighbors with dynamically changing connectivity an 2358 asymmetric security service such as SEND may be needed (see: 2359 Section 7). 2361 AERO Servers and Relays present targets for traffic amplification 2362 Denial of Service (DoS) attacks. This concern is no different than 2363 for widely-deployed VPN security gateways in the Internet, where 2364 attackers could send spoofed packets to the gateways at high data 2365 rates. This can be mitigated by connecting Relays and Servers over 2366 dedicated links with no connections to the Internet and/or when 2367 connections to the Internet are only permitted through well-managed 2368 firewalls. Traffic amplification DoS attacks can also target an AERO 2369 Client's low data rate links. This is a concern not only for Clients 2370 located on the open Internet but also for Clients in secured 2371 enclaves. AERO Servers and Proxys can institute rate limits that 2372 protect Clients from receiving packet floods that could DoS low data 2373 rate links. 2375 AERO Clients MUST ensure that their connectivity is not used by 2376 unauthorized nodes on their EUNs to gain access to a protected 2377 network, i.e., AERO Clients that act as routers MUST NOT provide 2378 routing services for unauthorized nodes. (This concern is no 2379 different than for ordinary hosts that receive an IP address 2380 delegation but then "share" the address with other nodes via some 2381 form of Internet connection sharing such as tethering.) 2383 Although public domain and commercial SEND implementations exist, 2384 concerns regarding the strength of the cryptographic hash algorithm 2385 have been documented [RFC6273] [RFC4982]. 2387 The PRL MUST be well-managed and secured from unauthorized tampering, 2388 even though the list includes only public information. 2390 Security considerations for accepting link-layer ICMP messages and 2391 reflected packets are discussed throughout the document. 2393 11. Acknowledgements 2395 Discussions in the IETF, aviation standards communities and private 2396 exchanges helped shape some of the concepts in this work. 2397 Individuals who contributed insights include Mikael Abrahamsson, Mark 2398 Andrews, Fred Baker, Bob Braden, Stewart Bryant, Brian Carpenter, 2399 Wojciech Dec, Ralph Droms, Adrian Farrel, Nick Green, Sri Gundavelli, 2400 Brian Haberman, Bernhard Haindl, Joel Halpern, Tom Herbert, Sascha 2401 Hlusiak, Lee Howard, Andre Kostur, Hubert Kuenig, Ted Lemon, Andy 2402 Malis, Satoru Matsushima, Tomek Mrugalski, Madhu Niraula, Alexandru 2403 Petrescu, Behcet Saikaya, Michal Skorepa, Joe Touch, Bernie Volz, 2404 Ryuji Wakikawa, Tony Whyman, Lloyd Wood and James Woodyatt. Members 2405 of the IESG also provided valuable input during their review process 2406 that greatly improved the document. Special thanks go to Stewart 2407 Bryant, Joel Halpern and Brian Haberman for their shepherding 2408 guidance during the publication of the AERO first edition. 2410 This work has further been encouraged and supported by Boeing 2411 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2412 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2413 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Seth Jahne, Ed 2414 King, Gene MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Greg 2415 Saccone, Kent Shuey, Brian Skeen, Mike Slane, Carrie Spiker, Brendan 2416 Williams, Julie Wulff, Yueli Yang, Eric Yeh and other members of the 2417 BR&T and BIT mobile networking teams. Kyle Bae, Wayne Benson and 2418 Eric Yeh are especially acknowledged for implementing the AERO 2419 functions as extensions to the public domain OpenVPN distribution. 2421 Earlier works on NBMA tunneling approaches are found in 2422 [RFC2529][RFC5214][RFC5569]. 2424 Many of the constructs presented in this second edition of AERO are 2425 based on the author's earlier works, including: 2427 o The Internet Routing Overlay Network (IRON) 2428 [RFC6179][I-D.templin-ironbis] 2430 o Virtual Enterprise Traversal (VET) 2431 [RFC5558][I-D.templin-intarea-vet] 2433 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2434 [RFC5320][I-D.templin-intarea-seal] 2436 o AERO, First Edition [RFC6706] 2438 Note that these works cite numerous earlier efforts that are not also 2439 cited here due to space limitations. The authors of those earlier 2440 works are acknowledged for their insights. 2442 This work is aligned with the NASA Safe Autonomous Systems Operation 2443 (SASO) program under NASA contract number NNA16BD84C. 2445 This work is aligned with the FAA as per the SE2025 contract number 2446 DTFAWA-15-D-00030. 2448 This work is aligned with the Boeing Information Technology (BIT) 2449 MobileNet program. 2451 This work is aligned with the Boeing autonomy program. 2453 12. References 2455 12.1. Normative References 2457 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2458 DOI 10.17487/RFC0768, August 1980, 2459 . 2461 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2462 DOI 10.17487/RFC0791, September 1981, 2463 . 2465 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2466 RFC 792, DOI 10.17487/RFC0792, September 1981, 2467 . 2469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2470 Requirement Levels", BCP 14, RFC 2119, 2471 DOI 10.17487/RFC2119, March 1997, 2472 . 2474 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2475 "Definition of the Differentiated Services Field (DS 2476 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2477 DOI 10.17487/RFC2474, December 1998, 2478 . 2480 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2481 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2482 DOI 10.17487/RFC3971, March 2005, 2483 . 2485 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2486 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2487 . 2489 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2490 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2491 November 2005, . 2493 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2494 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2495 . 2497 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2498 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2499 DOI 10.17487/RFC4861, September 2007, 2500 . 2502 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2503 Address Autoconfiguration", RFC 4862, 2504 DOI 10.17487/RFC4862, September 2007, 2505 . 2507 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2508 Advertisement Flags Option", RFC 5175, 2509 DOI 10.17487/RFC5175, March 2008, 2510 . 2512 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2513 (IPv6) Specification", STD 86, RFC 8200, 2514 DOI 10.17487/RFC8200, July 2017, 2515 . 2517 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2518 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2519 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2520 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2521 . 2523 12.2. Informative References 2525 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2526 2016. 2528 [I-D.ietf-dmm-distributed-mobility-anchoring] 2529 Chan, A., Wei, X., Lee, J., Jeon, S., and C. Bernardos, 2530 "Distributed Mobility Anchoring", draft-ietf-dmm- 2531 distributed-mobility-anchoring-12 (work in progress), 2532 January 2019. 2534 [I-D.ietf-intarea-gue] 2535 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2536 Encapsulation", draft-ietf-intarea-gue-06 (work in 2537 progress), August 2018. 2539 [I-D.ietf-intarea-gue-extensions] 2540 Herbert, T., Yong, L., and F. Templin, "Extensions for 2541 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2542 extensions-05 (work in progress), August 2018. 2544 [I-D.ietf-intarea-tunnels] 2545 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2546 Architecture", draft-ietf-intarea-tunnels-09 (work in 2547 progress), July 2018. 2549 [I-D.ietf-rtgwg-atn-bgp] 2550 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 2551 Moreno, "A Simple BGP-based Mobile Routing System for the 2552 Aeronautical Telecommunications Network", draft-ietf- 2553 rtgwg-atn-bgp-01 (work in progress), January 2019. 2555 [I-D.templin-6man-aeroaddr] 2556 Templin, F., "The AERO Address", draft-templin-6man- 2557 aeroaddr-04 (work in progress), December 2018. 2559 [I-D.templin-6man-dhcpv6-ndopt] 2560 Templin, F., "A Unified Stateful/Stateless Configuration 2561 Service for IPv6", draft-templin-6man-dhcpv6-ndopt-07 2562 (work in progress), December 2018. 2564 [I-D.templin-6man-rio-redirect] 2565 Templin, F. and j. woodyatt, "Route Information Options in 2566 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2567 redirect-07 (work in progress), December 2018. 2569 [I-D.templin-intarea-grefrag] 2570 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2571 templin-intarea-grefrag-04 (work in progress), July 2016. 2573 [I-D.templin-intarea-seal] 2574 Templin, F., "The Subnetwork Encapsulation and Adaptation 2575 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2576 progress), January 2014. 2578 [I-D.templin-intarea-vet] 2579 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2580 templin-intarea-vet-40 (work in progress), May 2013. 2582 [I-D.templin-ironbis] 2583 Templin, F., "The Interior Routing Overlay Network 2584 (IRON)", draft-templin-ironbis-16 (work in progress), 2585 March 2014. 2587 [I-D.templin-v6ops-pdhost] 2588 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing 2589 Models", draft-templin-v6ops-pdhost-23 (work in progress), 2590 December 2018. 2592 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2594 [RFC1035] Mockapetris, P., "Domain names - implementation and 2595 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2596 November 1987, . 2598 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2599 Communication Layers", STD 3, RFC 1122, 2600 DOI 10.17487/RFC1122, October 1989, 2601 . 2603 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2604 DOI 10.17487/RFC1191, November 1990, 2605 . 2607 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2608 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2609 . 2611 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2612 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2613 1996, . 2615 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2616 DOI 10.17487/RFC2003, October 1996, 2617 . 2619 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2620 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2621 . 2623 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2624 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2625 December 1998, . 2627 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2628 Domains without Explicit Tunnels", RFC 2529, 2629 DOI 10.17487/RFC2529, March 1999, 2630 . 2632 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2633 Malis, "A Framework for IP Based Virtual Private 2634 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2635 . 2637 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2638 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2639 DOI 10.17487/RFC2784, March 2000, 2640 . 2642 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2643 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2644 . 2646 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2647 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2648 . 2650 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2651 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2652 . 2654 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2655 of Explicit Congestion Notification (ECN) to IP", 2656 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2657 . 2659 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2660 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2661 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2662 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2663 . 2665 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2666 for IPv6 Hosts and Routers", RFC 4213, 2667 DOI 10.17487/RFC4213, October 2005, 2668 . 2670 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 2671 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 2672 January 2006, . 2674 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2675 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2676 DOI 10.17487/RFC4271, January 2006, 2677 . 2679 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2680 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2681 2006, . 2683 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2684 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2685 December 2005, . 2687 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2688 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2689 2006, . 2691 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2692 Control Message Protocol (ICMPv6) for the Internet 2693 Protocol Version 6 (IPv6) Specification", STD 89, 2694 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2695 . 2697 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2698 Protocol (LDAP): The Protocol", RFC 4511, 2699 DOI 10.17487/RFC4511, June 2006, 2700 . 2702 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2703 "Internet Group Management Protocol (IGMP) / Multicast 2704 Listener Discovery (MLD)-Based Multicast Forwarding 2705 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2706 August 2006, . 2708 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2709 Errors at High Data Rates", RFC 4963, 2710 DOI 10.17487/RFC4963, July 2007, 2711 . 2713 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 2714 Algorithms in Cryptographically Generated Addresses 2715 (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, 2716 . 2718 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2719 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2720 DOI 10.17487/RFC5214, March 2008, 2721 . 2723 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2724 (TLS) Protocol Version 1.2", RFC 5246, 2725 DOI 10.17487/RFC5246, August 2008, 2726 . 2728 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2729 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2730 February 2010, . 2732 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2733 Route Optimization Requirements for Operational Use in 2734 Aeronautics and Space Exploration Mobile Networks", 2735 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2736 . 2738 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2739 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2740 . 2742 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2743 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2744 January 2010, . 2746 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2747 Global Enterprise Recursion (RANGER)", RFC 5720, 2748 DOI 10.17487/RFC5720, February 2010, 2749 . 2751 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2752 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2753 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2754 . 2756 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2757 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2758 . 2760 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2761 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2762 DOI 10.17487/RFC6221, May 2011, 2763 . 2765 [RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure 2766 Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, 2767 DOI 10.17487/RFC6273, June 2011, 2768 . 2770 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2771 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2772 January 2012, . 2774 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2775 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2776 . 2778 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2779 for Equal Cost Multipath Routing and Link Aggregation in 2780 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2781 . 2783 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2784 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2785 . 2787 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2788 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2789 . 2791 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 2792 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 2793 March 2017, . 2795 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2796 October 2014. 2798 Appendix A. AERO Alternate Encapsulations 2800 When GUE encapsulation is not needed, AERO can use common 2801 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2802 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2803 encapsulation is therefore only differentiated from non-AERO tunnels 2804 through the application of AERO control messaging and not through, 2805 e.g., a well-known UDP port number. 2807 As for GUE encapsulation, alternate AERO encapsulation formats may 2808 require encapsulation layer fragmentation. For simple IP-in-IP 2809 encapsulation, an IPv6 fragment header is inserted directly between 2810 the inner and outer IP headers when needed, i.e., even if the outer 2811 header is IPv4. The IPv6 Fragment Header is identified to the outer 2812 IP layer by its IP protocol number, and the Next Header field in the 2813 IPv6 Fragment Header identifies the inner IP header version. For GRE 2814 encapsulation, a GRE fragment header is inserted within the GRE 2815 header [I-D.templin-intarea-grefrag]. 2817 Figure 5 shows the AERO IP-in-IP encapsulation format before any 2818 fragmentation is applied: 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 | Outer IPv4 Header | | Outer IPv6 Header | 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | Inner IP Header | | Inner IP Header | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | | | | 2828 ~ ~ ~ ~ 2829 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2830 ~ ~ ~ ~ 2831 | | | | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2834 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2836 Figure 5: Minimal Encapsulation Format using IP-in-IP 2838 Figure 6 shows the AERO GRE encapsulation format before any 2839 fragmentation is applied: 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | Outer IP Header | 2843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2844 | GRE Header | 2845 | (with checksum, key, etc..) | 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 | GRE Fragment Header (optional)| 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 | Inner IP Header | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | | 2852 ~ ~ 2853 ~ Inner Packet Body ~ 2854 ~ ~ 2855 | | 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2858 Figure 6: Minimal Encapsulation Using GRE 2860 Alternate encapsulation may be preferred in environments where GUE 2861 encapsulation would add unnecessary overhead. For example, certain 2862 low-bandwidth wireless data links may benefit from a reduced 2863 encapsulation overhead. 2865 GUE encapsulation can traverse network paths that are inaccessible to 2866 non-UDP encapsulations, e.g., for crossing Network Address 2867 Translators (NATs). More and more, network middleboxes are also 2868 being configured to discard packets that include anything other than 2869 a well-known IP protocol such as UDP and TCP. It may therefore be 2870 necessary to determine the potential for middlebox filtering before 2871 enabling alternate encapsulation in a given environment. 2873 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2874 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 2875 messaging and route determination occur before security encapsulation 2876 is applied for outgoing packets and after security decapsulation is 2877 applied for incoming packets. 2879 AERO is especially well suited for use with VPN system encapsulations 2880 such as OpenVPN [OVPN]. 2882 Appendix B. When to Insert an Encapsulation Fragment Header 2884 An encapsulation fragment header is inserted when the AERO tunnel 2885 ingress needs to apply fragmentation to accommodate packets that must 2886 be delivered without loss due to a size restriction. Fragmentation 2887 is performed on the inner packet while encapsulating each inner 2888 packet fragment in outer IP and encapsulation layer headers that 2889 differ only in the fragment header fields. 2891 The fragment header can also be inserted in order to include a 2892 coherent Identification value with each packet, e.g., to aid in 2893 Duplicate Packet Detection (DPD). In this way, network nodes can 2894 cache the Identification values of recently-seen packets and use the 2895 cached values to determine whether a newly-arrived packet is in fact 2896 a duplicate. The Identification value within each packet could 2897 further provide a rough indicator of packet reordering, e.g., in 2898 cases when the tunnel egress wishes to discard packets that are 2899 grossly out of order. 2901 In some use cases, there may be operational assurance that no 2902 fragmentation of any kind will be necessary, or that only occasional 2903 large control messages will require fragmentation. In that case, the 2904 encapsulation fragment header can be omitted and ordinary 2905 fragmentation of the outer IP protocol version can be applied when 2906 necessary. 2908 Appendix C. Autoconfiguration for Constrained Platforms 2910 On some platforms (e.g., popular cell phone operating systems), the 2911 act of assigning a default IPv6 route and/or assigning an address to 2912 an interface may not be permitted from a user application due to 2913 security policy. Typically, those platforms include a TUN/TAP 2914 interface [TUNTAP] that acts as a point-to-point conduit between user 2915 applications and the AERO interface. In that case, the Client can 2916 instead generate a "synthesized RA" message. The message conforms to 2917 [RFC4861] and is prepared as follows: 2919 o the IPv6 source address is the Client's AERO address 2921 o the IPv6 destination address is all-nodes multicast 2923 o the Router Lifetime is set to a time that is no longer than the 2924 ACP DHCPv6 lifetime 2926 o the message does not include a Source Link Layer Address Option 2927 (SLLAO) 2929 o the message includes a Prefix Information Option (PIO) with a /64 2930 prefix taken from the ACP as the prefix for autoconfiguration 2932 The Client then sends the synthesized RA message via the TUN/TAP 2933 interface, where the operating system kernel will interpret it as 2934 though it were generated by an actual router. The operating system 2935 will then install a default route and use StateLess Address 2936 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 2937 interface. Methods for similarly installing an IPv4 default route 2938 and IPv4 address on the TUN/TAP interface are based on synthesized 2939 DHCPv4 messages [RFC2131]. 2941 Appendix D. Operational Deployment Alternatives 2943 AERO can be used in many different variations based on the specific 2944 use case. The following sections discuss variations that adhere to 2945 the AERO principles while allowing selective application of AERO 2946 components. 2948 D.1. Operation on AERO Links Without DHCPv6 Services 2950 When Servers on the AERO link do not provide DHCPv6 services, 2951 operation can still be accommodated through administrative 2952 configuration of ACPs on AERO Clients. In that case, administrative 2953 configurations of AERO interface neighbor cache entries on both the 2954 Server and Client are also necessary. However, this may interfere 2955 with the ability for Clients to dynamically change to new Servers, 2956 and can expose the AERO link to misconfigurations unless the 2957 administrative configurations are carefully coordinated. 2959 D.2. Operation on Server-less AERO Links 2961 In some AERO link scenarios, there may be no Servers on the link and/ 2962 or no need for Clients to use a Server as an intermediary trust 2963 anchor. In that case, each Client acts as a Server unto itself to 2964 establish neighbor cache entries by performing direct Client-to- 2965 Client IPv6 ND message exchanges, and some other form of trust basis 2966 must be applied so that each Client can verify that the prospective 2967 neighbor is authorized to use its claimed ACP. 2969 When there is no Server on the link, Clients must arrange to receive 2970 ACPs and publish them via a secure alternate PD authority through 2971 some means outside the scope of this document. 2973 D.3. Operation on Client-less AERO Links 2975 In some environments, the AERO service may be useful for mobile nodes 2976 that do not implement the AERO Client function and do not perform 2977 encapsulation. For example, if the mobile node has a way of 2978 injecting its ACP into the access subnetwork routing system an AERO 2979 Server connected to the same access network can accept the ACP prefix 2980 injection as an indication that a new mobile node has come onto the 2981 subnetwork. The Server can then inject the ACP into the BGP routing 2982 system the same as if an AERO Client/Server PD exchange had occurred. 2983 If the mobile node subsequently withdraws the ACP from the access 2984 network routing system, the Server can then withdraw the ACP from the 2985 BGP routing system. 2987 In this arrangement, AERO Servers and Relays are used in exactly the 2988 same ways as for environments where DHCPv6 Client/Server exchanges 2989 are supported. However, the access subnetwork routing systems must 2990 be capable of accommodating rapid ACP injections and withdrawals from 2991 mobile nodes with the understanding that the information must be 2992 propagated to all routers in the system. Operational experience has 2993 shown that this kind of routing system "churn" can lead to overall 2994 instability and routing system inconsistency. 2996 D.4. Manually-Configured AERO Tunnels 2998 In addition to the dynamic neighbor discovery procedures for AERO 2999 link neighbors described above, AERO encapsulation can be applied to 3000 manually-configured tunnels. In that case, the tunnel endpoints use 3001 an administratively-provisioned AERO address and exchange NS/NA 3002 messages the same as for dynamically-established tunnels. 3004 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links 3006 In some environments, AERO Servers and Relays may be connected by 3007 dedicated point-to-point links, e.g., high speed fiberoptic leased 3008 lines. In that case, the Servers and Relays can participate in the 3009 AERO link the same as specified above but can avoid encapsulation 3010 over the dedicated links. In that case, however, the links would be 3011 dedicated for AERO and could not be multiplexed for both AERO and 3012 non-AERO communications. 3014 D.6. Encapsulation Protocol Version Considerations 3016 A source Client may connect only to an IPvX underlying network, while 3017 the target Client connects only to an IPvY underlying network. In 3018 that case, the target and source Clients have no means for reaching 3019 each other directly (since they connect to underlying networks of 3020 different IP protocol versions) and so must ignore any route 3021 optimization messages and continue to send packets via their Servers. 3023 D.7. Extending AERO Links Through Security Gateways 3025 When an enterprise mobile node moves from a campus LAN connection to 3026 a public Internet link, it must re-enter the enterprise via a 3027 security gateway that has both a physical interface connection to the 3028 Internet and a physical interface connection to the enterprise 3029 internetwork. This most often entails the establishment of a Virtual 3030 Private Network (VPN) link over the public Internet from the mobile 3031 node to the security gateway. During this process, the mobile node 3032 supplies the security gateway with its public Internet address as the 3033 link-layer address for the VPN. The mobile node then acts as an AERO 3034 Client to negotiate with the security gateway to obtain its ACP. 3036 In order to satisfy this need, the security gateway also operates as 3037 an AERO Server with support for AERO Client proxying. In particular, 3038 when a mobile node (i.e., the Client) connects via the security 3039 gateway (i.e., the Server), the Server provides the Client with an 3040 ACP in a PD exchange the same as if it were attached to an enterprise 3041 campus access link. The Server then replaces the Client's link-layer 3042 source address with the Server's enterprise-facing link-layer address 3043 in all AERO messages the Client sends toward neighbors on the AERO 3044 link. The AERO messages are then delivered to other nodes on the 3045 AERO link as if they were originated by the security gateway instead 3046 of by the AERO Client. In the reverse direction, the AERO messages 3047 sourced by nodes within the enterprise network can be forwarded to 3048 the security gateway, which then replaces the link-layer destination 3049 address with the Client's link-layer address and replaces the link- 3050 layer source address with its own (Internet-facing) link-layer 3051 address. 3053 After receiving the ACP, the Client can send IP packets that use an 3054 address taken from the ACP as the network layer source address, the 3055 Client's link-layer address as the link-layer source address, and the 3056 Server's Internet-facing link-layer address as the link-layer 3057 destination address. The Server will then rewrite the link-layer 3058 source address with the Server's own enterprise-facing link-layer 3059 address and rewrite the link-layer destination address with the 3060 target AERO node's link-layer address, and the packets will enter the 3061 enterprise network as though they were sourced from a node located 3062 within the enterprise. In the reverse direction, when a packet 3063 sourced by a node within the enterprise network uses a destination 3064 address from the Client's ACP, the packet will be delivered to the 3065 security gateway which then rewrites the link-layer destination 3066 address to the Client's link-layer address and rewrites the link- 3067 layer source address to the Server's Internet-facing link-layer 3068 address. The Server then delivers the packet across the VPN to the 3069 AERO Client. In this way, the AERO virtual link is essentially 3070 extended *through* the security gateway to the point at which the VPN 3071 link and AERO link are effectively grafted together by the link-layer 3072 address rewriting performed by the security gateway. All AERO 3073 messaging services (including route optimization and mobility 3074 signaling) are therefore extended to the Client. 3076 In order to support this virtual link grafting, the security gateway 3077 (acting as an AERO Server) must keep static neighbor cache entries 3078 for all of its associated Clients located on the public Internet. 3079 The neighbor cache entry is keyed by the AERO Client's AERO address 3080 the same as if the Client were located within the enterprise 3081 internetwork. The neighbor cache is then managed in all ways as 3082 though the Client were an ordinary AERO Client. This includes the 3083 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 3084 Unreachability Detection. 3086 Note that the main difference between a security gateway acting as an 3087 AERO Server and an enterprise-internal AERO Server is that the 3088 security gateway has at least one enterprise-internal physical 3089 interface and at least one public Internet physical interface. 3090 Conversely, the enterprise-internal AERO Server has only enterprise- 3091 internal physical interfaces. For this reason security gateway 3092 proxying is needed to ensure that the public Internet link-layer 3093 addressing space is kept separate from the enterprise-internal link- 3094 layer addressing space. This is afforded through a natural extension 3095 of the security association caching already performed for each VPN 3096 client by the security gateway. 3098 Appendix E. S/TLLAO Extensions for Special-Purpose Links 3100 The AERO S/TLLAO format specified in Section 3.5 includes a Length 3101 value of 5 (i.e., 5 units of 8 octets). However, special-purpose 3102 links may extend the basic format to include additional fields and a 3103 Length value larger than 5. 3105 For example, adaptation of AERO to the Aeronautical 3106 Telecommunications Network with Internet Protocol Services (ATN/IPS) 3107 includes link selection preferences based on transport port numbers 3108 in addition to the existing DSCP-based preferences. ATN/IPS nodes 3109 maintain a map of transport port numbers to 64 possible preference 3110 fields, e.g., TCP port 22 maps to preference field 8, TCP port 443 3111 maps to preference field 20, UDP port 8060 maps to preference field 3112 34, etc. The extended S/TLLAO format for ATN/IPS is shown in 3113 Figure 7, where the Length value is 7 and the 'Q(i)' fields provide 3114 link preferences for the corresponding transport port number. 3116 0 1 2 3 3117 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 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Type | Length = 7 | Reserved | 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 | Interface ID | UDP Port Number | 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 | | 3124 + + 3125 | | 3126 + IP Address + 3127 | | 3128 + + 3129 | | 3130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3131 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 |Q00|Q01|Q02|Q03|Q04|Q05|Q06|Q07|Q08|Q09|Q10|Q11|Q12|Q13|Q14|Q15| 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 |Q16|Q17|Q18|Q19|Q20|Q21|Q22|Q23|Q24|Q25|Q26|Q27|Q28|Q29|Q30|Q31| 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3143 |Q32|Q33|Q34|Q35|Q36|Q37|Q38|Q39|Q40|Q41|Q42|Q43|Q44|Q45|Q46|Q47| 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 |Q48|Q49|Q50|Q51|Q52|Q53|Q54|Q55|Q56|Q57|Q58|Q59|Q60|Q61|Q62|Q63| 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3148 Figure 7: ATN/IPS Extended S/TLLAO Format 3150 Appendix F. Change Log 3152 << RFC Editor - remove prior to publication >> 3154 Changes from draft-templin-intarea-6706bis-04 to draft-templin- 3155 intrea-6706bis-05: 3157 o New Appendix E on S/TLLAO Extensions for special-purpose links. 3158 Discussed ATN/IPS as example. 3160 o New sentence in introduction to declare appendices as non- 3161 normative. 3163 Changes from draft-templin-intarea-6706bis-03 to draft-templin- 3164 intrea-6706bis-04: 3166 o Added definitions for Potential Router List (PRL) and secure 3167 enclave 3169 o Included text on mapping transport layer port numbers to network 3170 layer DSCP values 3172 o Added reference to DTLS and DMM Distributed Mobility Anchoring 3173 working group document 3175 o Reworked Security Considerations 3177 o Updated references. 3179 Changes from draft-templin-intarea-6706bis-02 to draft-templin- 3180 intrea-6706bis-03: 3182 o Added new section on SEND. 3184 o Clarifications on "AERO Address" section. 3186 o Updated references and added new reference for RFC8086. 3188 o Security considerations updates. 3190 o General text clarifications and cleanup. 3192 Changes from draft-templin-intarea-6706bis-01 to draft-templin- 3193 intrea-6706bis-02: 3195 o Note on encapsulation avoidance in Section 4. 3197 Changes from draft-templin-intarea-6706bis-00 to draft-templin- 3198 intrea-6706bis-01: 3200 o Remove DHCPv6 Server Release procedures that leveraged the old way 3201 Relays used to "route" between Server link-local addresses 3203 o Remove all text relating to Relays needing to do any AERO-specific 3204 operations 3206 o Proxy sends RS and receives RA from Server using SEND. Use CGAs 3207 as source addresses, and destination address of RA reply is to the 3208 AERO address corresponding to the Client's ACP. 3210 o Proxy uses SEND to protect RS and authenticate RA (Client does not 3211 use SEND, but rather relies on subnetwork security. When the 3212 Proxy receives an RS from the Client, it creates a new RS using 3213 its own addresses as the source and uses SEND with CGAs to send a 3214 new RS to the Server. 3216 o Emphasize distributed mobility management 3218 o AERO address-based RS injection of ACP into underlying routing 3219 system. 3221 Changes from draft-templin-aerolink-82 to draft-templin-intarea- 3222 6706bis-00: 3224 o Document use of NUD (NS/NA) for reliable link-layer address 3225 updates as an alternative to unreliable unsolicited NA. 3226 Consistent with Section 7.2.6 of RFC4861. 3228 o Server adds additional layer of encapsulation between outer and 3229 inner headers of NS/NA messages for transmission through Relays 3230 that act as vanilla IPv6 routers. The messages include the AERO 3231 Server Subnet Router Anycast address as the source and the Subnet 3232 Router Anycast address corresponding to the Client's ACP as the 3233 destination. 3235 o Clients use Subnet Router Anycast address as the encapsulation 3236 source address when the access network does not provide a 3237 topologically-fixed address. 3239 Author's Address 3241 Fred L. Templin (editor) 3242 Boeing Research & Technology 3243 P.O. Box 3707 3244 Seattle, WA 98124 3245 USA 3247 Email: fltemplin@acm.org