idnits 2.17.1 draft-templin-aerolink-77.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2017) is 2325 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 2308, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 2377, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-sedhcpv6' is defined on line 2391, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2440, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 2444, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 2461, but no explicit reference was found in the text == Unused Reference: 'RFC2675' is defined on line 2479, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 2510, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 2540, but no explicit reference was found in the text == Unused Reference: 'RFC4555' is defined on line 2549, but no explicit reference was found in the text == Unused Reference: 'RFC4592' is defined on line 2553, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 2563, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 2572, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 2577, but no explicit reference was found in the text == Unused Reference: 'RFC5494' is defined on line 2596, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2615, but no explicit reference was found in the text == Unused Reference: 'RFC5844' is defined on line 2620, but no explicit reference was found in the text == Unused Reference: 'RFC5949' is defined on line 2624, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 2634, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 2643, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 2653, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 2658, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 2662, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2667, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 2676, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 2688, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 2693, but no explicit reference was found in the text == Unused Reference: 'RFC6939' is defined on line 2698, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 2702, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 2707, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-07 == Outdated reference: A later version (-11) exists of draft-templin-6man-dhcpv6-ndopt-00 == 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-16 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 36 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc5320, rfc5558, rfc5720, December 13, 2017 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: June 16, 2018 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-77.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 Admission control and address/prefix provisioning are supported by 23 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), while 24 mobility management, quality of service signaling and route 25 optimization are naturally supported through dynamic neighbor cache 26 updates. 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 June 16, 2018. 47 Copyright Notice 49 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 12 71 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 13 72 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 15 73 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . 19 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 . . . . 21 84 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 22 85 3.11. AERO Interface Data Origin Authentication . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . 28 90 3.14.1. AERO DHCPv6 and IPv6 ND Service Model . . . . . . . 28 91 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 29 92 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 31 93 3.15. AERO Interface Route Optimization . . . . . . . . . . . . 32 94 3.15.1. Reference Operational Scenario . . . . . . . . . . . 33 95 3.15.2. Concept of Operations . . . . . . . . . . . . . . . 34 96 3.15.3. Sending NS Messages . . . . . . . . . . . . . . . . 35 97 3.15.4. Re-encapsulating and Relaying the NS . . . . . . . . 36 98 3.15.5. Processing NSs and Sending NAs . . . . . . . . . . . 37 99 3.15.6. Re-encapsulating and Relaying NAs . . . . . . . . . 38 100 3.15.7. Processing NAs . . . . . . . . . . . . . . . . . . . 38 101 3.15.8. Server-to-Client and Client-to-Server Route 102 Optimization . . . . . . . . . . . . . . . . . . . . 39 103 3.15.9. Server-to-Server Route Optimization . . . . . . . . 40 104 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 40 105 3.17. Mobility Management and Quality of Service . . . . . . . 41 106 3.17.1. Forwarding Packets on Behalf of Departed Clients . . 41 107 3.17.2. Announcing Link-Layer Address and Quality of Service 108 Changes . . . . . . . . . . . . . . . . . . . . . . 42 109 3.17.3. Bringing New Links Into Service . . . . . . . . . . 42 110 3.17.4. Removing Existing Links from Service . . . . . . . . 42 111 3.17.5. Implicit Mobility Management . . . . . . . . . . . . 42 112 3.17.6. Moving to a New Server . . . . . . . . . . . . . . . 43 113 3.17.7. Alternate Mobility Security Model . . . . . . . . . 44 114 3.17.8. Packet Queueing for Mobility . . . . . . . . . . . . 44 115 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 44 116 4. The AERO Proxy . . . . . . . . . . . . . . . . . . . . . . . 45 117 5. Operation on AERO Links with /64 ASPs . . . . . . . . . . . . 46 118 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 47 119 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 120 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 121 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 122 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 123 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 124 10.2. Informative References . . . . . . . . . . . . . . . . . 51 125 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 58 126 Appendix B. When to Insert an Encapsulation Fragment Header . . 60 127 Appendix C. Autoconfiguration for Constrained Platforms . . . . 60 128 Appendix D. Operational Deployment Alternatives . . . . . . . . 61 129 D.1. Operation on AERO Links Without DHCPv6 Services . . . . . 61 130 D.2. Operation on Server-less AERO Links . . . . . . . . . . . 62 131 D.3. Operation on Client-less AERO Links . . . . . . . . . . . 62 132 D.4. Manually-Configured AERO Tunnels . . . . . . . . . . . . 62 133 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links . 63 134 D.6. Encapsulation Protocol Version Considerations . . . . . . 63 135 D.7. Extending AERO Links Through Security Gateways . . . . . 63 136 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 65 137 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 65 139 1. Introduction 141 This document specifies the operation of IP over tunnel virtual links 142 using Asymmetric Extended Route Optimization (AERO). The AERO link 143 can be used for tunneling between neighboring nodes over either IPv6 144 or IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 145 equivalent links for tunneling. Nodes attached to AERO links can 146 exchange packets via trusted intermediate routers that provide 147 forwarding services to reach off-link destinations and route 148 optimization services for improved performance [RFC5522]. 150 AERO provides an IPv6 link-local address format that supports 151 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 152 links IPv6 ND to IP forwarding. Admission control and address/prefix 153 provisioning are supported by the Dynamic Host Configuration Protocol 154 for IPv6 (DHCPv6) [RFC3315], while mobility management, quality of 155 service signaling and route optimization are naturally supported 156 through dynamic neighbor cache updates. 158 A node's AERO interface can be configured over multiple underlying 159 interfaces. From the standpoint of IPv6 ND, AERO interface neighbors 160 therefore may appear to have multiple link-layer addresses. Each 161 link-layer address is subject to change due to mobility, and link- 162 layer address changes are signaled by IPv6 ND messaging the same as 163 for any IPv6 link. 165 AERO is applicable to a wide variety of use cases. For example, it 166 can be used to coordinate the Virtual Private Network (VPN) links of 167 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 168 connect into a home enterprise network via public access networks 169 using services such as OpenVPN [OVPN]. AERO is also applicable to 170 aviation 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 AERO link 182 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 183 configured over a node's attached IPv6 and/or IPv4 networks. All 184 nodes on the AERO link appear as single-hop neighbors from the 185 perspective of the virtual overlay even though they may be 186 separated by many underlying network hops. The AERO mechanisms 187 can also operate over native link types (e.g., Ethernet, WiFi 188 etc.) when a tunnel virtual overlay is not needed. 190 AERO interface 191 a node's attachment to an AERO link. Since the addresses assigned 192 to an AERO interface are managed for uniqueness, AERO interfaces 193 do not require Duplicate Address Detection (DAD) and therefore set 194 the administrative variable DupAddrDetectTransmits to zero 195 [RFC4862]. 197 AERO address 198 an IPv6 link-local address constructed as specified in 199 Section 3.4. 201 AERO node 202 a node that is connected to an AERO link. 204 AERO Client ("Client") 205 a node that issues DHCPv6 messages to receive IP Prefix 206 Delegations (PDs) from one or more AERO Servers. Following PD, 207 the Client assigns an AERO address to the AERO interface for use 208 in IPv6 ND exchanges with other AERO nodes. A node that acts as 209 an AERO Client on one AERO interface can also act as an AERO 210 Server on a different AERO interface. 212 AERO Server ("Server") 213 a node that configures an AERO interface to provide default 214 forwarding services for AERO Clients. The Server assigns an 215 administratively provisioned IPv6 link-local unicast address to 216 the AERO interface to support the operation of DHCPv6 and the IPv6 217 ND protocol. An AERO Server can also act as an AERO Relay. 219 AERO Relay ("Relay") 220 a node that configures an AERO interface to relay IP packets 221 between nodes on the same AERO link and/or forward IP packets 222 between the AERO link and the native Internetwork. The Relay 223 assigns an administratively provisioned IPv6 link-local unicast 224 address to the AERO interface the same as for a Server. An AERO 225 Relay can also act as an AERO Server. 227 AERO Proxy ("Proxy") 228 a node that provides proxying services for Clients that cannot 229 associate directly with Servers, e.g., when the Client is located 230 in a secured internal enclave and the Server is located in the 231 exteranal Internetwork. The AERO Proxy is a conduit between the 232 secured enclave and the outside world, i.e., in the same manner as 233 for common web proxies. 235 ingress tunnel endpoint (ITE) 236 an AERO interface endpoint that injects encapsulated packets into 237 an AERO link. 239 egress tunnel endpoint (ETE) 240 an AERO interface endpoint that receives encapsulated packets from 241 an AERO link. 243 underlying network 244 a connected IPv6 or IPv4 network routing region over which the 245 tunnel virtual overlay is configured. 247 underlying interface 248 an AERO node's interface point of attachment to an underlying 249 network. 251 link-layer address 252 an IP address assigned to an AERO node's underlying interface. 253 When UDP encapsulation is used, the UDP port number is also 254 considered as part of the link-layer address. Link-layer 255 addresses are used as the encapsulation header source and 256 destination addresses. 258 network layer address 259 the source or destination address of the encapsulated IP packet. 261 end user network (EUN) 262 an internal virtual or external edge IP network that an AERO 263 Client connects to the rest of the network via the AERO interface. 264 The Client sees each EUN as a "downstream" network and sees the 265 AERO interface as its point of attachment to the "upstream" 266 network. 268 AERO Service Prefix (ASP) 269 an IP prefix associated with the AERO link and from which more- 270 specific AERO Client Prefixes (ACPs) are derived. 272 AERO Client Prefix (ACP) 273 an IP prefix derived from an ASP and delegated to a Client, where 274 the ACP prefix length must be no shorter than the ASP prefix 275 length and must be no longer than 64 for IPv6 or 32 for IPv4. 277 base AERO address 278 the lowest-numbered AERO address from the first ACP delegated to 279 the Client (see Section 3.4). 281 Throughout the document, the simple terms "Client", "Server", "Relay" 282 and "Proxy" refer to "AERO Client", "AERO Server", "AERO Relay" and 283 "AERO Proxy", respectively. Capitalization is used to distinguish 284 these terms from DHCPv6 client/server/relay [RFC3315]. 286 The terminology of DHCPv6 [RFC3315] and IPv6 ND [RFC4861] (including 287 the names of node variables and protocol constants) applies to this 288 document. Also throughout the document, the term "IP" is used to 289 generically refer to either Internet Protocol version (i.e., IPv4 or 290 IPv6). 292 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 293 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 294 document are to be interpreted as described in [RFC2119]. Lower case 295 uses of these words are not to be interpreted as carrying RFC2119 296 significance. 298 3. Asymmetric Extended Route Optimization (AERO) 300 The following sections specify the operation of IP over Asymmetric 301 Extended Route Optimization (AERO) links: 303 3.1. AERO Link Reference Model 304 .-(::::::::) 305 .-(:::: IP ::::)-. 306 (:: Internetwork ::) 307 `-(::::::::::::)-' 308 `-(::::::)-' 309 | 310 +--------------+ +--------+-------+ +--------------+ 311 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 312 | Nbr: C1; R1 | | Nbr: S1; S2 | | Nbr: C2; R1 | 313 | default->R1 | |(P1->S1; P2->S2)| | default->R1 | 314 | X1->C1 | | ASP A1 | | X2->C2 | 315 +-------+------+ +--------+-------+ +------+-------+ 316 | AERO Link | | 317 X---+---+-----------------+-+------------------+---+---X 318 | | | 319 +-----+--------+ +-----+--------+ +--------+-----+ 320 |AERO Client C1| |AERO Proxy P1 | |AERO Client C2| 321 | Nbr: S1 | | Nbr: S1, S2 | | Nbr: S2 | 322 | default->S1 | | default->R1 | | default->S2 | 323 | ACP X1 | +-------+------+ | ACP X2 | 324 +------+-------+ .--------|-------. +-----+--------+ 325 | (- Proxied Clients -) | 326 .-. `---------------' .-. 327 ,-( _)-. ,-( _)-. 328 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 329 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 330 `-(______)-' +-------+ +-------+ `-(______)-' 332 Figure 1: AERO Link Reference Model 334 Figure 1 presents the AERO link reference model. In this model: 336 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 337 default router for its associated Servers and Proxies (S1, S2 and 338 P1), and connects the AERO link to the rest of the IP 339 Internetwork. 341 o AERO Servers S1 and S2 associate with Relay R1 and also act as 342 default routers for their associated Clients C1 and C2. 344 o AERO Clients C1 and C2 associate with Servers S1 and S2, 345 respectively. They receive AERO Client Prefix (ACP) delegations 346 X1 and X2, and also act as default routers for their associated 347 physical or internal virtual EUNs. Simple hosts H1 and H2 attach 348 to the EUNs served by Clients C1 and C2, respectively. 350 o AERO Proxy P1 associates with Relay R1 as a default router and 351 Servers S1 and S2 as neighbors. P1 provides proxy services for 352 AERO Clients in secured enclaves that cannot associate directly 353 with Servers in the outside world. 355 Each node on the AERO link maintains an AERO interface neighbor cache 356 and an IP forwarding table the same as for any link. In common 357 operational practice, there may be many additional Relays, Servers, 358 Proxies and Clients. 360 3.2. AERO Node Types 362 AERO Relays provide default forwarding services to AERO Servers. 363 Each Relay also peers with Servers and other Relays in a dynamic 364 routing protocol instance to discover the list of active ACPs (see 365 Section 3.3). Relays forward packets between neighbors connected to 366 the same AERO link and also forward packets between the AERO link and 367 the native IP Internetwork. Relays present the AERO link to the 368 native Internetwork as a set of one or more AERO Service Prefixes 369 (ASPs) and serve as a gateway between the AERO link and the 370 Internetwork. Relays maintain AERO interface neighbor cache entries 371 for Servers, and maintain an IP forwarding table entry for each AERO 372 Client Prefix (ACP). AERO Relays can also be configured to act as 373 AERO Servers. 375 AERO Servers provide default forwarding services to AERO Clients. 376 Each Server also peers with Relays in a dynamic routing protocol 377 instance to advertise its list of associated ACPs (see Section 3.3). 378 Servers configure a DHCPv6 server function and act as delegating 379 routers to facilitate Prefix Delegation (PD) exchanges with Clients. 380 Each delegated prefix becomes an ACP taken from an ASP. Servers 381 forward packets between AERO interface neighbors, and maintain an 382 AERO interface neighbor cache entry for each Relay. They also 383 maintain both neighbor cache entries and IP forwarding table entries 384 for each of their associated Clients. AERO Servers can also be 385 configured to act as AERO Relays. 387 AERO Clients act as requesting routers to receive ACPs through DHCPv6 388 PD exchanges with AERO Servers over the AERO link. Each Client can 389 associate with a single Server or with multiple Servers, e.g., for 390 fault tolerance, load balancing, etc. Each IPv6 Client receives at 391 least a /64 IPv6 ACP, and may receive even shorter prefixes. 392 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 393 singleton IPv4 address), and may receive even shorter prefixes. 394 Clients maintain an AERO interface neighbor cache entry for each of 395 their associated Servers as well as for each of their correspondent 396 Clients. 398 AERO Proxies provide a conduit for AERO Clients located in secured 399 enclaves to assocaite with Servers located in the outside 400 Internetwork. The Proxy can either be explicit or transparent. In 401 the explicit case, the Client sends all of its control plane messages 402 addressed to the Server to the link-layer address of the Proxy. In 403 the transparent case, the Client sends all of its control plane 404 messages to the Server's link-layer address and the Proxy intercepts 405 them before they leave the secured enclave. In both cases, the Proxy 406 forwards the Client's control plane messages to the Server, forwards 407 the Client's outbound data plane messages to a Relay and accepts 408 inbound data plane messages from the Client's current Server(s). The 409 Proxy may also discover a more direct route toward a target 410 destination via AERO route optimization, in which case future packets 411 would be forwarded via the more direct route instead of via a Relay. 412 The Proxy function is discussed in more detail in Section 4. 414 3.3. AERO Routing System 416 The AERO routing system comprises a private instance of the Border 417 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 418 and Servers and does not interact with either the public Internet BGP 419 routing system or the native IP Internetwork interior routing system. 420 Relays advertise only a small and unchanging set of ASPs to the 421 native routing system instead of the full dynamically changing set of 422 ACPs. 424 In a reference deployment, each AERO Server is configured as an 425 Autonomous System Border Router (ASBR) for a stub Autonomous System 426 (AS) using an AS Number (ASN) that is unique within the BGP instance, 427 and each Server further uses eBGP to peer with one or more Relays but 428 does not peer with other Servers. All Relays are members of the same 429 hub AS using a common ASN, and use iBGP to maintain a consistent view 430 of all active ACPs currently in service. 432 Each Server maintains a working set of associated ACPs, and 433 dynamically announces new ACPs and withdraws departed ACPs in its 434 eBGP updates to Relays. Clients are expected to remain associated 435 with their current Servers for extended timeframes, however Servers 436 SHOULD selectively suppress updates for impatient Clients that 437 repeatedly associate and disassociate with them in order to dampen 438 routing churn. 440 Each Relay configures a black-hole route for each of its ASPs. By 441 black-holing the ASPs, the Relay will maintain forwarding table 442 entries only for the ACPs that are currently active, and packets 443 destined to all other ACPs will correctly incur Destination 444 Unreachable messages due to the black hole route. Relays do not send 445 eBGP updates for ACPs to Servers, but instead originate a default 446 route. In this way, Servers have only partial topology knowledge 447 (i.e., they know only about the ACPs of their directly associated 448 Clients) and they forward all other packets to Relays which have full 449 topology knowledge. 451 Scaling properties of the AERO routing system are limited by the 452 number of BGP routes that can be carried by Relays. At the time of 453 this writing, the global public Internet BGP routing system manages 454 more than 500K routes with linear growth and no signs of router 455 resource exhaustion [BGP]. Network emulation studies have also shown 456 that a single Relay can accommodate at least 1M dynamically changing 457 BGP routes even on a lightweight virtual machine, i.e., and without 458 requiring high-end dedicated router hardware. 460 Therefore, assuming each Relay can carry 1M or more routes, this 461 means that at least 1M Clients can be serviced by a single set of 462 Relays. A means of increasing scaling would be to assign a different 463 set of Relays for each set of ASPs. In that case, each Server still 464 peers with one or more Relays, but the Server institutes route 465 filters so that it only sends BGP updates to the specific set of 466 Relays that aggregate the ASP. For example, if the ASP for the AERO 467 link is 2001:db8::/32, a first set of Relays could service the ASP 468 segment 2001:db8::/40, a second set of Relays could service 469 2001:db8:0100::/40, a third set could service 2001:db8:0200::/40, 470 etc. 472 Assuming up to 1K sets of Relays, the AERO routing system can then 473 accommodate 1B or more ACPs with no additional overhead for Servers 474 and Relays (for example, it should be possible to service 1B /64 ACPs 475 taken from a /34 ASP and even more for shorter prefixes). In this 476 way, each set of Relays services a specific set of ASPs that they 477 advertise to the native routing system, and each Server configures 478 ASP-specific routes that list the correct set of Relays as next hops. 479 This arrangement also allows for natural incremental deployment, and 480 can support small scale initial deployments followed by dynamic 481 deployment of additional Clients, Servers and Relays without 482 disturbing the already-deployed base. 484 Note that in an alternate routing arrangement each set of Relays 485 could advertise an aggregated ASP for the link into the native 486 routing system even though each Relay services only smaller segments 487 of the ASP. In that case, a Relay upon receiving a packet with a 488 destination address covered by the ASP segment of another Relay can 489 simply tunnel the packet to the other Relay. The tradeoff then is 490 the penalty for Relay-to-Relay tunneling compared with reduced 491 routing information in the native routing system. 493 3.4. AERO Interface Link-local Addresses 495 AERO interface link-local address types include administratively- 496 provisioned addresses and AERO addresses. 498 Administratively-provisioned addresses are allocated from the range 499 fe80::/96 and assigned to a Server or Relay's AERO interface. 500 Administratively-provisioned addresses MUST be managed for uniqueness 501 by the administrative authority for the AERO link. (Note that fe80:: 502 is the IPv6 link-local subnet router anycast address, and 503 fe80::ffff:ffff is the address used by Clients to bootstrap AERO 504 address autoconfiguration. These special addresses are therefore not 505 available for assignment.) 507 An AERO address is an IPv6 link-local address with an embedded prefix 508 based on an ACP and associated with a Client's AERO interface. AERO 509 addresses remain stable as the Client moves between topological 510 locations, i.e., even if its link-layer addresses change. 512 For IPv6, AERO addresses begin with the prefix fe80::/64 and include 513 in the interface identifier (i.e., the lower 64 bits) a 64-bit prefix 514 taken from one of the Client's IPv6 ACPs. For example, if the AERO 515 Client receives the IPv6 ACP: 517 2001:db8:1000:2000::/56 519 it constructs its corresponding AERO addresses as: 521 fe80::2001:db8:1000:2000 523 fe80::2001:db8:1000:2001 525 fe80::2001:db8:1000:2002 527 ... etc. ... 529 fe80::2001:db8:1000:20ff 531 For IPv4, AERO addresses are based on an IPv4-mapped IPv6 address 532 [RFC4291] formed from an IPv4 ACP and with a Prefix Length of 96 plus 533 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 534 the IPv4-mapped IPv6 ACP is: 536 0:0:0:0:0:FFFF:192.0.2.16/124 538 The Client then constructs its AERO addresses with the prefix 539 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 540 in the interface identifier as: 542 fe80::FFFF:192.0.2.16 544 fe80::FFFF:192.0.2.17 546 fe80::FFFF:192.0.2.18 548 ... etc. ... 550 fe80:FFFF:192.0.2.31 552 When the Server delegates ACPs to the Client, both the Server and 553 Client use the lowest-numbered AERO address from the first ACP 554 delegation as the "base" AERO address. (For example, for the ACP 555 2001:db8:1000:2000::/56 the base address is 2001:db8:1000:2000.) The 556 Client then assigns the base AERO address to the AERO interface and 557 uses it for the purpose of maintaining the neighbor cache entry. If 558 the Client has multiple AERO addresses (i.e., when there are multiple 559 ACPs and/or ACPs with short prefix lengths), the Client originates 560 IPv6 ND messages using the base AERO address as the source address 561 and accepts and responds to IPv6 ND messages destined to any of its 562 AERO addresses as equivalent to the base AERO address. In this way, 563 the Client maintains a single neighbor cache entry that may include 564 multiple AERO addresses. 566 3.5. AERO Interface Characteristics 568 AERO interfaces use encapsulation (see: Section 3.9) to exchange 569 packets with neighbors attached to the AERO link. 571 AERO interfaces maintain a neighbor cache, and use both DHCPv6 and 572 IPv6 ND control messaging to manage the creation, modification and 573 deletion of neighbor cache entries. AERO interfaces use standard 574 DHCPv6 messaging for prefix delegation, and use unicast IPv6 ND 575 Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router 576 Solicitation (RS), Router Advertisement (RA) and Redirect messages 577 for neighbor cache management the same as for any IPv6 link. AERO 578 interfaces include routing information in IPv6 ND messages to support 579 route optimization. 581 AERO interface ND messages include one or more Source/Target Link- 582 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Length = 5 | Reserved | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Interface ID | UDP Port Number | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 + + 593 | | 594 + IP Address + 595 | | 596 + + 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 609 Format 611 In this format: 613 o Type is set to '1' for SLLAO or '2' for TLLAO the same as for IPv6 614 ND. 616 o Length is set to the constant value '5' (i.e., 5 units of 8 617 octets). 619 o Reserved is set to the value '0' on transmission and ignored on 620 receipt. 622 o Interface ID is set to an integer value between 0 and 65535 623 corresponding to an underlying interface of the AERO node. 625 o UDP Port Number and IP Address are set to the addresses used by 626 the AERO node when it sends encapsulated packets over the 627 underlying interface. When UDP is not used as part of the 628 encapsulation, UDP Port Number is set to the value '0'. When the 629 encapsulation IP address family is IPv4, IP Address is formed as 630 an IPv4-mapped IPv6 address as specified in Section 3.4. 632 o P[i] is a set of 64 Preference values that correspond to the 64 633 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 634 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 635 ("medium") or '3' ("high") to indicate a preference level for 636 packet forwarding purposes. 638 AERO interfaces may be configured over multiple underlying 639 interfaces. For example, common mobile handheld devices have both 640 wireless local area network ("WLAN") and cellular wireless links. 641 These links are typically used "one at a time" with low-cost WLAN 642 preferred and highly-available cellular wireless as a standby. In a 643 more complex example, aircraft frequently have many wireless data 644 link types (e.g. satellite-based, cellular, terrestrial, air-to-air 645 directional, etc.) with diverse performance and cost properties. 647 If a Client's multiple underlying interfaces are used "one at a time" 648 (i.e., all other interfaces are in standby mode while one interface 649 is active), then IPv6 ND messages include only a single S/TLLAO with 650 Interface ID set to a constant value. In that case, the Client would 651 appear to have a single underlying interface but with a dynamically 652 changing link-layer address. 654 If the Client has multiple active underlying interfaces, then from 655 the perspective of IPv6 ND it would appear to have multiple link- 656 layer addresses. In that case, IPv6 ND messages MAY include multiple 657 S/TLLAOs -- each with an Interface ID that corresponds to a specific 658 underlying interface of the AERO node. 660 When an IPv6 ND message includes multiple S/TLLAOs, the first S/TLLAO 661 MUST correspond to the Client's underlying interface used to transmit 662 the message. 664 3.6. AERO Interface Initialization 666 3.6.1. AERO Relay Behavior 668 When a Relay enables an AERO interface, it first assigns an 669 administratively-provisioned link-local address fe80::ID to the 670 interface. Each fe80::ID address MUST be unique among all AERO nodes 671 on the link, and is taken from the range fe80::/96 but excluding the 672 special addresses fe80:: and fe80::ffff:ffff. The Relay then engages 673 in a dynamic routing protocol session with Servers on the link (see: 674 Section 3.3), and advertises its assigned ASPs into the native IP 675 Internetwork. 677 Each Relay subsequently maintains an IP forwarding table entry for 678 each active ACP covered by its ASP(s), and maintains neighbor cache 679 entries for Servers on the link. Relays exchange NS/NA messages with 680 AERO link neighbors the same as for any AERO node, however they need 681 not perform explicit Neighbor Unreachability Detection (NUD) (see: 682 Section 3.16) since the dynamic routing protocol already provides 683 reachability confirmation. 685 3.6.2. AERO Server Behavior 687 When a Server enables an AERO interface, it assigns an 688 administratively-provisioned link-local address fe80::ID the same as 689 for Relays. The Server further configures a DHCPv6 server function 690 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 691 maintains neighbor cache entries for Relays on the link, and manages 692 per-Client neighbor cache entries and IP forwarding table entries 693 based on control message exchanges. Each Server also engages in a 694 dynamic routing protocol with Relays on the link (see: Section 3.3). 696 When the Server receives an NS/RS message from a Client on the AERO 697 interface it returns an NA/RA message. The Server further provides a 698 simple link-layer conduit between AERO interface neighbors. In 699 particular, when a packet sent by a source Client arrives on the 700 Server's AERO interface and is destined to another AERO node, the 701 Server forwards the packet from within the AERO interface driver at 702 the link layer without ever disturbing the network layer. 704 3.6.3. AERO Client Behavior 706 When a Client enables an AERO interface, it uses the special 707 administratively-provisioned link-local address fe80::ffff:ffff as 708 the source network-layer address in an RS message with an embedded 709 DHCPv6 PD Solicit message per [I-D.templin-6man-dhcpv6-ndopt] to 710 obtain one or more ACPs from one or more AERO Servers. Each Server 711 processes the message and returns an RA message with an embedded 712 DHCPv6 PD Reply message with the destination network-layer address 713 set to the base AERO address. In this way, the combined RS/RA and 714 DHCPv6 PD message exchange securely performs all autoconfiguration 715 operations in a single message exchange. 717 After the initial DHCPv6 message exchange, the Client can register 718 additional links with the Server by sending an RS message over each 719 link without including a DHCPv6 option. The Server will update its 720 neighbor cache entry for the Client and return an RA message. 722 The Client maintains a neighbor cache entry for each of its Servers 723 and each of its active correspondent Clients. When the Client 724 receives IPv6 ND messages on the AERO interface it updates or creates 725 neighbor cache entries, including link-layer address information. 727 3.6.4. AERO Proxy Behavior 729 When a Proxy enables an AERO interface, it assigns an 730 administratively-provisioned link-local address fe80::ID the same as 731 for Servers and Relays. The Proxy maintains neighbor cache entries 732 for Relays and Servers on the link, and manages per-Client neighbor 733 cache entries and IP forwarding table entries based on control 734 message exchanges. Proxies use Relays as default routers for 735 forwarding packets before a route-optimized path via a target is 736 discovered. Proxies accept packets that are destined for one of 737 their associated Clients. 739 When the Proxy receives an RS message from a Client in the secured 740 enclave, it caches the RS and forwards it to a Server selected by the 741 Client while using its own link-layer address as the source address. 742 When the Server returns an RA message, the Proxy caches the 743 autoconfiguration information in the RA and forwards the RA to the 744 Client while using its own link-layer address as the source address. 745 Both the Client and Proxy will then have the necessary state for 746 managing the AERO interface association with the Server. 748 3.7. AERO Interface Neighbor Cache Maintenace 750 Each AERO interface maintains a conceptual neighbor cache that 751 includes an entry for each neighbor it communicates with on the AERO 752 link, the same as for any IPv6 interface [RFC4861]. AERO interface 753 neighbor cache entires are said to be one of "permanent", "static" or 754 "dynamic". 756 Permanent neighbor cache entries are created through explicit 757 administrative action; they have no timeout values and remain in 758 place until explicitly deleted. AERO Relays and Proxies maintain 759 permanent neighbor cache entries for Servers on the link, and AERO 760 Servers maintain permanent neighbor cache entry for Proxies and 761 Relays. Each entry maintains the mapping between the neighbor's 762 fe80::ID network-layer address and corresponding link-layer address. 764 Static neighbor cache entries are created and maintained through 765 prefix delegation exchanges as specified in Section 3.14, and remain 766 in place for durations bounded by prefix delegation lifetimes. AERO 767 Servers and Proxies maintain static neighbor cache entries for each 768 of their associated Clients, and AERO Clients maintain static 769 neighbor cache entries for each of their associated Servers. 771 Dynamic neighbor cache entries are created or updated based on 772 receipt of route optimization messages as specified in Section 3.15, 773 and are garbage-collected when keepalive timers expire. AERO Clients 774 maintain dynamic neighbor cache entries for each of their active 775 correspondents with lifetimes based on IPv6 ND messaging constants. 777 When an AERO Client receives a valid NS message , it creates or 778 updates a dynamic neighbor cache entry for the source network-layer 779 and link-layer addresses. The node then sets an "AcceptTime" 780 variable in the neighbor cache entry to ACCEPT_TIME seconds and uses 781 this value to determine whether packets received from the 782 correspondent can be accepted. The node resets AcceptTime when it 783 receives a new IPv6 ND message, and otherwise decrements AcceptTime 784 while no IPv6 ND messages have been received. It is RECOMMENDED that 785 ACCEPT_TIME be set to the default constant value 40 seconds to allow 786 a 10 second window so that the AERO route optimization procedure can 787 converge before AcceptTime decrements below FORWARD_TIME (see below). 789 When an AERO Client receives a valid NA message that matches its NS 790 message, it creates or updates a dynamic neighbor cache entry for the 791 target network-layer and link-layer addresses. The Client then sets 792 a "ForwardTime" variable in the neighbor cache entry to FORWARD_TIME 793 seconds and uses this value to determine whether packets can be sent 794 directly to the correspondent. The node resets ForwardTime when it 795 receives a new NA, and otherwise decrements ForwardTime while no 796 further NA messages have been received. It is RECOMMENDED that 797 FORWARD_TIME be set to the default constant value 30 seconds to match 798 the default REACHABLE_TIME value specified for IPv6 ND [RFC4861]. 800 The Client also sets a "MaxRetry" variable to MAX_RETRY to limit the 801 number of keepalives sent when a correspondent may have gone 802 unreachable. It is RECOMMENDED that MAX_RETRY be set to 3 the same 803 as described for IPv6 ND address resolution in Section 7.3.3 of 804 [RFC4861]. 806 Different values for ACCEPT_TIME, FORWARD_TIME and MAX_RETRY MAY be 807 administratively set, if necessary, to better match the AERO link's 808 performance characteristics; however, if different values are chosen, 809 all nodes on the link MUST consistently configure the same values. 810 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 811 sufficiently longer than FORWARD_TIME to allow the AERO route 812 optimization procedure to converge. 814 When there may be a Network Address Translator (NAT) between the 815 Client and the Server, or if the path from the Client to the Server 816 should be tested for reachability, the Client can send periodic RS 817 messages to the Server without a DHCPv6 option to receive RA replies. 818 The RS/RA messaging will keep NAT state alive and test Server 819 reachability without disturbing the DHCPv6 server. 821 3.8. AERO Interface Forwarding Algorithm 823 IP packets enter a node's AERO interface either from the network 824 layer (i.e., from a local application or the IP forwarding system) or 825 from the link layer (i.e., from the AERO tunnel virtual link). 826 Packets that enter the AERO interface from the network layer are 827 encapsulated and forwarded into the AERO link, i.e., they are 828 tunnelled to an AERO interface neighbor. Packets that enter the AERO 829 interface from the link layer are either re-admitted into the AERO 830 link or forwarded to the network layer where they are subject to 831 either local delivery or IP forwarding. In all cases, the AERO 832 interface itself MUST NOT decrement the network layer TTL/Hop-count 833 since its forwarding actions occur below the network layer. 835 AERO interfaces may have multiple underlying interfaces and/or 836 neighbor cache entries for neighbors with multiple Interface ID 837 registrations (see Section 3.5). The AERO node uses each packet's 838 DSCP value to select an outgoing underlying interface based on the 839 node's own preference values, and also to select a destination link- 840 layer address based on the neighbor's underlying interface with the 841 highest preference value. If multiple outgoing interfaces and/or 842 neighbor interfaces have a preference of "high", the AERO node sends 843 one copy of the packet via each of the (outgoing / neighbor) 844 interface pairs; otherwise, the node sends a single copy of the 845 packet. 847 The following sections discuss the AERO interface forwarding 848 algorithms for Clients, Servers and Relays. In the following 849 discussion, a packet's destination address is said to "match" if it 850 is a non-link-local address with a prefix covered by an ASP/ACP, or 851 if it is an AERO address that embeds an ACP, or if it is the same as 852 an administratively-provisioned link-local address. 854 3.8.1. Client Forwarding Algorithm 856 When an IP packet enters a Client's AERO interface from the network 857 layer the Client searches for a dynamic neighbor cache entry that 858 matches the destination. If there is a match, the Client uses one or 859 more link-layer addresses in the entry as the link-layer addresses 860 for encapsulation and admits the packet into the AERO link. 861 Otherwise, the Client uses the link-layer address in a static 862 neighbor cache entry for a Server as the encapsulation address 863 (noting that the Server may be behind a Proxy). 865 When an IP packet enters a Client's AERO interface from the link- 866 layer, if the destination matches one of the Client's ACPs or link- 867 local addresses the Client decapsulates the packet and delivers it to 868 the network layer. Otherwise, the Client drops the packet silently. 870 3.8.2. Proxy Forwarding Algorithm 872 When the Proxy receives a packet from a Client within the secured 873 enclave, the Proxy searches for a remote Client's route that matches 874 the destination. If there is a match, the Proxy uses the link-layer 875 address of a Server that services the remote Client as the link-layer 876 address for encapsulation and admits the packet into the AERO link. 877 Otherwise, the Proxy uses the link-layer address in a permanent 878 neighbor cache entry for a Relay as the encapsulation address. 880 When the Proxy receives a packet from a Server, it searches for a 881 local Client's route that matches the destination. If there is a 882 match, the Proxy forwards the packet to the local Client within the 883 secured enclave. Otherwise, the Proxy drops the packet silently. 885 3.8.3. Server Forwarding Algorithm 887 When an IP packet enters a Server's AERO interface from the network 888 layer, the Server searches for a neighbor cache entry for a Client or 889 Proxy that matches the destination. If there is a match, the Server 890 uses one or more link-layer addresses in the entry as the link-layer 891 addresses for encapsulation and admits the packet into the AERO link. 892 Otherwise, the Server uses the link-layer address in a neighbor cache 893 entry for a Relay (selected through longest-prefix match) as the 894 link-layer address for encapsulation. 896 When an IP packet enters a Server's AERO interface from the link 897 layer, the Server processes the packet as follows: 899 o if the destination matches one of the Server's own addresses the 900 Server decapsulates the packet and forwards it to the network 901 layer for local delivery. 903 o else, if the destination matches a neighbor cache entry for a 904 Client or Proxy the Server first determines whether the neighbor 905 is the same as the one it received the packet from. If so, the 906 Server MUST drop the packet silently to avoid looping; otherwise, 907 the Server uses the neighbor's link-layer address(es) as the 908 destination for encapsulation and re-admits the packet into the 909 AERO link. 911 o else, the Server uses the link-layer address in a permanent 912 neighbor cache entry for a Relay (selected through longest-prefix 913 match) as the link-layer address for encapsulation. 915 3.8.4. Relay Forwarding Algorithm 917 When an IP packet enters a Relay's AERO interface from the network 918 layer, the Relay searches its IP forwarding table for an ACP entry 919 that matches the destination and otherwise searches for a neighbor 920 cache entry that matches the destination. If there is a match, the 921 Relay uses the link-layer address in the corresponding neighbor cache 922 entry as the link-layer address for encapsulation and forwards the 923 packet into the AERO link. Otherwise, the Relay drops the packet and 924 (for non-link-local addresses) returns an ICMP Destination 925 Unreachable message subject to rate limiting (see: Section 3.13). 927 When an IP packet enters a Relay's AERO interface from the link- 928 layer, the Relay processes the packet as follows: 930 o if the destination does not match an ASP, or if the destination 931 matches one of the Relay's own addresses, the Relay decapsulates 932 the packet and forwards it to the network layer where it will be 933 subject to either local delivery or IP forwarding. 935 o else, if the destination matches an ACP entry in the IP forwarding 936 table, or if the destination matches the link-local address in a 937 permanent neighbor cache entry, the Relay first determines whether 938 the neighbor is the same as the one it received the packet from. 939 If so the Relay MUST drop the packet silently to avoid looping; 940 otherwise, the Relay uses the neighbor's link-layer address as the 941 destination for encapsulation and re-admits the packet into the 942 AERO link. 944 o else, the Relay drops the packet and (for non-link-local 945 addresses) returns an ICMP Destination Unreachable message subject 946 to rate limiting (see: Section 3.13). 948 3.9. AERO Interface Encapsulation and Re-encapsulation 950 AERO interfaces encapsulate IP packets according to whether they are 951 entering the AERO interface from the network layer or if they are 952 being re-admitted into the same AERO link they arrived on. This 953 latter form of encapsulation is known as "re-encapsulation". 955 The AERO interface encapsulates packets per the Generic UDP 956 Encapsulation (GUE) procedures in 957 [I-D.ietf-nvo3-gue][I-D.herbert-gue-fragmentation], or through an 958 alternate encapsulation format (see: Appendix A). For packets 959 entering the AERO interface from the network layer, the AERO 960 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 961 [RFC2983], "Flow Label"[RFC6438].(for IPv6) and "Congestion 962 Experienced" [RFC3168] values in the packet's IP header into the 963 corresponding fields in the encapsulation IP header. For packets 964 undergoing re-encapsulation, the AERO interface instead copies these 965 values from the original encapsulation IP header into the new 966 encapsulation header, i.e., the values are transferred between 967 encapsulation headers and *not* copied from the encapsulated packet's 968 network-layer header. (Note especially that by copying the TTL/Hop 969 Limit between encapsulation headers the value will eventually 970 decrement to 0 if there is a (temporary) routing loop.) For IPv4 971 encapsulation/re-encapsulation, the AERO interface sets the DF bit as 972 discussed in Section 3.12. 974 When GUE encapsulation is used, the AERO interface next sets the UDP 975 source port to a constant value that it will use in each successive 976 packet it sends, and sets the UDP length field to the length of the 977 encapsulated packet plus 8 bytes for the UDP header itself plus the 978 length of the GUE header (or 0 if GUE direct IP encapsulation is 979 used). For packets sent to a Server or Relay, the AERO interface 980 sets the UDP destination port to 8060, i.e., the IANA-registered port 981 number for AERO. For packets sent to a Client, the AERO interface 982 sets the UDP destination port to the port value stored in the 983 neighbor cache entry for this Client. The AERO interface then either 984 includes or omits the UDP checksum according to the GUE 985 specification. 987 3.10. AERO Interface Decapsulation 989 AERO interfaces decapsulate packets destined either to the AERO node 990 itself or to a destination reached via an interface other than the 991 AERO interface the packet was received on. Decapsulation is per the 992 procedures specified for the appropriate encapsulation format. 994 3.11. AERO Interface Data Origin Authentication 996 AERO nodes employ simple data origin authentication procedures for 997 encapsulated packets they receive from other nodes on the AERO link. 998 In particular: 1000 o AERO Servers, Relays and Proxies accept encapsulated packets with 1001 a link-layer source address that matches a permanent neighbor 1002 cache entry. 1004 o AERO Servers accept authentic encapsulated DHCPv6 and IPv6 ND 1005 messages from Clients, and create or update a static neighbor 1006 cache entry for the Client based on the specific message type. 1008 o AERO Clients and Servers accept encapsulated packets if there is a 1009 static neighbor cache entry with a link-layer address that matches 1010 the packet's link-layer source address. 1012 o AERO Clients and Servers accept encapsulated packets if there is a 1013 dynamic neighbor cache entry with an AERO address that matches the 1014 packet's network-layer source address, with a link-layer address 1015 that matches the packet's link-layer source address, and with a 1016 non-zero AcceptTime. 1018 Note that this simple data origin authentication is effective in 1019 environments in which link-layer addresses cannot be spoofed. In 1020 other environments, each AERO message must include a signature that 1021 the recipient can use to authenticate the message origin, e.g., as 1022 for common VPN systems such as OpenVPN [OVPN]. In environments where 1023 end systems use end-to-end security, however, it may be sufficient to 1024 require signatures only for AERO DHCPv6, IPv6 ND and ICMP control 1025 plane messages and omit signatures for data plane messages. 1027 3.12. AERO Interface Packet Size Issues 1029 The AERO interface is the node's attachment to the AERO link. The 1030 AERO interface acts as a tunnel ingress when it sends a packet to an 1031 AERO link neighbor and as a tunnel egress when it receives a packet 1032 from an AERO link neighbor. AERO interfaces observe the packet 1033 sizing considerations for tunnels discussed in 1034 [I-D.ietf-intarea-tunnels] and as specified below. 1036 The Internet Protocol expects that IP packets will either be 1037 delivered to the destination or a suitable Packet Too Big (PTB) 1038 message returned to support the process known as IP Path MTU 1039 Discovery (PMTUD) [RFC1191][RFC1981]. However, PTB messages may be 1040 crafted for malicious purposes such as denial of service, or lost in 1041 the network [RFC2923]. This can be especially problematic for 1042 tunnels, where a condition known as a PMTUD "black hole" can result. 1043 For these reasons, AERO interfaces employ operational procedures that 1044 avoid interactions with PMTUD, including the use of fragmentation 1045 when necessary. 1047 AERO interfaces observe two different types of fragmentation. Source 1048 fragmentation occurs when the AERO interface (acting as a tunnel 1049 ingress) fragments the encapsulated packet into multiple fragments 1050 before admitting each fragment into the tunnel. Network 1051 fragmentation occurs when an encapsulated packet admitted into the 1052 tunnel by the ingress is fragmented by an IPv4 router on the path to 1053 the egress. Note that a packet that incurs source fragmentation may 1054 also incur network fragmentation. 1056 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 1057 bytes [RFC2460]. Although IPv4 specifies a smaller minimum link MTU 1058 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 1059 for IPv4 even if encapsulated packets may incur network 1060 fragmentation. 1062 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 1063 [RFC2460], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 1064 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 1065 than the IPv4 minimum). 1067 AERO interfaces therefore configure an MTU that MUST NOT be smaller 1068 than 1280 bytes, MUST NOT be larger than the minimum MRU among all 1069 nodes on the AERO link minus the encapsulation overhead ("ENCAPS"), 1070 and SHOULD NOT be smaller than 1500 bytes. AERO interfaces also 1071 configure a Maximum Segment Unit (MSU) as the maximum-sized 1072 encapsulated packet that the ingress can inject into the tunnel 1073 without source fragmentation. The MSU value MUST NOT be larger than 1074 (MTU+ENCAPS) and MUST NOT be larger than 1280 bytes unless there is 1075 operational assurance that a larger size can traverse the link along 1076 all paths. 1078 All AERO nodes MUST configure the same MTU/MSU values for reasons 1079 cited in [RFC3819][RFC4861]; in particular, multicast support 1080 requires a common MTU value among all nodes on the link. All AERO 1081 nodes MUST configure an MRU large enough to reassemble packets up to 1082 (MTU+ENCAPS) bytes in length; nodes that cannot configure a large- 1083 enough MRU MUST NOT enable an AERO interface. 1085 The network layer proceeds as follow when it presents an IP packet to 1086 the AERO interface. For each IPv4 packet that is larger than the 1087 AERO interface MTU and with the DF bit set to 0, the network layer 1088 uses IPv4 fragmentation to break the packet into a minimum number of 1089 non-overlapping fragments where the first fragment is no larger than 1090 the MTU and the remaining fragments are no larger than the first. 1091 For all other IP packets, if the packet is larger than the AERO 1092 interface MTU, the network layer drops the packet and returns a PTB 1093 message to the original source. Otherwise, the network layer admits 1094 each IP packet or fragment into the AERO interface. 1096 For each IP packet admitted into the AERO interface, the interface 1097 (acting as a tunnel ingress) encapsulates the packet. If the 1098 encapsulated packet is larger than the AERO interface MSU the ingress 1099 source-fragments the encapsulated packet into a minimum number of 1100 non-overlapping fragments where the first fragment is no larger than 1101 the MSU and the remaining fragments are no larger than the first. 1102 The ingress then admits each encapsulated packet or fragment into the 1103 tunnel, and for IPv4 sets the DF bit to 0 in the IP encapsulation 1104 header in case any network fragmentation is necessary. The 1105 encapsulated packets will be delivered to the egress, which 1106 reassembles them into a whole packet if necessary. 1108 Several factors must be considered when fragmentation is needed. For 1109 AERO links over IPv4, the IP ID field is only 16 bits in length, 1110 meaning that fragmentation at high data rates could result in data 1111 corruption due to reassembly misassociations [RFC6864][RFC4963]. For 1112 AERO links over both IPv4 and IPv6, studies have also shown that IP 1113 fragments are dropped unconditionally over some network paths [I- 1114 D.taylor-v6ops-fragdrop]. In environments where IP fragmentation 1115 issues could result in operational problems, the ingress SHOULD 1116 employ intermediate-layer source fragmentation (see: [RFC2764] and 1117 [I-D.herbert-gue-fragmentation]) before appending the outer 1118 encapsulation headers to each fragment. Since the encapsulation 1119 fragment header reduces the room available for packet data, but the 1120 original source has no way to control its insertion, the ingress MUST 1121 include the fragment header length in the ENCAPS length even for 1122 packets in which the header is absent. 1124 3.13. AERO Interface Error Handling 1126 When an AERO node admits encapsulated packets into the AERO 1127 interface, it may receive link-layer or network-layer error 1128 indications. 1130 A link-layer error indication is an ICMP error message generated by a 1131 router on the path to the neighbor or by the neighbor itself. The 1132 message includes an IP header with the address of the node that 1133 generated the error as the source address and with the link-layer 1134 address of the AERO node as the destination address. 1136 The IP header is followed by an ICMP header that includes an error 1137 Type, Code and Checksum. Valid type values include "Destination 1138 Unreachable", "Time Exceeded" and "Parameter Problem" 1139 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1140 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1141 only emit packets that are guaranteed to be no larger than the IP 1142 minimum link MTU as discussed in Section 3.12.) 1144 The ICMP header is followed by the leading portion of the packet that 1145 generated the error, also known as the "packet-in-error". For 1146 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1147 much of invoking packet as possible without the ICMPv6 packet 1148 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1149 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1150 "Internet Header + 64 bits of Original Data Datagram", however 1151 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1152 ICMP datagram SHOULD contain as much of the original datagram as 1153 possible without the length of the ICMP datagram exceeding 576 1154 bytes". 1156 The link-layer error message format is shown in Figure 3 (where, "L2" 1157 and "L3" refer to link-layer and network-layer, respectively): 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 ~ ~ 1161 | L2 IP Header of | 1162 | error message | 1163 ~ ~ 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | L2 ICMP Header | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1167 ~ ~ P 1168 | IP and other encapsulation | a 1169 | headers of original L3 packet | c 1170 ~ ~ k 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1172 ~ ~ t 1173 | IP header of | 1174 | original L3 packet | i 1175 ~ ~ n 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 ~ ~ e 1178 | Upper layer headers and | r 1179 | leading portion of body | r 1180 | of the original L3 packet | o 1181 ~ ~ r 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1184 Figure 3: AERO Interface Link-Layer Error Message Format 1186 The AERO node rules for processing these link-layer error messages 1187 are as follows: 1189 o When an AERO node receives a link-layer Parameter Problem message, 1190 it processes the message the same as described as for ordinary 1191 ICMP errors in the normative references [RFC0792][RFC4443]. 1193 o When an AERO node receives persistent link-layer Time Exceeded 1194 messages, the IP ID field may be wrapping before earlier fragments 1195 awaiting reassembly have been processed. In that case, the node 1196 SHOULD begin including integrity checks and/or institute rate 1197 limits for subsequent packets. 1199 o When an AERO node receives persistent link-layer Destination 1200 Unreachable messages in response to encapsulated packets that it 1201 sends to one of its dynamic neighbor correspondents, the node 1202 SHOULD test the path to the correspondent using Neighbor 1203 Unreachability Detection (NUD) (see Section 3.16). If NUD fails, 1204 the node SHOULD set ForwardTime for the corresponding dynamic 1205 neighbor cache entry to 0 and allow future packets destined to the 1206 correspondent to flow through a default route. 1208 o When an AERO Client receives persistent link-layer Destination 1209 Unreachable messages in response to encapsulated packets that it 1210 sends to one of its static neighbor Servers, the Client SHOULD 1211 test the path to the Server using NUD. If NUD fails, the Client 1212 SHOULD associate with a new Server and send a DHCPv6 Release 1213 message to the old Server as specified in Section 3.17.6. 1215 o When an AERO Server receives persistent link-layer Destination 1216 Unreachable messages in response to encapsulated packets that it 1217 sends to one of its static neighbor Clients, the Server SHOULD 1218 test the path to the Client using NUD. If NUD fails, the Server 1219 SHOULD cancel the Client's ACP prefix delegation, withdraw its 1220 route for the ACP from the AERO routing system and delete the 1221 neighbor cache entry (see Section 3.16 and Section 3.17). 1223 o When an AERO Relay or Server receives link-layer Destination 1224 Unreachable messages in response to an encapsulated packet that it 1225 sends to one of its permanent neighbors, it treats the messages as 1226 an indication that the path to the neighbor may be failing. 1227 However, neighbor reachability will be determined by the dynamic 1228 routing protocol. 1230 When an AERO Relay receives a packet for which the network-layer 1231 destination address is covered by an ASP, if there is no more- 1232 specific routing information for the destination the Relay drops the 1233 packet and returns a network-layer Destination Unreachable message 1234 subject to rate limiting. The Relay first writes the network-layer 1235 source address of the original packet as the destination address of 1236 the message and determines the next hop to the destination. If the 1237 next hop is reached via the AERO interface, the Relay uses the IPv6 1238 address "::" or the IPv4 address "0.0.0.0" as the source address of 1239 the message, then encapsulates the message and forwards it to the 1240 next hop within the AERO interface. Otherwise, the Relay uses one of 1241 its non link-local addresses as the source address of the message and 1242 forwards it via a link outside the AERO interface. 1244 When an AERO node receives an encapsulated packet for which the 1245 reassembly buffer it too small, it drops the packet and returns an 1246 network-layer Packet Too Big (PTB) message. The node first writes 1247 the MRU value into the PTB message MTU field, writes the network- 1248 layer source address of the original packet as the destination 1249 address of the message and determines the next hop to the 1250 destination. If the next hop is reached via the AERO interface, the 1251 node uses the IPv6 address "::" or the IPv4 address "0.0.0.0" as the 1252 source address of the message, then encapsulates the message and 1253 forwards it to the next hop within the AERO interface. Otherwise, 1254 the node uses one of its non link-local addresses as the source 1255 address of the message and forwards it via a link outside the AERO 1256 interface. 1258 When an AERO node receives any network-layer error message via the 1259 AERO interface, it examines the network-layer destination address. 1260 If the next hop toward the destination is via the AERO interface, the 1261 node re-encapsulates and forwards the message to the next hop within 1262 the AERO interface. Otherwise, if the network-layer source address 1263 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1264 writes one of its non link-local addresses as the source address, 1265 recalculates the IP and/or ICMP checksums then forwards the message 1266 via a link outside the AERO interface. 1268 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1270 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1271 coordinated by the DHCPv6 and IPv6 ND control messaging protocols as 1272 discussed in the following Sections. 1274 3.14.1. AERO DHCPv6 and IPv6 ND Service Model 1276 Each AERO Server configures a DHCPv6 server function to facilitate PD 1277 requests from Clients. Each Server is provisioned with a database of 1278 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1279 system, as well as any information necessary to authenticate each 1280 Client. The Client database is maintained by a central 1281 administrative authority for the AERO link and securely distributed 1282 to all Servers, e.g., via the Lightweight Directory Access Protocol 1283 (LDAP) [RFC4511], via static configuration, etc. 1285 Therefore, no Server-to-Server DHCPv6 PD state synchronization is 1286 necessary, and Clients can optionally hold separate PDs for the same 1287 ACPs from multiple Servers. In this way, Clients can associate with 1288 multiple Servers, and can receive new PDs from new Servers before 1289 deprecating PDs received from existing Servers. This provides the 1290 Client with a natural fault-tolerance and/or load balancing profile. 1292 AERO Clients and Servers use unicast IPv6 ND messages to maintain 1293 neighbor cache entries the same as for any link. AERO Servers 1294 configure their AERO interfaces as advertising interfaces, and 1295 therefore send unicast RA messages with configuration information in 1296 response to a Client's RS message. 1298 The following sections specify the Client and Server behavior. 1300 3.14.2. AERO Client Behavior 1302 AERO Clients discover the link-layer addresses of AERO Servers via 1303 static configuration (e.g., from a flat-file map of Server addresses 1304 and locations), or through an automated means such as DNS name 1305 resolution. In the absence of other information, the Client resolves 1306 the FQDN "linkupnetworks.[domainname]" where "linkupnetworks" is a 1307 constant text string and "[domainname]" is a DNS suffix for the 1308 Client's underlying network (e.g., "example.com"). After discovering 1309 the link-layer addresses, the Client associates with one or more of 1310 the corresponding Servers. 1312 To associate with a Server, the Client acts as a requesting router to 1313 request ACPs through a DHCPv6 PD exchange [RFC3315][RFC3633] in 1314 conjunction with standard IPv6 ND Router Discovery. The Client 1315 prepares an RS message with an embedded DHCPv6 Solicit message per 1316 [I-D.templin-6man-dhcpv6-ndopt] with fe80::ffff:ffff as the IPv6 1317 source address, All-Routers multicast as the IPv6 destination 1318 address, the address of the Client's underlying interface as the 1319 link-layer source address and the link-layer address of the Server as 1320 the link-layer destination address. 1322 In the embedded DHCPv6 Solicit message, the Client includes a Client 1323 Identifier option with the Client's DUID, and an Identity Association 1324 for Prefix Delegation (IA_PD) option. If the Client is pre- 1325 provisioned with ACPs associated with the AERO service, it MAY also 1326 include the ACPs in the IA_PD to indicate its preferences to the 1327 DHCPv6 server. The Client finally includes any additional DHCPv6 1328 options, including any necessary authentication options to identify 1329 itself to the DHCPv6 server. 1331 The Client next includes one or more SLLAOs in the RS formatted as 1332 described in Section 3.5 to register its link-layer address(es) with 1333 the Server. The first SLLAO MUST correspond to the underlying 1334 interface over which the Client will send the RS/DHCPv6 message. The 1335 Client MAY include additional SLLAOs specific to other underlying 1336 interfaces, but if so it MUST have assurance that there will be no 1337 NATs on the paths to the Server via those interfaces. (Otherwise, 1338 the Client can register additional link-layer addresses with the 1339 Server by sending subsequent NS/RS messages via different underlying 1340 interfaces after the initial RS/RA exchange). The Server will use 1341 the SLLAOs to populate its link-layer address information for the 1342 Client. 1344 The Client then sends the combined RS/DHCPv6 message to the AERO 1345 Server and waits for an RA reply (see Section 3.14.3) while retrying 1346 MAX_RETRY times until an RA is received. If no RA is received, or if 1347 the RA includes a zero Router Lifetime, the Client SHOULD discontinue 1348 autoconfiguration attempts through this Server and try another 1349 Server. Otherwise, the Client processes the embedded DHCPv6 Reply 1350 message and verifies that the message contains valid ACPs in IA_PD 1351 options. 1353 Next, the Client creates a static neighbor cache entry with the 1354 Server's link-local address as the network-layer address and the 1355 Server's encapsulation source address as the link-layer address. The 1356 Client then autoconfigures AERO addresses for each of the delegated 1357 ACPs and assigns the base AERO addresses to the AERO interface. 1359 The Client next examines the Code value in the RA message; if Code 1360 was 1 the Client can assume there was a NAT on the path to the 1361 Server. The Client also caches any ASPs included in Route 1362 Information Options (RIOs) [RFC4191] as ASPs to associate with the 1363 AERO link, and assigns the MTU/MSU values in the MTU options to its 1364 AERO interface while configuring an appropriate MRU. This 1365 configuration information applies to the AERO link as a whole, and 1366 all AERO nodes will use the same values. 1368 Following autoconfiguration, the Client sub-delegates the ACPs to its 1369 attached EUNs and/or the Client's own internal virtual interfaces as 1370 described in [I-D.templin-v6ops-pdhost]. The Client subsequently 1371 renews its ACP delegations through each of its Servers by sending RS/ 1372 DHCPv6 Renew messages. 1374 After the Client registers its Interface IDs and their associated 1375 UDP/IP addresses and 'P(i)' values, it may wish to change one or more 1376 Interface ID registrations, e.g., if an underlying interface becomes 1377 unavailable, if quality of service profiles change, etc. To do so, 1378 the Client prepares an unsolicited NA message to send over any 1379 available underlying interface. The NA MUST include a TLLAO specific 1380 to the selected available underlying interface as the first TLLAO and 1381 MAY include any additional TLLAOs specific to other underlying 1382 interfaces. The Client includes fresh 'P(i)' values in each TLLAO to 1383 update the Server's neighbor cache entry. If the Client wishes to 1384 disable some or all DSCPs for an underlying interface, it includes an 1385 TLLAO with 'P(i)' values set to 0 ("disabled"). 1387 If the Client wishes to discontinue use of a Server it issues an RS 1388 with an embedded DHCPv6 Release message. When the Server processes 1389 the message, it releases the DHCPv6 PD, deletes its neighbor cache 1390 entry for the Client, withdraws the IP route from the routing system 1391 and returns an RA response with Router Lifetime set to 0. 1393 3.14.3. AERO Server Behavior 1395 AERO Servers act as IPv6 routers and configure a DHCPv6 server 1396 function on their AERO links. AERO Servers arrange to add their 1397 encapsulation layer IP addresses (i.e., their link-layer addresses) 1398 to a static map of Server addresses for the link and/or the DNS 1399 resource records for the FQDN "linkupnetworks.[domainname]" before 1400 entering service. 1402 When an AERO Server receives a prospective Client's RS with embedded 1403 DHCPv6 Solicit message on its AERO interface, and the Server is too 1404 busy, it SHOULD return an RA with Router Lifetime set to 0. 1405 Otherwise, the Server processes the embedded DHCPv6 Solicit message. 1406 If authentication succeeds, the Server determines the correct ACPs to 1407 delegate to the Client by searching the Client database. When the 1408 Server delegates the ACPs, it also creates an IP forwarding table 1409 entry for each ACP so that the AERO BGP-based routing system will 1410 propagate the ACPs to the Relays that aggregate the corresponding ASP 1411 (see: Section 3.3). 1413 Next, the Server prepares a DHCPv6 Reply message with IA_PD options 1414 with the delegated ACPs. For IPv4 ACPs, the prefix included in the 1415 IA_PD option is in IPv4-mapped IPv6 address format and with prefix 1416 length set as specified in Section 3.4. The Server then prepares a 1417 unicast RA message using its link-local address (i.e., fe80::ID) as 1418 the network-layer source address, the Client's base AERO address as 1419 the network-layer destination address, the Server's link-layer 1420 address as the source link-layer address, and the source link-layer 1421 address of the RS message as the destination link-layer address. In 1422 the RA message, if the actual encapsulation source address in the RS 1423 message was the same as that in the first SLLAO (see above), the 1424 Server sets the Code field to 0; otherwise it sets Code to 1. The 1425 Server then includes one or more RIOs that encode the ASPs for the 1426 AERO link. The Server also includes two MTU options - the first MTU 1427 option includes the MTU for the link and the second MTU option 1428 includes the MSU for the link (see Section 3.12). The Server finally 1429 embeds the body of the DHCPv6 Reply message in the RA, then sends the 1430 RA to the Client. 1432 The Server next creates a static neighbor cache entry for the Client 1433 using the base AERO address as the network-layer address and with 1434 lifetime set to no more than the smallest PD lifetime. Next, the 1435 Server updates the neighbor cache entry link-layer address(es) by 1436 recording the information in each SLLAO option indexed by the 1437 Interface ID and including the UDP port number, IP address and P(i) 1438 values. For the first SLLAO in the list, however, the Server records 1439 the actual encapsulation source UDP and IP addresses instead of those 1440 that appear in the SLLAO in case there was a NAT in the path. 1442 After the initial RS/RA/DHCPv6 exchange, the AERO Server maintains 1443 the neighbor cache entry for the Client until the PD lifetimes 1444 expire. If the Client issues a Renew, the Server extends the PD 1445 lifetimes. If the Client issues a Release, or if the Client does not 1446 issue a Renew before the lifetime expires, the Server deletes the 1447 neighbor cache entry for the Client and withdraws the IP routes from 1448 the AERO routing system. 1450 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1452 AERO Clients and Servers are always on the same link (i.e., the AERO 1453 link) from the perspective of DHCPv6. However, in some 1454 implementations the DHCPv6 server and IPv6 ND function may be located 1455 in separate modules. In that case, the Server's AERO interface 1456 driver module can act as a Lightweight DHCPv6 Relay Agent 1457 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1458 server module. 1460 When the LDRA receives an RS/DHCPv6 message, it extracts the DHCPv6 1461 message and wraps it in IPv6/UDP headers. It sets the IPv6 source 1462 address to the source address of the RS message, sets the IPv6 1463 destination address to 'All_DHCP_Relay_Agents_and_Servers' and sets 1464 the UDP fields to values that will be understood by the DHCPv6 1465 server. 1467 The LDRA then wraps the message in a Relay-Forward message header and 1468 includes an Interface-ID option that includes enough information to 1469 allow the LDRA to forward the resulting Reply message back to the 1470 Client (e.g., the Client's link-layer addresses, a security 1471 association identifier, etc). The LDRA also wraps the information in 1472 all of the SLLAO options from the RS message into the Interface-ID 1473 option, then forwards the message to the DHCPv6 server. 1475 When the DHCPv6 server prepares a Reply message, it wraps the message 1476 in a Relay-Reply message and echoes the Interface-ID option. The 1477 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1478 which discards the Relay-Reply wrapper and delivers the DHCPv6 1479 message to be wrapped into an RA response to the Client. The Server 1480 uses the information in the Interface ID option to prepare the RA 1481 message and to cache the link-layer addresses taken from the SLLAOs 1482 echoed in the Interface-ID option. 1484 3.15. AERO Interface Route Optimization 1486 When a source Client forwards packets to a prospective correspondent 1487 Client within the same AERO link domain (i.e., one for which the 1488 packet's destination address is covered by an ASP), the source Client 1489 MAY initiate an AERO link route optimization procedure. The 1490 procedure is based on an exchange of IPv6 ND messages using a chain 1491 of AERO Servers and Relays as a trust basis. 1493 Although the Client is responsible for initiating route optimization, 1494 the Server is the policy enforcement point that determines whether 1495 route optimization is permitted. For example, on some AERO links 1496 route optimization would allow traffic to circumvent critical 1497 network-based traffic interception points. In those cases, the 1498 Server can simply discard any route optimization messages instead of 1499 forwarding them. 1501 The following sections specify the AERO link route optimization 1502 procedure. 1504 3.15.1. Reference Operational Scenario 1506 Figure 4 depicts the AERO link route optimization reference 1507 operational scenario, using IPv6 addressing as the example (while not 1508 shown, a corresponding example for IPv4 addressing can be easily 1509 constructed). The figure shows an AERO Relay ('R1'), two AERO 1510 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1511 IPv6 hosts ('H1', 'H2'): 1513 +--------------+ +--------------+ +--------------+ 1514 | Server S1 | | Relay R1 | | Server S2 | 1515 +--------------+ +--------------+ +--------------+ 1516 fe80::2 fe80::1 fe80::3 1517 L2(S1) L2(R1) L2(S2) 1518 | | | 1519 X-----+-----+------------------+-----------------+----+----X 1520 | AERO Link | 1521 L2(C1) L2(C2) 1522 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1523 +--------------+ +--------------+ 1524 |AERO Client C1| |AERO Client C2| 1525 +--------------+ +--------------+ 1526 2001:DB8:0::/48 2001:DB8:1::/48 1527 | | 1528 .-. .-. 1529 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1530 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 1531 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 1532 `-(______)-' +-------+ +-------+ `-(______)-' 1534 Figure 4: AERO Reference Operational Scenario 1536 In Figure 4, Relay ('R1') assigns the administratively-provisioned 1537 link-local address fe80::1 to its AERO interface with link-layer 1538 address L2(R1), Server ('S1') assigns the address fe80::2 with link- 1539 layer address L2(S1),and Server ('S2') assigns the address fe80::3 1540 with link-layer address L2(S2). Servers ('S1') and ('S2') next 1541 arrange to add their link-layer addresses to a published list of 1542 valid Servers for the AERO link. 1544 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1545 exchange via AERO Server ('S1') then assigns the address 1546 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1547 L2(C1). Client ('C1') configures a default route and neighbor cache 1548 entry via the AERO interface with next-hop address fe80::2 and link- 1549 layer address L2(S1), then sub-delegates the ACP to its attached 1550 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1551 address 2001:db8:0::1. 1553 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1554 exchange via AERO Server ('S2') then assigns the address 1555 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1556 L2(C2). Client ('C2') configures a default route and neighbor cache 1557 entry via the AERO interface with next-hop address fe80::3 and link- 1558 layer address L2(S2), then sub-delegates the ACP to its attached 1559 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1560 address 2001:db8:1::1. 1562 3.15.2. Concept of Operations 1564 Again, with reference to Figure 4, when source host ('H1') sends a 1565 packet to destination host ('H2'), the packet is first forwarded over 1566 the source host's attached EUN to Client ('C1'). Client ('C1') then 1567 forwards the packet via its AERO interface to Server ('S1') and also 1568 sends an NS message toward Client ('C2') via Server ('S1'). Server 1569 ('S1') then re-encapsulates and forwards both the packet and the NS 1570 message out the same AERO interface toward Client ('C2') via Relay 1571 ('R1'). 1573 When Relay ('R1') receives the packet and NS message, it consults its 1574 forwarding table to discover Server ('S2') as the next hop toward 1575 Client ('C2'). Relay ('R1') then forwards both the packet and the NS 1576 message to Server ('S2'), which then forwards them to Client ('C2'). 1578 After Client ('C2') receives the NS message, it process the message 1579 and returns an NA message toward Client ('C1') via Server ('S2'). 1580 During the process, Client ('C2') also creates or updates a dynamic 1581 neighbor cache entry for Client ('C1'). 1583 When Server ('S2') receives the NA message, it re-encapsulates the 1584 message and forwards it on to Relay ('R1'), which forwards the 1585 message on to Server ('S1') which forwards the message on to Client 1586 ('C1'). After Client ('C1') receives the NA message, it processes 1587 the message and creates or updates a dynamic neighbor cache entry for 1588 Client ('C2'). 1590 Following the above NS/NA message exchange, forwarding of packets 1591 from Client ('C1') to Client ('C2') without involving any 1592 intermediate nodes is enabled. The mechanisms that support this 1593 exchange are specified in the following sections. 1595 3.15.3. Sending NS Messages 1597 When a Client forwards a packet with a source address from one of its 1598 ACPs toward a destination address covered by an ASP (i.e., toward 1599 another AERO Client connected to the same AERO link), the source 1600 Client MAY send an NS message forward toward the destination Client 1601 via the Server. 1603 In the reference operational scenario, when Client ('C1') forwards a 1604 packet toward Client ('C2'), it MAY also send an NS message forward 1605 toward Client ('C2'), subject to rate limiting (see Section 8.2 of 1606 [RFC4861]). Client ('C1') prepares the NS message as follows: 1608 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1609 layer address of Client ('C1')). 1611 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1612 link-layer address of Server ('S1')). 1614 o the network-layer source address is set to fe80::2001:db8:0:0 1615 (i.e., the base AERO address of Client ('C1')). 1617 o the network-layer destination address is set to the AERO address 1618 corresponding to the destination address of Client ('C2'). 1620 o the Type is set to 135. 1622 o the Target Address is set to the destination address of the packet 1623 that triggered route optimization. 1625 o the message includes one or more SLLAOs set to appropriate values 1626 for Client ('C1')'s underlying interfaces. 1628 o the message includes one or more RIOs that include Client ('C1')'s 1629 ACPs [I-D.templin-6man-rio-redirect]. 1631 o the message SHOULD include a Timestamp option and a Nonce option. 1633 Note that the act of sending NS messages is cited as "MAY", since 1634 Client ('C1') may have advanced knowledge that the direct path to 1635 Client ('C2') would be unusable or otherwise undesirable. If the 1636 direct path later becomes unusable after the initial route 1637 optimization, Client ('C1') simply allows packets to again flow 1638 through Server ('S1'). 1640 3.15.4. Re-encapsulating and Relaying the NS 1642 When Server ('S1') receives an NS message from Client ('C1'), it 1643 first verifies that the SLLAOs in the NS are a proper subset of the 1644 link-layer addresses in Client ('C1')'s neighbor cache entry. If the 1645 Client's SLLAOs are not acceptable, Server ('S1') discards the 1646 message. Otherwise, Server ('S1') verifies that Client ('C1') is 1647 authorized to use the ACPs encoded in the RIOs of the NS. If 1648 validation fails, Server ('S1') discards the NS; otherwise, it copies 1649 the correct UDP Port number and IP Address for Client ('C1')'s 1650 underlying link into the first SLLAO in case the addresses have been 1651 subject to NAT. 1653 Server ('S1') then examines the network-layer destination address of 1654 the NS to determine the next hop toward Client ('C2') by searching 1655 for the AERO address in the neighbor cache. Since Client ('C2') is 1656 not one of its neighbors, Server ('S1') re-encapsulates the NS and 1657 relays it via Relay ('R1') by changing the link-layer source address 1658 of the message to 'L2(S1)' and changing the link-layer destination 1659 address to 'L2(R1)'. Server ('S1') finally forwards the re- 1660 encapsulated message to Relay ('R1') without decrementing the 1661 network-layer TTL/Hop Limit field. 1663 When Relay ('R1') receives the NS message from Server ('S1') it 1664 determines that Server ('S2') is the next hop toward Client ('C2') by 1665 consulting its forwarding table. Relay ('R1') then re-encapsulates 1666 the NS while changing the link-layer source address to 'L2(R1)' and 1667 changing the link-layer destination address to 'L2(S2)'. Relay 1668 ('R1') then relays the NS via Server ('S2'). 1670 When Server ('S2') receives the NS message from Relay ('R1') it 1671 determines that Client ('C2') is a neighbor by consulting its 1672 neighbor cache. Server ('S2') then re-encapsulates the NS while 1673 changing the link-layer source address to 'L2(S2)' and changing the 1674 link-layer destination address to 'L2(C2)'. Server ('S2') then 1675 forwards the message to Client ('C2'). 1677 3.15.5. Processing NSs and Sending NAs 1679 When Client ('C2') receives the NS message, it accepts the NS only if 1680 the message has a link-layer source address of one of its Servers 1681 (e.g., L2(S2)). Client ('C2') further accepts the message only if it 1682 is willing to serve as a route optimization target. 1684 In the reference operational scenario, when Client ('C2') receives a 1685 valid NS message, it either creates or updates a dynamic neighbor 1686 cache entry that stores the source address of the message as the 1687 network-layer address of Client ('C1') , stores the link-layer 1688 addresses found in the TLLAOs as the link-layer addresses of Client 1689 ('C1'), and stores the ACPs encoded in the RIOs of the NS as the ACPs 1690 for Client ('C1'). Client ('C2') then sets AcceptTime for the 1691 neighbor cache entry to ACCEPT_TIME. 1693 After processing the message, Client ('C2') prepares an NA message 1694 response as follows: 1696 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1697 layer address of Client ('C2')). 1699 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1700 link-layer address of Server ('S2')). 1702 o the network-layer source address is set to fe80::2001:db8:1:0 1703 (i.e., the base AERO address of Client ('C2')). 1705 o the network-layer destination address is set to fe80::2001:db8:0:0 1706 (i.e., the base AERO address of Client ('C1')). 1708 o the Type is set to 136. 1710 o The Target Addrress is set to the Target Address field in the NS 1711 message. 1713 o the message includes one or more TLLAOs set to appropriate values 1714 for Client ('C2')'s underlying interfaces. 1716 o the message includes one or more RIOs that include Client ('C2')'s 1717 ACPs [I-D.templin-6man-rio-redirect]. 1719 o the message SHOULD include a Timestamp option and MUST echo the 1720 Nonce option received in the NS (i.e., if a Nonce option is 1721 included). 1723 After Client ('C2') prepares the NA message, it sends the message to 1724 Server ('S2'). 1726 3.15.6. Re-encapsulating and Relaying NAs 1728 When Server ('S2') receives an NA message from Client ('C2'), it 1729 first verifies that the TLLAOs in the NA are a proper subset of the 1730 Interface IDs in Client ('C2')'s neighbor cache entry. If the 1731 Client's TLLAOs are not acceptable, Server ('S2') discards the 1732 message. Otherwise, Server ('S2') verifies that Client ('C2') is 1733 authorized to use the ACPs encoded in the RIOs of the NA message. If 1734 validation fails, Server ('S2') discards the NA; otherwise, it copies 1735 the correct UDP Port number and IP Address for Client ('C2')'s 1736 underlying link into the first TLLAO in case the addresses have been 1737 subject to NAT. 1739 Server ('S2') then examines the network-layer destination address of 1740 the NA to determine the next hop toward Client ('C1') by searching 1741 for the AERO address in the neighbor cache. Since Client ('C1') is 1742 not a neighbor, Server ('S2') re-encapsulates the NA and relays it 1743 via Relay ('R1') by changing the link-layer source address of the 1744 message to 'L2(S2)' and changing the link-layer destination address 1745 to 'L2(R1)'. Server ('S2') finally forwards the re-encapsulated 1746 message to Relay ('R1') without decrementing the network-layer TTL/ 1747 Hop Limit field. 1749 When Relay ('R1') receives the NA message from Server ('S2') it 1750 determines that Server ('S1') is the next hop toward Client ('C1') by 1751 consulting its forwarding table. Relay ('R1') then re-encapsulates 1752 the NA while changing the link-layer source address to 'L2(R1)' and 1753 changing the link-layer destination address to 'L2(S1)'. Relay 1754 ('R1') then relays the NA via Server ('S1'). 1756 When Server ('S1') receives the NA message from Relay ('R1') it 1757 determines that Client ('C1') is a neighbor by consulting its 1758 neighbor cache. Server ('S1') then re-encapsulates the NA while 1759 changing the link-layer source address to 'L2(S1)' and changing the 1760 link-layer destination address to 'L2(C1)'. Server ('S1') then 1761 forwards the message to Client ('C1'). 1763 3.15.7. Processing NAs 1765 When Client ('C1') receives the NA message, it accepts the message 1766 only if it has a link-layer source address of one of its Servers 1767 (e.g., 'L2(S1)'). Client ('C1') then processes the message as 1768 follows. 1770 In the reference operational scenario, when Client ('C1') receives 1771 the NA message, it either creates or updates a dynamic neighbor cache 1772 entry that stores the source address of the message as the network- 1773 layer address of Client ('C2'), stores the link-layer addresses found 1774 in the TLLAOs as the link-layer addresses of Client ('C2') and stores 1775 the ACPs encoded in the RIOs of the NA as the ACPs for Client ('C2'). 1776 Client ('C1') then sets ForwardTime for the neighbor cache entry to 1777 FORWARD_TIME. 1779 Now, Client ('C1') has a neighbor cache entry with a valid 1780 ForwardTime value, while Client ('C2') has a neighbor cache entry 1781 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 1782 ordinary network-layer data packets directly to Client ('C2') without 1783 involving any intermediate nodes, and Client ('C2') can verify that 1784 the packets came from an acceptable source. (In order for Client 1785 ('C2') to forward packets to Client ('C1'), a corresponding NS/NA 1786 message exchange is required in the reverse direction; hence, the 1787 mechanism is asymmetric.) 1789 3.15.8. Server-to-Client and Client-to-Server Route Optimization 1791 In some environments, the Server nearest the target Client may need 1792 to serve as a route optimization target, e.g., if direct Client-to- 1793 Client communications are not possible. In that case, when the 1794 source Client sends an NS message the target Server prepares a 1795 corresponding NA the same as if it were the target Client (see: 1796 Section 3.15.5), except that it writes its own link-layer address in 1797 the TLLAO option. The Server must then maintain a dynamic neighbor 1798 cache entry for the source Client. 1800 Similarly, when the source Client must send all packets via its own 1801 Server and cannot act on a route optimization request, the source 1802 Server can send an NS message toward the target Client. The target 1803 Client then prepares a corresponding NA message the same as for 1804 Client-to-Client route optimization and sends the NA message back to 1805 the source Server. 1807 Thereafter, if the target Client moves to a new Server, the old 1808 Server sends unsolicited NA messages with no TLLAOs (subject to rate 1809 limiting) in response to data packets received from a correspondent 1810 node while forwarding the packets themselves to a Relay. The Relay 1811 will then either forward the packets to the new Server if the target 1812 Client has moved, or drop the packets if the target Client is no 1813 longer in the network. The source Client (or Server) then allows 1814 future packets destined to the target Client to again flow through 1815 its own Server (or Relay). Note however that the old Server retains 1816 the neighbor cache entry with its associated AcceptTime since there 1817 may be many packets in flight. When the old Server receives these 1818 packets, it forwards them to a Relay which will forward them to the 1819 departed Client's new Server. AcceptTime will then eventually 1820 decrement to 0 once the correspondent node processes and acts on the 1821 unsolicited NAs. 1823 In any case, a Server MUST NOT send a BGP update to its Relays for 1824 Clients discovered through dynamic route optimization. BGP updates 1825 are only to be sent for the Server's working set of statically- 1826 associated Clients. 1828 3.15.9. Server-to-Server Route Optimization 1830 If neither the source nor target Clients are capable of sending 1831 packets other than via their own Servers, a Server-to-Server route 1832 optimization can still be employed. In that case, the source 1833 Client's Server can send an NS message via a Relay to the AERO 1834 address of the target Client, and the Relay will forward the message 1835 to the target Client's Server. The target Server prepares the NA 1836 message the same as if it were the target Client, except that it 1837 writes its own link-layer address in the TLLAO option then sends the 1838 NA back to the source Server. (The target Server can send the NA 1839 message back to the source Server either directly or via the Relay 1840 according to the security model.) 1842 Thereafter, if the target Client moves to a new Server, the old 1843 Server sends unsolicited NA messages with no TLLAOs (subject to rate 1844 limiting) in response to data packets received from a correspondent 1845 node while forwarding the packets themselves to a Relay. The Relay 1846 will then either forward the packets to the new Server if the target 1847 Client has moved, or drop the packets if the target Client is no 1848 longer in the network. The source Server then allows future packets 1849 destined to the target Client to again flow through a Relay. Note 1850 however that the old Server retains the neighbor cache entry with its 1851 associated AcceptTime since there may be many packets in flight. 1852 When the old Server receives these packets, it forwards them to a 1853 Relay which will forward them to the departed Client's new Server. 1854 AcceptTime will then eventually decrement to 0 once the correspondent 1855 node processes and acts on the unsolicited NAs. 1857 In any case, a Server MUST NOT send a BGP update to its Relays for 1858 correspondents discovered through dynamic route optimization. BGP 1859 updates are only to be sent for the Server's working set of 1860 statically-associated Clients.. 1862 3.16. Neighbor Unreachability Detection (NUD) 1864 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1865 unicast NS messages with SLLAOs to elicit solicited NA messages from 1866 neighbors the same as described in [RFC4861]. NUD is performed 1867 either reactively in response to persistent L2 errors (see 1868 Section 3.13) or proactively to update neighbor cache entry timers 1869 and/or link-layer address information. 1871 When an AERO node sends an NS/NA message, it MUST use one of its 1872 link-local addresses as the IPv6 source address and a link-local 1873 address of the neighbor as the IPv6 destination address. When an 1874 AERO node receives an NS message or a solicited NA message, it 1875 accepts the message if it has a neighbor cache entry for the 1876 neighbor; otherwise, it ignores the message. 1878 When a source AERO node is redirected to a target AERO node it SHOULD 1879 proactively test the direct path by sending an initial NS message to 1880 elicit a solicited NA response. While testing the path, the source 1881 node can optionally continue sending packets via its default router, 1882 maintain a small queue of packets until target reachability is 1883 confirmed, or (optimistically) allow packets to flow directly to the 1884 target. 1886 While data packets are still flowing, the source node thereafter 1887 periodically tests the direct path to the target node (see 1888 Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache 1889 entries alive. When the target node receives a valid NS message, it 1890 resets AcceptTime to ACCEPT_TIME and updates its cached link-layer 1891 addresses (if necessary). When the source node receives a solicited 1892 NA message, it resets ForwardTime to FORWARD_TIME and updates its 1893 cached link-layer addresses (if necessary). If the source node is 1894 unable to elicit a solicited NA response from the target node after 1895 MaxRetry attempts, it SHOULD set ForwardTime to 0. Otherwise, the 1896 source node considers the path usable and SHOULD thereafter process 1897 any link-layer errors as a hint that the direct path to the target 1898 node has either failed or has become intermittent. 1900 When ForwardTime for a dynamic neighbor cache entry expires, the 1901 source node resumes sending any subsequent packets via a Server (or 1902 Relay) and may (eventually) attempt to re-initiate the AERO route 1903 optimization process. When AcceptTime for a dynamic neighbor cache 1904 entry expires, the target node discards any subsequent packets 1905 received directly from the source node. When both ForwardTime and 1906 AcceptTime for a dynamic neighbor cache entry expire, the node 1907 deletes the neighbor cache entry. 1909 3.17. Mobility Management and Quality of Service 1911 3.17.1. Forwarding Packets on Behalf of Departed Clients 1913 When a Server receives packets with destination addresses that do not 1914 match one of its static neighbor cache Clients, it forwards the 1915 packets packets to a Relay and also returns an unsolicited NA message 1916 to sender with no TLLAO. The packets will be delivered to the target 1917 Client's new location, and the sender will realize that it needs to 1918 deprecate its routing inforrmation that associated the target with 1919 this Server. 1921 3.17.2. Announcing Link-Layer Address and Quality of Service Changes 1923 When a Client needs to change its link-layer addresses, e.g., due to 1924 a mobility event, it sends unsolicited NAs to its neighbors using the 1925 new link-layer address as the source address and with TLLAOs that 1926 include the updated Client link-layer information. 1928 Note that this same mechanism is used to change the Client's quality 1929 of service parameters even if the Client's link-layer address itself 1930 is unchanged. The Client can include TLLAOs with P[i] values that 1931 have changed even if the link-layer address is unchanged. 1933 The Client MAY send up to MaxRetry unsolicited NA messages in 1934 parallel with sending actual data packets in case one or more NAs are 1935 lost. If all NAs are lost, the Client will eventually invoke NUD by 1936 sending NS messages that include SLLAOs. 1938 3.17.3. Bringing New Links Into Service 1940 When a Client needs to bring new underlying interfaces into service 1941 (e.g., when it activates a new data link), it sends unsolicited NAs 1942 to its neighbors using the new link-layer address as the source 1943 address and with TLLAOs that include the new Client link-layer 1944 information. 1946 3.17.4. Removing Existing Links from Service 1948 When a Client needs to remove existing underlying interfaces from 1949 service (e.g., when it de-activates an existing data link), it sends 1950 unsolicited NAs to its neighbors with TLLAOs with UDP Port and IP 1951 Address set to 0, and with all P(i) values set to "disabled". 1953 If the Client needs to send the unsolicited NAs over a link other 1954 than the one being removed from service, it MUST include a TLLAO for 1955 the sending link as the first TLLAO and include the TLLAO for the 1956 link being removed from service as an additional TLLAO. 1958 3.17.5. Implicit Mobility Management 1960 AERO interface neighbors MAY include a configuration knob that allows 1961 them to perform implicit mobility management in which no IPv6 ND 1962 messaging is used. In that case, the Client only transmits packets 1963 over a single interface at a time, and the neighbor always observes 1964 packets arriving from the Client from the same link-layer source 1965 address. 1967 If the Client's underlying interface address changes (either due to a 1968 readdressing of the original interface or switching to a new 1969 interface) the neighbor immediately updates the neighbor cache entry 1970 for the Client and begins accepting and sending packets to the 1971 Client's new link-layer address. This implicit mobility method 1972 applies to use cases such as cellphones with both WiFi and Cellular 1973 interfaces where only one of the interfaces is active at a given 1974 time, and the Client automatically switches over to the backup 1975 interface if the primary interface fails. 1977 3.17.6. Moving to a New Server 1979 When a Client associates with a new Server, it performs the Client 1980 procedures specified in Section 3.14.2. 1982 When a Client disassociates with an existing Server, it sends a 1983 DHCPv6 Release message via a new Server with its base AERO address as 1984 the network-layer source address and the unicast link-local address 1985 of the old Server as the network-layer destination address. The new 1986 Server then encapsulates the Release message in a DHCPv6 Relay- 1987 Forward message header, writes the Client's source address in the 1988 'peer-address' field, and writes its own link-local address in the IP 1989 source address (i.e., the new Server acts as a DHCPv6 relay agent). 1990 The new Server then forwards the message to a Relay, which forwards 1991 the message to the old Server based on the network-layer destination 1992 address. 1994 When the old Server receives the Release, it first authenticates the 1995 message then releases the DHCPv6 PDs and deletes the Client's ACP 1996 routes. The old Server then deletes the Client's neighbor cache 1997 entry so that any in-flight packets will be forwarded via a Relay to 1998 the new Server, which will forward them to the Client. The old 1999 Server finally returns a DHCPv6 Relay-Reply message via a Relay to 2000 the new Server, which will decapsulate the DHCPv6 Reply message and 2001 forward it to the Client. 2003 When the new Server forwards the Reply message, the Client can delete 2004 both the default route and the neighbor cache entry for the old 2005 Server. (Note that since Release/Reply messages may be lost in the 2006 network the Client SHOULD retry until it gets a Reply indicating that 2007 the Release was successful. If the Client does not receive a Reply 2008 after MaxRetry attempts, the old Server may have failed and the 2009 Client should discontinue its Release attempts.) 2011 Note that this DHCPv6 relay-chaining approach is provided to avoid 2012 failures, e.g., due to temporary routing fluctuations. In 2013 particular, the Client should always be able to forward messages via 2014 its new Server but may not always be able to send messages directly 2015 to an old Server. But, the new Server and Old Server should always 2016 be able to exchange messages with one another. 2018 Finally, Clients SHOULD NOT move rapidly between Servers in order to 2019 avoid causing excessive oscillations in the AERO routing system. 2020 Such oscillations could result in intermittent reachability for the 2021 Client itself, while causing little harm to the network. Examples of 2022 when a Client might wish to change to a different Server include a 2023 Server that has gone unreachable, topological movements of 2024 significant distance, etc. 2026 3.17.7. Alternate Mobility Security Model 2028 In some environments, an AERO node may have no way of authenticating 2029 any unsolicited NA messages it receives. In that case, the target 2030 AERO node SHOULD ignore any unsolicited NA messages it receives, and 2031 the source AERO node SHOULD inform the target of its new link-layer 2032 addresses by sending a fresh NS message via its Server (or Relay). 2033 The target AERO node can then accept the NS message and update its 2034 link-layer addresses based on the NS SLLAOs. 2036 3.17.8. Packet Queueing for Mobility 2038 AERO Clients and Servers should maintain a small queue of packets 2039 they have recently sent to an AERO neighbor, e.g., a 1 second window. 2040 If the AERO neighbor moves, the AERO node MAY retransmit the queued 2041 packets to ensure that they are delivered to the AERO neighbor's new 2042 location. 2044 Note that this may have performance implications for asymmetric 2045 paths. For example, if the AERO neighbor moves from a 50Mbps link to 2046 a 128Kbps link, retransmitting a 1 second window could cause 2047 significant congestion. However, any retransmission bursts will 2048 subside after the 1 second window. 2050 3.18. Multicast Considerations 2052 When the underlying network does not support multicast, AERO Clients 2053 map link-scoped multicast addresses to the link-layer address of a 2054 Server, which acts as a multicast forwarding agent. The AERO Client 2055 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2056 applications per [RFC4605] while using the link-layer address of the 2057 Server as the link-layer address for all multicast packets. 2059 When the underlying network supports multicast, AERO nodes use the 2060 multicast address mapping specification found in [RFC2529] for IPv4 2061 underlying networks and use a TBD site-scoped multicast mapping for 2062 IPv6 underlying networks. In that case, border routers must ensure 2063 that the encapsulated site-scoped multicast packets do not leak 2064 outside of the site spanned by the AERO link. 2066 4. The AERO Proxy 2068 In some environments, AERO Clients may be located in secured enclaves 2069 (e.g., a corporate enterprise network) that does not allow direct 2070 communications from the Client to the outside world. This is the 2071 same consideration as for web proxies commonly used in enterprise 2072 networks. 2074 The AERO Proxy is located at the secured enclave perimeter and sets a 2075 default route via one or more external Relays in the same way that a 2076 Server would, except the Proxy does not establish BGP peering session 2077 since the Relays will never send packets directly to the Proxy. The 2078 Proxy listens for RS/RA/DHCv6 messages originating from or destined 2079 to AERO Clients located within the enclave and acts on the messages 2080 as follows: 2082 o when the Proxy receives an RS/DHCPv6 message from a Client within 2083 the secured enclave, it caches the message locally. The Proxy 2084 then forwards the message to the external Server indicated by the 2085 destination link-layer address in the packet while substituting 2086 its own external address as the source link-layer address 2088 o when the Proxy receives an RA/DHCPv6 message from an external 2089 Server, it matches the RA with the RS message that it cached 2090 previously. The Proxy then caches the route information in the 2091 message as a mapping from the Client's ACPs to the Client's 2092 address within the secured enclave. The Proxy then forwards the 2093 message to the Client. 2095 After the initial RS/RA/DHCPv6 handshake is concluded, the Proxy can 2096 send unsolicited NA messages to the Client's chosen Server to update 2097 the Server's neighbor cache entry for the Client (e.g., to update the 2098 Client's quality of service parameters). The Proxy also orwards all 2099 data packets originating from the Client to one of its default router 2100 Relays in the external network. At the same time, for destination 2101 addresses that match an ASP the Proxy sends an NS message via the 2102 Relay to solicit an NA message from a Server that is currently 2103 serving the target Client. When the Proxy receives the NA message, 2104 it configures routing information that associates the source of the 2105 NA message as the next-hop toward the routes adveritsed in the NA 2106 RIOs. 2108 From the perspective of the target Server, the Proxy that sent the 2109 route optimization NS message will appear as if it is an ordinary 2110 AERO Client. However, the target Server must deliver the NA message 2111 directly to the Proxy (i.e., instead of relaying through the backward 2112 chain of Relays and Servers) since the backwards chain could deliver 2113 the NA to a different Proxy besides the one that produced the NS. 2114 For this reason, when a Proxy sends a route optimization NS message 2115 it must set the "Proxy" bit in the message (TBD). When the target 2116 Server receives the NS message, if the Proxy bit is set it returns 2117 the NA message directly to the address of the Proxy. 2119 After the NS/NA exchange, the Proxy may receive unsolicited NA 2120 messages without TLLAOs from the target Server in response to data 2121 packets destined to a Client that is no longer associated with the 2122 target. In that case, the Proxy deletes the routes associated with 2123 the NA Target Address and allows future packets to flow through a 2124 Relay. It can then re-initialize route optimization as above to 2125 discover the new Server for the target Client. 2127 5. Operation on AERO Links with /64 ASPs 2129 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2130 length /64 or shorter. However, in some cases it may be desirable to 2131 use AERO over links that have only a /64 ASP. This can be 2132 accommodated by treating all Clients on the AERO link as simple hosts 2133 that receive /128 prefix delegations. 2135 In that case, the Client sends an RS/DHCPv6 PD message to the Server 2136 the same as for ordinary AERO links. The Server responds with an RA/ 2137 DHCPv6 message that includes one or more /128 prefixes (i.e., 2138 singleton addresses) that include the /64 ASP prefix along with an 2139 interface identifier portion to be assigned to the Client. The 2140 Client and Server then configure their AERO addresses based on the 2141 interface identifier portions of the /128s (i.e., the lower 64 bits) 2142 and not based on the /64 prefix (i.e., the upper 64 bits). 2144 For example, if the ASP for the host-only IPv6 AERO link is 2145 2001:db8:1000:2000::/64, each Client will receive one or more /128 2146 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2147 2001:db8:1000:2000::2/128, etc. When the Client receives the prefix 2148 delegations, it assigns the AERO addresses fe80::1, fe80::2, etc. to 2149 the AERO interface, and assigns the global IPv6 addresses (i.e., the 2150 /128s) to either the AERO interface or an internal virtual interface 2151 such as a loopback. In this arrangement, the Client conducts route 2152 optimization in the same sense as discussed in Section 3.15. 2154 This specification has applicability for nodes that act as a Client 2155 on an "upstream" AERO link, but also act as a Server on "downstream" 2156 AERO links. More specifically, if the node acts as a Client to 2157 receive a /64 prefix from the upstream AERO link it can then act as a 2158 Server to provision /128s to Clients on downstream AERO links. 2160 Note that, due to the nature of the AERO address format, valid IPv6 2161 ACP lengths are either /64 or shorter, or exactly /128 (i.e., prefix 2162 lengths between /65 and /127 cannot be accommodated). 2164 6. Implementation Status 2166 An AERO implementation based on OpenVPN (https://openvpn.net/) was 2167 cleared for public release on December 13, 2017. 2169 An initial public release of the AERO proof-of-concept source code 2170 was announced on the intarea mailing list on August 21, 2015, and a 2171 pointer to the code is available in the list archives. 2173 7. IANA Considerations 2175 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2176 AERO in the "enterprise-numbers" registry. 2178 The IANA has assigned the UDP port number "8060" for an earlier 2179 experimental version of AERO [RFC6706]. This document obsoletes 2180 [RFC6706] and claims the UDP port number "8060" for all future use. 2182 No further IANA actions are required. 2184 8. Security Considerations 2186 AERO link security considerations are the same as for standard IPv6 2187 Neighbor Discovery [RFC4861] except that AERO improves on some 2188 aspects. In particular, AERO uses a trust basis between Clients and 2189 Servers, where the Clients only engage in the AERO mechanism when it 2190 is facilitated by a trust anchor. 2192 NS and NA messages SHOULD include a Timestamp option (see Section 5.3 2193 of [RFC3971]) that other AERO nodes can use to verify the message 2194 time of origin. NS and RS messages SHOULD include a Nonce option 2195 (see Section 5.3 of [RFC3971]) that recipients echo back in 2196 corresponding responses. In cases where spoofing cannot be mitigated 2197 through other means, however, all AERO IPv6 ND messages should employ 2198 Secure Neighbor Discovery (SeND) [RFC3971]. 2200 AERO links must be protected against link-layer address spoofing 2201 attacks in which an attacker on the link pretends to be a trusted 2202 neighbor. Links that provide link-layer securing mechanisms (e.g., 2203 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2204 enterprise network wired LANs) provide a first line of defense, 2205 however AERO nodes SHOULD also use IPv6 ND and/or DHCPv6 securing 2206 services for Client authentication and network admission control. 2207 Following authenticated DHCPv6 PD procedures, AERO nodes MUST ensure 2208 that the source of data packets corresponds to the node to which the 2209 prefixes were delegated. 2211 AERO Clients MUST ensure that their connectivity is not used by 2212 unauthorized nodes on their EUNs to gain access to a protected 2213 network, i.e., AERO Clients that act as routers MUST NOT provide 2214 routing services for unauthorized nodes. (This concern is no 2215 different than for ordinary hosts that receive an IP address 2216 delegation but then "share" the address with other nodes via some 2217 form of Internet connection sharing.) 2219 AERO Clients, Servers and Relays on the open Internet are susceptible 2220 to the same attack profiles as for any Internet nodes. For this 2221 reason, IP security SHOULD be used when AERO is employed over 2222 unmanaged/unsecured links using securing mechanisms such as IPsec 2223 [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, 2224 however, the use of end-to-end security from Clients to correspondent 2225 nodes (i.e., other Clients and/or Internet nodes) could obviate the 2226 need for IP security between AERO Clients, Servers and Relays. 2228 AERO Servers and Relays present targets for traffic amplification DoS 2229 attacks. This concern is no different than for widely-deployed VPN 2230 security gateways in the Internet, where attackers could send spoofed 2231 packets to the gateways at high data rates. This can be mitigated by 2232 connecting Relays and Servers over dedicated links with no 2233 connections to the Internet and/or when connections to the Internet 2234 are only permitted through well-managed firewalls. 2236 Traffic amplification DoS attacks can also target an AERO Client's 2237 low data rate links. This is a concern not only for Clients located 2238 on the open Internet but also for Clients in secured enclaves. AERO 2239 Servers can institute rate limits that protect Clients from receiving 2240 packet floods that could DoS low data rate links. 2242 9. Acknowledgements 2244 Discussions both on IETF lists and in private exchanges helped shape 2245 some of the concepts in this work. Individuals who contributed 2246 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, Bob 2247 Braden, Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, 2248 Adrian Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom 2249 Herbert, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy 2250 Malis, Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2251 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. 2252 Members of the IESG also provided valuable input during their review 2253 process that greatly improved the document. Discussions on the v6ops 2254 list in the December 2015 through January 2016 timeframe further 2255 helped clarify AERO multi-addressing capabilities. Special thanks go 2256 to Stewart Bryant, Joel Halpern and Brian Haberman for their 2257 shepherding guidance during the publication of the AERO first 2258 edition. 2260 This work has further been encouraged and supported by Boeing 2261 colleagues including Kyle Bae, M. Wayne Benson, Dave Bernhardt, Cam 2262 Brodie, Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu 2263 Danilov, Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gene 2264 MacLean III, Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian 2265 Skeen, Mike Slane, Carrie Spiker, Brendan Williams, Julie Wulff, 2266 Yueli Yang, Eric Yeh and other members of the BR&T and BIT mobile 2267 networking teams. Wayne Benson is especially acknowledged for 2268 converting the AERO proof-of-concept implementation into production- 2269 ready code for OpenVPN. 2271 Earlier works on NBMA tunneling approaches are found in 2272 [RFC2529][RFC5214][RFC5569]. 2274 Many of the constructs presented in this second edition of AERO are 2275 based on the author's earlier works, including: 2277 o The Internet Routing Overlay Network (IRON) 2278 [RFC6179][I-D.templin-ironbis] 2280 o Virtual Enterprise Traversal (VET) 2281 [RFC5558][I-D.templin-intarea-vet] 2283 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2284 [RFC5320][I-D.templin-intarea-seal] 2286 o AERO, First Edition [RFC6706] 2288 Note that these works cite numerous earlier efforts that are not also 2289 cited here due to space limitations. The authors of those earlier 2290 works are acknowledged for their insights. 2292 This work is aligned with the NASA Safe Autonomous Systems Operation 2293 (SASO) program under NASA contract number NNA16BD84C. 2295 This work is aligned with the FAA as per the SE2025 contract number 2296 DTFAWA-15-D-00030. 2298 This work is aligned with the Boeing Information Technology (BIT) 2299 MobileNet program. 2301 This work is aligned with the Boeing Research and Technology (BR&T) 2302 autonomous systems networking program. 2304 10. References 2306 10.1. Normative References 2308 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2309 DOI 10.17487/RFC0768, August 1980, 2310 . 2312 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2313 DOI 10.17487/RFC0791, September 1981, 2314 . 2316 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2317 RFC 792, DOI 10.17487/RFC0792, September 1981, 2318 . 2320 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2321 DOI 10.17487/RFC2003, October 1996, 2322 . 2324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2325 Requirement Levels", BCP 14, RFC 2119, 2326 DOI 10.17487/RFC2119, March 1997, 2327 . 2329 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2330 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2331 December 1998, . 2333 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2334 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2335 December 1998, . 2337 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2338 "Definition of the Differentiated Services Field (DS 2339 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2340 DOI 10.17487/RFC2474, December 1998, 2341 . 2343 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2344 C., and M. Carney, "Dynamic Host Configuration Protocol 2345 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2346 2003, . 2348 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2349 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2350 DOI 10.17487/RFC3633, December 2003, 2351 . 2353 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2354 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2355 DOI 10.17487/RFC3971, March 2005, 2356 . 2358 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2359 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2360 November 2005, . 2362 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2363 for IPv6 Hosts and Routers", RFC 4213, 2364 DOI 10.17487/RFC4213, October 2005, 2365 . 2367 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2368 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2369 DOI 10.17487/RFC4861, September 2007, 2370 . 2372 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2373 Address Autoconfiguration", RFC 4862, 2374 DOI 10.17487/RFC4862, September 2007, 2375 . 2377 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2378 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2379 2011, . 2381 10.2. Informative References 2383 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 2384 2016. 2386 [I-D.herbert-gue-fragmentation] 2387 Herbert, T. and F. Templin, "Fragmentation option for 2388 Generic UDP Encapsulation", draft-herbert-gue- 2389 fragmentation-02 (work in progress), October 2015. 2391 [I-D.ietf-dhc-sedhcpv6] 2392 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 2393 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 2394 in progress), February 2017. 2396 [I-D.ietf-intarea-tunnels] 2397 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2398 Architecture", draft-ietf-intarea-tunnels-07 (work in 2399 progress), June 2017. 2401 [I-D.ietf-nvo3-gue] 2402 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2403 Encapsulation", draft-ietf-nvo3-gue-05 (work in progress), 2404 October 2016. 2406 [I-D.templin-6man-dhcpv6-ndopt] 2407 Templin, F., "The DHCPv6 Option for IPv6 Neighbor 2408 Discovery", draft-templin-6man-dhcpv6-ndopt-00 (work in 2409 progress), November 2017. 2411 [I-D.templin-6man-rio-redirect] 2412 Templin, F. and j. woodyatt, "Route Information Options in 2413 IPv6 Neighbor Discovery", draft-templin-6man-rio- 2414 redirect-05 (work in progress), October 2017. 2416 [I-D.templin-intarea-grefrag] 2417 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2418 templin-intarea-grefrag-04 (work in progress), July 2016. 2420 [I-D.templin-intarea-seal] 2421 Templin, F., "The Subnetwork Encapsulation and Adaptation 2422 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2423 progress), January 2014. 2425 [I-D.templin-intarea-vet] 2426 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2427 templin-intarea-vet-40 (work in progress), May 2013. 2429 [I-D.templin-ironbis] 2430 Templin, F., "The Interior Routing Overlay Network 2431 (IRON)", draft-templin-ironbis-16 (work in progress), 2432 March 2014. 2434 [I-D.templin-v6ops-pdhost] 2435 Templin, F., "IPv6 Prefix Delegation Models", draft- 2436 templin-v6ops-pdhost-16 (work in progress), November 2017. 2438 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2440 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 2441 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 2442 . 2444 [RFC1035] Mockapetris, P., "Domain names - implementation and 2445 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2446 November 1987, . 2448 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2449 Communication Layers", STD 3, RFC 1122, 2450 DOI 10.17487/RFC1122, October 1989, 2451 . 2453 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2454 DOI 10.17487/RFC1191, November 1990, 2455 . 2457 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2458 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2459 . 2461 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2462 selection, and registration of an Autonomous System (AS)", 2463 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 2464 . 2466 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2467 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2468 1996, . 2470 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2471 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2472 . 2474 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2475 Domains without Explicit Tunnels", RFC 2529, 2476 DOI 10.17487/RFC2529, March 1999, 2477 . 2479 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2480 RFC 2675, DOI 10.17487/RFC2675, August 1999, 2481 . 2483 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2484 Malis, "A Framework for IP Based Virtual Private 2485 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2486 . 2488 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2489 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2490 DOI 10.17487/RFC2784, March 2000, 2491 . 2493 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2494 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2495 . 2497 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2498 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2499 . 2501 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2502 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2503 . 2505 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2506 of Explicit Congestion Notification (ECN) to IP", 2507 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2508 . 2510 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2511 "DNS Extensions to Support IP Version 6", STD 88, 2512 RFC 3596, DOI 10.17487/RFC3596, October 2003, 2513 . 2515 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2516 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2517 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2518 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2519 . 2521 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2522 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2523 DOI 10.17487/RFC4271, January 2006, 2524 . 2526 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2527 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2528 2006, . 2530 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2531 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2532 December 2005, . 2534 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2535 Control Message Protocol (ICMPv6) for the Internet 2536 Protocol Version 6 (IPv6) Specification", STD 89, 2537 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2538 . 2540 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 2541 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2542 2006, . 2544 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2545 Protocol (LDAP): The Protocol", RFC 4511, 2546 DOI 10.17487/RFC4511, June 2006, 2547 . 2549 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2550 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 2551 . 2553 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 2554 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 2555 . 2557 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2558 "Internet Group Management Protocol (IGMP) / Multicast 2559 Listener Discovery (MLD)-Based Multicast Forwarding 2560 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2561 August 2006, . 2563 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2564 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2565 . 2567 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2568 Errors at High Data Rates", RFC 4963, 2569 DOI 10.17487/RFC4963, July 2007, 2570 . 2572 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 2573 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 2574 DOI 10.17487/RFC4994, September 2007, 2575 . 2577 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 2578 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 2579 RFC 5213, DOI 10.17487/RFC5213, August 2008, 2580 . 2582 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2583 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2584 DOI 10.17487/RFC5214, March 2008, 2585 . 2587 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2588 (TLS) Protocol Version 1.2", RFC 5246, 2589 DOI 10.17487/RFC5246, August 2008, 2590 . 2592 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2593 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2594 February 2010, . 2596 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 2597 for the Address Resolution Protocol (ARP)", RFC 5494, 2598 DOI 10.17487/RFC5494, April 2009, 2599 . 2601 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2602 Route Optimization Requirements for Operational Use in 2603 Aeronautics and Space Exploration Mobile Networks", 2604 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2605 . 2607 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2608 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2609 . 2611 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2612 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2613 January 2010, . 2615 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2616 Global Enterprise Recursion (RANGER)", RFC 5720, 2617 DOI 10.17487/RFC5720, February 2010, 2618 . 2620 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 2621 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 2622 . 2624 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 2625 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 2626 DOI 10.17487/RFC5949, September 2010, 2627 . 2629 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2630 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2631 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2632 . 2634 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2635 NAT64: Network Address and Protocol Translation from IPv6 2636 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2637 April 2011, . 2639 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2640 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2641 . 2643 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2644 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 2645 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 2646 . 2648 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2649 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2650 DOI 10.17487/RFC6221, May 2011, 2651 . 2653 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2654 and A. Bierman, Ed., "Network Configuration Protocol 2655 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2656 . 2658 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2659 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2660 2011, . 2662 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2663 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2664 DOI 10.17487/RFC6355, August 2011, 2665 . 2667 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2668 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2669 . 2671 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2672 for Equal Cost Multipath Routing and Link Aggregation in 2673 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2674 . 2676 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2677 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2678 . 2680 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2681 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2682 . 2684 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2685 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2686 . 2688 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2689 UDP Checksums for Tunneled Packets", RFC 6935, 2690 DOI 10.17487/RFC6935, April 2013, 2691 . 2693 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2694 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2695 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2696 . 2698 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2699 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 2700 May 2013, . 2702 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2703 with IPv6 Neighbor Discovery", RFC 6980, 2704 DOI 10.17487/RFC6980, August 2013, 2705 . 2707 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2708 Address Selection Policy Using DHCPv6", RFC 7078, 2709 DOI 10.17487/RFC7078, January 2014, 2710 . 2712 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2713 October 2014. 2715 Appendix A. AERO Alternate Encapsulations 2717 When GUE encapsulation is not needed, AERO can use common 2718 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2719 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2720 encapsulation is therefore only differentiated from non-AERO tunnels 2721 through the application of AERO control messaging and not through, 2722 e.g., a well-known UDP port number. 2724 As for GUE encapsulation, alternate AERO encapsulation formats may 2725 require encapsulation layer fragmentation. For simple IP-in-IP 2726 encapsulation, an IPv6 fragment header is inserted directly between 2727 the inner and outer IP headers when needed, i.e., even if the outer 2728 header is IPv4. The IPv6 Fragment Header is identified to the outer 2729 IP layer by its IP protocol number, and the Next Header field in the 2730 IPv6 Fragment Header identifies the inner IP header version. For GRE 2731 encapsulation, a GRE fragment header is inserted within the GRE 2732 header [I-D.templin-intarea-grefrag]. 2734 Figure 5 shows the AERO IP-in-IP encapsulation format before any 2735 fragmentation is applied: 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | Outer IPv4 Header | | Outer IPv6 Header | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | Inner IP Header | | Inner IP Header | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | | | | 2745 ~ ~ ~ ~ 2746 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2747 ~ ~ ~ ~ 2748 | | | | 2749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2753 Figure 5: Minimal Encapsulation Format using IP-in-IP 2755 Figure 6 shows the AERO GRE encapsulation format before any 2756 fragmentation is applied: 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 | Outer IP Header | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2761 | GRE Header | 2762 | (with checksum, key, etc..) | 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | GRE Fragment Header (optional)| 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | Inner IP Header | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | | 2769 ~ ~ 2770 ~ Inner Packet Body ~ 2771 ~ ~ 2772 | | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 Figure 6: Minimal Encapsulation Using GRE 2777 Alternate encapsulation may be preferred in environments where GUE 2778 encapsulation would add unnecessary overhead. For example, certain 2779 low-bandwidth wireless data links may benefit from a reduced 2780 encapsulation overhead. 2782 GUE encapsulation can traverse network paths that are inaccessible to 2783 non-UDP encapsulations, e.g., for crossing Network Address 2784 Translators (NATs). More and more, network middleboxes are also 2785 being configured to discard packets that include anything other than 2786 a well-known IP protocol such as UDP and TCP. It may therefore be 2787 necessary to determine the potential for middlebox filtering before 2788 enabling alternate encapsulation in a given environment. 2790 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2791 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 2792 messaging and route determination occur before security encapsulation 2793 is applied for outgoing packets and after security decapsulation is 2794 applied for incoming packets. 2796 AERO is especially well suited for use with VPN system encapsulations 2797 such as OpenVPN [OVPN]. 2799 Appendix B. When to Insert an Encapsulation Fragment Header 2801 An encapsulation fragment header is inserted when the AERO tunnel 2802 ingress needs to apply fragmentation to accommodate packets that must 2803 be delivered without loss due to a size restriction. Fragmentation 2804 is performed on the inner packet while encapsulating each inner 2805 packet fragment in outer IP and encapsulation layer headers that 2806 differ only in the fragment header fields. 2808 The fragment header can also be inserted in order to include a 2809 coherent Identification value with each packet, e.g., to aid in 2810 Duplicate Packet Detection (DPD). In this way, network nodes can 2811 cache the Identification values of recently-seen packets and use the 2812 cached values to determine whether a newly-arrived packet is in fact 2813 a duplicate. The Identification value within each packet could 2814 further provide a rough indicator of packet reordering, e.g., in 2815 cases when the tunnel egress wishes to discard packets that are 2816 grossly out of order. 2818 In some use cases, there may be operational assurance that no 2819 fragmentation of any kind will be necessary, or that only occasional 2820 large control messages will require fragmentation. In that case, the 2821 encapsulation fragment header can be omitted and ordinary 2822 fragmentation of the outer IP protocol version can be applied when 2823 necessary. 2825 Appendix C. Autoconfiguration for Constrained Platforms 2827 On some platforms (e.g., popular cell phone operating systems), the 2828 act of assigning a default IPv6 route and/or assigning an address to 2829 an interface may not be permitted from a user application due to 2830 security policy. Typically, those platforms include a TUN/TAP 2831 interface [TUNTAP] that acts as a point-to-point conduit between user 2832 applications and the AERO interface. In that case, the Client can 2833 instead generate a "synthesized RA" message. The message conforms to 2834 [RFC4861] and is prepared as follows: 2836 o the IPv6 source address is the Client's AERO address 2838 o the IPv6 destination address is all-nodes multicast 2840 o the Router Lifetime is set to a time that is no longer than the 2841 ACP DHCPv6 lifetime 2843 o the message does not include a Source Link Layer Address Option 2844 (SLLAO) 2846 o the message includes a Prefix Information Option (PIO) with a /64 2847 prefix taken from the ACP as the prefix for autoconfiguration 2849 The Client then sends the synthesized RA message via the TUN/TAP 2850 interface, where the operating system kernel will interpret it as 2851 though it were generated by an actual router. The operating system 2852 will then install a default route and use StateLess Address 2853 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 2854 interface. Methods for similarly installing an IPv4 default route 2855 and IPv4 address on the TUN/TAP interface are based on synthesized 2856 DHCPv4 messages [RFC2131]. 2858 Appendix D. Operational Deployment Alternatives 2860 AERO can be used in many different variations based on the specific 2861 use case. The following sections discuss variations that adhere to 2862 the AERO principles while allowing selective application of AERO 2863 components. 2865 D.1. Operation on AERO Links Without DHCPv6 Services 2867 When Servers on the AERO link do not provide DHCPv6 services, 2868 operation can still be accommodated through administrative 2869 configuration of ACPs on AERO Clients. In that case, administrative 2870 configurations of AERO interface neighbor cache entries on both the 2871 Server and Client are also necessary. However, this may interfere 2872 with the ability for Clients to dynamically change to new Servers, 2873 and can expose the AERO link to misconfigurations unless the 2874 administrative configurations are carefully coordinated. 2876 D.2. Operation on Server-less AERO Links 2878 In some AERO link scenarios, there may be no Servers on the link and/ 2879 or no need for Clients to use a Server as an intermediary trust 2880 anchor. In that case, each Client acts as a Server unto itself to 2881 establish neighbor cache entries by performing direct Client-to- 2882 Client IPv6 ND message exchanges, and some other form of trust basis 2883 must be applied so that each Client can verify that the prospective 2884 neighbor is authorized to use its claimed ACP. 2886 When there is no Server on the link, Clients must arrange to receive 2887 ACPs and publish them via a secure alternate PD authority through 2888 some means outside the scope of this document. 2890 D.3. Operation on Client-less AERO Links 2892 In some environments, the AERO service may be useful for mobile nodes 2893 that do not implement the AERO Client function and do not perform 2894 encapsulation. For example, if the mobile node has a way of 2895 injecting its ACP into the access subnetwork routing system an AERO 2896 Server connected to the same access network can accept the ACP prefix 2897 injection as an indication that a new mobile node has come onto the 2898 subnetwork. The Server can then inject the ACP into the BGP routing 2899 system the same as if an AERO Client/Server DHCPv6 PD exchange had 2900 occurred. If the mobile node subsequently withdraws the ACP from the 2901 access network routing system, the Server can then withdraw the ACP 2902 from the BGP routing system. 2904 In this arrangement, AERO Servers and Relays are used in exactly the 2905 same ways as for environments where DHCPv6 Client/Server exchanges 2906 are supported. However, the access subnetwork routing systems must 2907 be capable of accommodating rapid ACP injections and withdrawals from 2908 mobile nodes with the understanding that the information must be 2909 propagated to all routers in the system. Operational experience has 2910 shown that this kind of routing system "churn" can lead to overall 2911 instability and routing system inconsistency. 2913 D.4. Manually-Configured AERO Tunnels 2915 In addition to the dynamic neighbor discovery procedures for AERO 2916 link neighbors described above, AERO encapsulation can be applied to 2917 manually-configured tunnels. In that case, the tunnel endpoints use 2918 an administratively-provisioned link-local address and exchange NS/NA 2919 messages the same as for dynamically-established tunnels. 2921 D.5. Encapsulation Avoidance on Relay-Server Dedicated Links 2923 In some environments, AERO Servers and Relays may be connected by 2924 dedicated point-to-point links, e.g., high speed fiberoptic leased 2925 lines. In that case, the Servers and Relays can participate in the 2926 AERO link the same as specified above but can avoid encapsulation 2927 over the dedicated links. In that case, however, the links would be 2928 dedicated for AERO and could not be multiplexed for both AERO and 2929 non-AERO communications. 2931 D.6. Encapsulation Protocol Version Considerations 2933 A source Client may connect only to an IPvX underlying network, while 2934 the target Client connects only to an IPvY underlying network. In 2935 that case, the target and source Clients have no means for reaching 2936 each other directly (since they connect to underlying networks of 2937 different IP protocol versions) and so must ignore any route 2938 optimization messages and continue to send packets via their Servers. 2940 D.7. Extending AERO Links Through Security Gateways 2942 When an enterprise mobile node moves from a campus LAN connection to 2943 a public Internet link, it must re-enter the enterprise via a 2944 security gateway that has both a physical interface connection to the 2945 Internet and a physical interface connection to the enterprise 2946 internetwork. This most often entails the establishment of a Virtual 2947 Private Network (VPN) link over the public Internet from the mobile 2948 node to the security gateway. During this process, the mobile node 2949 supplies the security gateway with its public Internet address as the 2950 link-layer address for the VPN. The mobile node then acts as an AERO 2951 Client to negotiate with the security gateway to obtain its ACP. 2953 In order to satisfy this need, the security gateway also operates as 2954 an AERO Server with support for AERO Client proxying. In particular, 2955 when a mobile node (i.e., the Client) connects via the security 2956 gateway (i.e., the Server), the Server provides the Client with an 2957 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2958 enterprise campus access link. The Server then replaces the Client's 2959 link-layer source address with the Server's enterprise-facing link- 2960 layer address in all AERO messages the Client sends toward neighbors 2961 on the AERO link. The AERO messages are then delivered to other 2962 nodes on the AERO link as if they were originated by the security 2963 gateway instead of by the AERO Client. In the reverse direction, the 2964 AERO messages sourced by nodes within the enterprise network can be 2965 forwarded to the security gateway, which then replaces the link-layer 2966 destination address with the Client's link-layer address and replaces 2967 the link-layer source address with its own (Internet-facing) link- 2968 layer address. 2970 After receiving the ACP, the Client can send IP packets that use an 2971 address taken from the ACP as the network layer source address, the 2972 Client's link-layer address as the link-layer source address, and the 2973 Server's Internet-facing link-layer address as the link-layer 2974 destination address. The Server will then rewrite the link-layer 2975 source address with the Server's own enterprise-facing link-layer 2976 address and rewrite the link-layer destination address with the 2977 target AERO node's link-layer address, and the packets will enter the 2978 enterprise network as though they were sourced from a node located 2979 within the enterprise. In the reverse direction, when a packet 2980 sourced by a node within the enterprise network uses a destination 2981 address from the Client's ACP, the packet will be delivered to the 2982 security gateway which then rewrites the link-layer destination 2983 address to the Client's link-layer address and rewrites the link- 2984 layer source address to the Server's Internet-facing link-layer 2985 address. The Server then delivers the packet across the VPN to the 2986 AERO Client. In this way, the AERO virtual link is essentially 2987 extended *through* the security gateway to the point at which the VPN 2988 link and AERO link are effectively grafted together by the link-layer 2989 address rewriting performed by the security gateway. All AERO 2990 messaging services (including route optimization and mobility 2991 signaling) are therefore extended to the Client. 2993 In order to support this virtual link grafting, the security gateway 2994 (acting as an AERO Server) must keep static neighbor cache entries 2995 for all of its associated Clients located on the public Internet. 2996 The neighbor cache entry is keyed by the AERO Client's AERO address 2997 the same as if the Client were located within the enterprise 2998 internetwork. The neighbor cache is then managed in all ways as 2999 though the Client were an ordinary AERO Client. This includes the 3000 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 3001 Unreachability Detection. 3003 Note that the main difference between a security gateway acting as an 3004 AERO Server and an enterprise-internal AERO Server is that the 3005 security gateway has at least one enterprise-internal physical 3006 interface and at least one public Internet physical interface. 3007 Conversely, the enterprise-internal AERO Server has only enterprise- 3008 internal physical interfaces. For this reason security gateway 3009 proxying is needed to ensure that the public Internet link-layer 3010 addressing space is kept separate from the enterprise-internal link- 3011 layer addressing space. This is afforded through a natural extension 3012 of the security association caching already performed for each VPN 3013 client by the security gateway. 3015 Appendix E. Change Log 3017 Changes from -76 to -77: 3019 o Now using IPv6 ND NS/NA messaging for route optimization (no 3020 longer using Predirect/Redirect) 3022 o Now using combined IPv6 ND/DHCPv6 messaging so autoconfiguration 3023 can be conducted in a single message exchange 3025 o Introduced the AERO Proxy construct. Critical for applications 3026 such as ATN/IPS 3028 Changes from -75 to -76: 3030 o Bumped version number ahead of expiration deadline 3032 Changes from -74 to -75: 3034 o Bumped version number ahead of expiration deadline 3036 Author's Address 3038 Fred L. Templin (editor) 3039 Boeing Research & Technology 3040 P.O. Box 3707 3041 Seattle, WA 98124 3042 USA 3044 Email: fltemplin@acm.org