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