idnits 2.17.1 draft-templin-aerolink-72.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 07, 2016) is 2759 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) == Missing Reference: 'I-D.taylor-v6ops-fragdrop' is mentioned on line 1039, but not defined == Unused Reference: 'RFC0768' is defined on line 2286, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 2355, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2401, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 2405, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'RFC2675' is defined on line 2440, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 2471, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 2501, but no explicit reference was found in the text == Unused Reference: 'RFC4555' is defined on line 2510, but no explicit reference was found in the text == Unused Reference: 'RFC4592' is defined on line 2514, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 2524, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 2533, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 2538, but no explicit reference was found in the text == Unused Reference: 'RFC5494' is defined on line 2557, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2576, but no explicit reference was found in the text == Unused Reference: 'RFC5844' is defined on line 2581, but no explicit reference was found in the text == Unused Reference: 'RFC5949' is defined on line 2585, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 2595, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 2604, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 2614, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 2619, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 2623, but no explicit reference was found in the text == Unused Reference: 'RFC6422' is defined on line 2628, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 2637, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 2649, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 2654, but no explicit reference was found in the text == Unused Reference: 'RFC6939' is defined on line 2659, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 2663, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 2668, 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 (-21) exists of draft-ietf-dhc-sedhcpv6-13 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-03 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-04 -- 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 (~~), 35 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, October 07, 2016 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: April 10, 2017 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-72.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 redirection services for route optimization. AERO provides an IPv6 20 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 and route optimization are naturally supported 25 through dynamic neighbor cache updates. Although DHCPv6 and IPv6 ND 26 messaging are used in the control plane, both IPv4 and IPv6 are 27 supported in the data plane. AERO is a widely-applicable tunneling 28 solution especially well suited to mobile Virtual Private Networks 29 (VPNs) and other applications as described in this document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 10, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 7 68 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 7 69 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 8 70 3.3. AERO Routing System . . . . . . . . . . . . . . . . . . . 9 71 3.4. AERO Interface Link-local Addresses . . . . . . . . . . . 10 72 3.5. AERO Interface Characteristics . . . . . . . . . . . . . 12 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 14 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 14 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 15 76 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 15 77 3.7. AERO Interface Neighbor Cache Maintenace . . . . . . . . 15 78 3.8. AERO Interface Forwarding Algorithm . . . . . . . . . . . 17 79 3.8.1. Client Fowarding Algorithm . . . . . . . . . . . . . 18 80 3.8.2. Server Fowarding Algorithm . . . . . . . . . . . . . 18 81 3.8.3. Relay Fowarding Algorithm . . . . . . . . . . . . . . 19 82 3.9. AERO Interface Encapsulation and Re-encapsulation . . . . 19 83 3.10. AERO Interface Decapsulation . . . . . . . . . . . . . . 20 84 3.11. AERO Interface Data Origin Authentication . . . . . . . . 20 85 3.12. AERO Interface Packet Size Issues . . . . . . . . . . . . 21 86 3.13. AERO Interface Error Handling . . . . . . . . . . . . . . 23 87 3.14. AERO Router Discovery, Prefix Delegation and 88 Autoconfiguration . . . . . . . . . . . . . . . . . . . . 26 89 3.14.1. AERO DHCPv6 and IPv6 ND Service Model . . . . . . . 26 90 3.14.2. AERO Client Behavior . . . . . . . . . . . . . . . . 27 91 3.14.3. AERO Server Behavior . . . . . . . . . . . . . . . . 29 92 3.15. AERO Interface Route Optimization . . . . . . . . . . . . 31 93 3.15.1. Reference Operational Scenario . . . . . . . . . . . 31 94 3.15.2. Concept of Operations . . . . . . . . . . . . . . . 33 95 3.15.3. Message Format . . . . . . . . . . . . . . . . . . . 33 96 3.15.4. Sending Predirects . . . . . . . . . . . . . . . . . 34 97 3.15.5. Re-encapsulating and Relaying Predirects . . . . . . 35 98 3.15.6. Processing Predirects and Sending Redirects . . . . 36 99 3.15.7. Re-encapsulating and Relaying Redirects . . . . . . 38 100 3.15.8. Processing Redirects . . . . . . . . . . . . . . . . 38 101 3.15.9. Server-to-Client and Client-to-Server Redirection . 39 102 3.15.10. Server-to-Server Redirection . . . . . . . . . . . . 40 103 3.16. Neighbor Unreachability Detection (NUD) . . . . . . . . . 40 104 3.17. Mobility Management . . . . . . . . . . . . . . . . . . . 41 105 3.17.1. Announcing Link-Layer Address Changes . . . . . . . 41 106 3.17.2. Bringing New Links Into Service . . . . . . . . . . 41 107 3.17.3. Removing Existing Links from Service . . . . . . . . 42 108 3.17.4. Implicit Mobility Management . . . . . . . . . . . . 42 109 3.17.5. Moving to a New Server . . . . . . . . . . . . . . . 42 110 3.17.6. Packet Queueing for Mobility . . . . . . . . . . . . 43 111 3.18. Multicast Considerations . . . . . . . . . . . . . . . . 44 112 4. AERO Variations . . . . . . . . . . . . . . . . . . . . . . . 44 113 4.1. Operation on Host-Only IPv6 AERO Links . . . . . . . . . 44 114 4.2. Operation on AERO Links Without DHCPv6 Services . . . . . 45 115 4.3. Operation on Server-less AERO Links . . . . . . . . . . . 45 116 4.4. Operation on Client-less AERO Links . . . . . . . . . . . 45 117 4.5. Manually-Configured AERO Tunnels . . . . . . . . . . . . 46 118 4.6. Encapsulation Avoidance on Relay-Server Dedicated Links . 46 119 4.7. Encapsulation Protocol Version Considerations . . . . . . 46 120 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 47 121 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 122 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 123 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 124 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 125 9.1. Normative References . . . . . . . . . . . . . . . . . . 49 126 9.2. Informative References . . . . . . . . . . . . . . . . . 51 127 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 58 128 Appendix B. When to Insert an Encapsulation Fragment Header . . 60 129 Appendix C. Autoconfiguration for Constrained Platforms . . . . 60 130 Appendix D. Extending AERO Links Through Security Gateways . . . 61 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 133 1. Introduction 135 This document specifies the operation of IP over tunnel virtual links 136 using Asymmetric Extended Route Optimization (AERO). The AERO link 137 can be used for tunneling to neighboring nodes over either IPv6 or 138 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 139 equivalent links for tunneling. Nodes attached to AERO links can 140 exchange packets via trusted intermediate routers that provide 141 forwarding services to reach off-link destinations and redirection 142 services for route optimization [RFC5522]. 144 AERO provides an IPv6 link-local address format that supports 145 operation of the IPv6 Neighbor Discovery (ND) [RFC4861] protocol and 146 links IPv6 ND to IP forwarding. Admission control and address/prefix 147 provisioning are supported by the Dynamic Host Configuration Protocol 148 for IPv6 (DHCPv6) [RFC3315], while mobility management and route 149 optimization are naturally supported through dynamic neighbor cache 150 updates. Although DHCPv6 and IPv6 ND messaging are used in the 151 control plane, both IPv4 and IPv6 can be used in the data plane. 153 A Client's AERO interface can be configured over multiple underlying 154 interfaces. From the standpoint of IPv6 ND, AERO interface neighbors 155 therefore may appear to have multiple link-layer addresses. Each 156 link-layer address is subject to change due to mobility, and link- 157 layer address changes are signaled by IPv6 ND messaging the same as 158 for any IPv6 link. 160 AERO is applicable to a wide variety of use cases. For example, it 161 can be used to coordinate the Virtual Private Network (VPN) links of 162 mobile nodes (e.g., cellphones, tablets, laptop computers, etc.) that 163 connect into a home enterprise network via public access networks 164 using services such as OpenVPN [OVPN]. AERO is also applicable to 165 aviation applications for both manned and unmanned aircraft where the 166 aircraft is treated as a mobile node that can connect an Internet of 167 Things (IoT). Numerous other use cases are also in scope. 169 The AERO mobile node tunneling and Border Gateway Protocol (BGP)- 170 based core routing system can further be employed either in 171 conjunction or separately according to the specific use case (see 172 Section 4). This allows for correct fitting of the (modular) AERO 173 components to match the specific application. The remainder of this 174 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 a 209 Client on one AERO interface can also act as an AERO Server on a 210 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 ingress tunnel endpoint (ITE) 228 an AERO interface endpoint that injects encapsulated packets into 229 an AERO link. 231 egress tunnel endpoint (ETE) 232 an AERO interface endpoint that receives encapsulated packets from 233 an AERO link. 235 underlying network 236 a connected IPv6 or IPv4 network routing region over which the 237 tunnel virtual overlay is configured. 239 underlying interface 240 an AERO node's interface point of attachment to an underlying 241 network. 243 link-layer address 244 an IP address assigned to an AERO node's underlying interface. 245 When UDP encapsulation is used, the UDP port number is also 246 considered as part of the link-layer address. Link-layer 247 addresses are used as the encapsulation header source and 248 destination addresses. 250 network layer address 251 the source or destination address of the encapsulated IP packet. 253 end user network (EUN) 254 an internal virtual or external edge IP network that an AERO 255 Client connects to the rest of the network via the AERO interface. 257 AERO Service Prefix (ASP) 258 an IP prefix associated with the AERO link and from which more- 259 specific AERO Client Prefixes (ACPs) are derived. 261 AERO Client Prefix (ACP) 262 an IP prefix derived from an ASP and delegated to a Client, where 263 the ACP prefix length must be no shorter than the ASP prefix 264 length and must be no longer than 64 for IPv6 or 32 for IPv4. 266 base AERO address 267 the lowest-numbered AERO address from the first ACP delegated to 268 the Client (see Section 3.4). 270 Throughout the document, the simple terms "Client", "Server" and 271 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 272 respectively. Capitalization is used to distinguish these terms from 273 DHCPv6 client/server/relay [RFC3315]. 275 The terminology of DHCPv6 [RFC3315] and IPv6 ND [RFC4861] (including 276 the names of node variables and protocol constants) applies to this 277 document. Also throughout the document, the term "IP" is used to 278 generically refer to either Internet Protocol version (i.e., IPv4 or 279 IPv6). 281 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 282 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 283 document are to be interpreted as described in [RFC2119]. Lower case 284 uses of these words are not to be interpreted as carrying RFC2119 285 significance. 287 3. Asymmetric Extended Route Optimization (AERO) 289 The following sections specify the operation of IP over Asymmetric 290 Extended Route Optimization (AERO) links: 292 3.1. AERO Link Reference Model 294 .-(::::::::) 295 .-(:::: IP ::::)-. 296 (:: Internetwork ::) 297 `-(::::::::::::)-' 298 `-(::::::)-' 299 | 300 +--------------+ +--------+-------+ +--------------+ 301 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 302 | Nbr: C1; R1 | | Nbr: S1; S2 | | Nbr: C2; R1 | 303 | default->R1 | |(P1->S1; P2->S2)| | default->R1 | 304 | P1->C1 | | ASP A1 | | P2->C2 | 305 +-------+------+ +--------+-------+ +------+-------+ 306 | | | 307 X---+---+-------------------+------------------+---+---X 308 | AERO Link | 309 +-----+--------+ +--------+-----+ 310 |AERO Client C1| |AERO Client C2| 311 | Nbr: S1 | | Nbr: S2 | 312 | default->S1 | | default->S2 | 313 | ACP P1 | | ACP P2 | 314 +------+-------+ +------+-------+ 315 | | 316 .-. .-. 317 ,-( _)-. ,-( _)-. 318 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 319 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 320 `-(______)-' +-------+ +-------+ `-(______)-' 322 Figure 1: AERO Link Reference Model 324 Figure 1 presents the AERO link reference model. In this model: 326 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 327 default router for its associated Servers S1 and S2, and connects 328 the AERO link to the rest of the IP Internetwork. 330 o AERO Servers S1 and S2 associate with Relay R1 and also act as 331 default routers for their associated Clients C1 and C2. 333 o AERO Clients C1 and C2 associate with Servers S1 and S2, 334 respectively. They receive AERO Client Prefix (ACP) delegations 335 P1 and P2, and also act as default routers for their associated 336 physical or internal virtual EUNs. (Alternatively, Clients can 337 act as multi-addressed hosts without serving any EUNs). 339 o Simple hosts H1 and H2 attach to the EUNs served by Clients C1 and 340 C2, respectively. 342 Each node on the AERO link maintains an AERO interface neighbor cache 343 and an IP forwarding table the same as for any link. In common 344 operational practice, there may be many additional Relays, Servers 345 and Clients. 347 3.2. AERO Node Types 349 AERO Relays provide default forwarding services to AERO Servers. 350 Each Relay also peers with each Server in a dynamic routing protocol 351 instance to discover the Server's list of associated ACPs (see 352 Section 3.3). Relays forward packets between neighbors connected to 353 the same AERO link and also forward packets between the AERO link and 354 the native IP Internetwork. Relays present the AERO link to the 355 native Internetwork as a set of one or more AERO Service Prefixes 356 (ASPs) and serve as a gateway between the AERO link and the 357 Internetwork. Relays maintain an AERO interface neighbor cache entry 358 for each AERO Server, and maintain an IP forwarding table entry for 359 each AERO Client Prefix (ACP). AERO Relays can also be configured to 360 act as AERO Servers. 362 AERO Servers provide default forwarding services to AERO Clients. 363 Each Server also peers with each Relay in a dynamic routing protocol 364 instance to advertise its list of associated ACPs (see Section 3.3). 365 Servers configure a DHCPv6 server function and act as delegating 366 routers to facilitate Prefix Delegation (PD) exchanges with Clients. 367 Each delegated prefix becomes an ACP taken from an ASP. Servers 368 forward packets between AERO interface neighbors, and maintain an 369 AERO interface neighbor cache entry for each Relay. They also 370 maintain both neighbor cache entries and IP forwarding table entries 371 for each of their associated Clients. AERO Servers can also be 372 configured to act as AERO Relays. 374 AERO Clients act as requesting routers to receive ACPs through DHCPv6 375 PD exchanges with AERO Servers over the AERO link. Each Client MAY 376 associate with a single Server or with multiple Servers, e.g., for 377 fault tolerance, load balancing, etc. Each IPv6 Client receives at 378 least a /64 IPv6 ACP, and may receive even shorter prefixes. 379 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 380 singleton IPv4 address), and may receive even shorter prefixes. 381 Clients maintain an AERO interface neighbor cache entry for each of 382 their associated Servers as well as for each of their correspondent 383 Clients. 385 3.3. AERO Routing System 387 The AERO routing system comprises a private instance of the Border 388 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 389 and Servers and does not interact with either the public Internet BGP 390 routing system or the native IP Internetwork interior routing system. 391 Relays advertise only a small and unchanging set of ASPs to the 392 native routing system instead of the full dynamically changing set of 393 ACPs. 395 In a reference deployment, each AERO Server is configured as an 396 Autonomous System Border Router (ASBR) for a stub Autonomous System 397 (AS) using an AS Number (ASN) that is unique within the BGP instance, 398 and each Server further peers with each Relay but does not peer with 399 other Servers. Similarly, Relays do not peer with each other, since 400 they will reliably receive all updates from all Servers and will 401 therefore have a consistent view of the AERO link ACP delegations. 403 Each Server maintains a working set of associated ACPs, and 404 dynamically announces new ACPs and withdraws departed ACPs in its BGP 405 updates to Relays. Clients are expected to remain associated with 406 their current Servers for extended timeframes, however Servers SHOULD 407 selectively suppress BGP updates for impatient Clients that 408 repeatedly associate and disassociate with them in order to dampen 409 routing churn. 411 Each Relay configures a black-hole route for each of its ASPs. By 412 black-holing the ASPs, the Relay will maintain forwarding table 413 entries only for the ACPs that are currently active, and all other 414 ACPs will correctly result in destination unreachable failures due to 415 the black hole route. Relays do not send BGP updates for ACPs to 416 Servers, but instead originate a default route. In this way, Servers 417 have only partial topology knowledge (i.e., they know only about the 418 ACPs of their directly associated Clients) and they forward all other 419 packets to Relays which have full topology knowledge. 421 Scaling properties of the AERO routing system are limited by the 422 number of BGP routes that can be carried by Relays. Assuming O(10^6) 423 as a maximum number of BGP routes, this means that O(10^6) Clients 424 can be serviced by a single set of Relays. A means of increasing 425 scaling would be to assign a different set of Relays for each set of 426 ASPs. In that case, each Server still peers with each Relay, but the 427 Server institutes route filters so that it only sends BGP updates to 428 the specific set of Relays that aggregate the ASP. For example, if 429 the ASP for the AERO link is 2001:db8::/32, a first set of Relays 430 could service the ASP segment 2001:db8::/40, a second set of Relays 431 could service 2001:db8:0100::/40, a third set could service 432 2001:db8:0200::/40, etc. 434 Assuming up to O(10^3) sets of Relays, the AERO routing system can 435 then accommodate O(10^9) ACPs with no additional overhead for Servers 436 and Relays (for example, it should be possible to service 4 billion 437 /64 ACPs taken from a /32 ASP and even more for shorter ASPs). In 438 this way, each set of Relays services a specific set of ASPs that 439 they advertise to the native routing system, and each Server 440 configures ASP-specific routes that list the correct set of Relays as 441 next hops. This arrangement also allows for natural incremental 442 deployment, and can support small scale initial deployments followed 443 by dynamic deployment of additional Clients, Servers and Relays 444 without disturbing the already-deployed base. 446 Note that in an alternate routing arrangement each set of Relays 447 could advertise an aggregated ASP for the link into the native 448 routing system even though each Relay services only a segment of the 449 ASP. In that case, a Relay upon receiving a packet with a 450 destination address covered by the ASP segment of another Relay can 451 simply tunnel the packet to the correct Relay. The tradeoff then is 452 the penalty for Relay-to-Relay tunneling compared with reduced 453 routing information in the native routing system. 455 Finally, Relays can determine preferences for ACPs learned from 456 multiple Servers by examining a BGP weight associated with each 457 Server's peering configuration. In this way Relays can choose the 458 Server with the highest weight as the preferred path, and then fail 459 over to a Server with lower weight in case of ACP withdrawal or 460 Server failure. 462 3.4. AERO Interface Link-local Addresses 464 AERO interface link-local address types include administratively- 465 provisioned addresses and AERO addresses. 467 Administratively-provisioned addresses are allocated from the range 468 fe80::/96 and assigned to a Server or Relay's AERO interface. 469 Administratively-provisioned addresses MUST be managed for uniqueness 470 by the administrative authority for the AERO link. (Note that fe80:: 471 is the IPv6 link-local subnet router anycast address, and 472 fe80::ffff:ffff is the address used by Clients to bootstrap AERO 473 address autoconfiguration. These special addresses are therefore not 474 available for administrative provisioning.) 476 An AERO address is an IPv6 link-local address with an embedded prefix 477 based on an ACP and associated with a Client's AERO interface. AERO 478 addresses remain stable as the Client moves between topological 479 locations, i.e., even if its link-layer addresses change. 481 For IPv6, AERO addresses begin with the prefix fe80::/64 and include 482 in the interface identifier (i.e., the lower 64 bits) a 64-bit prefix 483 taken from one of the Client's IPv6 ACPs. For example, if the AERO 484 Client receives the IPv6 ACP: 486 2001:db8:1000:2000::/56 488 it constructs its corresponding AERO addresses as: 490 fe80::2001:db8:1000:2000 492 fe80::2001:db8:1000:2001 494 fe80::2001:db8:1000:2002 496 ... etc. ... 498 fe80::2001:db8:1000:20ff 500 For IPv4, AERO addresses are based on an IPv4-mapped IPv6 address 501 [RFC4291] formed from an IPv4 ACP and with a Prefix Length of 96 plus 502 the ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 503 the IPv4-mapped IPv6 ACP is: 505 0:0:0:0:0:FFFF:192.0.2.16/124 507 The Client then constructs its AERO addresses with the prefix 508 fe80::/64 and with the lower 64 bits of the IPv4-mapped IPv6 address 509 in the interface identifier as: 511 fe80::FFFF:192.0.2.16 513 fe80::FFFF:192.0.2.17 515 fe80::FFFF:192.0.2.18 517 ... etc. ... 519 fe80:FFFF:192.0.2.31 521 When the Server delegates ACPs to the Client, both the Server and 522 Client use the lowest-numbered AERO address from the first ACP 523 delegation as the "base" AERO address. (For example, for the ACP 524 2001:db8:1000:2000::/56 the base address is 2001:db8:1000:2000.) The 525 Client then assigns the base AERO address to the AERO interface and 526 uses it for the purpose of maintaining the neighbor cache entry. If 527 the Client has multiple AERO addresses (i.e., when there are multiple 528 ACPs and/or ACPs with short prefix lengths), the Client originates 529 IPv6 ND messages using the base AERO address as the source address 530 and accepts and responds to IPv6 ND messages destined to any of its 531 AERO addresses as equivalent to the base AERO address. In this way, 532 the Client maintains a single neighbor cache entry with multiple AERO 533 addresses. 535 3.5. AERO Interface Characteristics 537 AERO interfaces use encapsulation (see: Section 3.9) to exchange 538 packets with neighbors attached to the AERO link. 540 AERO interfaces maintain a neighbor cache, and use both DHCPv6 and 541 IPv6 ND control messaging to manage the creation, modification and 542 deletion of neighbor cache entries. AERO interfaces use standard 543 DHCPv6 messaging for prefix delegation, prefix management, admission 544 control and neighbor cache entry establishment. AERO interfaces use 545 unicast IPv6 ND Neighbor Solicitation (NS), Neighbor Advertisement 546 (NA), Router Solicitation (RS) and Router Advertisement (RA) messages 547 for neighbor cache management the same as for any IPv6 link. AERO 548 interfaces use two IPv6 ND redirection message types -- the first 549 known as a Predirect message and the second being the standard 550 Redirect message (see Section 3.15). 552 AERO interface ND messages include one or more Source/Target Link- 553 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length = 5 | Reserved | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Interface ID | UDP Port Number | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 + + 564 | | 565 + IP Address + 566 | | 567 + + 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 580 Format 582 In this format: 584 o Type is set to '1' for SLLAO or '2' for TLLAO the same as for IPv6 585 ND. 587 o Length is set to the constant value '5' (i.e., 5 units of 8 588 octets). 590 o Reserved is set to the value '0' on transmission and ignored on 591 receipt. 593 o Interface ID is set to an integer value between 0 and 65535 594 corresponding to an underlying interface of the AERO node. 596 o UDP Port Number and IP Address are set to the addresses used by 597 the AERO node when it sends encapsulated packets over the 598 underlying interface. When UDP is not used as part of the 599 encapsulation, UDP Port Number is set to the value '0'. When the 600 encapsulation IP address family is IPv4, IP Address is formed as 601 an IPv4-mapped IPv6 address as specified in Section 3.4. 603 o P[i] is a set of 64 Preference values that correspond to the 64 604 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 605 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 606 ("medium") or '3' ("high") to indicate a preference level for 607 packet forwarding purposes. 609 AERO interfaces may be configured over multiple underlying 610 interfaces. For example, common mobile handheld devices have both 611 wireless local area network ("WLAN") and cellular wireless links. 612 These links are typically used "one at a time" with low-cost WLAN 613 preferred and highly-available cellular wireless as a standby. In a 614 more complex example, aircraft frequently have many wireless data 615 link types (e.g. satellite-based, cellular, terrestrial, air-to-air 616 directional, etc.) with diverse performance and cost properties. 618 If a Client's multiple underlying interfaces are used "one at a time" 619 (i.e., all other interfaces are in standby mode while one interface 620 is active), then IPv6 ND messages include only a single S/TLLAO with 621 Interface ID set to a constant value. 623 If the Client has multiple active underlying interfaces, then from 624 the perspective of IPv6 ND it would appear to have multiple link- 625 layer addresses. In that case, IPv6 ND messages MAY include multiple 626 S/TLLAOs -- each with an Interface ID that corresponds to a specific 627 underlying interface of the AERO node. 629 3.6. AERO Interface Initialization 631 3.6.1. AERO Relay Behavior 633 When a Relay enables an AERO interface, it first assigns an 634 administratively-provisioned link-local address fe80::ID to the 635 interface. Each fe80::ID address MUST be unique among all AERO nodes 636 on the link, and is taken from the range fe80::/96 but excluding the 637 special addresses fe80:: and fe80::ffff:ffff. The Relay then engages 638 in a dynamic routing protocol session with all Servers on the link 639 (see: Section 3.3), and advertises its assigned ASPs into the native 640 IP Internetwork. 642 Each Relay subsequently maintains an IP forwarding table entry for 643 each active ACP covered by its ASP(s), and maintains a neighbor cache 644 entry for each Server on the link. Relays exchange NS/NA messages 645 with AERO link neighbors the same as for any AERO node, however they 646 typically do not perform explicit Neighbor Unreachability Detection 647 (NUD) (see: Section 3.16) since the dynamic routing protocol already 648 provides reachability confirmation. 650 3.6.2. AERO Server Behavior 652 When a Server enables an AERO interface, it assigns an 653 administratively-provisioned link-local address fe80::ID the same as 654 for Relays. The Server further configures a DHCPv6 server function 655 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 656 maintains a neighbor cache entry for each Relay on the link, and 657 manages per-Client neighbor cache entries and IP forwarding table 658 entries based on control message exchanges. Each Server also engages 659 in a dynamic routing protocol with each Relay on the link (see: 660 Section 3.3). 662 When the Server receives an NS/RS message from a Client on the AERO 663 interface it returns an NA/RA message. The Server further provides a 664 simple link-layer conduit between AERO interface neighbors. In 665 particular, when a packet sent by a source Client arrives on the 666 Server's AERO interface and is destined to another AERO node, the 667 Server forwards the packet at the link layer without ever disturbing 668 the network layer and without ever leaving the AERO interface. 670 3.6.3. AERO Client Behavior 672 When a Client enables an AERO interface, it uses the special 673 administratively-provisioned link-local address fe80::ffff:ffff as 674 the source network-layer address in DHCPv6 PD messages to obtain one 675 or more ACPs from an AERO Server. Next, the Client assigns the base 676 AERO address to the AERO interface and sends an RS to the Server to 677 receive an RA. In this way, the DHCPv6 PD exchange securely 678 bootstraps autoconfiguration of unique link-local address(es) while 679 the RS/RA exchange establishes link-layer addresses and 680 autoconfigures AERO link parameters. The Client maintains a neighbor 681 cache entry for each of its Servers and each of its active 682 correspondent Clients. When the Client receives IPv6 ND messages on 683 the AERO interface it updates or creates neighbor cache entries, 684 including link-layer address information. 686 3.7. AERO Interface Neighbor Cache Maintenace 688 Each AERO interface maintains a conceptual neighbor cache that 689 includes an entry for each neighbor it communicates with on the AERO 690 link, the same as for any IPv6 interface [RFC4861]. AERO interface 691 neighbor cache entires are said to be one of "permanent", "static" or 692 "dynamic". 694 Permanent neighbor cache entries are created through explicit 695 administrative action; they have no timeout values and remain in 696 place until explicitly deleted. AERO Relays maintain a permanent 697 neighbor cache entry for each Server on the link, and AERO Servers 698 maintain a permanent neighbor cache entry for each Relay. Each entry 699 maintains the mapping between the neighbor's fe80::ID network-layer 700 address and corresponding link-layer address. 702 Static neighbor cache entries are created and maintained through 703 DHCPv6 PD and IPv6 ND exchanges as specified in Section 3.14, and 704 remain in place for durations bounded by prefix delegation lifetimes. 705 AERO Servers maintain static neighbor cache entries for the ACPs of 706 each of their associated Clients, and AERO Clients maintain a static 707 neighbor cache entry for each of their associated Servers. When an 708 AERO Server delegates prefixes via DHCPv6 PD, it creates a static 709 neighbor cache entry for the Client using the Client's base AERO 710 address as the network-layer address and associates all of the 711 Client's other AERO addresses with the neighbor cache entry. When 712 the Client receives the prefix delegation, it creates a static 713 neighbor cache entry for the Server based on the DHCPv6 Reply message 714 link-local source address as the network-layer address and the 715 encapsulation IP source address and UDP source port number as the 716 link-layer address. The Client then sends an RS message to inform 717 the Server of its link-layer addresses and to solicit an RA. When 718 the Server returns an RA message, the Client uses the 719 autoconfiguration information in the RA message to configure AERO 720 interface parameters. 722 Dynamic neighbor cache entries are created or updated based on 723 receipt of a Predirect/Redirect message as specified in Section 3.15, 724 and are garbage-collected when keepalive timers expire. AERO Clients 725 maintain dynamic neighbor cache entries for each of their active 726 correspondent Clients with lifetimes based on IPv6 ND messaging 727 constants. When an AERO Client receives a valid Predirect message it 728 creates or updates a dynamic neighbor cache entry for the Predirect 729 target network-layer and link-layer addresses. The node then sets an 730 "AcceptTime" variable in the neighbor cache entry to ACCEPT_TIME 731 seconds and uses this value to determine whether packets received 732 from the correspondent can be accepted. When an AERO Client receives 733 a valid Redirect message it creates or updates a dynamic neighbor 734 cache entry for the Redirect target network-layer and link-layer 735 addresses. The Client then sets a "ForwardTime" variable in the 736 neighbor cache entry to FORWARD_TIME seconds and uses this value to 737 determine whether packets can be sent directly to the correspondent. 738 The Client also sets a "MaxRetry" variable to MAX_RETRY to limit the 739 number of keepalives sent when a correspondent may have gone 740 unreachable. 742 It is RECOMMENDED that FORWARD_TIME be set to the default constant 743 value 30 seconds to match the default REACHABLE_TIME value specified 744 for IPv6 ND [RFC4861]. 746 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 747 value 40 seconds to allow a 10 second window so that the AERO 748 redirection procedure can converge before AcceptTime decrements below 749 FORWARD_TIME. 751 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 752 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 754 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 755 administratively set, if necessary, to better match the AERO link's 756 performance characteristics; however, if different values are chosen, 757 all nodes on the link MUST consistently configure the same values. 758 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 759 sufficiently longer than FORWARD_TIME to allow the AERO redirection 760 procedure to converge. 762 When there may be a Network Address Translator (NAT) between the 763 Client and the Server, or if the path from the Client to the Server 764 should be tested for reachability, the Client can send periodic RS 765 messages to the Server to receive RA replies. The RS/RA messaging 766 will keep NAT state alive and test Server reachability without 767 disturbing the DHCPv6 server. 769 3.8. AERO Interface Forwarding Algorithm 771 IP packets enter a node's AERO interface either from the network 772 layer (i.e., from a local application or the IP forwarding system) or 773 from the link layer (i.e., from the AERO tunnel virtual link). 774 Packets that enter the AERO interface from the network layer are 775 encapsulated and forwarded into the AERO link, i.e., they are 776 tunnelled to an AERO interface neighbor. Packets that enter the AERO 777 interface from the link layer are either re-admitted into the AERO 778 link or forwarded to the network layer where they are subject to 779 either local delivery or IP forwarding. In all cases, the AERO 780 interface itself MUST NOT decrement the network layer TTL/Hop-count 781 since its forwarding actions occur below the network layer. 783 AERO interfaces may have multiple underlying interfaces and/or 784 neighbor cache entries for neighbors with multiple Interface ID 785 registrations (see Section 3.5). The AERO node uses each packet's 786 DSCP value to select an outgoing underlying interface based on the 787 node's own preference values, and also to select a destination link- 788 layer address based on the neighbor's underlying interface with the 789 highest preference value. If multiple outgoing interfaces and/or 790 neighbor interfaces have a preference of "high", the AERO node sends 791 one copy of the packet via each of the (outgoing interface, neighbor 792 interface) pairs; otherwise, the node sends a single copy of the 793 packet. 795 The following sections discuss the AERO interface forwarding 796 algorithms for Clients, Servers and Relays. In the following 797 discussion, a packet's destination address is said to "match" if it 798 is a non-link-local address with a prefix covered by an ASP/ACP, or 799 if it is an AERO address that embeds an ACP, or if it is the same as 800 an administratively-provisioned link-local address. 802 3.8.1. Client Fowarding Algorithm 804 When an IP packet enters a Client's AERO interface from the network 805 layer the Client searches for a neighbor cache entry that matches the 806 destination. If there is a match, the Client uses one or more link- 807 layer addresses in the entry as the link-layer addresses for 808 encapsulation and admits the packet into the AERO link. Otherwise, 809 the Client uses the link-layer address in a static neighbor cache 810 entry for a Server as the encapsulation address. 812 When an IP packet enters a Client's AERO interface from the link- 813 layer, if the destination matches one of the Client's ACPs or link- 814 local addresses the Client decapsulates the packet and delivers it to 815 the network layer. Otherwise, the Client drops the packet silently. 817 3.8.2. Server Fowarding Algorithm 819 When an IP packet enters a Server's AERO interface from the network 820 layer, the Server searches for a static or dynamic neighbor cache 821 entry that matches the destination. If there is a match, the Server 822 uses one or more link-layer addresses in the entry as the link-layer 823 addresses for encapsulation and admits the packet into the AERO link. 824 Otherwise, the Server uses the link-layer address in a permanent 825 neighbor cache entry for a Relay (selected through longest-prefix 826 match) as the link-layer address for encapsulation. 828 When an IP packet enters a Server's AERO interface from the link 829 layer, the Server processes the packet as follows: 831 o if the destination matches one of the Server's link-local 832 addresses the Server decapsulates the packet and forwards it to 833 the network layer for local delivery. 835 o else, if the destination matches a dynamic neighbor cache entry 836 the Server first determines whether the neighbor is the same as 837 the one it received the packet from. If so, the Server MUST drop 838 the packet silently to avoid looping; otherwise, the Server uses 839 the neighbor's link-layer address(es) as the destination for 840 encapsulation and re-admits the packet into the AERO link. 842 o else, the Server uses the link-layer address in a permanent 843 neighbor cache entry for a Relay (selected through longest-prefix 844 match) as the link-layer address for encapsulation. 846 3.8.3. Relay Fowarding Algorithm 848 When an IP packet enters a Relay's AERO interface from the network 849 layer, the Relay searches its IP forwarding table for an ACP entry 850 that matches the destination and otherwise searches for a neighbor 851 cache entry that matches the destination. If there is a match, the 852 Relay uses the link-layer address in the corresponding neighbor cache 853 entry as the link-layer address for encapsulation and forwards the 854 packet into the AERO link. Otherwise, the Relay drops the packet and 855 (for non-link-local addresses) returns an ICMP Destination 856 Unreachable message subject to rate limiting (see: Section 3.13). 858 When an IP packet enters a Relay's AERO interface from the link- 859 layer, the Relay processes the packet as follows: 861 o if the destination does not match an ASP, or if the destination 862 matches one of the Relay's link-local addresses, the Relay 863 decapsulates the packet and forwards it to the network layer where 864 it will be subject to either local delivery or IP forwarding. 866 o else, if the destination matches an ACP entry in the IP forwarding 867 table, or if the destination matches the link-local address in a 868 permanent neighbor cache entry, the Relay first determines whether 869 the neighbor is the same as the one it received the packet from. 870 If so the Relay MUST drop the packet silently to avoid looping; 871 otherwise, the Relay uses the neighbor's link-layer address as the 872 destination for encapsulation and re-admits the packet into the 873 AERO link. 875 o else, the Relay drops the packet and (for non-link-local 876 addresses) returns an ICMP Destination Unreachable message subject 877 to rate limiting (see: Section 3.13). 879 3.9. AERO Interface Encapsulation and Re-encapsulation 881 AERO interfaces encapsulate IP packets according to whether they are 882 entering the AERO interface from the network layer or if they are 883 being re-admitted into the same AERO link they arrived on. This 884 latter form of encapsulation is known as "re-encapsulation". 886 The AERO interface encapsulates packets per the Generic UDP 887 Encapsulation (GUE) procedures in 888 [I-D.ietf-nvo3-gue][I-D.herbert-gue-fragmentation], or through an 889 alternate encapsulation format (see: Appendix A). For packets 890 entering the AERO interface from the network layer, the AERO 891 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 892 [RFC2983], "Flow Label"[RFC6438].(for IPv6) and "Congestion 893 Experienced" [RFC3168] values in the packet's IP header into the 894 corresponding fields in the encapsulation IP header. For packets 895 undergoing re-encapsulation, the AERO interface instead copies these 896 values from the original encapsulation IP header into he new 897 encapsulation header, i.e., the values are transferred between 898 encapsulation headers and *not* copied from the encapsulated packet's 899 network-layer header. (Note especially that by copying the TTL/Hop 900 Limit between encapsulation headers the value will eventually 901 decrement to 0 if there is a (temporary) routing loop.) For IPv4 902 encapsulation/re-encapsulation, the AERO interface sets the DF bit as 903 discussed in Section 3.12. 905 When GUE encapsulation is used, the AERO interface next sets the UDP 906 source port to a constant value that it will use in each successive 907 packet it sends, and sets the UDP length field to the length of the 908 encapsulated packet plus 8 bytes for the UDP header itself plus the 909 length of the GUE header (or 0 if GUE direct IP encapsulation is 910 used). For packets sent to a Server or Relay, the AERO interface 911 sets the UDP destination port to 8060, i.e., the IANA-registered port 912 number for AERO. For packets sent to a Client, the AERO interface 913 sets the UDP destination port to the port value stored in the 914 neighbor cache entry for this Client. The AERO interface then either 915 includes or omits the UDP checksum according to the GUE 916 specification. 918 3.10. AERO Interface Decapsulation 920 AERO interfaces decapsulate packets destined either to the AERO node 921 itself or to a destination reached via an interface other than the 922 AERO interface the packet was received on. Decapsulation is per the 923 procedures specified for the appropriate encapsulation format. 925 3.11. AERO Interface Data Origin Authentication 927 AERO nodes employ simple data origin authentication procedures for 928 encapsulated packets they receive from other nodes on the AERO link. 929 In particular: 931 o AERO Servers and Relays accept encapsulated packets with a link- 932 layer source address that matches a permanent neighbor cache 933 entry. 935 o AERO Servers accept authentic encapsulated DHCPv6 and IPv6 ND 936 messages from Clients, and create or update a static neighbor 937 cache entry for the Client based on the specific message type. 939 o AERO Clients and Servers accept encapsulated packets if there is a 940 static neighbor cache entry with a link-layer address that matches 941 the packet's link-layer source address. 943 o AERO Clients and Servers accept encapsulated packets if there is a 944 dynamic neighbor cache entry with an AERO address that matches the 945 packet's network-layer (link-local or non-link-local) source 946 address, with a link-layer address that matches the packet's link- 947 layer source address, and with a non-zero AcceptTime. 949 Note that this simple data origin authentication is effective in 950 environments in which link-layer addresses cannot be spoofed. In 951 other environments, each AERO message must include a signature that 952 the recipient can use to authenticate the message origin, e.g., as 953 for common VPN systems such as OpenVPN [OVPN]. In environments where 954 end systems use end-to-end security, however, it may be sufficient to 955 require signatures only for AERO DHCPv6, IPv6 ND and ICMP control 956 plane messages and omit signatures for data plane messages. 958 3.12. AERO Interface Packet Size Issues 960 The AERO interface is the node's attachment to the AERO link. The 961 AERO interface acts as a tunnel ingress when it sends a packet to an 962 AERO link neighbor and as a tunnel egress when it receives a packet 963 from an AERO link neighbor. AERO interfaces observe the packet 964 sizing considerations for tunnels discussed in 965 [I-D.ietf-intarea-tunnels] and as specified below. 967 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 968 bytes [RFC2460]. Although IPv4 specifies a smaller minimum link MTU 969 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 970 for IPv4 even if the packet may incur fragmentation in the network. 972 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 973 [RFC2460], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 974 (note that common IPv6 over IPv4 tunnels already assume a larger MRU 975 than the IPv4 minimum). 977 Original sources expect that IP packets will either be delivered to 978 the final destination or a suitable Packet Too Big (PTB) message 979 returned. However, PTB messages may be crafted for malicious 980 purposes such as denial of service, or lost in the network [RFC2923] 981 resulting in failure of the IP Path MTU Discovery (PMTUD) mechanisms 982 [RFC1191][RFC1981]. For these reasons, AERO links employ operational 983 procedures that avoid all interactions with PMTUD. 985 AERO Servers advertise an MTU that MUST NOT be smaller than 1280 986 bytes, MUST NOT be larger than the minimum MRU among all nodes on the 987 AERO link minus the encapsulation overhead ("ENCAPS"), and SHOULD NOT 988 be smaller than 1500 bytes. AERO Servers advertise a Maximum 989 Fragment Unit (MFU) as the maximum size for the fragments of an 990 encapsulated packet that require fragmentation. The MFU value MUST 991 NOT be larger than (MTU+ENCAPS) and MUST NOT be larger than 1280 992 bytes unless there is operational assurance that a larger size can 993 traverse the link along all paths without fragmentation. 995 All AERO nodes MUST set the AERO interface MTU/MFU according to the 996 values advertised by Servers. All AERO nodes MUST configure the same 997 MTU/MFU values for reasons cited in [RFC3819][RFC4861] (in 998 particular, multicast support requires a common MTU value among all 999 nodes on the link). All AERO nodes MUST configure an MRU large 1000 enough to reassemble packets up to (MTU+ENCAPS) bytes in length; 1001 nodes that cannot configure a large-enough MRU MUST NOT enable an 1002 AERO interface. 1004 In accordance with these requirements, the ingress accommodates 1005 packets of various sizes as follows: 1007 o First, for each original IPv4 packet that is larger than the AERO 1008 interface MTU and with the DF bit set to 0, the ingress uses IPv4 1009 fragmentation to break the packet into a minimum number of non- 1010 overlapping fragments where the first fragment is no larger than 1011 (MFU-ENCAPS) bytes and the remaining fragments are no larger than 1012 the first. 1014 o Next, for each original IP packet or fragment that is no larger 1015 than (MFU-ENCAPS) bytes, the ingress encapsulates the packet and 1016 admits it into the tunnel. For IPv4 encapsulation, the ingress 1017 sets the Don't Fragment (DF) bit to 0 so that these packets will 1018 be delivered to the egress even if some fragmentation occurs in 1019 the network. 1021 o For all other original IP packets or fragments, if the packet is 1022 larger than the AERO interface MTU, the ingress drops the packet 1023 and returns a PTB message to the original source. Otherwise, the 1024 ingress encapsulates the packet and fragments the encapsulated 1025 packet into a minimum number of non-overlapping fragments where 1026 the first fragment is no larger than MFU bytes and the remaining 1027 fragments are no larger than the first. The ingress then admits 1028 the fragments into the tunnel, and for IPv4 sets the DF bit to 0 1029 in the IP encapsulation header. These fragmented encapsulated 1030 packets will be delivered to the egress, which reassembles them 1031 into a whole packet. 1033 Several factors must be considered when fragmentation of the 1034 encapsulated packet is needed. For AERO links over IPv4, the IP ID 1035 field is only 16 bits in length, meaning that fragmentation at high 1036 data rates could result in data corruption due to reassembly 1037 misassociations [RFC6864][RFC4963]. For AERO links over both IPv4 1038 and IPv6, studies have also shown that IP fragments are dropped 1039 unconditionally over some network paths [I-D.taylor-v6ops-fragdrop]. 1040 In environments where IP fragmentation issues could result in 1041 operational problems, the ingress SHOULD employ intermediate-layer 1042 fragmentation (see: [RFC2764] and [I-D.herbert-gue-fragmentation]) 1043 before appending the outer encapsulation headers to each fragment. 1045 Since the encapsulation fragment header reduces the room available 1046 for packet data, but the original source has no way to control its 1047 insertion, the ingress MUST include the fragment header length in the 1048 ENCAPS length even for packets in which the header is absent. 1050 3.13. AERO Interface Error Handling 1052 When an AERO node admits encapsulated packets into the AERO 1053 interface, it may receive link-layer or network-layer error 1054 indications. 1056 A link-layer error indication is an ICMP error message generated by a 1057 router on the path to the neighbor or by the neighbor itself. The 1058 message includes an IP header with the address of the node that 1059 generated the error as the source address and with the link-layer 1060 address of the AERO node as the destination address. 1062 The IP header is followed by an ICMP header that includes an error 1063 Type, Code and Checksum. Valid type values include "Destination 1064 Unreachable", "Time Exceeded" and "Parameter Problem" 1065 [RFC0792][RFC4443]. (AERO interfaces ignore all link-layer IPv4 1066 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1067 only emit packets that are guaranteed to be no larger than the IP 1068 minimum link MTU as discussed in Section 3.12.) 1070 The ICMP header is followed by the leading portion of the packet that 1071 generated the error, also known as the "packet-in-error". For 1072 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1073 much of invoking packet as possible without the ICMPv6 packet 1074 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1075 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1076 "Internet Header + 64 bits of Original Data Datagram", however 1077 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1078 ICMP datagram SHOULD contain as much of the original datagram as 1079 possible without the length of the ICMP datagram exceeding 576 1080 bytes". 1082 The link-layer error message format is shown in Figure 3 (where, "L2" 1083 and "L3" refer to link-layer and network-layer, respectively): 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 ~ ~ 1087 | L2 IP Header of | 1088 | error message | 1089 ~ ~ 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | L2 ICMP Header | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1093 ~ ~ P 1094 | IP and other encapsulation | a 1095 | headers of original L3 packet | c 1096 ~ ~ k 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1098 ~ ~ t 1099 | IP header of | 1100 | original L3 packet | i 1101 ~ ~ n 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 ~ ~ e 1104 | Upper layer headers and | r 1105 | leading portion of body | r 1106 | of the original L3 packet | o 1107 ~ ~ r 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1110 Figure 3: AERO Interface Link-Layer Error Message Format 1112 The AERO node rules for processing these link-layer error messages 1113 are as follows: 1115 o When an AERO node receives a link-layer Parameter Problem message, 1116 it processes the message the same as described as for ordinary 1117 ICMP errors in the normative references [RFC0792][RFC4443]. 1119 o When an AERO node receives persistent link-layer Time Exceeded 1120 messages, the IP ID field may be wrapping before earlier fragments 1121 awaiting reassembly have been processed. In that case, the node 1122 SHOULD begin including integrity checks and/or institute rate 1123 limits for subsequent packets. 1125 o When an AERO node receives persistent link-layer Destination 1126 Unreachable messages in response to encapsulated packets that it 1127 sends to one of its dynamic neighbor correspondents, the node 1128 SHOULD test the path to the correspondent using Neighbor 1129 Unreachability Detection (NUD) (see Section 3.16). If NUD fails, 1130 the node SHOULD set ForwardTime for the corresponding dynamic 1131 neighbor cache entry to 0 and allow future packets destined to the 1132 correspondent to flow through a default route. 1134 o When an AERO Client receives persistent link-layer Destination 1135 Unreachable messages in response to encapsulated packets that it 1136 sends to one of its static neighbor Servers, the Client SHOULD 1137 test the path to the Server using NUD. If NUD fails, the Client 1138 SHOULD associate with a new Server and send a DHCPv6 Release 1139 message to the old Server as specified in Section 3.17.5. 1141 o When an AERO Server receives persistent link-layer Destination 1142 Unreachable messages in response to encapsulated packets that it 1143 sends to one of its static neighbor Clients, the Server SHOULD 1144 test the path to the Client using NUD. If NUD fails, the Server 1145 SHOULD cancel the DHCPv6 PD for the Client's ACP, withdraw its 1146 route for the ACP from the AERO routing system and delete the 1147 neighbor cache entry (see Section 3.16 and Section 3.17). 1149 o When an AERO Relay or Server receives link-layer Destination 1150 Unreachable messages in response to an encapsulated packet that it 1151 sends to one of its permanent neighbors, it treats the messages as 1152 an indication that the path to the neighbor may be failing. 1153 However, neighbor reachability will be determined by the dynamic 1154 routing protocol. 1156 When an AERO Relay receives a packet for which the network-layer 1157 destination address is covered by an ASP, if there is no more- 1158 specific routing information for the destination the Relay drops the 1159 packet and returns a network-layer Destination Unreachable message 1160 subject to rate limiting. The Relay first writes the network-layer 1161 source address of the original packet as the destination address of 1162 the message and determines the next hop to the destination. If the 1163 next hop is reached via the AERO interface, the Relay uses the IPv6 1164 address "::" or the IPv4 address "0.0.0.0" as the source address of 1165 the message, then encapsulates the message and forwards it to the 1166 next hop within the AERO interface. Otherwise, the Relay uses one of 1167 its non link-local addresses as the source address of the message and 1168 forwards it via a link outside the AERO interface. 1170 When an AERO node receives an encapsulated packet for which the 1171 reassembly buffer it too small, it drops the packet and returns an 1172 network-layer Packet Too Big (PTB) message. The node first writes 1173 the MRU value into the PTB message MTU field, writes the network- 1174 layer source address of the original packet as the destination 1175 address of the message and determines the next hop to the 1176 destination. If the next hop is reached via the AERO interface, the 1177 node uses the IPv6 address "::" or the IPv4 address "0.0.0.0" as the 1178 source address of the message, then encapsulates the message and 1179 forwards it to the next hop within the AERO interface. Otherwise, 1180 the node uses one of its non link-local addresses as the source 1181 address of the message and forwards it via a link outside the AERO 1182 interface. 1184 When an AERO node receives any network-layer error message via the 1185 AERO interface, it examines the network-layer destination address. 1186 If the next hop toward the destination is via the AERO interface, the 1187 node re-encapsulates and forwards the message to the next hop within 1188 the AERO interface. Otherwise, if the network-layer source address 1189 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1190 writes one of its non link-local addresses as the source address, 1191 recalculates the IP and/or ICMP checksums then forwards the message 1192 via a link outside the AERO interface. 1194 3.14. AERO Router Discovery, Prefix Delegation and Autoconfiguration 1196 AERO Router Discovery, Prefix Delegation and Autoconfiguration are 1197 coordinated by the DHCPv6 and IPv6 ND control messaging protocols as 1198 discussed in the following Sections. 1200 3.14.1. AERO DHCPv6 and IPv6 ND Service Model 1202 Each AERO Server configures a DHCPv6 server function to facilitate PD 1203 requests from Clients. Each Server is provisioned with a database of 1204 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1205 system, as well as any information necessary to authenticate each 1206 Client. The Client database is maintained by a central 1207 administrative authority for the AERO link and securely distributed 1208 to all Servers, e.g., via the Lightweight Directory Access Protocol 1209 (LDAP) [RFC4511], via static configuration, etc. 1211 Therefore, no Server-to-Server DHCPv6 PD state synchronization is 1212 necessary, and Clients can optionally hold separate PDs for the same 1213 ACPs from multiple Servers. In this way, Clients can associate with 1214 multiple Servers, and can receive new PDs from new Servers before 1215 deprecating PDs received from existing Servers. This provides the 1216 Client with a natural fault-tolerance and/or load balancing profile. 1218 AERO Clients and Servers use unicast IPv6 ND messages to maintain 1219 neighbor cache entries the same as for any link. AERO Servers act as 1220 default routers for AERO Clients, and therefore send unicast RA 1221 messages with configuration information in response to a Client's RS 1222 message. 1224 The following sections specify the Client and Server behavior. 1226 3.14.2. AERO Client Behavior 1228 AERO Clients discover the link-layer addresses of AERO Servers via 1229 static configuration (e.g., from a flat-file map of Server addresses 1230 and locations), or through an automated means such as DNS name 1231 resolution. In the absence of other information, the Client resolves 1232 the FQDN "linkupnetworks.[domainname]" where "linkupnetworks" is a 1233 constant text string and "[domainname]" is a DNS suffix for the 1234 Client's underlying network (e.g., "example.com"). After discovering 1235 the link-layer addresses, the Client associates with one or more of 1236 the corresponding Servers. 1238 To associate with a Server, the Client acts as a requesting router to 1239 request ACPs through a DHCPv6 PD exchange [RFC3315][RFC3633]. The 1240 Client's DHCPv6 Solicit message includes fe80::ffff:ffff as the IPv6 1241 source address, 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 1242 destination address, the address of the Client's underlying interface 1243 as the link-layer source address and the link-layer address of the 1244 Server as the link-layer destination address. The Client also 1245 includes a Client Identifier option with the Client's DUID, and an 1246 Identity Association for Prefix Delegation (IA_PD) option. If the 1247 Client is pre-provisioned with ACPs associated with the AERO service, 1248 it MAY also include the ACPs in the IA_PD to indicate its preferences 1249 to the DHCPv6 server. The Client finally includes any additional 1250 DHCPv6 options (including any necessary authentication options to 1251 identify itself to the DHCPv6 server), and sends the encapsulated 1252 Solicit message via any available underlying interface. 1254 When the Client attempts to perform a DHCPv6 PD exchange with a 1255 Server that is too busy to service the request, the Client may 1256 receive an error status code such as "NoPrefixAvail" in the Server's 1257 Reply [RFC3633] or no Reply at all. In that case, the Client SHOULD 1258 discontinue DHCPv6 PD attempts through this Server and try another 1259 Server. When the Client receives a Reply from the AERO Server it 1260 creates a static neighbor cache entry with the Server's link-local 1261 address as the network-layer address and the Server's encapsulation 1262 address as the link-layer address. Next, the Client autoconfigures 1263 AERO addresses for each of the delegated ACPs and assigns the base 1264 AERO address to the AERO interface. 1266 The Client then prepares a unicast RS message to send to the Server 1267 in order to obtain a solicited RA. The Client includes its base AERO 1268 address as the network-layer source address, the Server's link-local 1269 address as the network-layer destination address, the Client's link- 1270 layer address as the link-layer source address, and Server's link- 1271 layer address as the link-layer destination address. The Client also 1272 includes one or more SLLAOs formatted as described in Section 3.5 to 1273 register its link-layer address(es) with the Server. 1275 The first SLLAO MUST correspond to the underlying interface over 1276 which the Client will send the RS. The Client MAY include additional 1277 SLLAOs specific to other underlying interfaces, but if so it MUST 1278 have assurance that there will be no NATs on the paths to the Server 1279 via those interfaces (otherwise, the Client can register additional 1280 link-layer addresses with the Server by sending subsequent 1281 unsolicited NA messages after the initial RS/RA exchange). The 1282 Server will use the S/TLLAOs to populate its link-layer address 1283 information for the Client. 1285 When the Client receives an RA from the AERO Server (see 1286 Section 3.14.3), it configures a default route with the Server as the 1287 next hop via the AERO interface. The Client also caches any ASPs 1288 included in Prefix Information Options (PIOs) as ASPs to associate 1289 with the AERO link, and assigns the MTU/MFU values in the MTU options 1290 to its AERO interface while configuring an appropriate MRU. This 1291 configuration information applies to the AERO link as a whole, and 1292 all AERO nodes will use the same values.. 1294 Following autoconfiguration, the Client sub-delegates the ACPs to its 1295 attached EUNs and/or the Client's own internal virtual interfaces. 1296 In the former case, the Client acts as a router for nodes on its 1297 attached EUNs. In the latter case, the Client acts as a host and can 1298 configure as many addresses as it wants from /64 prefixes taken from 1299 the ACPs and assign them to either an internal virtual interface 1300 ("weak end-system") or to the AERO interface itself ("strong end- 1301 system") [RFC1122] while black-holing the remaining portions of the 1302 /64s. The Client subsequently renews its ACP delegations through 1303 each of its Servers by sending DHCPv6 Renew messages. 1305 After the Client registers its Interface IDs and their associated 1306 'P(i)' values, it may wish to change one or more Interface ID 1307 registrations, e.g., if an underlying interface becomes unavailable, 1308 if cost profiles change, etc. To do so, the Client prepares an 1309 unsolicited NA message to send over any available underlying 1310 interface. The NA MUST include a S/TLLAO specific to the selected 1311 available underlying interface as the first S/TLLAO and MAY include 1312 any additional S/TLLAOs specific to other underlying interfaces. The 1313 Client includes fresh 'P(i)' values in each S/TLLAO to update the 1314 Server's neighbor cache entry. If the Client wishes to disable some 1315 or all DSCPs for an underlying interface, it includes an S/TLLAO with 1316 'P(i)' values set to 0 ("disabled"). 1318 If the Client wishes to discontinue use of a Server it issues a 1319 DHCPv6 Release message to both delete the Server's neighbor cache 1320 entry and release the DHCPv6 PD. 1322 3.14.3. AERO Server Behavior 1324 AERO Servers configure a DHCPv6 server function on their AERO links. 1325 AERO Servers arrange to add their encapsulation layer IP addresses 1326 (i.e., their link-layer addresses) to a static map of Server 1327 addresses for the link and/or the DNS resource records for the FQDN 1328 "linkupnetworks.[domainname]" before entering service. 1330 When an AERO Server receives a prospective Client's Solicit on its 1331 AERO interface, and the Server is too busy to service the message, it 1332 SHOULD return a Reply with status code "NoPrefixAvail" per [RFC3633]. 1333 Otherwise, the Server authenticates the message. If authentication 1334 succeeds, the Server determines the correct ACPs to delegate to the 1335 Client by searching the Client database. 1337 Next, the Server prepares a Reply message to send to the Client while 1338 using fe80::ID as the network-layer source address, the link-local 1339 address taken from the Client's Solicit as the network-layer 1340 destination address, the Server's link-layer address as the source 1341 link-layer address, and the Client's link-layer address as the 1342 destination link-layer address. The Server also includes an IA_PD 1343 option with the delegated ACPs. For IPv4 ACPs, the prefix included 1344 in the IA_PD option is in IPv4-mapped IPv6 address format and with 1345 prefix length set as specified in Section 3.4. 1347 When the Server sends the Reply message, it creates a static neighbor 1348 cache entry for the Client using the base AERO address as the 1349 network-layer address and with lifetime set to no more than the 1350 smallest PD lifetime. The Client will subsequently issue an RS 1351 message with one or more SLLAO options and with the Client's base 1352 AERO address as the source address. 1354 When the Server receives the RS message, it first verifies that a 1355 neighbor cache entry for the Client exists (otherwise, it discards 1356 the RS). The Server then updates the neighbor cache entry link-layer 1357 address(es) by recording the information in each SLLAO option indexed 1358 by the Interface ID and including the UDP port number, IP address and 1359 P(i) values. For the first SLLAO in the list, however, the Server 1360 records the actual encapsulation source UDP and IP addresses instead 1361 of those that appear in the SLLAO in case there was a NAT in the 1362 path. 1364 The Server then prepares a unicast RA message to send back to the 1365 Client using fe80::ID as the network-layer source address, the 1366 Client's base AERO address as the network-layer destination address, 1367 the Server's link-layer address as the source link-layer address, and 1368 the source link-layer address of the RS message as the destination 1369 link-layer address. In the RA message, the Server includes one or 1370 more PIOs that encode the ASPs for the AERO link, and with flags A=0; 1371 L=1. The Server also includes two MTU options - the first MTU option 1372 includes the MTU for the link and the second MTU option includes the 1373 MFU for the link (see Section 3.12). 1375 When the Server delegates the ACPs, it also creates an IP forwarding 1376 table entry for each ACP so that the AERO BGP-based routing system 1377 will propagate the ACPs to all Relays that aggregate the 1378 corresponding ASP (see: Section 3.3). 1380 After the initial DHCPv6 PD Solicit/Reply and IPv6 ND RS/RA 1381 exchanges, the AERO Server maintains the neighbor cache entry for the 1382 Client until the PD lifetimes expire. If the Client issues a Renew, 1383 the Server extends the PD lifetimes. If the Client issues a Release, 1384 or if the Client does not issue a Renew before the lifetime expires, 1385 the Server deletes the neighbor cache entry for the Client and 1386 withdraws the IP routes from the AERO routing system. 1388 3.14.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1390 AERO Clients and Servers are always on the same link (i.e., the AERO 1391 link) from the perspective of DHCPv6. However, in some 1392 implementations the DHCPv6 server and AERO interface driver may be 1393 located in separate modules. In that case, the Server's AERO 1394 interface driver module can act as a Lightweight DHCPv6 Relay Agent 1395 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1396 server module. 1398 When the LDRA receives a DHCPv6 message from a Client addressed to 1399 either 'All_DHCP_Relay_Agents_and_Servers' or the Server's fe80::ID 1400 unicast address, it wraps the message in a Relay-Forward message 1401 header and includes an Interface-ID option that includes enough 1402 information to allow the LDRA to forward the resulting Reply message 1403 back to the Client (this information may include the Client's UDP and 1404 IP addresses, a security association identifier, etc). The LDRA then 1405 forwards the message to the DHCPv6 server. 1407 When the DHCPv6 server prepares a Reply message, it wraps the message 1408 in a Relay-Reply message and echoes the Interface-ID option. The 1409 DHCPv6 server then delivers the Relay-Reply message to the LDRA, 1410 which discards the Relay-Reply wrapper and delivers the DHCPv6 1411 message to the Client based on the information in the Interface ID 1412 option. 1414 3.15. AERO Interface Route Optimization 1416 When a source Client forwards packets to a prospective correspondent 1417 Client within the same AERO link domain (i.e., one for which the 1418 packet's destination address is covered by an ASP), the source Client 1419 MAY initiate an AERO link route optimization procedure. The 1420 procedure is based on an exchange of IPv6 ND messages using a chain 1421 of AERO Servers and Relays as a trust basis. 1423 Although the Client is responsible for initiating route optimization, 1424 the Server is the policy enforcement point that determines whether 1425 route optimization is permitted. For example, on some AERO links 1426 route optimization would allow traffic to circumvent critical 1427 network-based traffic interception points. In those cases, the 1428 Server can simply discard any route optimization messages instead of 1429 forwarding them. 1431 The following sections specify the AERO link route optimization 1432 procedure. 1434 3.15.1. Reference Operational Scenario 1436 Figure 4 depicts the AERO link route optimization reference 1437 operational scenario, using IPv6 addressing as the example (while not 1438 shown, a corresponding example for IPv4 addressing can be easily 1439 constructed). The figure shows an AERO Relay ('R1'), two AERO 1440 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1441 IPv6 hosts ('H1', 'H2'): 1443 +--------------+ +--------------+ +--------------+ 1444 | Server S1 | | Relay R1 | | Server S2 | 1445 +--------------+ +--------------+ +--------------+ 1446 fe80::2 fe80::1 fe80::3 1447 L2(S1) L2(R1) L2(S2) 1448 | | | 1449 X-----+-----+------------------+-----------------+----+----X 1450 | AERO Link | 1451 L2(C1) L2(C2) 1452 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1453 +--------------+ +--------------+ 1454 |AERO Client C1| |AERO Client C2| 1455 +--------------+ +--------------+ 1456 2001:DB8:0::/48 2001:DB8:1::/48 1457 | | 1458 .-. .-. 1459 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1460 .-(_ IP )-. +-------+ +-------+ .-(_ IP )-. 1461 (__ EUN )--|Host H1| |Host H2|--(__ EUN ) 1462 `-(______)-' +-------+ +-------+ `-(______)-' 1464 Figure 4: AERO Reference Operational Scenario 1466 In Figure 4, Relay ('R1') assigns the administratively-provisioned 1467 link-local address fe80::1 to its AERO interface with link-layer 1468 address L2(R1), Server ('S1') assigns the address fe80::2 with link- 1469 layer address L2(S1),and Server ('S2') assigns the address fe80::3 1470 with link-layer address L2(S2). Servers ('S1') and ('S2') next 1471 arrange to add their link-layer addresses to a published list of 1472 valid Servers for the AERO link. 1474 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1475 exchange via AERO Server ('S1') then assigns the address 1476 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1477 L2(C1). Client ('C1') configures a default route and neighbor cache 1478 entry via the AERO interface with next-hop address fe80::2 and link- 1479 layer address L2(S1), then sub-delegates the ACP to its attached 1480 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1481 address 2001:db8:0::1. 1483 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1484 exchange via AERO Server ('S2') then assigns the address 1485 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1486 L2(C2). Client ('C2') configures a default route and neighbor cache 1487 entry via the AERO interface with next-hop address fe80::3 and link- 1488 layer address L2(S2), then sub-delegates the ACP to its attached 1489 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1490 address 2001:db8:1::1. 1492 3.15.2. Concept of Operations 1494 Again, with reference to Figure 4, when source host ('H1') sends a 1495 packet to destination host ('H2'), the packet is first forwarded over 1496 the source host's attached EUN to Client ('C1'). Client ('C1') then 1497 forwards the packet via its AERO interface to Server ('S1') and also 1498 sends a Predirect message toward Client ('C2') via Server ('S1'). 1499 Server ('S1') then re-encapsulates and forwards both the packet and 1500 the Predirect message out the same AERO interface toward Client 1501 ('C2') via Relay ('R1'). 1503 When Relay ('R1') receives the packet and Predirect message, it 1504 consults its forwarding table to discover Server ('S2') as the next 1505 hop toward Client ('C2'). Relay ('R1') then forwards both the packet 1506 and the Predirect message to Server ('S2'), which then forwards them 1507 to Client ('C2'). 1509 After Client ('C2') receives the Predirect message, it process the 1510 message and returns a Redirect message toward Client ('C1') via 1511 Server ('S2'). During the process, Client ('C2') also creates or 1512 updates a dynamic neighbor cache entry for Client ('C1'). 1514 When Server ('S2') receives the Redirect message, it re-encapsulates 1515 the message and forwards it on to Relay ('R1'), which forwards the 1516 message on to Server ('S1') which forwards the message on to Client 1517 ('C1'). After Client ('C1') receives the Redirect message, it 1518 processes the message and creates or updates a dynamic neighbor cache 1519 entry for Client ('C2'). 1521 Following the above Predirect/Redirect message exchange, forwarding 1522 of packets from Client ('C1') to Client ('C2') without involving any 1523 intermediate nodes is enabled. The mechanisms that support this 1524 exchange are specified in the following sections. 1526 3.15.3. Message Format 1528 AERO Redirect/Predirect messages use the same format as for IPv6 ND 1529 Redirect messages depicted in Section 4.5 of [RFC4861]. AERO 1530 Redirect/Predirect messages formats are identical except that 1531 Redirect messages use Code=0, while Predirect messages use Code=1. 1532 The Redirect/Predirect message format is shown in Figure 5: 1534 0 1 2 3 1535 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 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Type (=137) | Code (=0/1) | Checksum | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Reserved | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | | 1542 + + 1543 | | 1544 + Target Address + 1545 | | 1546 + + 1547 | | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | | 1550 + + 1551 | | 1552 + Destination Address + 1553 | | 1554 + + 1555 | | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Options ... 1558 +-+-+-+-+-+-+-+-+-+-+-+- 1560 Figure 5: AERO Redirect/Predirect Message Format 1562 3.15.4. Sending Predirects 1564 When a Client forwards a packet with a source address from one of its 1565 ACPs toward a destination address covered by an ASP (i.e., toward 1566 another AERO Client connected to the same AERO link), the source 1567 Client MAY send a Predirect message forward toward the destination 1568 Client via the Server. 1570 In the reference operational scenario, when Client ('C1') forwards a 1571 packet toward Client ('C2'), it MAY also send a Predirect message 1572 forward toward Client ('C2'), subject to rate limiting (see 1573 Section 8.2 of [RFC4861]). Client ('C1') prepares the Predirect 1574 message as follows: 1576 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1577 layer address of Client ('C1')). 1579 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1580 link-layer address of Server ('S1')). 1582 o the network-layer source address is set to fe80::2001:db8:0:0 1583 (i.e., the base AERO address of Client ('C1')). 1585 o the network-layer destination address is set to the AERO address 1586 corresponding to the destination address of Client ('C2'). 1588 o the Type is set to 137. 1590 o the Code is set to 1 to indicate "Predirect". 1592 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the base 1593 AERO address of Client ('C1')). 1595 o the Destination Address is set to the source address of the 1596 originating packet that triggered the Predirection event. (If the 1597 originating packet is an IPv4 packet, the address is constructed 1598 in IPv4-mapped IPv6 address format). 1600 o the message includes one or more TLLAOs set to appropriate values 1601 for Client ('C1')'s underlying interfaces. 1603 o the message includes one or more Route Information Options (RIOs) 1604 [RFC4191] that include Client ('C1')'s ACPs. 1606 o the message SHOULD include a Timestamp option and a Nonce option. 1608 o the message includes a Redirected Header Option (RHO) that 1609 contains the originating packet truncated if necessary to ensure 1610 that at least the network-layer header is included but the size of 1611 the message does not exceed 1280 bytes. 1613 Note that the act of sending Predirect messages is cited as "MAY", 1614 since Client ('C1') may have advanced knowledge that the direct path 1615 to Client ('C2') would be unusable or otherwise undesirable. If the 1616 direct path later becomes unusable after the initial route 1617 optimization, Client ('C1') simply allows packets to again flow 1618 through Server ('S1'). 1620 3.15.5. Re-encapsulating and Relaying Predirects 1622 When Server ('S1') receives a Predirect message from Client ('C1'), 1623 it first verifies that the TLLAOs in the Predirect are a proper 1624 subset of the Interface IDs in Client ('C1')'s neighbor cache entry. 1625 If the Client's TLLAOs are not acceptable, Server ('S1') discards the 1626 message. Otherwise, Server ('S1') validates the message according to 1627 the Redirect message validation rules in Section 8.1 of [RFC4861], 1628 except that the Predirect has Code=1. Server ('S1') also verifies 1629 that Client ('C1') is authorized to use the ACPs encoded in the RIOs 1630 of the Predirect. If validation fails, Server ('S1') discards the 1631 Predirect; otherwise, it copies the correct UDP Port number and IP 1632 Address for Client ('C1')'s underlying link into the first TLLAO in 1633 case the addresses have been subject to NAT. 1635 Server ('S1') then examines the network-layer destination address of 1636 the Predirect to determine the next hop toward Client ('C2') by 1637 searching for the AERO address in the neighbor cache. Since Client 1638 ('C2') is not one of its neighbors, Server ('S1') re-encapsulates the 1639 Predirect and relays it via Relay ('R1') by changing the link-layer 1640 source address of the message to 'L2(S1)' and changing the link-layer 1641 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1642 re-encapsulated message to Relay ('R1') without decrementing the 1643 network-layer TTL/Hop Limit field. 1645 When Relay ('R1') receives the Predirect message from Server ('S1') 1646 it determines that Server ('S2') is the next hop toward Client ('C2') 1647 by consulting its forwarding table. Relay ('R1') then re- 1648 encapsulates the Predirect while changing the link-layer source 1649 address to 'L2(R1)' and changing the link-layer destination address 1650 to 'L2(S2)'. Relay ('R1') then relays the Predirect via Server 1651 ('S2'). 1653 When Server ('S2') receives the Predirect message from Relay ('R1') 1654 it determines that Client ('C2') is a neighbor by consulting its 1655 neighbor cache. Server ('S2') then re-encapsulates the Predirect 1656 while changing the link-layer source address to 'L2(S2)' and changing 1657 the link-layer destination address to 'L2(C2)'. Server ('S2') then 1658 forwards the message to Client ('C2'). 1660 3.15.6. Processing Predirects and Sending Redirects 1662 When Client ('C2') receives the Predirect message, it accepts the 1663 Predirect only if the message has a link-layer source address of one 1664 of its Servers (e.g., L2(S2)). Client ('C2') further accepts the 1665 message only if it is willing to serve as a redirection target. 1666 Next, Client ('C2') validates the message according to the Redirect 1667 message validation rules in Section 8.1 of [RFC4861], except that it 1668 accepts the message even though Code=1 and even though the network- 1669 layer source address is not that of it's current first-hop router. 1671 In the reference operational scenario, when Client ('C2') receives a 1672 valid Predirect message, it either creates or updates a dynamic 1673 neighbor cache entry that stores the Target Address of the message as 1674 the network-layer address of Client ('C1') , stores the link-layer 1675 addresses found in the TLLAOs as the link-layer addresses of Client 1676 ('C1'), and stores the ACPs encoded in the RIOs of the Predirect as 1677 the ACPs for Client ('C1'). Client ('C2') then sets AcceptTime for 1678 the neighbor cache entry to ACCEPT_TIME. 1680 After processing the message, Client ('C2') prepares a Redirect 1681 message response as follows: 1683 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1684 layer address of Client ('C2')). 1686 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1687 link-layer address of Server ('S2')). 1689 o the network-layer source address is set to fe80::2001:db8:1:0 1690 (i.e., the base AERO address of Client ('C2')). 1692 o the network-layer destination address is set to fe80::2001:db8:0:0 1693 (i.e., the base AERO address of Client ('C1')). 1695 o the Type is set to 137. 1697 o the Code is set to 0 to indicate "Redirect". 1699 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the base 1700 AERO address of Client ('C2')). 1702 o the Destination Address is set to the destination address of the 1703 originating packet that triggered the Redirection event. (If the 1704 originating packet is an IPv4 packet, the address is constructed 1705 in IPv4-mapped IPv6 address format). 1707 o the message includes one or more TLLAOs set to appropriate values 1708 for Client ('C2')'s underlying interfaces. 1710 o the message includes one or more Route Information Options (RIOs) 1711 that include Client ('C2')'s ACPs. 1713 o the message SHOULD include a Timestamp option and MUST echo the 1714 Nonce option received in the Predirect (i.e., if a Nonce option is 1715 included). 1717 o the message includes as much of the RHO copied from the 1718 corresponding Predirect message as possible such that at least the 1719 network-layer header is included but the size of the message does 1720 not exceed 1280 bytes. 1722 After Client ('C2') prepares the Redirect message, it sends the 1723 message to Server ('S2'). 1725 3.15.7. Re-encapsulating and Relaying Redirects 1727 When Server ('S2') receives a Redirect message from Client ('C2'), it 1728 first verifies that the TLLAOs in the Redirect are a proper subset of 1729 the Interface IDs in Client ('C2')'s neighbor cache entry. If the 1730 Client's TLLAOs are not acceptable, Server ('S2') discards the 1731 message. Otherwise, Server ('S2') validates the message according to 1732 the Redirect message validation rules in Section 8.1 of [RFC4861]. 1733 Server ('S2') also verifies that Client ('C2') is authorized to use 1734 the ACPs encoded in the RIOs of the Redirect message. If validation 1735 fails, Server ('S2') discards the Redirect; otherwise, it copies the 1736 correct UDP Port number and IP Address for Client ('C2')'s underlying 1737 link into the first TLLAO in case the addresses have been subject to 1738 NAT. 1740 Server ('S2') then examines the network-layer destination address of 1741 the Redirect to determine the next hop toward Client ('C1') by 1742 searching for the AERO address in the neighbor cache. Since Client 1743 ('C1') is not a neighbor, Server ('S2') re-encapsulates the Redirect 1744 and relays it via Relay ('R1') by changing the link-layer source 1745 address of the message to 'L2(S2)' and changing the link-layer 1746 destination address to 'L2(R1)'. Server ('S2') finally forwards the 1747 re-encapsulated message to Relay ('R1') without decrementing the 1748 network-layer TTL/Hop Limit field. 1750 When Relay ('R1') receives the Redirect message from Server ('S2') it 1751 determines that Server ('S1') is the next hop toward Client ('C1') by 1752 consulting its forwarding table. Relay ('R1') then re-encapsulates 1753 the Redirect while changing the link-layer source address to 'L2(R1)' 1754 and changing the link-layer destination address to 'L2(S1)'. Relay 1755 ('R1') then relays the Redirect via Server ('S1'). 1757 When Server ('S1') receives the Redirect message from Relay ('R1') it 1758 determines that Client ('C1') is a neighbor by consulting its 1759 neighbor cache. Server ('S1') then re-encapsulates the Redirect 1760 while changing the link-layer source address to 'L2(S1)' and changing 1761 the link-layer destination address to 'L2(C1)'. Server ('S1') then 1762 forwards the message to Client ('C1'). 1764 3.15.8. Processing Redirects 1766 When Client ('C1') receives the Redirect message, it accepts the 1767 message only if it has a link-layer source address of one of its 1768 Servers (e.g., 'L2(S1)'). Next, Client ('C1') validates the message 1769 according to the Redirect message validation rules in Section 8.1 of 1770 [RFC4861], except that it accepts the message even though the 1771 network-layer source address is not that of it's current first-hop 1772 router. Following validation, Client ('C1') then processes the 1773 message as follows. 1775 In the reference operational scenario, when Client ('C1') receives 1776 the Redirect message, it either creates or updates a dynamic neighbor 1777 cache entry that stores the Target Address of the message as the 1778 network-layer address of Client ('C2'), stores the link-layer 1779 addresses found in the TLLAOs as the link-layer addresses of Client 1780 ('C2') and stores the ACPs encoded in the RIOs of the Redirect as the 1781 ACPs for Client ('C2').. Client ('C1') then sets ForwardTime for the 1782 neighbor cache entry to FORWARD_TIME. 1784 Now, Client ('C1') has a neighbor cache entry with a valid 1785 ForwardTime value, while Client ('C2') has a neighbor cache entry 1786 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 1787 ordinary network-layer data packets directly to Client ('C2') without 1788 involving any intermediate nodes, and Client ('C2') can verify that 1789 the packets came from an acceptable source. (In order for Client 1790 ('C2') to forward packets to Client ('C1'), a corresponding 1791 Predirect/Redirect message exchange is required in the reverse 1792 direction; hence, the mechanism is asymmetric.) 1794 3.15.9. Server-to-Client and Client-to-Server Redirection 1796 In some environments, the Server nearest the target Client may need 1797 to serve as a proxy redirection target, e.g., if direct Client-to- 1798 Client communications are not possible. In that case, when the 1799 source Client sends a Predirect message the target Server prepares a 1800 corresponding Redirect the same as if it were the target Client (see: 1801 Section 3.15.6), except that it writes its own link-layer address in 1802 the TLLAO option. The Server must then maintain a dynamic neighbor 1803 cache entry for the redirected source Client. 1805 Similarly, when the source Client must send all packets via its own 1806 Server and cannot act on a route optimization request, the source 1807 Server can send a Predirect message toward the target Client. The 1808 target Client then prepares a corresponding Redirect message the same 1809 as for Client-to-Client route optimization and sends the Redirect 1810 message back to the source Server. 1812 Thereafter, if a Client moves to a new Server, the old Server sends 1813 ICMP "Destination Unreachable" messages subject to rate limiting in 1814 response to data packets received from a correspondent node to report 1815 that the route optimization ForwardTime should be set to 0. The 1816 correspondent Client (or Server) then allows future packets destined 1817 to the departed Client to again flow through its own Server (or 1818 Relay). 1820 In any case, a Server MUST NOT send a BGP update to its Relays for 1821 Clients discovered through dynamic route optimization redirection. 1822 BGP updates are only to be sent for the Server's working set of 1823 statically-associated Clients. 1825 3.15.10. Server-to-Server Redirection 1827 If neither the source nor target Clients are capable of sending 1828 packets other than via their own Servers, a Server-to-Server route 1829 optimization can still be employed. In that case, the source 1830 Client's Server can send a Predirect message via a Relay to the AERO 1831 address of the target Client, and the Relay will forward the message 1832 to the target Client's Server. The target Server prepares the 1833 Redirect message the same as if it were the target Client, except 1834 that it writes its own link-layer address in the TLLAO option then 1835 sends a Redirect message back to the source Server via the Relay. 1836 Both Servers must then maintain a dynamic neighbor cache entry for 1837 the redirected Clients. 1839 Thereafter, if a Client moves to a new Server, the old Server sends 1840 ICMP "Destination Unreachable" messages subject to rate limiting in 1841 response to data packets forwarded by the correspondent Server to 1842 report that the route optimization ForwardTime should be set to 0. 1843 The correspondent Server then allows future packets destined to the 1844 departed Client to again flow through its own Relay. 1846 In any case, a Server MUST NOT send a BGP update to its Relays for 1847 Clients discovered through dynamic route optimization redirection. 1848 BGP updates are only to be sent for the Server's working set of 1849 statically-associated Clients.. 1851 3.16. Neighbor Unreachability Detection (NUD) 1853 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1854 unicast NS messages with SLLAOs to elicit solicited NA messages from 1855 neighbors the same as described in [RFC4861]. NUD is performed 1856 either reactively in response to persistent L2 errors (see 1857 Section 3.13) or proactively to test existing neighbor cache entries 1858 and/or update link-layer information. 1860 When an AERO node sends an NS/NA message, it MUST use one of its 1861 link-local addresses as the IPv6 source address and a link-local 1862 address of the neighbor as the IPv6 destination address. When an 1863 AERO node receives an NS message or a solicited NA message, it 1864 accepts the message if it has a neighbor cache entry for the 1865 neighbor; otherwise, it ignores the message. 1867 When a source Client is redirected to a target Client it SHOULD 1868 proactively test the direct path by sending an initial NS message to 1869 elicit a solicited NA response. While testing the path, the source 1870 Client can optionally continue sending packets via the Server, 1871 maintain a small queue of packets until target reachability is 1872 confirmed, or (optimistically) allow packets to flow directly to the 1873 target. The source Client SHOULD thereafter periodically test the 1874 direct path to the target Client (see Section 7.3 of [RFC4861]) in 1875 order to keep dynamic neighbor cache entries alive. If the source 1876 Client is unable to elicit a solicited NA response from the target 1877 Client after MaxRetry attempts, it SHOULD set ForwardTime to 0 and 1878 resume sending packets via one of its Servers. Otherwise, the source 1879 Client considers the path usable and SHOULD thereafter process any 1880 link-layer errors as a hint that the direct path to the target Client 1881 has either failed or has become intermittent. 1883 When ForwardTime for a dynamic neighbor cache entry expires, the 1884 source Client resumes sending any subsequent packets via a Server and 1885 may (eventually) attempt to re-initiate the AERO redirection process. 1886 When AcceptTime for a dynamic neighbor cache entry expires, the 1887 target Client discards any subsequent packets received directly from 1888 the source Client. When both ForwardTime and AcceptTime for a 1889 dynamic neighbor cache entry expire, the Client deletes the neighbor 1890 cache entry. 1892 3.17. Mobility Management 1894 3.17.1. Announcing Link-Layer Address Changes 1896 When a Client needs to change its link-layer addresses, e.g., due to 1897 a mobility event, it sends unsolicited NAs to its neighbors using the 1898 new link-layer address as the source address and with TLLAOs that 1899 include the updated Client link-layer information. 1901 The Client MAY send up to MaxRetry unsolicited NA messages in 1902 parallel with sending actual data packets in case one or more NAs are 1903 lost. If all NAs are lost, the Client will eventually invoke NUD by 1904 sending NS messages that include SLLAOs. 1906 3.17.2. Bringing New Links Into Service 1908 When a Client needs to bring new underlying interfaces into service 1909 (e.g., when it activates a new data link), it sends unsolicited NAs 1910 to its neighbors using the new link-layer address as the source 1911 address and with TLLAOs that include the new Client link-layer 1912 information. 1914 3.17.3. Removing Existing Links from Service 1916 When a Client needs to remove existing underlying interfaces from 1917 service (e.g., when it de-activates an existing data link), it sends 1918 unsolicited NAs to its neighbors with TLLAOs that include P(i) values 1919 set to "disabled". 1921 If the Client needs to send the unsolicited NAs over a link other 1922 than the one being removed from service, it MUST include a TLLAO for 1923 the sending link as the first TLLAO and include the TLLAO for the 1924 link being removed from service as an additional TLLAO. 1926 3.17.4. Implicit Mobility Management 1928 AERO interface neighbors MAY include a configuration knob that allows 1929 them to perform implicit mobility management in which no IPv6 ND 1930 messaging is used. In that case, the Client only transmits packets 1931 over a single interface at a time, and the neighbor always observes 1932 packets arriving from the Client from the same link-layer source 1933 address. 1935 If the Client's underlying interface address changes (either due to a 1936 readdressing of the original interface or switching to a new 1937 interface) the neighbor immediately updates the neighbor cache entry 1938 for the Client and begins accepting and sending packets to the 1939 Client's new link-layer address. This implicit mobility method 1940 applies to use cases such as cellphones with both WiFi and Cellular 1941 interfaces where only one of the interfaces is active at a given 1942 time, and the Client automatically switches over to the backup 1943 interface if the primary interface fails. 1945 3.17.5. Moving to a New Server 1947 When a Client associates with a new Server, it performs the Client 1948 procedures specified in Section 3.14.2. 1950 When a Client disassociates with an existing Server, it sends a 1951 DHCPv6 Release message via a new Server with its base AERO address as 1952 the network-layer source address and the unicast link-local address 1953 of the old Server as the network-layer destination address. The new 1954 Server then encapsulates the Release message in a DHCPv6 Relay- 1955 Forward message header, writes the Client's source address in the 1956 'peer-address' field, and writes its own link-local address in the IP 1957 source address (i.e., the new Server acts as a DHCPv6 relay agent). 1958 The new Server then forwards the message to a Relay, which forwards 1959 the message to the old Server based on the network-layer destination 1960 address. 1962 When the old Server receives the Release, it first authenticates the 1963 message then releases the DHCPv6 PDs and deletes the Client's ACP 1964 routes. The old Server then deletes the Client's neighbor cache 1965 entry so that any in-flight packets will be forwarded via a Relay to 1966 the new Server, which will forward them to the Client. The old 1967 Server finally returns a DHCPv6 Relay-Reply message via an AERO Relay 1968 to the new Server, which will decapsulate the DHCPv6 Reply message 1969 and forward it to the Client. 1971 When the new Server forwards the Reply message, the Client can delete 1972 both the default route and the neighbor cache entry for the old 1973 Server. (Note that since Release/Reply messages may be lost in the 1974 network the Client SHOULD retry until it gets a Reply indicating that 1975 the Release was successful. If the Client does not receive a Reply 1976 after MaxRetry attempts, the old Server may have failed and the 1977 Client should discontinue its Release attempts.) 1979 Note that this DHCPv6 relay-chaining approach is necessary to avoid 1980 failures, e.g., due to temporary routing fluctuations. In 1981 particular, the Client should always be able to forward messages via 1982 its new Server but may not always be able to send messages directly 1983 to an old Server. But, the new Server and Old Server should always 1984 be able to exchange messages with one another. 1986 Finally, Clients SHOULD NOT move rapidly between Servers in order to 1987 avoid causing excessive oscillations in the AERO routing system. 1988 Such oscillations could result in intermittent reachability for the 1989 Client itself, while causing little harm to the network. Examples of 1990 when a Client might wish to change to a different Server include a 1991 Server that has gone unreachable, topological movements of 1992 significant distance, etc. 1994 3.17.6. Packet Queueing for Mobility 1996 AERO Clients and Servers should maintain a small queue of packets 1997 they have recently sent to an AERO neighbor, e.g., a 1 second window. 1998 If the AERO neighbor moves, the AERO node MAY retransmit the queued 1999 packets to ensure that they are delivered to the AERO neighbor's new 2000 location. 2002 Note that this may have performance implications for asymmetric 2003 paths. For example, if the AERO neighbor moves from a 50Mbps link to 2004 a 128Kbps link, retransmitting a 1 second window could cause 2005 significant congestion. However, any retransmission bursts will 2006 subside after the 1 second window. 2008 3.18. Multicast Considerations 2010 When the underlying network does not support multicast, AERO Clients 2011 map link-scoped multicast addresses to the link-layer address of a 2012 Server, which acts as a multicast forwarding agent. The AERO Client 2013 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2014 applications per [RFC4605] while using the link-layer address of the 2015 Server as the link-layer address for all multicast packets. 2017 When the underlying network supports multicast, AERO nodes use the 2018 multicast address mapping specification found in [RFC2529] for IPv4 2019 underlying networks and use a TBD site-scoped multicast mapping for 2020 IPv6 underlying networks. In that case, border routers must ensure 2021 that the encapsulated site-scoped multicast packets do not leak 2022 outside of the site spanned by the AERO link. 2024 4. AERO Variations 2026 AERO can be used in many different variations based on the specific 2027 use case. The following sections discuss variations that adhere to 2028 the AERO principles while allowing selective application of AERO 2029 components. 2031 4.1. Operation on Host-Only IPv6 AERO Links 2033 IPv6 AERO links typically have ASPs that cover many candidate ACPs of 2034 length /64 or shorter. However, in some cases it may be desirable to 2035 use AERO over links that have only a /64 ASP. This can be 2036 accommodated by treating all Clients on the AERO link as simple hosts 2037 that receive /128 prefix delegations. 2039 In that case, each Client configures an administratively-provisioned 2040 link-local address instead of an AERO address, i.e., the same as for 2041 Servers and Relays. The Client discovers its link-local address by 2042 including an IA_NA option in its DHCPv6 Solicit message to the 2043 Server. The Server responds by returning the Client's 2044 administratively-provisioned link-local address in the IA_NA option 2045 plus any IPv6 addresses for the Client in IA_PD options with prefix 2046 length /128. 2048 For example, if the ASP for the host-only IPv6 AERO link is 2049 2001:db8:1000:2000::/64, each Client will receive one or more /128 2050 IPv6 prefix delegations such as 2001:db8:1000:2000::1/128, 2051 2001:db8:1000:2000::2/128, etc. The Client then assigns the /128s to 2052 the AERO interface as IPv6 addresses, and the Client's applications 2053 treat the AERO interface as an ordinary host interface. 2055 In this arrangement, the Client conducts route optimization in the 2056 same sense as discussed in Section 3.15, except that the Predirect 2057 message network-layer source address is the Client's 2058 administratively-assigned link-local address and the network-layer 2059 destination address is the same as the destination address of the 2060 packet that triggered the redirection. All other aspects of AERO 2061 operation are the same as described in earlier sections. 2063 This has applicability for nodes that act as a Client on an 2064 "upstream" AERO link, but also act as a Server on "downstream" AERO 2065 links. More specifically, if the node acts as a Client to receive a 2066 /64 prefix from the upstream AERO link it can then act as a Server to 2067 provision /128s to Clients on downstream AERO links. 2069 Note that, due to the nature of the AERO address format, valid IPv6 2070 ACP lengths are either /64 or shorter, or exactly /128 (i.e., prefix 2071 lengths between /65 and /127 cannot be accommodated). 2073 4.2. Operation on AERO Links Without DHCPv6 Services 2075 When Servers on the AERO link do not provide DHCPv6 services, 2076 operation can still be accommodated through administrative 2077 configuration of ACPs on AERO Clients. In that case, administrative 2078 configurations of AERO interface neighbor cache entries on both the 2079 Server and Client are also necessary. However, this may interfere 2080 with the ability for Clients to dynamically change to new Servers, 2081 and can expose the AERO link to misconfigurations unless the 2082 administrative configurations are carefully coordinated. 2084 4.3. Operation on Server-less AERO Links 2086 In some AERO link scenarios, there may be no Servers on the link and/ 2087 or no need for Clients to use a Server as an intermediary trust 2088 anchor. In that case, each Client acts as a Server unto itself to 2089 establish neighbor cache entries by performing direct Client-to- 2090 Client IPv6 ND message exchanges, and some other form of trust basis 2091 must be applied so that each Client can verify that the prospective 2092 neighbor is authorized to use its claimed ACP. 2094 When there is no Server on the link, Clients must arrange to receive 2095 ACPs and publish them via a secure alternate PD authority through 2096 some means outside the scope of this document. 2098 4.4. Operation on Client-less AERO Links 2100 In some environments, the AERO service may be useful for mobile nodes 2101 that do not implement the AERO Client function and do not perform 2102 encapsulation. For example, if the mobile node has a way of 2103 injecting its ACP into the access subnetwork routing system an AERO 2104 Server connected to the same access network can accept the ACP prefix 2105 injection as an indication that a new mobile node has come onto the 2106 subnetwork. The Server can then inject the ACP into the BGP routing 2107 system the same as if an AERO Client/Server DHCPv6 PD exchange had 2108 occurred. If the mobile node subsequently withdraws the ACP from the 2109 access network routing system, the Server can then withdraw the ACP 2110 from the BGP routing system. 2112 In this arrangement, AERO Servers and Relays are used in exactly the 2113 same ways as for environments where DHCPv6 Client/Server exchanges 2114 are supported. However, the access subnetwork routing systems must 2115 be capable of accommodating rapid ACP injections and withdrawals from 2116 mobile nodes with the understanding that the information must be 2117 propagated to all routers in the system. Operational experience has 2118 shown that this kind of routing system "churn" can lead to overall 2119 instability and routing system inconsistency. 2121 4.5. Manually-Configured AERO Tunnels 2123 In addition to the dynamic neighbor discovery procedures for AERO 2124 link neighbors described above, AERO encapsulation can be applied to 2125 manually-configured tunnels. In that case, the tunnel endpoints use 2126 an administratively-provisioned link-local address and exchange NS/NA 2127 messages the same as for dynamically-established tunnels. 2129 4.6. Encapsulation Avoidance on Relay-Server Dedicated Links 2131 In some environments, AERO Servers and Relays may be connected by 2132 dedicated point-to-point links, e.g., high speed fiberoptic leased 2133 lines. In that case, the Servers and Relays can participate in the 2134 AERO link the same as specified above but can avoid encapsulation 2135 over the dedicated links. In that case, however, the links would be 2136 dedicated for AERO and could not be multiplexed for both AERO and 2137 non-AERO communications. 2139 4.7. Encapsulation Protocol Version Considerations 2141 A source Client may connect only to an IPvX underlying network, while 2142 the target Client connects only to an IPvY underlying network. In 2143 that case, the target and source Clients have no means for reaching 2144 each other directly (since they connect to underlying networks of 2145 different IP protocol versions) and so must ignore any redirection 2146 messages and continue to send packets via their Servers. 2148 5. Implementation Status 2150 Production user-level and kernel-level AERO implementations have been 2151 developed and are undergoing internal testing within Boeing. 2153 An initial public release of the AERO proof-of-concept source code 2154 was announced on the intarea mailing list on August 21, 2015, and a 2155 pointer to the code is available in the list archives. 2157 6. IANA Considerations 2159 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2160 AERO in the "enterprise-numbers" registry. 2162 The IANA has assigned the UDP port number "8060" for an earlier 2163 experimental version of AERO [RFC6706]. This document obsoletes 2164 [RFC6706] and claims the UDP port number "8060" for all future use. 2166 No further IANA actions are required. 2168 7. Security Considerations 2170 AERO link security considerations are the same as for standard IPv6 2171 Neighbor Discovery [RFC4861] except that AERO improves on some 2172 aspects. In particular, AERO uses a trust basis between Clients and 2173 Servers, where the Clients only engage in the AERO mechanism when it 2174 is facilitated by a trust anchor. 2176 Redirect, Predirect and unsolicited NA messages SHOULD include a 2177 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2178 can use to verify the message time of origin. Predirect, NS and RS 2179 messages SHOULD include a Nonce option (see Section 5.3 of [RFC3971]) 2180 that recipients echo back in corresponding responses. 2182 AERO links must be protected against link-layer address spoofing 2183 attacks in which an attacker on the link pretends to be a trusted 2184 neighbor. Links that provide link-layer securing mechanisms (e.g., 2185 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2186 enterprise network wired LANs) provide a first line of defense, 2187 however AERO nodes SHOULD also use DHCPv6 securing services (e.g., 2188 Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6], etc.) for Client 2189 authentication and network admission control. Following 2190 authenticated DHCPv6 PD procedures, AERO nodes MUST ensure that the 2191 source of data packets corresponds to the node to which the prefixes 2192 were delegated. 2194 AERO Clients MUST ensure that their connectivity is not used by 2195 unauthorized nodes on their EUNs to gain access to a protected 2196 network, i.e., AERO Clients that act as routers MUST NOT provide 2197 routing services for unauthorized nodes. (This concern is no 2198 different than for ordinary hosts that receive an IP address 2199 delegation but then "share" the address with other nodes via some 2200 form of Internet connection sharing.) 2202 AERO Clients, Servers and Relays on the open Internet are susceptible 2203 to the same attack profiles as for any Internet nodes. For this 2204 reason, IP security SHOULD be used when AERO is employed over 2205 unmanaged/unsecured links using securing mechanisms such as IPsec 2206 [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. In some environments, 2207 however, the use of end-to-end security from Clients to correspondent 2208 nodes (i.e., other Clients and/or Internet nodes) could obviate the 2209 need for IP security between AERO Clients, Servers and Relays. 2211 AERO Servers and Relays present targets for traffic amplification DoS 2212 attacks. This concern is no different than for widely-deployed VPN 2213 security gateways in the Internet, where attackers could send spoofed 2214 packets to the gateways at high data rates. This can be mitigated by 2215 connecting Relays and Servers over dedicated links with no 2216 connections to the Internet and/or when connections to the Internet 2217 are only permitted through well-managed firewalls. 2219 Traffic amplfication DoS attacks can also target an AERO Client's low 2220 data rate links. This is a concern not only for Clients located on 2221 the open Internet but also for Clients in protected enclaves. AERO 2222 Servers can institute rate limits that protect Clients from receiving 2223 packet floods that could DoS low data rate links. 2225 8. Acknowledgements 2227 Discussions both on IETF lists and in private exchanges helped shape 2228 some of the concepts in this work. Individuals who contributed 2229 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, Bob 2230 Braden, Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, 2231 Adrian Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom 2232 Herbert, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy 2233 Malis, Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2234 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. 2235 Members of the IESG also provided valuable input during their review 2236 process that greatly improved the document. Discussions on the v6ops 2237 list in the December 2015 through January 2016 timeframe further 2238 helped clarify AERO multi-addressing capabilities. Special thanks go 2239 to Stewart Bryant, Joel Halpern and Brian Haberman for their 2240 shepherding guidance during the publication of the AERO first 2241 edition. 2243 This work has further been encouraged and supported by Boeing 2244 colleagues including M. Wayne Benson, Dave Bernhardt, Cam Brodie, 2245 Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu Danilov, 2246 Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gene MacLean III, 2247 Rob Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian Skeen, Mike 2248 Slane, Carrie Spiker, Brendan Williams, Julie Wulff, Yueli Yang, and 2249 other members of the BR&T and BIT mobile networking teams. Wayne 2250 Benson is especially acknowledged for his outstanding work in 2251 converting the AERO proof-of-concept implementation into production- 2252 ready code. 2254 Earlier works on NBMA tunneling approaches are found in 2255 [RFC2529][RFC5214][RFC5569]. 2257 Many of the constructs presented in this second edition of AERO are 2258 based on the author's earlier works, including: 2260 o The Internet Routing Overlay Network (IRON) 2261 [RFC6179][I-D.templin-ironbis] 2263 o Virtual Enterprise Traversal (VET) 2264 [RFC5558][I-D.templin-intarea-vet] 2266 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2267 [RFC5320][I-D.templin-intarea-seal] 2269 o AERO, First Edition [RFC6706] 2271 Note that these works cite numerous earlier efforts that are not also 2272 cited here due to space limitations. The authors of those earlier 2273 works are acknowledged for their insights. 2275 This work is aligned with the NASA Safe Autonomous Systems Operation 2276 (SASO) program under NASA contract number NNA16BD84C. 2278 This work is aligned with the FAA Aeronautical Telecommunications 2279 Network - Internet Protocol Services (ATN-IPS) program for the 2280 International Civil Aviation Organization (ICAO). 2282 9. References 2284 9.1. Normative References 2286 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2287 DOI 10.17487/RFC0768, August 1980, 2288 . 2290 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2291 DOI 10.17487/RFC0791, September 1981, 2292 . 2294 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2295 RFC 792, DOI 10.17487/RFC0792, September 1981, 2296 . 2298 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2299 DOI 10.17487/RFC2003, October 1996, 2300 . 2302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2303 Requirement Levels", BCP 14, RFC 2119, 2304 DOI 10.17487/RFC2119, March 1997, 2305 . 2307 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2308 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2309 December 1998, . 2311 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2312 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2313 December 1998, . 2315 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2316 "Definition of the Differentiated Services Field (DS 2317 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2318 DOI 10.17487/RFC2474, December 1998, 2319 . 2321 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2322 C., and M. Carney, "Dynamic Host Configuration Protocol 2323 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2324 2003, . 2326 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2327 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2328 DOI 10.17487/RFC3633, December 2003, 2329 . 2331 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2332 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2333 DOI 10.17487/RFC3971, March 2005, 2334 . 2336 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2337 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2338 November 2005, . 2340 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2341 for IPv6 Hosts and Routers", RFC 4213, 2342 DOI 10.17487/RFC4213, October 2005, 2343 . 2345 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2346 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2347 DOI 10.17487/RFC4861, September 2007, 2348 . 2350 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2351 Address Autoconfiguration", RFC 4862, 2352 DOI 10.17487/RFC4862, September 2007, 2353 . 2355 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2356 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2357 2011, . 2359 9.2. Informative References 2361 [I-D.herbert-gue-fragmentation] 2362 Herbert, T. and F. Templin, "Fragmentation option for 2363 Generic UDP Encapsulation", draft-herbert-gue- 2364 fragmentation-02 (work in progress), October 2015. 2366 [I-D.ietf-dhc-sedhcpv6] 2367 Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. 2368 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-13 (work 2369 in progress), July 2016. 2371 [I-D.ietf-intarea-tunnels] 2372 Touch, J. and W. Townsley, "IP Tunnels in the Internet 2373 Architecture", draft-ietf-intarea-tunnels-03 (work in 2374 progress), July 2016. 2376 [I-D.ietf-nvo3-gue] 2377 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2378 Encapsulation", draft-ietf-nvo3-gue-04 (work in progress), 2379 July 2016. 2381 [I-D.templin-intarea-grefrag] 2382 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2383 templin-intarea-grefrag-04 (work in progress), July 2016. 2385 [I-D.templin-intarea-seal] 2386 Templin, F., "The Subnetwork Encapsulation and Adaptation 2387 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2388 progress), January 2014. 2390 [I-D.templin-intarea-vet] 2391 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2392 templin-intarea-vet-40 (work in progress), May 2013. 2394 [I-D.templin-ironbis] 2395 Templin, F., "The Interior Routing Overlay Network 2396 (IRON)", draft-templin-ironbis-16 (work in progress), 2397 March 2014. 2399 [OVPN] OpenVPN, O., "http://openvpn.net", October 2016. 2401 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 2402 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 2403 . 2405 [RFC1035] Mockapetris, P., "Domain names - implementation and 2406 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2407 November 1987, . 2409 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2410 Communication Layers", STD 3, RFC 1122, 2411 DOI 10.17487/RFC1122, October 1989, 2412 . 2414 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2415 DOI 10.17487/RFC1191, November 1990, 2416 . 2418 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2419 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2420 . 2422 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2423 selection, and registration of an Autonomous System (AS)", 2424 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 2425 . 2427 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2428 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2429 1996, . 2431 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2432 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2433 . 2435 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2436 Domains without Explicit Tunnels", RFC 2529, 2437 DOI 10.17487/RFC2529, March 1999, 2438 . 2440 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2441 RFC 2675, DOI 10.17487/RFC2675, August 1999, 2442 . 2444 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2445 Malis, "A Framework for IP Based Virtual Private 2446 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2447 . 2449 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2450 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2451 DOI 10.17487/RFC2784, March 2000, 2452 . 2454 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2455 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2456 . 2458 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2459 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2460 . 2462 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2463 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2464 . 2466 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2467 of Explicit Congestion Notification (ECN) to IP", 2468 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2469 . 2471 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2472 "DNS Extensions to Support IP Version 6", RFC 3596, 2473 DOI 10.17487/RFC3596, October 2003, 2474 . 2476 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2477 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2478 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2479 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2480 . 2482 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2483 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2484 DOI 10.17487/RFC4271, January 2006, 2485 . 2487 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2488 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2489 2006, . 2491 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2492 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2493 December 2005, . 2495 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2496 Control Message Protocol (ICMPv6) for the Internet 2497 Protocol Version 6 (IPv6) Specification", RFC 4443, 2498 DOI 10.17487/RFC4443, March 2006, 2499 . 2501 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 2502 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2503 2006, . 2505 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2506 Protocol (LDAP): The Protocol", RFC 4511, 2507 DOI 10.17487/RFC4511, June 2006, 2508 . 2510 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2511 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 2512 . 2514 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 2515 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 2516 . 2518 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2519 "Internet Group Management Protocol (IGMP) / Multicast 2520 Listener Discovery (MLD)-Based Multicast Forwarding 2521 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2522 August 2006, . 2524 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2525 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2526 . 2528 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2529 Errors at High Data Rates", RFC 4963, 2530 DOI 10.17487/RFC4963, July 2007, 2531 . 2533 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 2534 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 2535 DOI 10.17487/RFC4994, September 2007, 2536 . 2538 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 2539 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 2540 RFC 5213, DOI 10.17487/RFC5213, August 2008, 2541 . 2543 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2544 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2545 DOI 10.17487/RFC5214, March 2008, 2546 . 2548 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2549 (TLS) Protocol Version 1.2", RFC 5246, 2550 DOI 10.17487/RFC5246, August 2008, 2551 . 2553 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2554 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2555 February 2010, . 2557 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 2558 for the Address Resolution Protocol (ARP)", RFC 5494, 2559 DOI 10.17487/RFC5494, April 2009, 2560 . 2562 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2563 Route Optimization Requirements for Operational Use in 2564 Aeronautics and Space Exploration Mobile Networks", 2565 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2566 . 2568 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2569 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2570 . 2572 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2573 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2574 January 2010, . 2576 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2577 Global Enterprise Recursion (RANGER)", RFC 5720, 2578 DOI 10.17487/RFC5720, February 2010, 2579 . 2581 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 2582 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 2583 . 2585 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 2586 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 2587 DOI 10.17487/RFC5949, September 2010, 2588 . 2590 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2591 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2592 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2593 . 2595 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2596 NAT64: Network Address and Protocol Translation from IPv6 2597 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2598 April 2011, . 2600 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2601 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2602 . 2604 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2605 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 2606 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 2607 . 2609 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2610 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2611 DOI 10.17487/RFC6221, May 2011, 2612 . 2614 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2615 and A. Bierman, Ed., "Network Configuration Protocol 2616 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2617 . 2619 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2620 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2621 2011, . 2623 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2624 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2625 DOI 10.17487/RFC6355, August 2011, 2626 . 2628 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2629 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2630 . 2632 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2633 for Equal Cost Multipath Routing and Link Aggregation in 2634 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2635 . 2637 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2638 RFC 6691, DOI 10.17487/RFC6691, July 2012, 2639 . 2641 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 2642 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 2643 . 2645 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2646 RFC 6864, DOI 10.17487/RFC6864, February 2013, 2647 . 2649 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2650 UDP Checksums for Tunneled Packets", RFC 6935, 2651 DOI 10.17487/RFC6935, April 2013, 2652 . 2654 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2655 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2656 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2657 . 2659 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2660 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 2661 May 2013, . 2663 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2664 with IPv6 Neighbor Discovery", RFC 6980, 2665 DOI 10.17487/RFC6980, August 2013, 2666 . 2668 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2669 Address Selection Policy Using DHCPv6", RFC 7078, 2670 DOI 10.17487/RFC7078, January 2014, 2671 . 2673 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 2674 October 2014. 2676 Appendix A. AERO Alternate Encapsulations 2678 When GUE encapsulation is not needed, AERO can use common 2679 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 2680 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 2681 encapsulation is therefore only differentiated from non-AERO tunnels 2682 through the application of AERO control messaging and not through, 2683 e.g., a well-known UDP port number. 2685 As for GUE encapsulation, alternate AERO encapsulation formats may 2686 require encapsulation layer fragmentation. For simple IP-in-IP 2687 encapsulation, an IPv6 fragment header is inserted directly between 2688 the inner and outer IP headers when needed, i.e., even if the outer 2689 header is IPv4. The IPv6 Fragment Header is identified to the outer 2690 IP layer by its IP protocol number, and the Next Header field in the 2691 IPv6 Fragment Header identifies the inner IP header version. For GRE 2692 encapsulation, a GRE fragment header is inserted within the GRE 2693 header [I-D.templin-intarea-grefrag]. 2695 Figure 6 shows the AERO IP-in-IP encapsulation format before any 2696 fragmentation is applied: 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | Outer IPv4 Header | | Outer IPv6 Header | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | Inner IP Header | | Inner IP Header | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | | | | 2706 ~ ~ ~ ~ 2707 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 2708 ~ ~ ~ ~ 2709 | | | | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 2714 Figure 6: Minimal Encapsulation Format using IP-in-IP 2716 Figure 7 shows the AERO GRE encapsulation format before any 2717 fragmentation is applied: 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Outer IP Header | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | GRE Header | 2723 | (with checksum, key, etc..) | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | GRE Fragment Header (optional)| 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Inner IP Header | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | | 2730 ~ ~ 2731 ~ Inner Packet Body ~ 2732 ~ ~ 2733 | | 2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 Figure 7: Minimal Encapsulation Using GRE 2738 Alternate encapsulation may be preferred in environments where GUE 2739 encapsulation would add unnecessary overhead. For example, certain 2740 low-bandwidth wireless data links may benefit from a reduced 2741 encapsulation overhead. 2743 GUE encapsulation can traverse network paths that are inaccessible to 2744 non-UDP encapsulations, e.g., for crossing Network Address 2745 Translators (NATs). More and more, network middleboxes are also 2746 being configured to discard packets that include anything other than 2747 a well-known IP protocol such as UDP and TCP. It may therefore be 2748 necessary to determine the potential for middlebox filtering before 2749 enabling alternate encapsulation in a given environment. 2751 In addition to IP-in-IP, GRE and GUE, AERO can also use security 2752 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 2753 messaging and route determination occur before security encapsulation 2754 is applied for outgoing packets and after security decapsulation is 2755 applied for incoming packets. 2757 AERO is especially well suited for use with VPN system encapsulations 2758 such as OpenVPN [OVPN]. 2760 Appendix B. When to Insert an Encapsulation Fragment Header 2762 An encapsulation fragment header is inserted when the AERO tunnel 2763 ingress needs to apply fragmentation to accommodate packets that must 2764 be delivered without loss due to a size restriction. Fragmentation 2765 is performed on the inner packet while encapsulating each inner 2766 packet fragment in outer IP and encapsulation layer headers that 2767 differ only in the fragment header fields. 2769 The fragment header can also be inserted in order to include a 2770 coherent Identification value with each packet, e.g., to aid in 2771 Duplicate Packet Detection (DPD). In this way, network nodes can 2772 cache the Identification values of recently-seen packets and use the 2773 cached values to determine whether a newly-arrived packet is in fact 2774 a duplicate. The Identification value within each packet could 2775 further provide a rough indicator of packet reordering, e.g., in 2776 cases when the tunnel egress wishes to discard packets that are 2777 grossly out of order. 2779 In some use cases, there may be operational assurance that no 2780 fragmentation of any kind will be necessary, or that only occasional 2781 large control messages will require fragmentation. In that case, the 2782 encapsulation fragment header can be omitted and ordinary 2783 fragmentation of the outer IP protocol version can be applied when 2784 necessary. 2786 Appendix C. Autoconfiguration for Constrained Platforms 2788 On some platforms (e.g., popular cell phone operating systems), the 2789 act of assigning a default IPv6 route and/or assigning an address to 2790 an interface may not be permitted from a user application due to 2791 security policy. Typically, those platforms include a TUN/TAP 2792 interface [TUNTAP] that acts as a point-to-point conduit between user 2793 applications and the AERO interface. In that case, the Client can 2794 instead generate a "synthesized RA" message. The message conforms to 2795 [RFC4861] and is prepared as follows: 2797 o the IPv6 source address is the Client's AERO address 2799 o the IPv6 destination address is all-nodes multicast 2801 o the Router Lifetime is set to a time that is no longer than the 2802 ACP DHCPv6 lifetime 2804 o the message does not include a Source Link Layer Address Option 2805 (SLLAO) 2807 o the message includes a Prefix Information Option (PIO) with a /64 2808 prefix taken from the ACP as the prefix for autoconfiguration 2810 The Client then sends the synthesized RA message via the TUN/TAP 2811 interface, where the operating system kernel will interpret it as 2812 though it were generated by an actual router. The operating system 2813 will then install a default route and use StateLess Address 2814 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 2815 interface. Methods for similarly installing an IPv4 default route 2816 and IPv4 address on the TUN/TAP interface are based on synthesized 2817 DHCPv4 messages [RFC2131]. 2819 Appendix D. Extending AERO Links Through Security Gateways 2821 When an enterprise mobile node moves from a campus LAN connection to 2822 a public Internet link, it must re-enter the enterprise via a 2823 security gateway that has both a physical interface connection to the 2824 Internet and a physical interface connection to the enterprise 2825 internetwork. This most often entails the establishment of a Virtual 2826 Private Network (VPN) link over the public Internet from the mobile 2827 node to the security gateway. During this process, the mobile node 2828 supplies the security gateway with its public Internet address as the 2829 link-layer address for the VPN. The mobile node then acts as an AERO 2830 Client to negotiate with the security gateway to obtain its ACP. 2832 In order to satisfy this need, the security gateway also operates as 2833 an AERO Server with support for AERO Client proxying. In particular, 2834 when a mobile node (i.e., the Client) connects via the security 2835 gateway (i.e., the Server), the Server provides the Client with an 2836 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2837 enterprise campus access link. The Server then replaces the Client's 2838 link-layer source address with the Server's enterprise-facing link- 2839 layer address in all AERO messages the Client sends toward neighbors 2840 on the AERO link. The AERO messages are then delivered to other 2841 nodes on the AERO link as if they were originated by the security 2842 gateway instead of by the AERO Client. In the reverse direction, the 2843 AERO messages sourced by nodes within the enterprise network can be 2844 forwarded to the security gateway, which then replaces the link-layer 2845 destination address with the Client's link-layer address and replaces 2846 the link-layer source address with its own (Internet-facing) link- 2847 layer address. 2849 After receiving the ACP, the Client can send IP packets that use an 2850 address taken from the ACP as the network layer source address, the 2851 Client's link-layer address as the link-layer source address, and the 2852 Server's Internet-facing link-layer address as the link-layer 2853 destination address. The Server will then rewrite the link-layer 2854 source address with the Server's own enterprise-facing link-layer 2855 address and rewrite the link-layer destination address with the 2856 target AERO node's link-layer address, and the packets will enter the 2857 enterprise network as though they were sourced from a node located 2858 within the enterprise. In the reverse direction, when a packet 2859 sourced by a node within the enterprise network uses a destination 2860 address from the Client's ACP, the packet will be delivered to the 2861 security gateway which then rewrites the link-layer destination 2862 address to the Client's link-layer address and rewrites the link- 2863 layer source address to the Server's Internet-facing link-layer 2864 address. The Server then delivers the packet across the VPN to the 2865 AERO Client. In this way, the AERO virtual link is essentially 2866 extended *through* the security gateway to the point at which the VPN 2867 link and AERO link are effectively grafted together by the link-layer 2868 address rewriting performed by the security gateway. All AERO 2869 messaging services (including route optimization and mobility 2870 signaling) are therefore extended to the Client. 2872 In order to support this virtual link grafting, the security gateway 2873 (acting as an AERO Server) must keep static neighbor cache entries 2874 for all of its associated Clients located on the public Internet. 2875 The neighbor cache entry is keyed by the AERO Client's AERO address 2876 the same as if the Client were located within the enterprise 2877 internetwork. The neighbor cache is then managed in all ways as 2878 though the Client were an ordinary AERO Client. This includes the 2879 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2880 Unreachability Detection. 2882 Note that the main difference between a security gateway acting as an 2883 AERO Server and an enterprise-internal AERO Server is that the 2884 security gateway has at least one enterprise-internal physical 2885 interface and at least one public Internet physical interface. 2886 Conversely, the enterprise-internal AERO Server has only enterprise- 2887 internal physical interfaces. For this reason security gateway 2888 proxying is needed to ensure that the public Internet link-layer 2889 addressing space is kept separate from the enterprise-internal link- 2890 layer addressing space. This is afforded through a natural extension 2891 of the security association caching already performed for each VPN 2892 client by the security gateway. 2894 Author's Address 2896 Fred L. Templin (editor) 2897 Boeing Research & Technology 2898 P.O. Box 3707 2899 Seattle, WA 98124 2900 USA 2902 Email: fltemplin@acm.org