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