idnits 2.17.1 draft-templin-aerolink-79.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 (January 22, 2018) is 2278 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 2372, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2631, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-05 == Outdated reference: A later version (-06) exists of draft-ietf-intarea-gue-extensions-03 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-08 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-01 == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-05 == Outdated reference: A later version (-27) exists of draft-templin-v6ops-pdhost-18 -- 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 (~~), 11 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, January 22, 2018 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: July 26, 2018 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-79.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 IPv6 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 prefix delegation (PD) is 25 supported by the Dynamic Host Configuration Protocol for IPv6 26 (DHCPv6). AERO is a widely-applicable tunneling solution especially 27 well suited to mobile Virtual Private Networks (VPNs) and other 28 applications as described in this document. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 26, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 7 67 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 7 68 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 9 69 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 10 70 3.4. AERO Interface Link-local Addresses . . . . . . . . . . . 11 71 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 13 72 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 16 73 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 16 74 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 16 75 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 16 76 3.6.4. AERO Proxy Behavior . . . . . . . . . . . . . . . . . 17 77 3.7. AERO Interface Neighbor Cache Maintenace . . . . . . . . 17 78 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 19 79 3.8.1. Client Forwarding Algorithm . . . . . . . . . . . . . 20 80 3.8.2. Proxy Forwarding Algorithm . . . . . . . . . . . . . 20 81 3.8.3. Server Forwarding Algorithm . . . . . . . . . . . . . 20 82 3.8.4. Relay Forwarding Algorithm . . . . . . . . . . . . . 21 83 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 22 84 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 22 85 3.11. AERO Interface Data Origin Authentication . . . . . . . . 23 86 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 23 87 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 25 88 3.14. AERO Router Discovery, Prefix Delegation and 89 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 29 90 3.14.1. AERO DHCPv6 and IPv6 ND Service Model . . . . . . . 29 91 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 30 92 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 32 93 3.15. AERO Interface Route Optimization . . . . . . . . . . . . 34 94 3.15.1. Reference Operational Scenario . . . . . . . . . . . 34 95 3.15.2. Concept of Operations . . . . . . . . . . . . . . . 36 96 3.15.3. Sending NS Messages . . . . . . . . . . . . . . . . 36 97 3.15.4. Re-encapsulating and Relaying the NS . . . . . . . . 37 98 3.15.5. Processing NSs and Sending NAs . . . . . . . . . . . 38 99 3.15.6. Re-encapsulating and Relaying NAs . . . . . . . . . 39 100 3.15.7. Processing NAs . . . . . . . . . . . . . . . . . . . 40 101 3.15.8. Server-to-Client and Client-to-Server Route 102 Optimization . . . . . . . . . . . . . . . . . . . . 40 103 3.15.9. Server-to-Server Route Optimization . . . . . . . . 41 104 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 42 105 3.17. Mobility Management and Quality of Service (QoS) . . . . 43 106 3.17.1. Forwarding Packets on Behalf of Departed Clients . . 43 107 3.17.2. Announcing Link-Layer Address and QoS Preference 108 Changes . . . . . . . . . . . . . . . . . . . . . . 43 109 3.17.3. Bringing New Links Into Service . . . . . . . . . . 44 110 3.17.4. Removing Existing Links from Service . . . . . . . . 44 111 3.17.5. Implicit Mobility Management . . . . . . . . . . . . 44 112 3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 44 113 3.17.7. Packet Queueing for Mobility . . . . . . . . . . . . 45 114 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 46 115 4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 46 116 5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 48 117 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 48 118 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 119 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 120 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 122 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 123 10.2. Informative References . . . . . . . . . . . . . . . . . 53 124 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 58 125 Appendix B. When to Insert an Encapsulation Fragment Header . . 60 126 Appendix C. Autoconfiguration for Constrained Platforms . . . . 60 127 Appendix D. Operational Deployment Alternatives . . . . . . . . 61 128 D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 61 129 D.2. Operation on Server-less AERO Links . . . . . . . . . . . 61 130 D.3. Operation on Client-less AERO Links . . . . . . . . . . . 62 131 D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 62 132 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 62 133 D.6. Encapsulation Protocol Version Considerations . . . . . . 62 134 D.7. Extending AERO Links Through Security Gateways . . . . . 63 135 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 64 136 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 65 138 1. Introduction 140 This document specifies the operation of IP over tunnel virtual links 141 using Asymmetric Extended Route Optimization (AERO). The AERO link 142 can be used for tunneling between neighboring nodes over either IPv6 143 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 144 equivalent links for tunneling. Nodes attached to AERO links can 145 exchange packets via trusted intermediate routers that provide 146 forwarding services to reach off-link destinations and route 147 optimization services for improved performance [RFC5522]. 149 AERO provides an IPv6 link-local address format that supports 150 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 151 links IPv6 ND to IP forwarding. Dynamic link selection, mobility 152 management, quality of service (QoS) signaling and route optimization 153 are naturally supported through dynamic neighbor cache updates, while 154 prefix delegation (PD) is supported by the Dynamic Host Configuration 155 Protocol for IPv6 (DHCPv6) [RFC3315]. 157 A node's AERO interface can be configured over multiple underlying 158 interfaces. From the standpoint of IPv6 ND, AERO interface neighbors 159 therefore may appear to have multiple link-layer addresses (i.e., the 160 addresses assigned to underlying interfaces). Each link-layer 161 address is subject to change due to mobility, and link-layer address 162 changes are signaled by IPv6 ND messaging the same as for any IPv6 163 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 applications 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 (native) Internetwork 182 a connected IPv6 or IPv4 network topology over which the AERO link 183 virtual overlay is configured and native peer-to-peer 184 communications are supported. Example Internetworks include the 185 global public Internet, private enterprise networks, aviation 186 networks, etc. 188 AERO link 189 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 190 configured over an underlying Internetwork. All nodes on the AERO 191 link appear as single-hop neighbors from the perspective of the 192 virtual overlay even though they may be separated by many 193 underlying Internetwork hops. The AERO mechanisms can also 194 operate over native link types (e.g., Ethernet, WiFi etc.) when a 195 tunnel virtual overlay is not needed. 197 AERO interface 198 a node's attachment to an AERO link. Since the addresses assigned 199 to an AERO interface are managed for uniqueness, AERO interfaces 200 do not require Duplicate Address Detection (DAD) and therefore set 201 the administrative variable DupAddrDetectTransmits to zero 202 [RFC4862]. 204 AERO address 205 an IPv6 link-local address constructed as specified in 206 Section 3.4. 208 AERO node 209 a node that is connected to an AERO link. 211 AERO Client ("Client") 212 a node that requests IP Prefix Delegations (PDs) from one or more 213 AERO Servers. Following PD, the Client assigns an AERO address to 214 the AERO interface for use in IPv6 ND exchanges with other AERO 215 nodes. A node that acts as an AERO Client on one AERO interface 216 can also act as an AERO Server on a different AERO interface. 218 AERO Server ("Server") 219 a node that configures an AERO interface to provide default 220 forwarding services for AERO Clients. The Server assigns an 221 administratively provisioned IPv6 link-local unicast address to 222 the AERO interface to support the operation of DHCPv6 and the IPv6 223 ND protocol. An AERO Server can also act as an AERO Relay. 225 AERO Relay ("Relay") 226 a node that configures an AERO interface to relay IP packets 227 between nodes on the same AERO link and/or forward IP packets 228 between the AERO link and the native Internetwork. The Relay 229 assigns an administratively provisioned IPv6 link-local unicast 230 address to the AERO interface the same as for a Server. An AERO 231 Relay can also act as an AERO Server. 233 AERO Proxy ("Proxy") 234 a node that provides proxying services for Clients that cannot 235 associate directly with Servers, e.g., when the Client is located 236 in a secured internal enclave and the Server is located in the 237 external Internetwork. The AERO Proxy is a conduit between the 238 secured enclave and the external Internetwork in the same manner 239 as for common web proxies, and behaves in a similar fashion as for 240 IPv6 Neighbor Discovery proxies [RFC4389]. 242 ingress tunnel endpoint (ITE) 243 an AERO interface endpoint that injects encapsulated packets into 244 an AERO link. 246 egress tunnel endpoint (ETE) 247 an AERO interface endpoint that receives encapsulated packets from 248 an AERO link. 250 underlying network 251 the same as defined for Internetwork. 253 underlying interface 254 an AERO node's interface point of attachment to an underlying 255 network. 257 link-layer address 258 an IP address assigned to an AERO node's underlying interface. 259 When UDP encapsulation is used, the UDP port number is also 260 considered as part of the link-layer address. Packets transmitted 261 over an AERO interface use link-layer addresses as encapsulation 262 header source and destination addresses. 264 network layer address 265 the source or destination address of an encapsulated IP packet. 267 end user network (EUN) 268 an internal virtual or external edge IP network that an AERO 269 Client connects to the rest of the network via the AERO interface. 270 The Client sees each EUN as a "downstream" network and sees the 271 AERO interface as its point of attachment to the "upstream" 272 network. 274 AERO Service Prefix (ASP) 275 an IP prefix associated with the AERO link and from which more- 276 specific AERO Client Prefixes (ACPs) are derived. 278 AERO Client Prefix (ACP) 279 an IP prefix derived from an ASP and delegated to a Client, where 280 the ACP prefix length must be no shorter than the ASP prefix 281 length and must be no longer than 64 for IPv6 or 32 for IPv4. 283 base AERO address 284 the lowest-numbered AERO address from the first ACP delegated to 285 the Client (see Section 3.4). 287 Throughout the document, the simple terms "Client", "Server", "Relay" 288 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 289 "AERO Proxy", respectively. Capitalization is used to distinguish 290 these terms from DHCPv6 client/server/relay [RFC3315]. 292 The terminology of DHCPv6 [RFC3315] and IPv6 ND [RFC4861] (including 293 the names of node variables and protocol constants) applies to this 294 document. Also throughout the document, the term "IP" is used to 295 generically refer to either Internet Protocol version (i.e., IPv4 296 [RFC0791] or IPv6 [RFC8200]). 298 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 299 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 300 document are to be interpreted as described in [RFC2119]. Lower case 301 uses of these words are not to be interpreted as carrying RFC2119 302 significance. 304 3. Asymmetric Extended Route Optimization (AERO) 306 The following sections specify the operation of IP over Asymmetric 307 Extended Route Optimization (AERO) links: 309 3.1. AERO Link Reference Model 310 .-(::::::::) 311 .-(::::::::::::)-. 312 (:: Internetwork ::) 313 `-(::::::::::::)-' 314 `-(::::::)-' 315 | 316 +--------------+ +--------+-------+ +--------------+ 317 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 318 | Nbr: C1, R1 | | Nbr: S1, S2 | | Nbr: C2, R1 | 319 | default->R1 | |(X1->S1; X2->S2)| | default->R1 | 320 | X1->C1 | | ASP A1 | | X2->C2 | 321 +-------+------+ +--------+-------+ +------+-------+ 322 | AERO Link | | 323 X---+---+-------------------+-+----------------+---+---X 324 | | | 325 +-----+--------+ +----------+------+ +--------+-----+ 326 |AERO Client C1| | AERO Proxy P1 | |AERO Client C2| 327 | Nbr: S1 | |(Proxy Nbr Cache)| | Nbr: S2 | 328 | default->S1 | +--------+--------+ | default->S2 | 329 | ACP X1 | | | ACP X2 | 330 +------+-------+ .--------+------. +-----+--------+ 331 | (- Proxied Clients -) | 332 .-. `---------------' .-. 333 ,-( _)-. ,-( _)-. 334 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 335 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 336 `-(______)-' +-------+ +-------+ `-(______)-' 338 Figure 1: AERO Link Reference Model 340 Figure 1 presents the AERO link reference model. In this model: 342 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 343 default router for its associated Servers (S1 and S2), and 344 connects the AERO link to the rest of the Internetwork. 346 o AERO Servers S1 and S2 associate with Relay R1 and also act as 347 default routers for their associated Clients C1 and C2. 349 o AERO Clients C1 and C2 associate with Servers S1 and S2, 350 respectively. They receive AERO Client Prefix (ACP) delegations 351 X1 and X2, and also act as default routers for their associated 352 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 353 to the EUNs served by Clients C1 and C2, respectively. 355 o AERO Proxy P1 provides proxy services for AERO Clients in secured 356 enclaves that cannot associate directly with other AERO link 357 neighbors. 359 Each node on the AERO link maintains an AERO interface neighbor cache 360 and an IP forwarding table the same as for any link. Although the 361 figure shows a limited deployment, in common operational practice 362 there may be many additional Relays, Servers, Clients and Proxies. 364 3.2. AERO Node Types 366 AERO Relays provide default forwarding services to AERO Servers. 367 Each Relay also peers with Servers and other Relays in a dynamic 368 routing protocol instance to discover the list of active ACPs (see 369 Section 3.3). Relays forward packets between neighbors connected to 370 the same AERO link and also forward packets between the AERO link and 371 the native Internetwork. Relays present the AERO link to the native 372 Internetwork as a set of one or more AERO Service Prefixes (ASPs) and 373 serve as a gateway between the AERO link and the Internetwork. 374 Relays maintain AERO interface neighbor cache entries for Servers, 375 and maintain an IP forwarding table entry for each AERO Client Prefix 376 (ACP). AERO Relays can also be configured to act as AERO Servers. 378 AERO Servers provide default forwarding services to AERO Clients. 379 Each Server also peers with Relays in a dynamic routing protocol 380 instance to advertise its list of associated ACPs (see Section 3.3). 381 Servers configure a DHCPv6 server function and act as delegating 382 routers to facilitate Prefix Delegation (PD) exchanges with Clients. 383 Each delegated prefix becomes an ACP taken from an ASP. Servers 384 forward packets between AERO interface neighbors, and maintain AERO 385 interface neighbor cache entries for Relays. They also maintain both 386 neighbor cache entries and IP forwarding table entries for each of 387 their associated Clients. AERO Servers can also be configured to act 388 as AERO Relays. 390 AERO Clients act as requesting routers to receive ACPs through DHCPv6 391 PD exchanges with AERO Servers over the AERO link. Each Client can 392 associate with a single Server or with multiple Servers, e.g., for 393 fault tolerance, load balancing, etc. Each IPv6 Client receives at 394 least a /64 IPv6 ACP, and may receive even shorter prefixes. 395 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 396 singleton IPv4 address), and may receive even shorter prefixes. 397 Clients maintain an AERO interface neighbor cache entry for each of 398 their associated Servers as well as for each of their correspondent 399 Clients. 401 AERO Proxies provide a conduit for AERO Clients connected to secured 402 enclaves to assocaite with AERO link Servers. The Proxy can either 403 be explicit or transparent. In the explicit case, the Client sends 404 all of its control plane messages addressed to the Server to the 405 link-layer address of the Proxy. In the transparent case, the Client 406 sends all of its control plane messages to the Server's link-layer 407 address and the Proxy intercepts them before they leave the secured 408 enclave. In both cases, the Proxy forwards the Client's control and 409 data plane messages to and from the Client's current Server(s). The 410 Proxy may also discover a more direct route toward a target 411 destination via AERO route optimization, in which case future 412 outbound data packets would be forwarded via the more direct route. 413 The Proxy function is specified in Section 4. 415 3.3. AERO Routing System 417 The AERO routing system comprises a private instance of the Border 418 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 419 and Servers and does not interact with either the public Internet BGP 420 routing system or the native Internetwork routing system. Relays 421 advertise only a small and unchanging set of ASPs to the native 422 Internetwork routing system instead of the full dynamically changing 423 set of ACPs. 425 In a reference deployment, each AERO Server is configured as an 426 Autonomous System Border Router (ASBR) for a stub Autonomous System 427 (AS) using an AS Number (ASN) that is unique within the BGP instance, 428 and each Server further uses eBGP to peer with one or more Relays but 429 does not peer with other Servers. All Relays are members of the same 430 hub AS using a common ASN, and use iBGP to maintain a consistent view 431 of all active ACPs currently in service. 433 Each Server maintains a working set of associated ACPs, and 434 dynamically announces new ACPs and withdraws departed ACPs in its 435 eBGP updates to Relays. Clients are expected to remain associated 436 with their current Servers for extended timeframes, however Servers 437 SHOULD selectively suppress updates for impatient Clients that 438 repeatedly associate and disassociate with them in order to dampen 439 routing churn. 441 Each Relay configures a black-hole route for each of its ASPs. By 442 black-holing the ASPs, the Relay will maintain forwarding table 443 entries only for the ACPs that are currently active, and packets 444 destined to all other ACPs will correctly incur Destination 445 Unreachable messages due to the black hole route. Relays do not send 446 eBGP updates for ACPs to Servers, but instead only originate a 447 default route. In this way, Servers have only partial topology 448 knowledge (i.e., they know only about the ACPs of their directly 449 associated Clients) and they forward all other packets to Relays 450 which have full topology knowledge. 452 Scaling properties of the AERO routing system are limited by the 453 number of BGP routes that can be carried by Relays. At the time of 454 this writing, the global public Internet BGP routing system manages 455 more than 500K routes with linear growth and no signs of router 456 resource exhaustion [BGP]. Network emulation studies have also shown 457 that a single Relay can accommodate at least 1M dynamically changing 458 BGP routes even on a lightweight virtual machine, i.e., and without 459 requiring high-end dedicated router hardware. 461 Therefore, assuming each Relay can carry 1M or more routes, this 462 means that at least 1M Clients can be serviced by a single set of 463 Relays. A means of increasing scaling would be to assign a different 464 set of Relays for each set of ASPs. In that case, each Server still 465 peers with one or more Relays, but the Server institutes route 466 filters so that it only sends BGP updates to the specific set of 467 Relays that aggregate the ASP. For example, if the ASP for the AERO 468 link is 2001:db8::/32, a first set of Relays could service the ASP 469 segment 2001:db8::/40, a second set of Relays could service 470 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 471 etc. 473 Assuming up to 1K sets of Relays, the AERO routing system can then 474 accommodate 1B or more ACPs with no additional overhead for Servers 475 and Relays (for example, it should be possible to service 1B /64 ACPs 476 taken from a /34 ASP and even more for shorter prefixes). In this 477 way, each set of Relays services a specific set of ASPs that they 478 advertise to the native Internetwork routing system, and each Server 479 configures ASP-specific routes that list the correct set of Relays as 480 next hops. This arrangement also allows for natural incremental 481 deployment, and can support small scale initial deployments followed 482 by dynamic deployment of additional Clients, Servers and Relays 483 without disturbing the already-deployed base. 485 Note that in an alternate routing arrangement each set of Relays 486 could advertise an aggregated ASP for the link into the native 487 Internetwork routing system even though each Relay services only 488 smaller segments of the ASP. In that case, a Relay upon receiving a 489 packet with a destination address covered by the ASP segment of 490 another Relay can simply tunnel the packet to the other Relay. The 491 tradeoff then is the penalty for Relay-to-Relay tunneling compared 492 with reduced routing information in the native routing system. 494 3.4. AERO Interface Link-local Addresses 496 AERO interface link-local address types include administratively- 497 provisioned addresses and AERO addresses. 499 Administratively-provisioned addresses are allocated from the range 500 fe80::/96 and assigned to a Server or Relay's AERO interface. 501 Administratively-provisioned addresses MUST be managed for uniqueness 502 by the administrative authority for the AERO link. (Note that fe80:: 504 is the IPv6 link-local subnet router anycast address, and 505 fe80::ffff:ffff is the address used by Clients to bootstrap AERO 506 address autoconfiguration. These special addresses are therefore not 507 available for assignment.) 509 An AERO address is an IPv6 link-local address with an embedded prefix 510 based on an ACP and associated with a Client's AERO interface. AERO 511 addresses remain stable as the Client moves between topological 512 locations, i.e., even if its link-layer addresses change. 514 For IPv6, AERO addresses begin with the prefix fe80::/64 and include 515 in the interface identifier (i.e., the lower 64 bits) a 64-bit prefix 516 taken from one of the Client's IPv6 ACPs. For example, if the AERO 517 Client receives the IPv6 ACP: 519 2001:db8:1000:2000::/56 521 it constructs its corresponding AERO addresses as: 523 fe80::2001:db8:1000:2000 525 fe80::2001:db8:1000:2001 527 fe80::2001:db8:1000:2002 529 ... etc. ... 531 fe80::2001:db8:1000:20ff 533 For IPv4, AERO addresses are based on an IPv4-mapped IPv6 address 534 [RFC4291] formed from an IPv4 ACP and with a Prefix Length of 96 plus 535 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 536 the IPv4-mapped IPv6 ACP is: 538 0:0:0:0:0:FFFF:192.0.2.16/124 540 The Client then constructs its AERO addresses with the prefix 541 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 542 in the interface identifier as: 544 fe80::FFFF:192.0.2.16 546 fe80::FFFF:192.0.2.17 548 fe80::FFFF:192.0.2.18 550 ... etc. ... 552 fe80:FFFF:192.0.2.31 554 When the Server delegates ACPs to the Client, both the Server and 555 Client use the lowest-numbered AERO address from the first ACP 556 delegation as the "base" AERO address (for example, for the ACP 557 2001:db8:1000:2000::/56 the base AERO address is 558 fe80::2001:db8:1000:2000). The Client then assigns the base AERO 559 address to the AERO interface and uses it for the purpose of 560 maintaining the neighbor cache entry. 562 If the Client has multiple AERO addresses (i.e., when there are 563 multiple ACPs and/or ACPs with short prefix lengths), the Client 564 originates IPv6 ND messages using the base AERO address as the source 565 address and accepts and responds to IPv6 ND messages destined to any 566 of its AERO addresses as equivalent to the base AERO address. In 567 this way, the Client maintains a single neighbor cache entry that may 568 be indexed by multiple AERO addresses. 570 3.5. AERO Interface Characteristics 572 AERO interfaces use encapsulation (see: Section 3.9) to exchange 573 packets with neighbors attached to the AERO link. 575 AERO interfaces maintain a neighbor cache for tracking per-neighbor 576 state the same as for any interface. AERO interfaces use unicast 577 IPv6 ND Neighbor Solicitation (NS), Neighbor Advertisement (NA), 578 Router Solicitation (RS), Router Advertisement (RA) and Redirect 579 messages for neighbor cache management. AERO interfaces use RS/RA 580 messages with an embedded DHCPv6 PD message 581 [I-D.templin-6man-dhcpv6-ndopt]. AERO interfaces include routing 582 information in IPv6 ND messages to support route optimization. 584 AERO interface ND messages include one or more Source/Target Link- 585 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type | Length = 5 |V| Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Interface ID | UDP Port Number | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 + + 596 | | 597 + IP Address + 598 | | 599 + + 600 | | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 612 Format 614 In this format: 616 o Type is set to '1' for SLLAO or '2' for TLLAO the same as for IPv6 617 ND. 619 o Length is set to the constant value '5' (i.e., 5 units of 8 620 octets). 622 o V (Verify) is set to '1' in the first SLLAO in an NS message if 623 the recipient is required to forward the NA reply back through the 624 reverse chain of Servers and Relays from the target to the source. 625 Otherwise, V is set to '0', and ignored in all other ND messages. 627 o Reserved is set to the value '0' on transmission and ignored on 628 receipt. 630 o Interface ID is set to an integer value between 0 and 65535 631 corresponding to an underlying interface of the AERO node. 633 o UDP Port Number and IP Address are set to the addresses used by 634 the AERO node when it sends encapsulated packets over the 635 specified underlying interface or to '0' when the T/SLLAO is not 636 to be used for address updates and/or Network Address Translator 637 (NAT) / Proxy detection. When UDP is not used as part of the 638 encapsulation, UDP Port Number is set to '0'. When the 639 encapsulation IP address family is IPv4, IP Address is formed as 640 an IPv4-mapped IPv6 address as specified in Section 3.4. 642 o P(i) is a set of 64 Preference values that correspond to the 64 643 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 644 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 645 ("medium") or '3' ("high") to indicate a QoS preference level for 646 packet forwarding purposes. 648 AERO interfaces may be configured over multiple underlying 649 interfaces. For example, common mobile handheld devices have both 650 wireless local area network ("WLAN") and cellular wireless links. 651 These links are typically used "one at a time" with low-cost WLAN 652 preferred and highly-available cellular wireless as a standby. In a 653 more complex example, aircraft frequently have many wireless data 654 link types (e.g. satellite-based, cellular, terrestrial, air-to-air 655 directional, etc.) with diverse performance and cost properties. 657 If a Client's multiple underlying interfaces are used "one at a time" 658 (i.e., all other interfaces are in standby mode while one interface 659 is active), then IPv6 ND messages include only a single S/TLLAO with 660 Interface ID set to a constant value. In that case, the Client would 661 appear to have a single underlying interface but with a dynamically 662 changing link-layer address. 664 If the Client has multiple active underlying interfaces, then from 665 the perspective of IPv6 ND it would appear to have multiple link- 666 layer addresses. In that case, IPv6 ND messages MAY include multiple 667 S/TLLAOs -- each with an Interface ID that corresponds to a specific 668 underlying interface of the AERO node. 670 When the Client includes an S/TLLAO for an underlying interface for 671 which it is aware that there is a NAT or Proxy on the path to the 672 Server, or when the Client includes an S/TLLAO solely for the purpose 673 of announcing new QoS preference values, the Client sets both UDP 674 Port Number and IP Address to 0. 676 When an IPv6 ND message includes multiple S/TLLAOs, the first S/TLLAO 677 MUST correspond to the AERO node's underlying interface used to 678 transmit the message. 680 3.6. AERO Interface Initialization 682 3.6.1. AERO Relay Behavior 684 When a Relay enables an AERO interface, it first assigns an 685 administratively-provisioned link-local address fe80::ID to the 686 interface. Each fe80::ID address MUST be unique among all AERO nodes 687 on the link, and is taken from the range fe80::/96 but excluding the 688 special addresses fe80:: and fe80::ffff:ffff. The Relay then engages 689 in a dynamic routing protocol session with one or more Servers and 690 all other Relays on the link (see: Section 3.3), and advertises its 691 assigned ASPs into the native Internetwork. 693 Each Relay subsequently maintains an IP forwarding table entry for 694 each active ACP covered by its ASP(s), and maintains neighbor cache 695 entries for all Servers on the link. Relays exchange NS/NA messages 696 with AERO link neighbors the same as for any AERO node. However, 697 Neighbor Unreachability Detection (NUD) (see: Section 3.16) is 698 optional since the dynamic routing protocol already provides 699 reachability confirmation. 701 3.6.2. AERO Server Behavior 703 When a Server enables an AERO interface, it assigns an 704 administratively-provisioned link-local address fe80::ID the same as 705 for Relays. The Server further configures a DHCPv6 server function 706 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 707 maintains neighbor cache entries for one or more Relays on the link, 708 and manages per-Client neighbor cache entries and IP forwarding table 709 entries based on control message exchanges. Each Server also engages 710 in a dynamic routing protocol with their neighboring Relays (see: 711 Section 3.3). 713 When the Server receives an NS/RS message from a Client on the AERO 714 interface it authenticates the message and returns an NA/RA message. 715 The Server further provides a simple link-layer conduit between AERO 716 interface neighbors. In particular, when a packet sent by a source 717 Client arrives on the Server's AERO interface and is destined to 718 another AERO node, the Server forwards the packet from within the 719 AERO interface driver at the link layer without ever disturbing the 720 network layer. 722 3.6.3. AERO Client Behavior 724 When a Client enables an AERO interface, it uses the special 725 administratively-provisioned link-local address fe80::ffff:ffff as 726 the source network-layer address in an RS message with an embedded 727 DHCPv6 PD Solicit message to obtain one or more ACPs from one or more 728 AERO Servers. Each Server processes the message and returns an RA 729 message with an embedded DHCPv6 PD Reply message with the destination 730 network-layer address set to the base AERO address. In this way, the 731 unified RS/DHCPv6 and RA/DHCPv6 control messages securely perform all 732 autoconfiguration operations in a single request/response exchange. 734 After the initial DHCPv6 message exchange, the Client can register 735 additional links with the Server by sending an RS message over each 736 link without including a DHCPv6 option. The Server will update its 737 neighbor cache entry for the Client and return an RA message. 739 The Client maintains a neighbor cache entry for each of its Servers 740 and each of its active correspondent Clients. When the Client 741 receives IPv6 ND messages on the AERO interface it updates or creates 742 neighbor cache entries, including link-layer address and QoS 743 preferences. 745 3.6.4. AERO Proxy Behavior 747 When a Proxy enables an AERO interface, it maintains per-Client proxy 748 neighbor cache entries based on control message exchanges. Proxies 749 forward packets between their associated Clients and the Clients' 750 associated Servers. 752 When the Proxy receives an RS message from a Client in the secured 753 enclave, it forwards the message to a Server selected by the Client 754 while using its own link-layer address as the source address. When 755 the Server returns an RA message, the Proxy caches the 756 autoconfiguration information in the RA and forwards the RA to the 757 Client while using its own link-layer address as the source address. 758 The Client, Server and Proxy will then have the necessary state for 759 managing the proxied neighbor association. 761 3.7. AERO Interface Neighbor Cache Maintenace 763 Each AERO interface maintains a conceptual neighbor cache that 764 includes an entry for each neighbor it communicates with on the AERO 765 link, the same as for any IPv6 interface [RFC4861]. AERO interface 766 neighbor cache entires are said to be one of "permanent", "static", 767 "proxy" or "dynamic". 769 Permanent neighbor cache entries are created through explicit 770 administrative action; they have no timeout values and remain in 771 place until explicitly deleted. AERO Relays maintain permanent 772 neighbor cache entries for Servers on the link, and AERO Servers 773 maintain permanent neighbor cache entries for Relays. Each entry 774 maintains the mapping between the neighbor's fe80::ID network-layer 775 address and corresponding link-layer address. 777 Static neighbor cache entries are created and maintained through 778 prefix delegation exchanges as specified in Section 3.14, and remain 779 in place for durations bounded by prefix delegation lifetimes. AERO 780 Servers maintain static neighbor cache entries for each of their 781 associated Clients, and AERO Clients maintain static neighbor cache 782 entries for each of their associated Servers. 784 Proxy neighbor cache entries are created and maintained by AERO 785 Proxies by gleaning information from Client/Server prefix delegation 786 exchanges, and remain in place for durations bounded by prefix 787 delegation lifetimes. AERO Proxies maintain proxy neighbor cache 788 entries for each of their associated Clients, and include pointers to 789 the Client's current set of Servers. 791 Dynamic neighbor cache entries are created or updated based on 792 receipt of route optimization messages as specified in Section 3.15, 793 and are garbage-collected when keepalive timers expire. AERO Clients 794 and Proxies maintain dynamic neighbor cache entries for each of their 795 active correspondents with lifetimes based on IPv6 ND messaging 796 constants. 798 When a target AERO node receives a valid NS message with an AERO 799 source address, it returns an NA message and also creates or updates 800 a dynamic neighbor cache entry for the source network-layer and link- 801 layer addresses. The node then sets an "AcceptTime" variable in the 802 neighbor cache entry to ACCEPT_TIME seconds and uses this value to 803 determine whether packets received from the correspondent can be 804 accepted. The node resets AcceptTime when it receives a new IPv6 ND 805 message, and otherwise decrements AcceptTime while no IPv6 ND 806 messages have been received. It is RECOMMENDED that ACCEPT_TIME be 807 set to the default constant value 40 seconds to allow a 10 second 808 window so that the AERO route optimization procedure can converge 809 before AcceptTime decrements below FORWARD_TIME (see below). 811 When an source AERO node receives a valid NA message with an AERO 812 source address that matches its NS message, it creates or updates a 813 dynamic neighbor cache entry for the target network-layer and link- 814 layer addresses. The node then sets a "ForwardTime" variable in the 815 neighbor cache entry to FORWARD_TIME seconds and uses this value to 816 determine whether packets can be sent directly to the correspondent. 817 The node resets ForwardTime when it receives a new NA, and otherwise 818 decrements ForwardTime while no further NA messages have been 819 received. It is RECOMMENDED that FORWARD_TIME be set to the default 820 constant value 30 seconds to match the default REACHABLE_TIME value 821 specified for IPv6 ND [RFC4861]. 823 The node also sets a "MaxRetry" variable to MAX_RETRY to limit the 824 number of keepalives sent when a correspondent may have gone 825 unreachable. It is RECOMMENDED that MAX_RETRY be set to 3 the same 826 as described for IPv6 ND address resolution in Section 7.3.3 of 827 [RFC4861]. 829 Different values for ACCEPT_TIME, FORWARD_TIME and MAX_RETRY MAY be 830 administratively set, if necessary, to better match the AERO link's 831 performance characteristics; however, if different values are chosen, 832 all nodes on the link MUST consistently configure the same values. 833 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 834 sufficiently longer than FORWARD_TIME to allow the AERO route 835 optimization procedure to converge. 837 When there may be a NAT between the Client and the Server, or if the 838 path from the Client to the Server should be tested for reachability, 839 the Client can send periodic RS messages to the Server without a 840 DHCPv6 option to receive RA replies. The RS/RA messaging will keep 841 NAT state alive and test Server reachability without disturbing the 842 DHCPv6 server. 844 3.8. AERO Interface Forwarding Algorithm 846 IP packets enter a node's AERO interface either from the network 847 layer (i.e., from a local application or the IP forwarding system) or 848 from the link layer (i.e., from the AERO tunnel virtual link). 849 Packets that enter the AERO interface from the network layer are 850 encapsulated and forwarded into the AERO link, i.e., they are 851 tunnelled to an AERO interface neighbor. Packets that enter the AERO 852 interface from the link layer are either re-admitted into the AERO 853 link or forwarded to the network layer where they are subject to 854 either local delivery or IP forwarding. In all cases, the AERO 855 interface itself MUST NOT decrement the network layer TTL/Hop-count 856 since its forwarding actions occur below the network layer. 858 AERO interfaces may have multiple underlying interfaces and/or 859 neighbor cache entries for neighbors with multiple Interface ID 860 registrations (see Section 3.5). The AERO node uses each packet's 861 DSCP value to select an outgoing underlying interface based on the 862 node's own QoS preference values, and also to select a destination 863 link-layer address based on the neighbor's underlying interface with 864 the highest preference value. If multiple outgoing interfaces and/or 865 neighbor interfaces have a preference of "high", the AERO node sends 866 one copy of the packet via each of the (outgoing / neighbor) 867 interface pairs; otherwise, the node sends a single copy of the 868 packet. 870 The following sections discuss the AERO interface forwarding 871 algorithms for Clients, Proxies, Servers and Relays. In the 872 following discussion, a packet's destination address is said to 873 "match" if it is a non-link-local address with a prefix covered by an 874 ASP/ACP, or if it is an AERO address that embeds an ACP, or if it is 875 the same as an administratively-provisioned link-local address. 877 3.8.1. Client Forwarding Algorithm 879 When an IP packet enters a Client's AERO interface from the network 880 layer the Client searches for a dynamic neighbor cache entry that 881 matches the destination. If there is a match, the Client uses one or 882 more link-layer addresses in the entry as the link-layer addresses 883 for encapsulation and admits the packet into the AERO link. 884 Otherwise, the Client uses the link-layer address in a static 885 neighbor cache entry for a Server as the encapsulation address 886 (noting that the address may actually be that of a Proxy on the path 887 to the real Server). 889 When an IP packet enters a Client's AERO interface from the link- 890 layer, if the destination matches one of the Client's ACPs or link- 891 local addresses the Client decapsulates the packet and delivers it to 892 the network layer. Otherwise, the Client drops the packet silently. 894 3.8.2. Proxy Forwarding Algorithm 896 When the Proxy receives a packet from a Client within the secured 897 enclave, the Proxy searches for a dynamic neighbor cache entry that 898 matches the destination. If there is a match, the Proxy uses the 899 link-layer address in the neighbor cache entry as the link-layer 900 address for encapsulation and admits the packet into the AERO link. 901 Otherwise, the Proxy uses the link-layer address for one of the 902 Client's Servers as the encapsulation address. 904 When the Proxy receives a packet from a Server, it searches for a 905 proxy neighbor cache entry for a local Client within the secured 906 enclave that matches the destination. If there is a match, the Proxy 907 forwards the packet to the local Client; otherwise, the Proxy drops 908 the packet silently. 910 3.8.3. Server Forwarding Algorithm 912 When an IP packet enters a Server's AERO interface from the network 913 layer, the Server searches for a static neighbor cache entry for a 914 Client that matches the destination. If there is a match, the Server 915 uses one or more link-layer addresses in the entry as the link-layer 916 addresses for encapsulation and admits the packet into the AERO link. 917 Otherwise, the Server uses the link-layer address in a permanent 918 neighbor cache entry for a Relay (selected through longest-prefix 919 match) as the link-layer address for encapsulation. 921 When an IP packet enters a Server's AERO interface from the link 922 layer, the Server processes the packet as follows: 924 o if the destination matches one of the Server's own addresses the 925 Server decapsulates the packet and forwards it to the network 926 layer for local delivery. 928 o else, if the destination matches a static neighbor cache entry for 929 a Client the Server first determines whether the neighbor is the 930 same as the one it received the packet from. If so, the Server 931 MUST drop the packet silently to avoid looping; otherwise, the 932 Server uses the neighbor's link-layer address(es) as the 933 destination for encapsulation and re-admits the packet into the 934 AERO link. 936 o else, the Server uses the link-layer address in a neighbor cache 937 entry for a Relay (selected through longest-prefix match) as the 938 link-layer address for encapsulation. 940 3.8.4. Relay Forwarding Algorithm 942 When an IP packet enters a Relay's AERO interface from the network 943 layer, the Relay searches its IP forwarding table for an ACP entry 944 that matches the destination and otherwise searches for a neighbor 945 cache entry that matches the destination (e.g., for administratively- 946 provisioned link-local addresses). If there is a match, the Relay 947 uses the link-layer address in the corresponding neighbor cache entry 948 as the link-layer address for encapsulation and forwards the packet 949 into the AERO link. Otherwise, the Relay drops the packet and (for 950 non-link-local addresses) returns an ICMP Destination Unreachable 951 message subject to rate limiting (see: Section 3.13). 953 When an IP packet enters a Relay's AERO interface from the link- 954 layer, the Relay processes the packet as follows: 956 o if the destination does not match an ASP, or if the destination 957 matches one of the Relay's own addresses, the Relay decapsulates 958 the packet and forwards it to the network layer where it will be 959 subject to either local delivery or IP forwarding. 961 o else, if the destination matches an ACP entry in the IP forwarding 962 table, or if the destination matches the (administratively- 963 provisioned) link-local address in a permanent neighbor cache 964 entry, the Relay first determines whether the neighbor is the same 965 as the one it received the packet from. If so the Relay MUST drop 966 the packet silently to avoid looping; otherwise, the Relay uses 967 the neighbor's link-layer address as the destination for 968 encapsulation and re-admits the packet into the AERO link. 970 o else, the Relay drops the packet and (for non-link-local 971 addresses) returns an ICMP Destination Unreachable message subject 972 to rate limiting (see: Section 3.13). 974 3.9. AERO Interface Encapsulation and Re-encapsulation 976 AERO interfaces encapsulate IP packets according to whether they are 977 entering the AERO interface from the network layer or if they are 978 being re-admitted into the same AERO link they arrived on. This 979 latter form of encapsulation is known as "re-encapsulation". 981 The AERO interface encapsulates packets per the Generic UDP 982 Encapsulation (GUE) procedures in 983 [I-D.ietf-intarea-gue][I-D.ietf-intarea-gue-extensions], or through 984 an alternate encapsulation format (see: Appendix A). For packets 985 entering the AERO interface from the network layer, the AERO 986 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 987 [RFC2983], "Flow Label"[RFC6438] (for IPv6) and "Congestion 988 Experienced" [RFC3168] values in the packet's IP header into the 989 corresponding fields in the encapsulation IP header. For packets 990 undergoing re-encapsulation, the AERO interface instead copies these 991 values from the original encapsulation IP header into the new 992 encapsulation header, i.e., the values are transferred between 993 encapsulation headers and *not* copied from the encapsulated packet's 994 network-layer header. (Note especially that by copying the TTL/Hop 995 Limit between encapsulation headers the value will eventually 996 decrement to 0 if there is a (temporary) routing loop.) For IPv4 997 encapsulation/re-encapsulation, the AERO interface sets the DF bit as 998 discussed in Section 3.12. 1000 When GUE encapsulation is used, the AERO interface next sets the UDP 1001 source port to a constant value that it will use in each successive 1002 packet it sends, and sets the UDP length field to the length of the 1003 encapsulated packet plus 8 bytes for the UDP header itself plus the 1004 length of the GUE header (or 0 if GUE direct IP encapsulation is 1005 used). For packets sent to a Server or Relay, the AERO interface 1006 sets the UDP destination port to 8060, i.e., the IANA-registered port 1007 number for AERO. For packets sent to a Client, the AERO interface 1008 sets the UDP destination port to the port value stored in the 1009 neighbor cache entry for this Client. The AERO interface then either 1010 includes or omits the UDP checksum according to the GUE 1011 specification. 1013 3.10. AERO Interface Decapsulation 1015 AERO interfaces decapsulate packets destined either to the AERO node 1016 itself or to a destination reached via an interface other than the 1017 AERO interface the packet was received on. Decapsulation is per the 1018 procedures specified for the appropriate encapsulation format. 1020 3.11. AERO Interface Data Origin Authentication 1022 AERO nodes employ simple data origin authentication procedures for 1023 encapsulated packets they receive from other nodes on the AERO link. 1024 In particular: 1026 o AERO Relays and Servers accept encapsulated packets with a link- 1027 layer source address that matches a permanent neighbor cache 1028 entry. 1030 o AERO Servers accept authentic encapsulated IPv6 ND / DHCPv6 1031 messages from Clients, and create or update a static neighbor 1032 cache entry for the Client based on the specific message type. 1034 o AERO Clients and Servers accept encapsulated packets if there is a 1035 static neighbor cache entry with a link-layer address that matches 1036 the packet's link-layer source address. 1038 o AERO Clients and Servers accept encapsulated packets if there is a 1039 dynamic neighbor cache entry with an AERO address that matches the 1040 packet's network-layer source address, with a link-layer address 1041 that matches the packet's link-layer source address, and with a 1042 non-zero AcceptTime. 1044 o AERO Proxies accept encapsulated packets if there is a proxy 1045 neighbor cache entry that matches the packet's network-layer 1046 destination address (i.e., the address of the Client) and link- 1047 layer source address (i.e., the address of one of the Client's 1048 Servers). 1050 Note that this simple data origin authentication is effective in 1051 environments in which link-layer addresses cannot be spoofed. In 1052 other environments, each AERO message must include a signature that 1053 the recipient can use to authenticate the message origin, e.g., as 1054 for common VPN systems such as OpenVPN [OVPN]. In environments where 1055 end systems use end-to-end security, however, it may be sufficient to 1056 require signatures only for AERO DHCPv6, IPv6 ND and ICMP control 1057 plane messages and omit signatures for data plane messages. 1059 3.12. AERO Interface Packet Size Issues 1061 The AERO interface is the node's attachment to the AERO link. The 1062 AERO interface acts as a tunnel ingress when it sends a packet to an 1063 AERO link neighbor and as a tunnel egress when it receives a packet 1064 from an AERO link neighbor. AERO interfaces observe the packet 1065 sizing considerations for tunnels discussed in 1066 [I-D.ietf-intarea-tunnels] and as specified below. 1068 The Internet Protocol expects that IP packets will either be 1069 delivered to the destination or a suitable Packet Too Big (PTB) 1070 message returned to support the process known as IP Path MTU 1071 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1072 crafted for malicious purposes such as denial of service, or lost in 1073 the network [RFC2923]. This can be especially problematic for 1074 tunnels, where a condition known as a PMTUD "black hole" can result. 1075 For these reasons, AERO interfaces employ operational procedures that 1076 avoid interactions with PMTUD, including the use of fragmentation 1077 when necessary. 1079 AERO interfaces observe two different types of fragmentation. Source 1080 fragmentation occurs when the AERO interface (acting as a tunnel 1081 ingress) fragments the encapsulated packet into multiple fragments 1082 before admitting each fragment into the tunnel. Network 1083 fragmentation occurs when an encapsulated packet admitted into the 1084 tunnel by the ingress is fragmented by an IPv4 router on the path to 1085 the egress. Note that a packet that incurs source fragmentation may 1086 also incur network fragmentation. 1088 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1089 bytes [RFC8200]. Although IPv4 specifies a smaller minimum link MTU 1090 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1091 for IPv4 even if encapsulated packets may incur network 1092 fragmentation. 1094 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1095 [RFC8200], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1096 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1097 than the IPv4 minimum). 1099 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1100 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1101 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1102 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1103 configure a Maximum Segment Unit (MSU) as the maximum-sized 1104 encapsulated packet that the ingress can inject into the tunnel 1105 without source fragmentation. The MSU value MUST NOT be larger than 1106 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1107 operational assurance that a larger size can traverse the link along 1108 all paths. 1110 All AERO nodes MUST configure the same MTU/MSU values for reasons 1111 cited in [RFC3819][RFC4861]; in particular, multicast support 1112 requires a common MTU value among all nodes on the link. All AERO 1113 nodes MUST configure an MRU large enough to reassemble packets up to 1114 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1115 enough MRU MUST NOT enable an AERO interface. 1117 The network layer proceeds as follow when it presents an IP packet to 1118 the AERO interface. For each IPv4 packet that is larger than the 1119 AERO interface MTU and with the DF bit set to 0, the network layer 1120 uses IPv4 fragmentation to break the packet into a minimum number of 1121 non-overlapping fragments where the first fragment is no larger than 1122 the MTU and the remaining fragments are no larger than the first. 1123 For all other IP packets, if the packet is larger than the AERO 1124 interface MTU, the network layer drops the packet and returns a PTB 1125 message to the original source. Otherwise, the network layer admits 1126 each IP packet or fragment into the AERO interface. 1128 For each IP packet admitted into the AERO interface, the interface 1129 (acting as a tunnel ingress) encapsulates the packet. If the 1130 encapsulated packet is larger than the AERO interface MSU the ingress 1131 source-fragments the encapsulated packet into a minimum number of 1132 non-overlapping fragments where the first fragment is no larger than 1133 the MSU and the remaining fragments are no larger than the first. 1134 The ingress then admits each encapsulated packet or fragment into the 1135 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1136 header in case any network fragmentation is necessary. The 1137 encapsulated packets will be delivered to the egress, which 1138 reassembles them into a whole packet if necessary. 1140 Several factors must be considered when fragmentation is needed. For 1141 AERO links over IPv4, the IP ID field is only 16 bits in length, 1142 meaning that fragmentation at high data rates could result in data 1143 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1144 AERO links over both IPv4 and IPv6, studies have also shown that IP 1145 fragments are dropped unconditionally over some network paths [I- 1146 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1147 issues could result in operational problems, the ingress SHOULD 1148 employ intermediate-layer source fragmentation (see: [RFC2764] and 1149 [I-D.ietf-intarea-gue-extensions]) before appending the outer 1150 encapsulation headers to each fragment. Since the encapsulation 1151 fragment header reduces the room available for packet data, but the 1152 original source has no way to control its insertion, the ingress MUST 1153 include the fragment header length in the ENCAPS length even for 1154 packets in which the header is absent. 1156 3.13. AERO Interface Error Handling 1158 When an AERO node admits encapsulated packets into the AERO 1159 interface, it may receive link-layer or network-layer error 1160 indications. 1162 A link-layer error indication is an ICMP error message generated by a 1163 router on the path to the neighbor or by the neighbor itself. The 1164 message includes an IP header with the address of the node that 1165 generated the error as the source address and with the link-layer 1166 address of the AERO node as the destination address. 1168 The IP header is followed by an ICMP header that includes an error 1169 Type, Code and Checksum. Valid type values include "Destination 1170 Unreachable", "Time Exceeded" and "Parameter Problem" 1171 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1172 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1173 only emit packets that are guaranteed to be no larger than the IP 1174 minimum link MTU as discussed in Section 3.12.) 1176 The ICMP header is followed by the leading portion of the packet that 1177 generated the error, also known as the "packet-in-error". For 1178 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1179 much of invoking packet as possible without the ICMPv6 packet 1180 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1181 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1182 "Internet Header + 64 bits of Original Data Datagram", however 1183 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1184 ICMP datagram SHOULD contain as much of the original datagram as 1185 possible without the length of the ICMP datagram exceeding 576 1186 bytes". 1188 The link-layer error message format is shown in Figure 3 (where, "L2" 1189 and "L3" refer to link-layer and network-layer, respectively): 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 ~ ~ 1193 | L2 IP Header of | 1194 | error message | 1195 ~ ~ 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | L2 ICMP Header | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1199 ~ ~ P 1200 | IP and other encapsulation | a 1201 | headers of original L3 packet | c 1202 ~ ~ k 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1204 ~ ~ t 1205 | IP header of | 1206 | original L3 packet | i 1207 ~ ~ n 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 ~ ~ e 1210 | Upper layer headers and | r 1211 | leading portion of body | r 1212 | of the original L3 packet | o 1213 ~ ~ r 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1216 Figure 3: AERO Interface Link-Layer Error Message Format 1218 The AERO node rules for processing these link-layer error messages 1219 are as follows: 1221 o When an AERO node receives a link-layer Parameter Problem message, 1222 it processes the message the same as described as for ordinary 1223 ICMP errors in the normative references [RFC0792][RFC4443]. 1225 o When an AERO node receives persistent link-layer Time Exceeded 1226 messages, the IP ID field may be wrapping before earlier fragments 1227 awaiting reassembly have been processed. In that case, the node 1228 SHOULD begin including integrity checks and/or institute rate 1229 limits for subsequent packets. 1231 o When an AERO node receives persistent link-layer Destination 1232 Unreachable messages in response to encapsulated packets that it 1233 sends to one of its dynamic neighbor correspondents, the node 1234 SHOULD mark the path as unusable and use another path. If it 1235 receives Destination Unreachable messages on all paths, the node 1236 SHOULD test the paths to the correspondent using Neighbor 1237 Unreachability Detection (NUD) (see Section 3.16). If NUD fails 1238 (or if the node opts to forego NUD) the node SHOULD set 1239 ForwardTime for the corresponding dynamic neighbor cache entry to 1240 0 and allow future packets destined to the correspondent to flow 1241 through a default route. 1243 o When an AERO Client receives persistent link-layer Destination 1244 Unreachable messages in response to encapsulated packets that it 1245 sends to one of its static neighbor Servers, the Client SHOULD 1246 mark the path as unusable and use another path. If it receives 1247 Destination Unreachable messages on alll paths, the Client SHOULD 1248 test the paths to the Server using NUD. If NUD fails, the Client 1249 SHOULD associate with a new Server and send a DHCPv6 Release 1250 message to the old Server as specified in Section 3.17.6. 1252 o When an AERO Server receives persistent link-layer Destination 1253 Unreachable messages in response to encapsulated packets that it 1254 sends to one of its static neighbor Clients, the Server SHOULD 1255 mark the path as unusable and use another path. If it receives 1256 Destination Unreachable messages on all paths, the Server should 1257 take no further actions unless it receives a DHCPv6 Release 1258 message or if the Prefix Delegation lifetime expires. In that 1259 case, the Server MUST release the Client's ACP prefix delegation, 1260 withdraw the ACP from the AERO routing system and delete the 1261 neighbor cache entry. 1263 o When an AERO Relay or Server receives link-layer Destination 1264 Unreachable messages in response to an encapsulated packet that it 1265 sends to one of its permanent neighbors, it treats the messages as 1266 an indication that the path to the neighbor may be failing. The 1267 node MAY then test the path using NUD, however routing 1268 reconvergence will be managed by the dynamic routing protocol. 1270 When an AERO Relay receives a packet for which the network-layer 1271 destination address is covered by an ASP, if there is no more- 1272 specific routing information for the destination the Relay drops the 1273 packet and returns a network-layer Destination Unreachable message 1274 subject to rate limiting. The Relay first writes the network-layer 1275 source address of the original packet as the destination address of 1276 the message and determines the next hop to the destination. If the 1277 next hop is reached via the AERO interface, the Relay uses the IPv6 1278 address "::" or the IPv4 address "0.0.0.0" as the source address of 1279 the message, then encapsulates the message and forwards it to the 1280 next hop within the AERO interface. Otherwise, the Relay uses one of 1281 its non link-local addresses as the source address of the message and 1282 forwards it via a link outside the AERO interface. 1284 When an AERO node receives an encapsulated packet for which the 1285 reassembly buffer it too small, it drops the packet and returns an 1286 network-layer Packet Too Big (PTB) message. The node first writes 1287 the MRU value into the PTB message MTU field, writes the network- 1288 layer source address of the original packet as the destination 1289 address of the message and determines the next hop to the 1290 destination. If the next hop is reached via the AERO interface, the 1291 node uses the IPv6 address "::" or the IPv4 address "0.0.0.0" as the 1292 source address of the message, then encapsulates the message and 1293 forwards it to the next hop within the AERO interface. Otherwise, 1294 the node uses one of its non link-local addresses as the source 1295 address of the message and forwards it via a link outside the AERO 1296 interface. 1298 When an AERO node receives any network-layer error message via the 1299 AERO interface, it examines the network-layer destination address. 1300 If the next hop toward the destination is via the AERO interface, the 1301 node re-encapsulates and forwards the message to the next hop within 1302 the AERO interface. Otherwise, if the network-layer source address 1303 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1304 writes one of its non link-local addresses as the source address, 1305 recalculates the IP and/or ICMP checksums then forwards the message 1306 via a link outside the AERO interface. 1308 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1310 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1311 coordinated by the DHCPv6 and IPv6 ND control messaging protocols as 1312 discussed in the following Sections. 1314 3.14.1. AERO DHCPv6 and IPv6 ND Service Model 1316 Each AERO Server configures a DHCPv6 server function to facilitate PD 1317 requests from Clients. Each Server is provisioned with a database of 1318 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1319 system, as well as any information necessary to authenticate each 1320 Client. The Client database is maintained by a central 1321 administrative authority for the AERO link and securely distributed 1322 to all Servers, e.g., via the Lightweight Directory Access Protocol 1323 (LDAP) [RFC4511], via static configuration, etc. Therefore, no 1324 Server-to-Server DHCPv6 PD state synchronization is necessary, and 1325 Clients can optionally hold separate PDs for the same ACPs from 1326 multiple Servers. In this way, Clients can associate with multiple 1327 Servers, and can receive new PDs from new Servers before deprecating 1328 PDs received from existing Servers. This provides the Client with a 1329 natural fault-tolerance and/or load balancing profile. 1331 AERO Clients and Servers use unicast IPv6 ND messages to maintain 1332 neighbor cache entries the same as for any link. AERO Servers 1333 configure their AERO interfaces as advertising interfaces, and 1334 therefore send unicast RA messages with configuration information in 1335 response to a Client's RS message. 1337 AERO Clients and Servers include DHCPv6 messages as IPv6 ND options 1338 in the RS/RA messages they exchange per 1339 [I-D.templin-6man-dhcpv6-ndopt]. Client-initiated DHCPv6 messages 1340 are included in RS messages, and Server-intiated DHCPv6 messages are 1341 included in RA messages. The unified RS/DHCPv6 and RA/DHCPv6 1342 messages are exchanged between Client and Server in unicast fashion 1343 according to the prefix management schedule determined by DHCPv6. 1344 The unified messages can be secured using SEcure Neighbor Discovery 1345 (SEND) [RFC3971]. 1347 The following sections specify the Client and Server behavior. 1349 3.14.2. AERO Client Behavior 1351 AERO Clients discover the link-layer addresses of AERO Servers via 1352 static configuration (e.g., from a flat-file map of Server addresses 1353 and locations), or through an automated means such as Domain Name 1354 System (DNS) name resolution [RFC1035]. In the absence of other 1355 information, the Client resolves the DNS Fully-Qualfied Domain Name 1356 (FQDN) "linkupnetworks.[domainname]" where "linkupnetworks" is a 1357 constant text string and "[domainname]" is a DNS suffix for the 1358 Client's underlying network (e.g., "example.com"). After discovering 1359 the link-layer addresses, the Client associates with one or more of 1360 the corresponding Servers. 1362 To associate with a Server, the Client acts as a requesting router to 1363 request ACPs through a DHCPv6 PD exchange [RFC3315][RFC3633] in 1364 conjunction with standard IPv6 ND Router Discovery. The Client 1365 embeds a DHCPv6 Solicit message in an RS message with fe80::ffff:ffff 1366 as the IPv6 source address, All-Routers multicast as the IPv6 1367 destination address, the address of the Client's underlying interface 1368 as the link-layer source address and the link-layer address of the 1369 Server as the link-layer destination address. 1371 In the embedded DHCPv6 Solicit message, the Client includes a Client 1372 Identifier option with the Client's DUID, and an Identity Association 1373 for Prefix Delegation (IA_PD) option. If the Client is pre- 1374 provisioned with ACPs associated with the AERO service, it MAY also 1375 include the ACPs in the IA_PD to indicate its preferences to the 1376 DHCPv6 server. The Client finally includes any additional DHCPv6 1377 options, including Rapid Commit. 1379 The Client next includes one or more SLLAOs in the RS formatted as 1380 described in Section 3.5 to register its link-layer address(es) with 1381 the Server. The first SLLAO MUST correspond to the underlying 1382 interface over which the Client will send the RS/DHCPv6 message. The 1383 Client MAY include additional SLLAOs specific to other underlying 1384 interfaces, but if so it MUST have assurance that there will be no 1385 NATs or Proxies on the paths to the Server via those interfaces. 1386 (Otherwise, the Client can register additional link-layer addresses 1387 with the Server by sending subsequent NS/RS messages via different 1388 underlying interfaces after the initial RS/RA exchange). 1390 The Client then sends the combined RS/DHCPv6 message to the AERO 1391 Server and waits for an RA reply (see Section 3.14.3) while retrying 1392 MAX_RETRY times until an RA is received. If no RA is received, or if 1393 the RA includes a zero Router Lifetime, the Client SHOULD discontinue 1394 autoconfiguration attempts through this Server and try another 1395 Server. Otherwise, the Client processes the embedded DHCPv6 Reply 1396 message and verifies that the message contains valid ACPs in IA_PD 1397 options. 1399 Next, the Client creates a static neighbor cache entry with the 1400 Server's link-local address as the network-layer address and the 1401 Server's encapsulation source address as the link-layer address. The 1402 Client then autoconfigures AERO addresses for each of the delegated 1403 ACPs and assigns the base AERO addresses to the AERO interface. 1405 The Client next examines the P bit in the RA message flags field 1406 [RFC5175]. If the P bit value was 1, the Client assumes that there 1407 is a NAT or Proxy on the path to the Server via the interface over 1408 which it sent the RS message. In that case, the Client SHOULD set 1409 UDP Port Number and IP Address to 0 in the S/TLLAOs of any subsequent 1410 IPv6 ND messages it sends to the Server over that link. 1412 The Client also caches any ASPs included in Route Information Options 1413 (RIOs) [RFC4191] as ASPs to associate with the AERO link, and assigns 1414 the MTU/MSU values in the MTU options to its AERO interface while 1415 configuring an appropriate MRU. This configuration information 1416 applies to the AERO link as a whole, and all AERO nodes will use the 1417 same values. 1419 Following autoconfiguration, the Client sub-delegates the ACPs to its 1420 attached EUNs and/or the Client's own internal virtual interfaces as 1421 described in [I-D.templin-v6ops-pdhost]. The Client subsequently 1422 maintains its ACP delegations through each of its Servers by sending 1423 unicast RS/DHCPv6 messages according to DHCPv6 lease management 1424 procedures (e.g., Renew, Rebind, Release, etc.). The Server will in 1425 turn send unicast RA/DHCPv6 replies. 1427 After the Client registers its Interface IDs and their associated 1428 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1429 Interface ID registrations, e.g., if an underlying interface changes 1430 address or becomes unavailable, if QoS preferences change, etc. To 1431 do so, the Client prepares an unsolicited NA message to send over any 1432 available underlying interface. The NA MUST include a TLLAO specific 1433 to the selected available underlying interface as the first TLLAO and 1434 MAY include any additional TLLAOs specific to other underlying 1435 interfaces. The Client includes fresh 'P(i)' values in each TLLAO to 1436 update the Server's neighbor cache entry. If the Client wishes to 1437 update 'P(i)' values without updating the link-layer address, it sets 1438 the UDP Port Number and IP Address fields to 0. If the Client wishes 1439 to disable the interface, it sets all 'P(i)' values to '0' 1440 ("disabled"). 1442 If the Client wishes to discontinue use of a Server it issues an RS 1443 with an embedded DHCPv6 Release message. When the Server processes 1444 the message, it releases the DHCPv6 PD, deletes its neighbor cache 1445 entry for the Client, withdraws the IP route from the routing system 1446 and returns an RA response with Router Lifetime set to 0. 1448 3.14.3. AERO Server Behavior 1450 AERO Servers act as IPv6 routers and configure a DHCPv6 server 1451 function on their AERO links. AERO Servers arrange to add their 1452 encapsulation layer IP addresses (i.e., their link-layer addresses) 1453 to a static map of Server addresses for the link and/or the DNS 1454 resource records for the FQDN "linkupnetworks.[domainname]" before 1455 entering service. 1457 When an AERO Server receives a prospective Client's RS with embedded 1458 DHCPv6 Solicit message on its AERO interface, and the Server is too 1459 busy, it SHOULD return an immediate RA with Router Lifetime set to 0. 1460 Otherwise, the Server authenticates the message and processes the 1461 embedded DHCPv6 Solicit message. The Server first determines the 1462 correct ACPs to delegate to the Client by searching the Client 1463 database. When the Server delegates the ACPs, it also creates an IP 1464 forwarding table entry for each ACP so that the AERO BGP-based 1465 routing system will propagate the ACPs to the Relays that aggregate 1466 the corresponding ASP (see: Section 3.3). 1468 Next, the Server prepares a DHCPv6 Reply message with IA_PD options 1469 with the delegated ACPs. For IPv4 ACPs, the prefix included in the 1470 IA_PD option is in IPv4-mapped IPv6 address format and with prefix 1471 length set as specified in Section 3.4. The Server then embeds the 1472 DHCPv6 Reply message in a unicast RA message using its link-local 1473 address (i.e., fe80::ID) as the network-layer source address, the 1474 Client's base AERO address from the first IA_PD as the network-layer 1475 destination address, the Server's link-layer address as the source 1476 link-layer address, and the source link-layer address of the RS 1477 message as the destination link-layer address. The Server next sets 1478 the P bit in the RA message flags field [RFC5175] to 1 iIf the source 1479 link-layer address in the RS message was different than the address 1480 in the first SLLAO to indicate that there is a NAT or Proxy on the 1481 path; otherwise it sets P to 0. The Server then includes one or more 1482 RIOs that encode the ASPs for the AERO link. The Server also 1483 includes two MTU options - the first MTU option includes the MTU for 1484 the link and the second MTU option includes the MSU for the link (see 1485 Section 3.12). The Server finally sends the RA to the Client. 1487 The Server next creates a static neighbor cache entry for the Client 1488 using the base AERO address as the network-layer address and with 1489 lifetime set to no more than the smallest PD lifetime. Next, the 1490 Server updates the neighbor cache entry link-layer address(es) by 1491 recording the information in each SLLAO option indexed by the 1492 Interface ID and including the UDP port number, IP address and P(i) 1493 values. For the first SLLAO in the list, however, the Server records 1494 the actual encapsulation source UDP and IP addresses instead of those 1495 that appear in the SLLAO in case there was a NAT or Proxy in the 1496 path. 1498 After the initial RS/DHCPv6 - RA/DHCPv6 exchange, the AERO Server 1499 maintains the neighbor cache entry for the Client until the PD 1500 lifetimes expire. If the Client issues a Renew, the Server extends 1501 the PD lifetimes. If the Client issues a Release, or if the Client 1502 does not issue a Renew before the lifetime expires, the Server 1503 deletes the neighbor cache entry for the Client and withdraws the IP 1504 routes from the AERO routing system. The Server processes these and 1505 any other Client DHCPv6 messages, and returns unicast RA/DHCPv6 1506 replies. The Server may also issue a Reconfigure message in an 1507 unsolicited RA/DHCPv6 message to inform the Client that it needs to 1508 renegotiate its prefix delegations. 1510 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1512 AERO Clients and Servers are always on the same link (i.e., the AERO 1513 link) from the perspective of DHCPv6. However, in some 1514 implementations the DHCPv6 server and IPv6 ND function may be located 1515 in separate modules. In that case, the Server's AERO interface 1516 driver module can act as a Lightweight DHCPv6 Relay Agent 1517 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1518 server module. 1520 When the LDRA receives an authentic RS/DHCPv6 message, it extracts 1521 the DHCPv6 message and wraps it in IPv6/UDP headers. It sets the 1522 IPv6 source address to the source address of the RS message, sets the 1523 IPv6 destination address to 'All_DHCP_Relay_Agents_and_Servers' and 1524 sets the UDP fields to values that will be understood by the DHCPv6 1525 server. 1527 The LDRA then wraps the message in a Relay-Forward message header and 1528 includes an Interface-ID option that includes enough information to 1529 allow the LDRA to forward the resulting Reply message back to the 1530 Client (e.g., the Client's link-layer addresses, a security 1531 association identifier, etc). The LDRA also wraps the information in 1532 all of the SLLAO options from the RS message into the Interface-ID 1533 option, then forwards the message to the DHCPv6 server. 1535 When the DHCPv6 server prepares a Reply message, it wraps the message 1536 in a Relay-Reply message and echoes the Interface-ID option. The 1537 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1538 which discards the Relay-Reply wrapper and IPv6/UDP headers, then 1539 delivers the DHCPv6 message to be wrapped into an RA response to the 1540 Client. The Server uses the information in the Interface ID option 1541 to prepare the RA message and to cache the link-layer addresses taken 1542 from the SLLAOs echoed in the Interface-ID option. 1544 3.15. AERO Interface Route Optimization 1546 When a source Client forwards packets to a prospective correspondent 1547 Client within the same AERO link domain (i.e., one for which the 1548 packet's destination address is covered by an ASP), the source Client 1549 MAY initiate an AERO link route optimization procedure. The 1550 procedure is based on an exchange of IPv6 ND messages using a chain 1551 of AERO Servers and Relays as a trust basis. 1553 Although the Client is responsible for initiating route optimization, 1554 the Server is the policy enforcement point that determines whether 1555 route optimization is permitted. For example, on some AERO links 1556 route optimization would allow traffic to circumvent critical 1557 network-based traffic inspection points. In those cases, the Server 1558 can simply discard any route optimization messages instead of 1559 forwarding them. 1561 The following sections specify the AERO link route optimization 1562 procedure. 1564 3.15.1. Reference Operational Scenario 1566 Figure 4 depicts the AERO link route optimization reference 1567 operational scenario, using IPv6 addressing as the example (while not 1568 shown, a corresponding example for IPv4 addressing can be easily 1569 constructed). The figure shows an AERO Relay ('R1'), two AERO 1570 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1571 IPv6 hosts ('H1', 'H2'): 1573 +--------------+ +--------------+ +--------------+ 1574 | Server S1 | | Relay R1 | | Server S2 | 1575 +--------------+ +--------------+ +--------------+ 1576 fe80::2 fe80::1 fe80::3 1577 L2(S1) L2(R1) L2(S2) 1578 | | | 1579 X-----+-----+------------------+-----------------+----+----X 1580 | AERO Link | 1581 L2(C1) L2(C2) 1582 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1583 +--------------+ +--------------+ 1584 |AERO Client C1| |AERO Client C2| 1585 +--------------+ +--------------+ 1586 2001:DB8:0::/48 2001:DB8:1::/48 1587 | | 1588 .-. .-. 1589 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1590 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 1591 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 1592 `-(______)-' +-------+ +-------+ `-(______)-' 1594 Figure 4: AERO Reference Operational Scenario 1596 In Figure 4, Relay ('R1') assigns the administratively-provisioned 1597 link-local address fe80::1 to its AERO interface with link-layer 1598 address L2(R1), Server ('S1') assigns the address fe80::2 with link- 1599 layer address L2(S1),and Server ('S2') assigns the address fe80::3 1600 with link-layer address L2(S2). Servers ('S1') and ('S2') next 1601 arrange to add their link-layer addresses to a published list of 1602 valid Servers for the AERO link. 1604 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1605 exchange via AERO Server ('S1') then assigns the address 1606 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1607 L2(C1). Client ('C1') configures a default route and neighbor cache 1608 entry via the AERO interface with next-hop address fe80::2 and link- 1609 layer address L2(S1), then sub-delegates the ACP to its attached 1610 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1611 address 2001:db8:0::1. 1613 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1614 exchange via AERO Server ('S2') then assigns the address 1615 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1616 L2(C2). Client ('C2') configures a default route and neighbor cache 1617 entry via the AERO interface with next-hop address fe80::3 and link- 1618 layer address L2(S2), then sub-delegates the ACP to its attached 1619 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1620 address 2001:db8:1::1. 1622 3.15.2. Concept of Operations 1624 Again, with reference to Figure 4, when source host ('H1') sends a 1625 packet to destination host ('H2'), the packet is first forwarded over 1626 the source host's attached EUN to Client ('C1'). Client ('C1') then 1627 forwards the packet via its AERO interface to Server ('S1') and also 1628 sends an NS message toward Client ('C2') via Server ('S1'). If 1629 Client ('C1') requires AERO link trust anchors to verify the route 1630 optimization, it sets the V bit in the first SLLAO in the NS message 1631 to '1'; otherwise, it sets V to '0'. 1633 Server ('S1') then re-encapsulates and forwards both the packet and 1634 the NS message out the same AERO interface toward Client ('C2') via 1635 Relay ('R1'). When Relay ('R1') receives the packet and NS message, 1636 it consults its forwarding table to discover Server ('S2') as the 1637 next hop toward Client ('C2'). Relay ('R1') then forwards both the 1638 packet and the NS message to Server ('S2'), which then forwards them 1639 to Client ('C2'). 1641 After Client ('C2') receives the NS message, it process the message 1642 and creates or updates a dynamic neighbor cache entry for Client 1643 ('C1'). Client ('C2') then examies the V bit in the first SLLAO in 1644 the NS message. If the V bit is 0 Client ('C2') sends an NA response 1645 message directly to the link-layer address of Client ('C1') as found 1646 in the first SLLAO in the NS message; otherwise, Client ('C2') sends 1647 the NA response to the link-layer address of Server ('S2'). In the 1648 latter case, when Server ('S2') receives the NA message it re- 1649 encapsulates the message and forwards it on to Relay ('R1'), which 1650 re-encapsulates and forwards the message on to Server ('S1') which 1651 re-encapsulates and forwards the message on to Client ('C1'). 1653 After Client ('C1') receives the NA message, it processes the message 1654 and creates or updates a dynamic neighbor cache entry for Client 1655 ('C2'). Thereafter, forwarding of packets from Client ('C1') to 1656 Client ('C2') without involving any intermediate nodes is enabled. 1657 The mechanisms that support this exchange are specified in the 1658 following sections. 1660 3.15.3. Sending NS Messages 1662 When a Client forwards a packet with a source address from one of its 1663 ACPs toward a destination address covered by an ASP (i.e., toward 1664 another AERO Client connected to the same AERO link), the source 1665 Client MAY send an NS message forward toward the destination Client 1666 via the Server. 1668 In the reference operational scenario, when Client ('C1') forwards a 1669 packet toward Client ('C2'), it MAY also send an NS message forward 1670 toward Client ('C2'), subject to rate limiting (see Section 8.2 of 1671 [RFC4861]). Client ('C1') prepares the NS message as follows: 1673 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1674 layer address of Client ('C1')). 1676 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1677 link-layer address of Server ('S1')). 1679 o the network-layer source address is set to fe80::2001:db8:0:0 1680 (i.e., the base AERO address of Client ('C1')). 1682 o the network-layer destination address is set to the AERO address 1683 corresponding to the destination address of Client ('C2'). 1685 o the Type is set to 135. 1687 o the Target Address is set to the destination address of the packet 1688 that triggered route optimization. 1690 o the message includes one or more SLLAOs set to appropriate values 1691 for Client ('C1')'s underlying interfaces. The V bit in the first 1692 SLLAO is set to 1 if the recipient is required to send the NA 1693 reply via the reverse chain of Servers and Relays. 1695 o the message includes one or more RIOs that include Client ('C1')'s 1696 ACPs [I-D.templin-6man-rio-redirect]. 1698 o the message SHOULD include a Timestamp option and a Nonce option. 1700 Note that the act of sending NS messages is cited as "MAY", since 1701 Client ('C1') may have advanced knowledge that the direct path to 1702 Client ('C2') would be unusable or otherwise undesirable. If the 1703 direct path later becomes unusable after the initial route 1704 optimization, Client ('C1') simply allows packets to again flow 1705 through Server ('S1'). 1707 3.15.4. Re-encapsulating and Relaying the NS 1709 When Server ('S1') receives an NS message from Client ('C1'), it 1710 first verifies that the SLLAOs in the NS are a proper subset of the 1711 link-layer addresses in Client ('C1')'s neighbor cache entry. If the 1712 Client's SLLAOs are not acceptable, Server ('S1') discards the 1713 message. Otherwise, Server ('S1') verifies that Client ('C1') is 1714 authorized to use the ACPs encoded in the RIOs of the NS. If 1715 validation fails, Server ('S1') discards the NS; otherwise, it copies 1716 the correct UDP Port number and IP Address for Client ('C1')'s 1717 underlying link into the first SLLAO in case the addresses have been 1718 subject to NAT. 1720 Server ('S1') then examines the network-layer destination address of 1721 the NS to determine the next hop toward Client ('C2') by searching 1722 for the AERO address in the neighbor cache. Since Client ('C2') is 1723 not one of its neighbors, Server ('S1') re-encapsulates the NS and 1724 relays it via Relay ('R1') by changing the link-layer source address 1725 of the message to 'L2(S1)' and changing the link-layer destination 1726 address to 'L2(R1)'. Server ('S1') finally forwards the re- 1727 encapsulated message to Relay ('R1') without decrementing the 1728 network-layer TTL/Hop Limit field. 1730 When Relay ('R1') receives the NS message from Server ('S1') it 1731 determines that Server ('S2') is the next hop toward Client ('C2') by 1732 consulting its forwarding table. Relay ('R1') then re-encapsulates 1733 the NS while changing the link-layer source address to 'L2(R1)' and 1734 changing the link-layer destination address to 'L2(S2)'. Relay 1735 ('R1') then relays the NS via Server ('S2'). 1737 When Server ('S2') receives the NS message from Relay ('R1') it 1738 determines that Client ('C2') is a neighbor by consulting its 1739 neighbor cache. Server ('S2') then re-encapsulates the NS while 1740 changing the link-layer source address to 'L2(S2)' and changing the 1741 link-layer destination address to 'L2(C2)'. Server ('S2') then 1742 forwards the message to Client ('C2'). 1744 3.15.5. Processing NSs and Sending NAs 1746 When Client ('C2') receives the NS message, it accepts the NS only if 1747 the message has a link-layer source address of one of its Servers 1748 (e.g., L2(S2)). Client ('C2') further accepts the message only if it 1749 is willing to serve as a route optimization target. 1751 In the reference operational scenario, when Client ('C2') receives a 1752 valid NS message, it either creates or updates a dynamic neighbor 1753 cache entry that stores the source address of the message as the 1754 network-layer address of Client ('C1') , stores the link-layer 1755 addresses found in the SLLAOs as the link-layer addresses of Client 1756 ('C1'), and stores the ACPs encoded in the RIOs of the NS as the ACPs 1757 for Client ('C1'). Client ('C2') then sets AcceptTime for the 1758 neighbor cache entry to ACCEPT_TIME. 1760 After processing the message, Client ('C2') prepares an NA message 1761 response as follows: 1763 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1764 layer address of Client ('C2')). 1766 o the network-layer source address is set to fe80::2001:db8:1:0 1767 (i.e., the base AERO address of Client ('C2')). 1769 o the network-layer destination address is set to fe80::2001:db8:0:0 1770 (i.e., the base AERO address of Client ('C1')). 1772 o the Type is set to 136. 1774 o The Target Addrress is set to the Target Address field in the NS 1775 message. 1777 o the message includes one or more TLLAOs set to appropriate values 1778 for Client ('C2')'s underlying interfaces. 1780 o the message includes one or more RIOs that include Client ('C2')'s 1781 ACPs [I-D.templin-6man-rio-redirect]. 1783 o the message SHOULD include a Timestamp option and MUST echo the 1784 Nonce option received in the NS (i.e., if a Nonce option is 1785 included). 1787 If the V bit in the first SLLAO in the NS message was set to 1, 1788 Client ('C2') then sets the link-layer destination address to 1789 'L2(S2)' (i.e., the link-layer address of Server ('S2')) and sends 1790 the NA message to Server ('S2'). Otherwise, Client ('C2') sets the 1791 link-layer destination address to the address found in the first 1792 SLLAO in the NS message and sends the NA message directly to Client 1793 ('C1'), which processes the message according to Section 3.15.7. 1795 3.15.6. Re-encapsulating and Relaying NAs 1797 When Server ('S2') receives an NA message from Client ('C2'), it 1798 first verifies that the TLLAOs in the NA are a proper subset of the 1799 Interface IDs in Client ('C2')'s neighbor cache entry. If the 1800 Client's TLLAOs are not acceptable, Server ('S2') discards the 1801 message. Otherwise, Server ('S2') verifies that Client ('C2') is 1802 authorized to use the ACPs encoded in the RIOs of the NA message. If 1803 validation fails, Server ('S2') discards the NA. 1805 Server ('S2') then examines the network-layer destination address of 1806 the NA to determine the next hop toward Client ('C1') by searching 1807 for the AERO address in the neighbor cache. Since Client ('C1') is 1808 not a neighbor, Server ('S2') re-encapsulates the NA and relays it 1809 via Relay ('R1') by changing the link-layer source address of the 1810 message to 'L2(S2)' and changing the link-layer destination address 1811 to 'L2(R1)'. Server ('S2') finally forwards the re-encapsulated 1812 message to Relay ('R1') without decrementing the network-layer TTL/ 1813 Hop Limit field. 1815 When Relay ('R1') receives the NA message from Server ('S2') it 1816 determines that Server ('S1') is the next hop toward Client ('C1') by 1817 consulting its forwarding table. Relay ('R1') then re-encapsulates 1818 the NA while changing the link-layer source address to 'L2(R1)' and 1819 changing the link-layer destination address to 'L2(S1)'. Relay 1820 ('R1') then relays the NA via Server ('S1'). 1822 When Server ('S1') receives the NA message from Relay ('R1') it 1823 determines that Client ('C1') is a neighbor by consulting its 1824 neighbor cache. Server ('S1') then re-encapsulates the NA while 1825 changing the link-layer source address to 'L2(S1)' and changing the 1826 link-layer destination address to 'L2(C1)'. Server ('S1') then 1827 forwards the message to Client ('C1'). 1829 3.15.7. Processing NAs 1831 When Client ('C1') receives the NA message, if it had sent the 1832 corresponding NS message with the V bit in the first SLLAO set to 1 1833 it accepts the message only if it has a link-layer source address of 1834 one of its Servers (e.g., 'L2(S1)') (otherwise, Client ('C') accepts 1835 the message unconditionally). Client ('C1') then processes the 1836 message as follows. 1838 In the reference operational scenario, when Client ('C1') receives 1839 the NA message, it either creates or updates a dynamic neighbor cache 1840 entry that stores the source address of the message as the network- 1841 layer address of Client ('C2'), stores the link-layer addresses found 1842 in the TLLAOs as the link-layer addresses of Client ('C2') and stores 1843 the ACPs encoded in the RIOs of the NA as the ACPs for Client ('C2'). 1844 Client ('C1') then sets ForwardTime for the neighbor cache entry to 1845 FORWARD_TIME. 1847 Now, Client ('C1') has a neighbor cache entry with a valid 1848 ForwardTime value, while Client ('C2') has a neighbor cache entry 1849 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 1850 ordinary network-layer data packets directly to Client ('C2') without 1851 involving any intermediate nodes, and Client ('C2') can verify that 1852 the packets came from an acceptable source. (In order for Client 1853 ('C2') to forward packets to Client ('C1'), a corresponding NS/NA 1854 message exchange is required in the reverse direction; hence, the 1855 mechanism is asymmetric.) 1857 3.15.8. Server-to-Client and Client-to-Server Route Optimization 1859 In some environments, the Server nearest the target Client may need 1860 to serve as a route optimization target, e.g., if direct Client-to- 1861 Client communications are not possible. In that case, when the 1862 source Client sends an NS message the target Server prepares a 1863 corresponding NA the same as if it were the target Client (see: 1864 Section 3.15.5), except that it writes its own link-layer address in 1865 the TLLAO option. The Server must then maintain a dynamic neighbor 1866 cache entry for the source Client. 1868 Similarly, when the source Client must send all packets via its own 1869 Server and cannot act on a route optimization request, the source 1870 Server can send an NS message toward the target Client. The target 1871 Client then prepares a corresponding NA message the same as for 1872 Client-to-Client route optimization and sends the NA message back to 1873 the source Server. 1875 Thereafter, if the target Client moves to a new Server, the old 1876 Server sends unsolicited NA messages with no TLLAOs (subject to rate 1877 limiting) in response to data packets received from a correspondent 1878 node while forwarding the packets themselves to a Relay. The Relay 1879 will then either forward the packets to the new Server if the target 1880 Client has moved, or drop the packets if the target Client is no 1881 longer in the network. The source Client (or Server) then allows 1882 future packets destined to the target Client to again flow through 1883 its own Server (or Relay). Note however that the old Server retains 1884 the neighbor cache entry with its associated AcceptTime since there 1885 may be many packets in flight. When the old Server receives these 1886 packets, it forwards them to a Relay which will forward them to the 1887 departed Client's new Server. AcceptTime will then eventually 1888 decrement to 0 once the correspondent node processes and acts on the 1889 unsolicited NAs. 1891 In any case, a Server MUST NOT send a BGP update to its Relays for 1892 Clients discovered through dynamic route optimization. BGP updates 1893 are only to be sent for the Server's working set of statically- 1894 associated Clients. 1896 3.15.9. Server-to-Server Route Optimization 1898 If neither the source nor target Clients are capable of sending 1899 packets other than via their own Servers, a Server-to-Server route 1900 optimization can still be employed. In that case, the source 1901 Client's Server can send an NS message via a Relay to the AERO 1902 address of the target Client, and the Relay will forward the message 1903 to the target Client's Server. The target Server prepares the NA 1904 message the same as if it were the target Client, except that it 1905 writes its own link-layer address in the TLLAO option then sends the 1906 NA back to the source Server. (The target Server can send the NA 1907 message back to the source Server either directly or via the Relay 1908 according to the SLLAO V bit as above.) 1909 Thereafter, if the target Client moves to a new Server, the old 1910 Server sends unsolicited NA messages with no TLLAOs (subject to rate 1911 limiting) in response to data packets received from a correspondent 1912 node while forwarding the packets themselves to a Relay. The Relay 1913 will then either forward the packets to the new Server if the target 1914 Client has moved, or drop the packets if the target Client is no 1915 longer in the network. The source Server then allows future packets 1916 destined to the target Client to again flow through a Relay. Note 1917 however that the old Server retains the neighbor cache entry with its 1918 associated AcceptTime since there may be many packets in flight. 1919 When the old Server receives these packets, it forwards them to a 1920 Relay which will forward them to the departed Client's new Server. 1921 AcceptTime will then eventually decrement to 0 once the correspondent 1922 node processes and acts on the unsolicited NAs. 1924 In any case, a Server MUST NOT send a BGP update to its Relays for 1925 correspondents discovered through dynamic route optimization. BGP 1926 updates are only to be sent for the Server's working set of 1927 statically-associated Clients. 1929 3.16. Neighbor Unreachability Detection (NUD) 1931 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1932 unicast NS messages to elicit solicited NA messages from neighbors 1933 the same as described in [RFC4861]. NUD is performed either 1934 reactively in response to persistent L2 errors (see Section 3.13) or 1935 proactively to update neighbor cache entry timers and/or link-layer 1936 address information. 1938 When an AERO node sends an NS/NA message, it uses one of its link- 1939 local addresses as the IPv6 source address and a link-local address 1940 of the neighbor as the IPv6 destination address. When an AERO node 1941 receives an NS message or a solicited NA message, it accepts the 1942 message if it has a neighbor cache entry for the neighbor; otherwise, 1943 it ignores the message. 1945 When route optimization directs a source AERO node to a target AERO 1946 node, the source node SHOULD proactively test the direct path by 1947 sending an initial NS message to elicit a solicited NA response. 1948 While testing the path, the source node can optionally continue 1949 sending packets via its default router, maintain a small queue of 1950 packets until target reachability is confirmed, or (optimistically) 1951 allow packets to flow directly to the target. 1953 While data packets are still flowing, the source node thereafter 1954 periodically tests the direct path to the target node (see 1955 Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache 1956 entries alive. When the target node receives a valid NS message, it 1957 resets AcceptTime to ACCEPT_TIME and updates its cached link-layer 1958 addresses (if necessary). When the source node receives a solicited 1959 NA message, it resets ForwardTime to FORWARD_TIME and updates its 1960 cached link-layer addresses (if necessary). If the source node is 1961 unable to elicit a solicited NA response from the target node after 1962 MaxRetry attempts, it SHOULD set ForwardTime to 0. Otherwise, the 1963 source node considers the path usable and SHOULD thereafter process 1964 any link-layer errors as a hint that the direct path to the target 1965 node has either failed or has become intermittent. 1967 When ForwardTime for a dynamic neighbor cache entry expires, the 1968 source node resumes sending any subsequent packets via a Server (or 1969 Relay) and may (eventually) attempt to re-initiate the AERO route 1970 optimization process. When AcceptTime for a dynamic neighbor cache 1971 entry expires, the target node discards any subsequent packets 1972 received directly from the source node. When both ForwardTime and 1973 AcceptTime for a dynamic neighbor cache entry expire, the node 1974 deletes the neighbor cache entry. 1976 Note that an AERO node may have multiple underlying interface paths 1977 toward the target neighbor. In that case, the node SHOULD perform 1978 NUD over each underlying interface and only consider the neighbor 1979 unreachable if NUD fails over all underlying interface paths. 1981 3.17. Mobility Management and Quality of Service (QoS) 1983 3.17.1. Forwarding Packets on Behalf of Departed Clients 1985 When a Server receives packets with destination addresses that do not 1986 match one of its static neighbor cache Clients, it forwards the 1987 packets packets to a Relay and also returns an unsolicited NA message 1988 to the sender with no TLLAOs. The packets will be delivered to the 1989 target Client's new location, and the sender will realize that it 1990 needs to deprecate its routing inforrmation that associated the 1991 target with this Server. 1993 3.17.2. Announcing Link-Layer Address and QoS Preference Changes 1995 When a Client needs to change its link-layer addresses, e.g., due to 1996 a mobility event, it sends unsolicited NAs to its neighbors using the 1997 new link-layer address as the source address and with TLLAOs that 1998 include the new Client UDP Port Numer, IP Address and P(i) values. 1999 If the Client sends the NA solely for the purpose of updating QoS 2000 preferences without updating the link-layer address, the Client sets 2001 the UDP Port Number and IP Address to 0. 2003 The Client MAY send up to MaxRetry unsolicited NA messages in 2004 parallel with sending actual data packets in case one or more NAs are 2005 lost. If all NAs are lost, the Client will eventually invoke NUD by 2006 sending NS messages that include SLLAOs. 2008 3.17.3. Bringing New Links Into Service 2010 When a Client needs to bring new underlying interfaces into service 2011 (e.g., when it activates a new data link), it sends unsolicited NAs 2012 to its neighbors using the new link-layer address as the source 2013 address and with TLLAOs that include the new Client link-layer 2014 information. 2016 3.17.4. Removing Existing Links from Service 2018 When a Client needs to remove existing underlying interfaces from 2019 service (e.g., when it de-activates an existing data link), it sends 2020 unsolicited NAs to its neighbors with TLLAOs with all P(i) values set 2021 to 0. 2023 If the Client needs to send the unsolicited NAs over an underlying 2024 interface other than the one being removed from service, it MUST 2025 include a current TLLAO for the sending interface as the first TLLAO 2026 and include TLLAOs for any underlying interface being removed from 2027 service as additional TLLAOs. 2029 3.17.5. Implicit Mobility Management 2031 AERO interface neighbors MAY provide a configuration option that 2032 allows them to perform implicit mobility management in which no IPv6 2033 ND messaging is used. In that case, the Client only transmits 2034 packets over a single interface at a time, and the neighbor always 2035 observes packets arriving from the Client from the same link-layer 2036 source address. 2038 If the Client's underlying interface address changes (either due to a 2039 readdressing of the original interface or switching to a new 2040 interface) the neighbor immediately updates the neighbor cache entry 2041 for the Client and begins accepting and sending packets to the 2042 Client's new link-layer address. This implicit mobility method 2043 applies to use cases such as cellphones with both WiFi and Cellular 2044 interfaces where only one of the interfaces is active at a given 2045 time, and the Client automatically switches over to the backup 2046 interface if the primary interface fails. 2048 3.17.6. Moving to a New Server 2050 When a Client associates with a new Server, it performs the Client 2051 procedures specified in Section 3.14.2. 2053 When a Client disassociates with an existing Server, it sends a 2054 DHCPv6 Release message via a new Server with its base AERO address as 2055 the network-layer source address and the (administratively- 2056 provisioned) unicast link-local address of the old Server as the 2057 network-layer destination address. The new Server then encapsulates 2058 the Release message in a DHCPv6 Relay-Forward message header, writes 2059 the Client's source address in the 'peer-address' field, and writes 2060 its own link-local address in the IP source address (i.e., the new 2061 Server acts as a DHCPv6 relay agent). The new Server then forwards 2062 the message to a Relay, which forwards the message to the old Server. 2064 When the old Server receives the Release, it releases the DHCPv6 PDs 2065 and deletes the Client's ACP routes. The old Server then deletes the 2066 Client's neighbor cache entry so that any in-flight packets will be 2067 forwarded via a Relay to the new Server, which will forward them to 2068 the Client. The old Server finally returns a DHCPv6 Relay-Reply 2069 message via a Relay to the new Server, which will decapsulate the 2070 DHCPv6 Reply message and forward it to the Client. 2072 When the new Server forwards the Reply message, the Client can delete 2073 both the default route and the neighbor cache entry for the old 2074 Server. (Note that since Release/Reply messages may be lost in the 2075 network the Client SHOULD retry until it gets a Reply indicating that 2076 the Release was successful. If the Client does not receive a Reply 2077 after MaxRetry attempts, the old Server may have failed and the 2078 Client should discontinue its Release attempts.) 2080 Note that this DHCPv6 relay-chaining approach is provided to avoid 2081 failures, e.g., due to temporary routing fluctuations. In 2082 particular, the Client should always be able to forward messages via 2083 its new Server but may not always be able to send messages directly 2084 to an old Server. But, the new Server and Old Server should always 2085 be able to exchange messages with one another. 2087 Finally, Clients SHOULD NOT move rapidly between Servers in order to 2088 avoid causing excessive oscillations in the AERO routing system. 2089 Such oscillations could result in intermittent reachability for the 2090 Client itself, while causing little harm to the network. Examples of 2091 when a Client might wish to change to a different Server include a 2092 Server that has gone unreachable, topological movements of 2093 significant distance, etc. 2095 3.17.7. Packet Queueing for Mobility 2097 AERO Clients and Servers should maintain a small queue of packets 2098 they have recently sent to an AERO neighbor, e.g., a 1 second window. 2099 If the AERO neighbor moves, the AERO node MAY retransmit the queued 2100 packets to ensure that they are delivered to the AERO neighbor's new 2101 location. 2103 Note that this may have performance implications for asymmetric 2104 paths. For example, if the AERO neighbor moves from a 50Mbps link to 2105 a 128Kbps link, retransmitting a 1 second window could cause 2106 significant congestion. However, any retransmission bursts will 2107 subside after the 1 second window. 2109 3.18. Multicast Considerations 2111 When the underlying network does not support multicast, AERO Clients 2112 map link-scoped multicast addresses to the link-layer address of a 2113 Server, which acts as a multicast forwarding agent. The AERO Client 2114 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2115 applications per [RFC4605] while using the link-layer address of the 2116 Server as the link-layer address for all multicast packets. 2118 When the underlying network supports multicast, AERO nodes use the 2119 multicast address mapping specification found in [RFC2529] for IPv4 2120 underlying networks and use a TBD site-scoped multicast mapping for 2121 IPv6 underlying networks. In that case, border routers must ensure 2122 that the encapsulated site-scoped multicast packets do not leak 2123 outside of the site spanned by the AERO link. 2125 4. The AERO Proxy 2127 In some environments, AERO Clients may be located in secured enclaves 2128 (e.g., a corporate enterprise network, a radio access network, etc.) 2129 that do not allow direct communications from the Client to a Server 2130 in the outside world. In that case, the secured enclave can emply an 2131 AERO Proxy. 2133 The AERO Proxy is located at the secured enclave perimeter and 2134 listens for RS/DHCPv6 messages originating from or RA/DHCPv6 messages 2135 destined to AERO Clients located within the enclave. The Proxy acts 2136 on these control messages as follows: 2138 o when the Proxy receives an RS/DHCPv6 message from a Client within 2139 the secured enclave, it creates a proxy neighbor cache entry for 2140 the Client in the INCOMPLETE State and caches the Client and 2141 Server link-layer address information. The Proxy then forwards 2142 the message to the external Server indicated by the destination 2143 link-layer address in the packet while substituting its own 2144 external address as the source link-layer address. 2146 o when the Proxy receives an RA/DHCPv6 message from an external 2147 Server, it matches the RA message with the (incomplete) proxy 2148 neighbor cache entry. The Proxy then caches the route information 2149 in the message as a mapping from the Client's ACPs to the Client's 2150 address within the secured enclave, and sets the neighbor cache 2151 entry state to REACHABLE. The Proxy then forwards the message to 2152 the Client. 2154 After the initial RS/DHCPv6 - RA/DHCPv6 handshake is concluded, the 2155 Proxy can send unsolicited NA messages to the Client's chosen Servers 2156 as-needed to update the Servers' neighbor cache entries on behalf of 2157 the Client. (For example, the Proxy can send NA messages with a 2158 TLLAO with UDP Port Number and IP Address set to 0 and with valid 2159 P(i) values to update the Client's QoS preferences for that link). 2160 The Proxy also forwards all data packets originating from the Client 2161 to one of its chosen Servers. At the same time, for destination 2162 addresses that match an ASP the Proxy can initiate route optimization 2163 by sending an NS message via the Server to solicit an NA message from 2164 a Server that is currently serving the target Client (or from the 2165 target Client itself). When the Proxy receives the NA message, it 2166 creates a dynamic neighbor cache entry in the FORWARD state that 2167 associates the source of the NA message as the next-hop toward the 2168 routes adveritsed in the NA RIOs. 2170 From the perspective of the target, the Proxy that sent the route 2171 optimization NS message will appear as if it is an ordinary AERO 2172 Client. However, the target must deliver the NA message directly to 2173 the Proxy (i.e., instead of relaying through the backward chain of 2174 Relays and Servers) since the backwards chain could deliver the NA to 2175 a different Proxy besides the one that produced the NS. For this 2176 reason, the Proxy sets the V bit in the first SLLAO in the NS message 2177 to 0. 2179 After the NS/NA exchange, the Proxy may receive unsolicited NA 2180 messages without TLLAOs from the target in response to data packets 2181 destined to a departed Client. In that case, the Proxy deletes the 2182 routes associated with the target and allows future packets to flow 2183 through the source Server, and can then re-initialize route 2184 optimization as above. 2186 After the NS/NA exchange, the Proxy may receive link-layer error 2187 messages in response to data packets destined to the target. In that 2188 case, the Proxy processes the link-layer error messages as a hint 2189 that the path to the target may be failing as discussed in 2190 Section 3.13. 2192 5. Operation on AERO Links with /64 ASPs 2194 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2195 length /64 or shorter. However, in some cases it may be desirable to 2196 use AERO over links that have only a /64 ASP. This can be 2197 accommodated by treating all Clients on the AERO link as simple hosts 2198 that receive /128 prefix delegations. 2200 In that case, the Client sends an RS/DHCPv6 PD message to the Server 2201 the same as for ordinary AERO links. The Server responds with an RA/ 2202 DHCPv6 message that includes one or more /128 prefixes (i.e., 2203 singleton addresses) that include the /64 ASP prefix along with an 2204 interface identifier portion to be assigned to the Client. The 2205 Client and Server then configure their AERO addresses based on the 2206 interface identifier portions of the /128s (i.e., the lower 64 bits) 2207 and not based on the /64 prefix (i.e., the upper 64 bits). 2209 For example, if the ASP for the host-only IPv6 AERO link is 2210 2001:db8:1000:2000::/64, each Client will receive one or more /128 2211 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2212 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2213 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2214 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2215 /128s) to either the AERO interface or an internal virtual interface 2216 such as a loopback. In this arrangement, the Client conducts route 2217 optimization in the same sense as discussed in Section 3.15. 2219 This specification has applicability for nodes that act as a Client 2220 on an "upstream" AERO link, but also act as a Server on "downstream" 2221 AERO links. More specifically, if the node acts as a Client to 2222 receive a /64 prefix from the upstream AERO link it can then act as a 2223 Server to provision /128s to Clients on downstream AERO links. 2225 6. Implementation Status 2227 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2228 announced on the v6ops mailing list on January 10, 2018. The latest 2229 version is available at: http://linkupnetworks.net/aero/AERO-OpenVPN- 2230 1.0.tgz. 2232 An initial public release of the AERO proof-of-concept source code 2233 was announced on the intarea mailing list on August 21, 2015. The 2234 latest version is available at: http://linkupnetworks.net/aero/aero- 2235 3.0.3a.tgz. 2237 7. IANA Considerations 2239 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2240 AERO in the "enterprise-numbers" registry. 2242 The IANA has assigned the UDP port number "8060" for an earlier 2243 experimental version of AERO [RFC6706]. This document obsoletes 2244 [RFC6706] and claims the UDP port number "8060" for all future use. 2246 No further IANA actions are required. 2248 8. Security Considerations 2250 AERO link security considerations are the same as for standard IPv6 2251 Neighbor Discovery [RFC4861] except that AERO improves on some 2252 aspects. In particular, AERO uses a trust basis between Clients and 2253 Servers, where the Clients only engage in the AERO mechanism when it 2254 is facilitated by a trusted Server. 2256 NS and NA messages SHOULD include a Timestamp option (see Section 5.3 2257 of [RFC3971]) that other AERO nodes can use to verify the message 2258 time of origin. NS and RS messages SHOULD include a Nonce option 2259 (see Section 5.3 of [RFC3971]) that recipients echo back in 2260 corresponding responses. In cases where spoofing cannot be mitigated 2261 through other means, however, all AERO IPv6 ND messages should employ 2262 SEND [RFC3971], which also protects the DHCPv6 information embedded 2263 in RS/RA message options. 2265 AERO links must be protected against link-layer address spoofing 2266 attacks in which an attacker on the link pretends to be a trusted 2267 neighbor. Links that provide link-layer securing mechanisms (e.g., 2268 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2269 enterprise network wired LANs) provide a first line of defense, 2270 however AERO nodes SHOULD also use securing services such as SEND for 2271 Client authentication and network admission control. Following 2272 authenticated Client admission and prefix delgation procedures, AERO 2273 nodes MUST ensure that the source of data packets corresponds to the 2274 node to which the prefixes were delegated. 2276 AERO Clients MUST ensure that their connectivity is not used by 2277 unauthorized nodes on their EUNs to gain access to a protected 2278 network, i.e., AERO Clients that act as routers MUST NOT provide 2279 routing services for unauthorized nodes. (This concern is no 2280 different than for ordinary hosts that receive an IP address 2281 delegation but then "share" the address with other nodes via some 2282 form of Internet connection sharing such as tethering.) 2283 AERO Clients, Servers and Relays on the open Internet are susceptible 2284 to the same attack profiles as for any Internet nodes. For this 2285 reason, IP security SHOULD be used when AERO is employed over 2286 unmanaged/unsecured links using securing mechanisms such as IPsec 2287 [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, 2288 however, the use of end-to-end security from Clients to correspondent 2289 nodes (i.e., other Clients and/or Internet nodes) could obviate the 2290 need for IP security between AERO Clients, Servers and Relays. 2292 AERO Servers and Relays present targets for traffic amplification DoS 2293 attacks. This concern is no different than for widely-deployed VPN 2294 security gateways in the Internet, where attackers could send spoofed 2295 packets to the gateways at high data rates. This can be mitigated by 2296 connecting Relays and Servers over dedicated links with no 2297 connections to the Internet and/or when connections to the Internet 2298 are only permitted through well-managed firewalls. 2300 Traffic amplification DoS attacks can also target an AERO Client's 2301 low data rate links. This is a concern not only for Clients located 2302 on the open Internet but also for Clients in secured enclaves. AERO 2303 Servers can institute rate limits that protect Clients from receiving 2304 packet floods that could DoS low data rate links. 2306 9. Acknowledgements 2308 Discussions both on IETF lists and in private exchanges helped shape 2309 some of the concepts in this work. Individuals who contributed 2310 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, Bob 2311 Braden, Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, 2312 Adrian Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom 2313 Herbert, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy 2314 Malis, Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2315 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa, Lloyd Wood and James 2316 Woodyatt. Members of the IESG also provided valuable input during 2317 their review process that greatly improved the document. Discussions 2318 on the v6ops list in the December 2015 through January 2016 timeframe 2319 further helped clarify AERO multi-addressing capabilities. Special 2320 thanks go to Stewart Bryant, Joel Halpern and Brian Haberman for 2321 their shepherding guidance during the publication of the AERO first 2322 edition. 2324 This work has further been encouraged and supported by Boeing 2325 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2326 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2327 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gene 2328 MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian 2329 Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie Wulff, 2330 Yueli Yang, Eric Yeh and other members of the BR&T and BIT mobile 2331 networking teams. Wayne Benson is especially acknowledged for 2332 converting the AERO proof-of-concept implementation into production- 2333 ready code for OpenVPN. 2335 Earlier works on NBMA tunneling approaches are found in 2336 [RFC2529][RFC5214][RFC5569]. 2338 Many of the constructs presented in this second edition of AERO are 2339 based on the author's earlier works, including: 2341 o The Internet Routing Overlay Network (IRON) 2342 [RFC6179][I-D.templin-ironbis] 2344 o Virtual Enterprise Traversal (VET) 2345 [RFC5558][I-D.templin-intarea-vet] 2347 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2348 [RFC5320][I-D.templin-intarea-seal] 2350 o AERO, First Edition [RFC6706] 2352 Note that these works cite numerous earlier efforts that are not also 2353 cited here due to space limitations. The authors of those earlier 2354 works are acknowledged for their insights. 2356 This work is aligned with the NASA Safe Autonomous Systems Operation 2357 (SASO) program under NASA contract number NNA16BD84C. 2359 This work is aligned with the FAA as per the SE2025 contract number 2360 DTFAWA-15-D-00030. 2362 This work is aligned with the Boeing Information Technology (BIT) 2363 MobileNet program. 2365 This work is aligned with the Boeing Research and Technology (BR&T) 2366 autonomous systems networking program. 2368 10. References 2370 10.1. Normative References 2372 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2373 DOI 10.17487/RFC0768, August 1980, 2374 . 2376 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2377 DOI 10.17487/RFC0791, September 1981, 2378 . 2380 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2381 RFC 792, DOI 10.17487/RFC0792, September 1981, 2382 . 2384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2385 Requirement Levels", BCP 14, RFC 2119, 2386 DOI 10.17487/RFC2119, March 1997, 2387 . 2389 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2390 "Definition of the Differentiated Services Field (DS 2391 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2392 DOI 10.17487/RFC2474, December 1998, 2393 . 2395 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2396 C., and M. Carney, "Dynamic Host Configuration Protocol 2397 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2398 2003, . 2400 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2401 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2402 DOI 10.17487/RFC3633, December 2003, 2403 . 2405 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2406 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2407 DOI 10.17487/RFC3971, March 2005, 2408 . 2410 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2411 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2412 November 2005, . 2414 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2415 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2416 DOI 10.17487/RFC4861, September 2007, 2417 . 2419 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2420 Address Autoconfiguration", RFC 4862, 2421 DOI 10.17487/RFC4862, September 2007, 2422 . 2424 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 2425 Advertisement Flags Option", RFC 5175, 2426 DOI 10.17487/RFC5175, March 2008, 2427 . 2429 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2430 (IPv6) Specification", STD 86, RFC 8200, 2431 DOI 10.17487/RFC8200, July 2017, 2432 . 2434 10.2. Informative References 2436 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2437 2016. 2439 [I-D.ietf-intarea-gue] 2440 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2441 Encapsulation", draft-ietf-intarea-gue-05 (work in 2442 progress), December 2017. 2444 [I-D.ietf-intarea-gue-extensions] 2445 Herbert, T., Yong, L., and F. Templin, "Extensions for 2446 Generic UDP Encapsulation", draft-ietf-intarea-gue- 2447 extensions-03 (work in progress), January 2018. 2449 [I-D.ietf-intarea-tunnels] 2450 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2451 Architecture", draft-ietf-intarea-tunnels-08 (work in 2452 progress), January 2018. 2454 [I-D.templin-6man-dhcpv6-ndopt] 2455 Templin, F., "The DHCPv6 Option for IPv6 Neighbor 2456 Discovery", draft-templin-6man-dhcpv6-ndopt-01 (work in 2457 progress), January 2018. 2459 [I-D.templin-6man-rio-redirect] 2460 Templin, F. and j. woodyatt, "Route Information Options in 2461 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2462 redirect-05 (work in progress), October 2017. 2464 [I-D.templin-intarea-grefrag] 2465 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2466 templin-intarea-grefrag-04 (work in progress), July 2016. 2468 [I-D.templin-intarea-seal] 2469 Templin, F., "The Subnetwork Encapsulation and Adaptation 2470 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2471 progress), January 2014. 2473 [I-D.templin-intarea-vet] 2474 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2475 templin-intarea-vet-40 (work in progress), May 2013. 2477 [I-D.templin-ironbis] 2478 Templin, F., "The Interior Routing Overlay Network 2479 (IRON)", draft-templin-ironbis-16 (work in progress), 2480 March 2014. 2482 [I-D.templin-v6ops-pdhost] 2483 Templin, F., "IPv6 Prefix Delegation Models", draft- 2484 templin-v6ops-pdhost-18 (work in progress), December 2017. 2486 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2488 [RFC1035] Mockapetris, P., "Domain names - implementation and 2489 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2490 November 1987, . 2492 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2493 Communication Layers", STD 3, RFC 1122, 2494 DOI 10.17487/RFC1122, October 1989, 2495 . 2497 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2498 DOI 10.17487/RFC1191, November 1990, 2499 . 2501 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2502 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2503 . 2505 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2506 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2507 1996, . 2509 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2510 DOI 10.17487/RFC2003, October 1996, 2511 . 2513 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2514 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2515 . 2517 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2518 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2519 December 1998, . 2521 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2522 Domains without Explicit Tunnels", RFC 2529, 2523 DOI 10.17487/RFC2529, March 1999, 2524 . 2526 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2527 Malis, "A Framework for IP Based Virtual Private 2528 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2529 . 2531 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2532 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2533 DOI 10.17487/RFC2784, March 2000, 2534 . 2536 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2537 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2538 . 2540 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2541 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2542 . 2544 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2545 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2546 . 2548 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2549 of Explicit Congestion Notification (ECN) to IP", 2550 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2551 . 2553 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2554 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2555 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2556 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2557 . 2559 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2560 for IPv6 Hosts and Routers", RFC 4213, 2561 DOI 10.17487/RFC4213, October 2005, 2562 . 2564 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2565 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2566 DOI 10.17487/RFC4271, January 2006, 2567 . 2569 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2570 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2571 2006, . 2573 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2574 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2575 December 2005, . 2577 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2578 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2579 2006, . 2581 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2582 Control Message Protocol (ICMPv6) for the Internet 2583 Protocol Version 6 (IPv6) Specification", STD 89, 2584 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2585 . 2587 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2588 Protocol (LDAP): The Protocol", RFC 4511, 2589 DOI 10.17487/RFC4511, June 2006, 2590 . 2592 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2593 "Internet Group Management Protocol (IGMP) / Multicast 2594 Listener Discovery (MLD)-Based Multicast Forwarding 2595 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2596 August 2006, . 2598 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2599 Errors at High Data Rates", RFC 4963, 2600 DOI 10.17487/RFC4963, July 2007, 2601 . 2603 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2604 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2605 DOI 10.17487/RFC5214, March 2008, 2606 . 2608 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2609 (TLS) Protocol Version 1.2", RFC 5246, 2610 DOI 10.17487/RFC5246, August 2008, 2611 . 2613 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2614 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2615 February 2010, . 2617 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2618 Route Optimization Requirements for Operational Use in 2619 Aeronautics and Space Exploration Mobile Networks", 2620 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2621 . 2623 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2624 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2625 . 2627 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2628 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2629 January 2010, . 2631 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2632 Global Enterprise Recursion (RANGER)", RFC 5720, 2633 DOI 10.17487/RFC5720, February 2010, 2634 . 2636 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2637 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2638 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2639 . 2641 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2642 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2643 . 2645 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2646 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2647 DOI 10.17487/RFC6221, May 2011, 2648 . 2650 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2651 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2652 . 2654 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2655 for Equal Cost Multipath Routing and Link Aggregation in 2656 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2657 . 2659 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2660 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2661 . 2663 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2664 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2665 . 2667 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2668 October 2014. 2670 Appendix A. AERO Alternate Encapsulations 2672 When GUE encapsulation is not needed, AERO can use common 2673 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2674 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2675 encapsulation is therefore only differentiated from non-AERO tunnels 2676 through the application of AERO control messaging and not through, 2677 e.g., a well-known UDP port number. 2679 As for GUE encapsulation, alternate AERO encapsulation formats may 2680 require encapsulation layer fragmentation. For simple IP-in-IP 2681 encapsulation, an IPv6 fragment header is inserted directly between 2682 the inner and outer IP headers when needed, i.e., even if the outer 2683 header is IPv4. The IPv6 Fragment Header is identified to the outer 2684 IP layer by its IP protocol number, and the Next Header field in the 2685 IPv6 Fragment Header identifies the inner IP header version. For GRE 2686 encapsulation, a GRE fragment header is inserted within the GRE 2687 header [I-D.templin-intarea-grefrag]. 2689 Figure 5 shows the AERO IP-in-IP encapsulation format before any 2690 fragmentation is applied: 2692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 | Outer IPv4 Header | | Outer IPv6 Header | 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | Inner IP Header | | Inner IP Header | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | | | | 2700 ~ ~ ~ ~ 2701 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2702 ~ ~ ~ ~ 2703 | | | | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2708 Figure 5: Minimal Encapsulation Format using IP-in-IP 2710 Figure 6 shows the AERO GRE encapsulation format before any 2711 fragmentation is applied: 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 | Outer IP Header | 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 | GRE Header | 2717 | (with checksum, key, etc..) | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | GRE Fragment Header (optional)| 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 | Inner IP Header | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | | 2724 ~ ~ 2725 ~ Inner Packet Body ~ 2726 ~ ~ 2727 | | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 Figure 6: Minimal Encapsulation Using GRE 2732 Alternate encapsulation may be preferred in environments where GUE 2733 encapsulation would add unnecessary overhead. For example, certain 2734 low-bandwidth wireless data links may benefit from a reduced 2735 encapsulation overhead. 2737 GUE encapsulation can traverse network paths that are inaccessible to 2738 non-UDP encapsulations, e.g., for crossing Network Address 2739 Translators (NATs). More and more, network middleboxes are also 2740 being configured to discard packets that include anything other than 2741 a well-known IP protocol such as UDP and TCP. It may therefore be 2742 necessary to determine the potential for middlebox filtering before 2743 enabling alternate encapsulation in a given environment. 2745 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2746 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 2747 messaging and route determination occur before security encapsulation 2748 is applied for outgoing packets and after security decapsulation is 2749 applied for incoming packets. 2751 AERO is especially well suited for use with VPN system encapsulations 2752 such as OpenVPN [OVPN]. 2754 Appendix B. When to Insert an Encapsulation Fragment Header 2756 An encapsulation fragment header is inserted when the AERO tunnel 2757 ingress needs to apply fragmentation to accommodate packets that must 2758 be delivered without loss due to a size restriction. Fragmentation 2759 is performed on the inner packet while encapsulating each inner 2760 packet fragment in outer IP and encapsulation layer headers that 2761 differ only in the fragment header fields. 2763 The fragment header can also be inserted in order to include a 2764 coherent Identification value with each packet, e.g., to aid in 2765 Duplicate Packet Detection (DPD). In this way, network nodes can 2766 cache the Identification values of recently-seen packets and use the 2767 cached values to determine whether a newly-arrived packet is in fact 2768 a duplicate. The Identification value within each packet could 2769 further provide a rough indicator of packet reordering, e.g., in 2770 cases when the tunnel egress wishes to discard packets that are 2771 grossly out of order. 2773 In some use cases, there may be operational assurance that no 2774 fragmentation of any kind will be necessary, or that only occasional 2775 large control messages will require fragmentation. In that case, the 2776 encapsulation fragment header can be omitted and ordinary 2777 fragmentation of the outer IP protocol version can be applied when 2778 necessary. 2780 Appendix C. Autoconfiguration for Constrained Platforms 2782 On some platforms (e.g., popular cell phone operating systems), the 2783 act of assigning a default IPv6 route and/or assigning an address to 2784 an interface may not be permitted from a user application due to 2785 security policy. Typically, those platforms include a TUN/TAP 2786 interface [TUNTAP] that acts as a point-to-point conduit between user 2787 applications and the AERO interface. In that case, the Client can 2788 instead generate a "synthesized RA" message. The message conforms to 2789 [RFC4861] and is prepared as follows: 2791 o the IPv6 source address is the Client's AERO address 2793 o the IPv6 destination address is all-nodes multicast 2795 o the Router Lifetime is set to a time that is no longer than the 2796 ACP DHCPv6 lifetime 2798 o the message does not include a Source Link Layer Address Option 2799 (SLLAO) 2801 o the message includes a Prefix Information Option (PIO) with a /64 2802 prefix taken from the ACP as the prefix for autoconfiguration 2804 The Client then sends the synthesized RA message via the TUN/TAP 2805 interface, where the operating system kernel will interpret it as 2806 though it were generated by an actual router. The operating system 2807 will then install a default route and use StateLess Address 2808 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 2809 interface. Methods for similarly installing an IPv4 default route 2810 and IPv4 address on the TUN/TAP interface are based on synthesized 2811 DHCPv4 messages [RFC2131]. 2813 Appendix D. Operational Deployment Alternatives 2815 AERO can be used in many different variations based on the specific 2816 use case. The following sections discuss variations that adhere to 2817 the AERO principles while allowing selective application of AERO 2818 components. 2820 D.1. Operation on AERO Links Without DHCPv6 Services 2822 When Servers on the AERO link do not provide DHCPv6 services, 2823 operation can still be accommodated through administrative 2824 configuration of ACPs on AERO Clients. In that case, administrative 2825 configurations of AERO interface neighbor cache entries on both the 2826 Server and Client are also necessary. However, this may interfere 2827 with the ability for Clients to dynamically change to new Servers, 2828 and can expose the AERO link to misconfigurations unless the 2829 administrative configurations are carefully coordinated. 2831 D.2. Operation on Server-less AERO Links 2833 In some AERO link scenarios, there may be no Servers on the link and/ 2834 or no need for Clients to use a Server as an intermediary trust 2835 anchor. In that case, each Client acts as a Server unto itself to 2836 establish neighbor cache entries by performing direct Client-to- 2837 Client IPv6 ND message exchanges, and some other form of trust basis 2838 must be applied so that each Client can verify that the prospective 2839 neighbor is authorized to use its claimed ACP. 2841 When there is no Server on the link, Clients must arrange to receive 2842 ACPs and publish them via a secure alternate PD authority through 2843 some means outside the scope of this document. 2845 D.3. Operation on Client-less AERO Links 2847 In some environments, the AERO service may be useful for mobile nodes 2848 that do not implement the AERO Client function and do not perform 2849 encapsulation. For example, if the mobile node has a way of 2850 injecting its ACP into the access subnetwork routing system an AERO 2851 Server connected to the same access network can accept the ACP prefix 2852 injection as an indication that a new mobile node has come onto the 2853 subnetwork. The Server can then inject the ACP into the BGP routing 2854 system the same as if an AERO Client/Server DHCPv6 PD exchange had 2855 occurred. If the mobile node subsequently withdraws the ACP from the 2856 access network routing system, the Server can then withdraw the ACP 2857 from the BGP routing system. 2859 In this arrangement, AERO Servers and Relays are used in exactly the 2860 same ways as for environments where DHCPv6 Client/Server exchanges 2861 are supported. However, the access subnetwork routing systems must 2862 be capable of accommodating rapid ACP injections and withdrawals from 2863 mobile nodes with the understanding that the information must be 2864 propagated to all routers in the system. Operational experience has 2865 shown that this kind of routing system "churn" can lead to overall 2866 instability and routing system inconsistency. 2868 D.4. Manually-Configured AERO Tunnels 2870 In addition to the dynamic neighbor discovery procedures for AERO 2871 link neighbors described above, AERO encapsulation can be applied to 2872 manually-configured tunnels. In that case, the tunnel endpoints use 2873 an administratively-provisioned link-local address and exchange NS/NA 2874 messages the same as for dynamically-established tunnels. 2876 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links 2878 In some environments, AERO Servers and Relays may be connected by 2879 dedicated point-to-point links, e.g., high speed fiberoptic leased 2880 lines. In that case, the Servers and Relays can participate in the 2881 AERO link the same as specified above but can avoid encapsulation 2882 over the dedicated links. In that case, however, the links would be 2883 dedicated for AERO and could not be multiplexed for both AERO and 2884 non-AERO communications. 2886 D.6. Encapsulation Protocol Version Considerations 2888 A source Client may connect only to an IPvX underlying network, while 2889 the target Client connects only to an IPvY underlying network. In 2890 that case, the target and source Clients have no means for reaching 2891 each other directly (since they connect to underlying networks of 2892 different IP protocol versions) and so must ignore any route 2893 optimization messages and continue to send packets via their Servers. 2895 D.7. Extending AERO Links Through Security Gateways 2897 When an enterprise mobile node moves from a campus LAN connection to 2898 a public Internet link, it must re-enter the enterprise via a 2899 security gateway that has both a physical interface connection to the 2900 Internet and a physical interface connection to the enterprise 2901 internetwork. This most often entails the establishment of a Virtual 2902 Private Network (VPN) link over the public Internet from the mobile 2903 node to the security gateway. During this process, the mobile node 2904 supplies the security gateway with its public Internet address as the 2905 link-layer address for the VPN. The mobile node then acts as an AERO 2906 Client to negotiate with the security gateway to obtain its ACP. 2908 In order to satisfy this need, the security gateway also operates as 2909 an AERO Server with support for AERO Client proxying. In particular, 2910 when a mobile node (i.e., the Client) connects via the security 2911 gateway (i.e., the Server), the Server provides the Client with an 2912 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2913 enterprise campus access link. The Server then replaces the Client's 2914 link-layer source address with the Server's enterprise-facing link- 2915 layer address in all AERO messages the Client sends toward neighbors 2916 on the AERO link. The AERO messages are then delivered to other 2917 nodes on the AERO link as if they were originated by the security 2918 gateway instead of by the AERO Client. In the reverse direction, the 2919 AERO messages sourced by nodes within the enterprise network can be 2920 forwarded to the security gateway, which then replaces the link-layer 2921 destination address with the Client's link-layer address and replaces 2922 the link-layer source address with its own (Internet-facing) link- 2923 layer address. 2925 After receiving the ACP, the Client can send IP packets that use an 2926 address taken from the ACP as the network layer source address, the 2927 Client's link-layer address as the link-layer source address, and the 2928 Server's Internet-facing link-layer address as the link-layer 2929 destination address. The Server will then rewrite the link-layer 2930 source address with the Server's own enterprise-facing link-layer 2931 address and rewrite the link-layer destination address with the 2932 target AERO node's link-layer address, and the packets will enter the 2933 enterprise network as though they were sourced from a node located 2934 within the enterprise. In the reverse direction, when a packet 2935 sourced by a node within the enterprise network uses a destination 2936 address from the Client's ACP, the packet will be delivered to the 2937 security gateway which then rewrites the link-layer destination 2938 address to the Client's link-layer address and rewrites the link- 2939 layer source address to the Server's Internet-facing link-layer 2940 address. The Server then delivers the packet across the VPN to the 2941 AERO Client. In this way, the AERO virtual link is essentially 2942 extended *through* the security gateway to the point at which the VPN 2943 link and AERO link are effectively grafted together by the link-layer 2944 address rewriting performed by the security gateway. All AERO 2945 messaging services (including route optimization and mobility 2946 signaling) are therefore extended to the Client. 2948 In order to support this virtual link grafting, the security gateway 2949 (acting as an AERO Server) must keep static neighbor cache entries 2950 for all of its associated Clients located on the public Internet. 2951 The neighbor cache entry is keyed by the AERO Client's AERO address 2952 the same as if the Client were located within the enterprise 2953 internetwork. The neighbor cache is then managed in all ways as 2954 though the Client were an ordinary AERO Client. This includes the 2955 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2956 Unreachability Detection. 2958 Note that the main difference between a security gateway acting as an 2959 AERO Server and an enterprise-internal AERO Server is that the 2960 security gateway has at least one enterprise-internal physical 2961 interface and at least one public Internet physical interface. 2962 Conversely, the enterprise-internal AERO Server has only enterprise- 2963 internal physical interfaces. For this reason security gateway 2964 proxying is needed to ensure that the public Internet link-layer 2965 addressing space is kept separate from the enterprise-internal link- 2966 layer addressing space. This is afforded through a natural extension 2967 of the security association caching already performed for each VPN 2968 client by the security gateway. 2970 Appendix E. Change Log 2972 Changes from -78 to -79: 2974 o Neighbors now set UDP Port Number and IP Address in S/TLLAOs to 0 2975 if the node is behind a NAT or otherwise does not wish to update 2976 its link-layer address for this underlying interface 2978 o Introduced "proxy" as a new neighbor cache entry type 2980 o updated GUE references 2982 o multipath considerations for error message handling and NUD 2984 Changes from -77 to -78: 2986 o Added "V" bit to SLLAO flags field for NS messages. V=1 indicates 2987 that the NA response must go through the reverse chain of Servers 2988 and Relays 2990 o Now using combined DHCPv6/IPvND messages (DHCPv6 as an IPv6ND 2991 message option) 2993 o Clarified the use of the "P" bit in the RA flags field 2995 o Use of SEND to protect the combined DHCPv6/IPv6ND messages 2997 o Proxy now treats a Client's Servers as the default routers (i.e., 2998 instead of using a Relay as the default). 3000 Changes from -76 to -77: 3002 o Now using IPv6 ND NS/NA messaging for route optimization (no 3003 longer using Predirect/Redirect) 3005 o Now using combined IPv6 ND/DHCPv6 messaging so autoconfiguration 3006 can be conducted in a single message exchange 3008 o Introduced the AERO Proxy construct. Critical for applications 3009 such as ATN/IPS 3011 Changes from -75 to -76: 3013 o Bumped version number ahead of expiration deadline 3015 Changes from -74 to -75: 3017 o Bumped version number ahead of expiration deadline 3019 Author's Address 3021 Fred L. Templin (editor) 3022 Boeing Research & Technology 3023 P.O. Box 3707 3024 Seattle, WA 98124 3025 USA 3027 Email: fltemplin@acm.org