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