idnits 2.17.1 draft-templin-aerolink-71.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 (September 07, 2016) is 2781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.taylor-v6ops-fragdrop' is mentioned on line 1016, but not defined == Unused Reference: 'RFC0768' is defined on line 2657, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 2722, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2766, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 2787, but no explicit reference was found in the text == Unused Reference: 'RFC2675' is defined on line 2805, but no explicit reference was found in the text == Unused Reference: 'RFC4459' is defined on line 2866, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 2889, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 2898, but no explicit reference was found in the text == Unused Reference: 'RFC5494' is defined on line 2922, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 2941, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 2960, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 2969, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 2979, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 2988, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 3002, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 3014, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 3019, but no explicit reference was found in the text == Unused Reference: 'RFC6939' is defined on line 3024, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 3028, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 3033, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-13 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-03 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-04 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 26 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, September 07, 2016 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: March 11, 2017 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-71.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 known as the AERO address that supports 21 operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 22 ND to IP forwarding. Admission control, address/prefix provisioning 23 and mobility are supported by the Dynamic Host Configuration Protocol 24 for IPv6 (DHCPv6), and route optimization is 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 March 11, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 6 68 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 6 69 3.2. AERO Link Node Types . . . . . . . . . . . . . . . . . . 8 70 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 9 71 3.4. AERO Interface Characteristics . . . . . . . . . . . . . 10 72 3.5. AERO Link Registration . . . . . . . . . . . . . . . . . 12 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 12 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 12 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 13 76 3.6.3. AERO Client Behavior . . . . . . . . . . . . . . . . 13 77 3.6.4. AERO Forwarding Agent Behavior . . . . . . . . . . . 13 78 3.7. AERO Routing System . . . . . . . . . . . . . . . . . . . 13 79 3.8. AERO Interface Neighbor Cache Maintenace . . . . . . . . 15 80 3.9. AERO Interface Sending Algorithm . . . . . . . . . . . . 17 81 3.10. AERO Interface Encapsulation and Re-encapsulation . . . . 19 82 3.11. AERO Interface Decapsulation . . . . . . . . . . . . . . 20 83 3.12. AERO Interface Data Origin Authentication . . . . . . . . 20 84 3.13. AERO Interface Packet Size Issues . . . . . . . . . . . . 20 85 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 22 86 3.15. AERO Router Discovery, Prefix Delegation and Address 87 Configuration . . . . . . . . . . . . . . . . . . . . . . 25 88 3.15.1. AERO DHCPv6 Service Model . . . . . . . . . . . . . 25 89 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 26 90 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 29 91 3.16. AERO Forwarding Agent Behavior . . . . . . . . . . . . . 32 92 3.17. AERO Link Route Optimization . . . . . . . . . . . . . . 32 93 3.17.1. Reference Operational Scenario . . . . . . . . . . . 33 94 3.17.2. Concept of Operations . . . . . . . . . . . . . . . 34 95 3.17.3. Message Format . . . . . . . . . . . . . . . . . . . 35 96 3.17.4. Sending Predirects . . . . . . . . . . . . . . . . . 35 97 3.17.5. Re-encapsulating and Relaying Predirects . . . . . . 37 98 3.17.6. Processing Predirects and Sending Redirects . . . . 37 99 3.17.7. Re-encapsulating and Relaying Redirects . . . . . . 39 100 3.17.8. Processing Redirects . . . . . . . . . . . . . . . . 40 101 3.17.9. Server-Oriented Redirection . . . . . . . . . . . . 40 102 3.17.10. Route Optimization Policy . . . . . . . . . . . . . 41 103 3.17.11. Route Optimization and Multiple ACPs . . . . . . . . 41 104 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 41 105 3.19. Mobility Management . . . . . . . . . . . . . . . . . . . 42 106 3.19.1. Announcing Link-Layer Address Changes . . . . . . . 42 107 3.19.2. Bringing New Links Into Service . . . . . . . . . . 42 108 3.19.3. Removing Existing Links from Service . . . . . . . . 43 109 3.19.4. Implicit Mobility Management . . . . . . . . . . . . 43 110 3.19.5. Moving to a New Server . . . . . . . . . . . . . . . 43 111 3.19.6. Packet Queueing for Mobility . . . . . . . . . . . . 44 112 3.20. Proxy AERO . . . . . . . . . . . . . . . . . . . . . . . 44 113 3.21. Extending AERO Links Through Security Gateways . . . . . 47 114 3.22. Extending IPv6 AERO Links to the Internet . . . . . . . . 49 115 3.23. Operation on AERO Links Without DHCPv6 Services . . . . . 52 116 3.24. Operation on Server-less AERO Links . . . . . . . . . . . 52 117 3.25. AERO Operation without DHCPv6 Client/Server Exchanges . . 53 118 3.26. Manually-Configured AERO Tunnels . . . . . . . . . . . . 53 119 3.27. Encapsulation Avoidance on Relay-Server Dedicated Links . 53 120 3.28. Encapsulation Protocol Version Considerations . . . . . . 54 121 3.29. Multicast Considerations . . . . . . . . . . . . . . . . 54 122 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 54 123 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 124 6. Security Considerations . . . . . . . . . . . . . . . . . . . 55 125 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 126 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 127 8.1. Normative References . . . . . . . . . . . . . . . . . . 57 128 8.2. Informative References . . . . . . . . . . . . . . . . . 58 129 Appendix A. AERO Alternate Encapsulations . . . . . . . . . . . 65 130 Appendix B. When to Insert an Encapsulation Fragment Header . . 66 131 Appendix C. Autoconfiguration for Constrained Platforms . . . . 67 132 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 68 134 1. Introduction 136 This document specifies the operation of IP over tunnel virtual links 137 using Asymmetric Extended Route Optimization (AERO). The AERO link 138 can be used for tunneling to neighboring nodes over either IPv6 or 139 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 140 equivalent links for tunneling. Nodes attached to AERO links can 141 exchange packets via trusted intermediate routers that provide 142 forwarding services to reach off-link destinations and redirection 143 services for route optimization [RFC5522]. 145 AERO provides an IPv6 link-local address format known as the AERO 146 address that supports operation of the IPv6 Neighbor Discovery (ND) 147 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 148 control, address/prefix provisioning and mobility are supported by 149 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], 150 and route optimization is naturally supported through dynamic 151 neighbor cache updates. Although DHCPv6 and IPv6 ND messaging are 152 used in the control plane, both IPv4 and IPv6 can be used in the data 153 plane. 155 AERO is applicable to a wide variety of use cases. For example, it 156 can be used to coordinate the Virtual Private Network (VPN) links of 157 mobile devices (e.g., cellphones, tablets, laptop computers, etc.) 158 that connect into a home enterprise network via public access 159 networks. AERO can also be applied to aviation applications for both 160 manned and unmanned aircraft where the aircraft is treated as a 161 mobile host or router that can connect an Internet of Things (IoT). 162 Numerous other use cases are also in scope. The remainder of this 163 document presents the AERO specification. 165 2. Terminology 167 The terminology in the normative references applies; the following 168 terms are defined within the scope of this document: 170 AERO link 171 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 172 configured over a node's attached IPv6 and/or IPv4 networks. All 173 nodes on the AERO link appear as single-hop neighbors from the 174 perspective of the virtual overlay even though they may be 175 separated by many underlying network hops. AERO can also operate 176 over native multiple access link types (e.g., Ethernet, WiFi etc.) 177 when a tunnel virtual overlay is not needed. 179 AERO interface 180 a node's attachment to an AERO link. Since the addresses assigned 181 to an AERO interface are obtained from the unique prefix 182 delegations it receives, AERO interfaces do not require Duplicate 183 Address Detection (DAD) and therefore set the administrative 184 variable DupAddrDetectTransmits to zero [RFC4862]. 186 AERO address 187 an IPv6 link-local address constructed as specified in Section 3.3 188 and assigned to a Client's AERO interface. 190 AERO node 191 a node that is connected to an AERO link and that participates in 192 IPv6 ND and DHCPv6 messaging over the link. 194 AERO Client ("Client") 195 a node that issues DHCPv6 messages to receive IP Prefix 196 Delegations (PDs) from one or more AERO Servers. Following PD, 197 the Client assigns an AERO address to the AERO interface for use 198 in DHCPv6 and IPv6 ND exchanges with other AERO nodes. 200 AERO Server ("Server") 201 a node that configures an AERO interface to provide default 202 forwarding and DHCPv6 services for AERO Clients. The Server 203 assigns an administratively provisioned IPv6 link-local unicast 204 address to support the operation of DHCPv6 and the IPv6 ND 205 protocol. An AERO Server can also act as an AERO Relay. 207 AERO Relay ("Relay") 208 a node that configures an AERO interface to relay IP packets 209 between nodes on the same AERO link and/or forward IP packets 210 between the AERO link and the native Internetwork. The Relay 211 assigns an administratively provisioned IPv6 link-local unicast 212 address to the AERO interface the same as for a Server. An AERO 213 Relay can also act as an AERO Server. 215 AERO Forwarding Agent ("Forwarding Agent") 216 a node that performs data plane forwarding services as a companion 217 to an AERO Server. 219 ingress tunnel endpoint (ITE) 220 an AERO interface endpoint that injects tunneled packets into an 221 AERO link. 223 egress tunnel endpoint (ETE) 224 an AERO interface endpoint that receives tunneled packets from an 225 AERO link. 227 underlying network 228 a connected IPv6 or IPv4 network routing region over which the 229 tunnel virtual overlay is configured. 231 underlying interface 232 an AERO node's interface point of attachment to an underlying 233 network. 235 link-layer address 236 an IP address assigned to an AERO node's underlying interface. 237 When UDP encapsulation is used, the UDP port number is also 238 considered as part of the link-layer address; otherwise, UDP port 239 number is set to the constant value '0'. Link-layer addresses are 240 used as the encapsulation header source and destination addresses. 242 network layer address 243 the source or destination address of the encapsulated IP packet. 245 end user network (EUN) 246 an internal virtual or external edge IP network that an AERO 247 Client connects to the rest of the network via the AERO interface. 249 AERO Service Prefix (ASP) 250 an IP prefix associated with the AERO link and from which more- 251 specific AERO Client Prefixes (ACPs) are derived. 253 AERO Client Prefix (ACP) 254 an IP prefix derived from an ASP and delegated to a Client, where 255 the ACP prefix length must be no shorter than the ASP prefix 256 length and must be no longer than 64 for IPv6 or 32 for IPv4. 258 Throughout the document, the simple terms "Client", "Server" and 259 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 260 respectively. Capitalization is used to distinguish these terms from 261 DHCPv6 client/server/relay [RFC3315]. 263 The terminology of DHCPv6 [RFC3315] and IPv6 ND [RFC4861] (including 264 the names of node variables and protocol constants) applies to this 265 document. Also throughout the document, the term "IP" is used to 266 generically refer to either Internet Protocol version (i.e., IPv4 or 267 IPv6). 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 271 document are to be interpreted as described in [RFC2119]. Lower case 272 uses of these words are not to be interpreted as carrying RFC2119 273 significance. 275 3. Asymmetric Extended Route Optimization (AERO) 277 The following sections specify the operation of IP over Asymmetric 278 Extended Route Optimization (AERO) links: 280 3.1. AERO Link Reference Model 281 .-(::::::::) 282 .-(:::: IP ::::)-. 283 (:: Internetwork ::) 284 `-(::::::::::::)-' 285 `-(::::::)-' 286 | 287 +--------------+ +--------+-------+ +--------------+ 288 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 289 | Nbr: C1; R1 | | Nbr: S1; S2 | | Nbr: C2; R1 | 290 | default->R1 | |(P1->S1; P2->S2)| | default->R1 | 291 | P1->C1 | | ASP A1 | | P2->C2 | 292 +-------+------+ +--------+-------+ +------+-------+ 293 | | | 294 X---+---+-------------------+------------------+---+---X 295 | AERO Link | 296 +-----+--------+ +--------+-----+ 297 |AERO Client C1| |AERO Client C2| 298 | Nbr: S1 | | Nbr: S2 | 299 | default->S1 | | default->S2 | 300 | ACP P1 | | ACP P2 | 301 +--------------+ +--------------+ 302 .-. .-. 303 ,-( _)-. ,-( _)-. 304 .-(_ IP )-. .-(_ IP )-. 305 (__ EUN ) (__ EUN ) 306 `-(______)-' `-(______)-' 307 | | 308 +--------+ +--------+ 309 | Host H1| | Host H2| 310 +--------+ +--------+ 312 Figure 1: AERO Link Reference Model 314 Figure 1 presents the AERO link reference model. In this model: 316 o AERO Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 317 default router for its associated Servers S1 and S2, and connects 318 the AERO link to the rest of the IP Internetwork. 320 o AERO Servers S1 and S2 associate with Relay R1 and also act as 321 default routers for their associated Clients C1 and C2. 323 o AERO Clients C1 and C2 associate with Servers S1 and S2, 324 respectively. They receive AERO Client Prefix (ACP) delegations 325 P1 and P2, and also act as default routers for their associated 326 physical or internal virtual EUNs. (Alternatively, clients can 327 act as multi-addressed hosts without serving any EUNs). 329 o Simple hosts H1 and H2 attach to the EUNs served by Clients C1 and 330 C2, respectively. 332 Each AERO node maintains an AERO interface neighbor cache and an IP 333 forwarding table. For example, AERO Relay R1 in the diagram has 334 neighbor cache entries for Servers S1 and S2 as well as IP forwarding 335 table entries for the ACPs delegated to Clients C1 and C2. In common 336 operational practice, there may be many additional Relays, Servers 337 and Clients. (Although not shown in the figure, AERO Forwarding 338 Agents may also be provided for data plane forwarding offload 339 services.) 341 3.2. AERO Link Node Types 343 AERO Relays provide default forwarding services to AERO Servers. 344 Relays forward packets between neighbors connected to the same AERO 345 link and also forward packets between the AERO link and the native IP 346 Internetwork. Relays present the AERO link to the native 347 Internetwork as a set of one or more AERO Service Prefixes (ASPs) and 348 serve as a gateway between the AERO link and the Internetwork. AERO 349 Relays maintain an AERO interface neighbor cache entry for each AERO 350 Server, and maintain an IP forwarding table entry for each AERO 351 Client Prefix (ACP). AERO Relays can also be configured to act as 352 AERO Servers. 354 AERO Servers provide default forwarding services to AERO Clients. 355 Each Server also peers with each Relay in a dynamic routing protocol 356 instance to advertise its list of associated ACPs. Servers configure 357 a DHCPv6 server function to facilitate Prefix Delegation (PD) 358 exchanges with Clients. Each delegated prefix becomes an ACP taken 359 from an ASP. Servers forward packets between AERO interface 360 neighbors, and maintain an AERO interface neighbor cache entry for 361 each AERO Relay. They also maintain both neighbor cache entries and 362 IP forwarding table entries for each of their associated Clients. 363 AERO Servers can also be configured to act as AERO Relays. 365 AERO Clients act as requesting routers to receive ACPs through DHCPv6 366 PD exchanges with AERO Servers over the AERO link. Each Client MAY 367 associate with a single Server or with multiple Servers, e.g., for 368 fault tolerance, load balancing, etc. Each IPv6 Client receives at 369 least a /64 IPv6 ACP, and may receive even shorter prefixes. 370 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 371 singleton IPv4 address), and may receive even shorter prefixes. AERO 372 Clients maintain an AERO interface neighbor cache entry for each of 373 their associated Servers as well as for each of their correspondent 374 Clients. 376 AERO Forwarding Agents provide data plane forwarding services as 377 companions to AERO Servers. Note that while Servers are required to 378 perform both control and data plane operations on their own behalf, 379 they may optionally enlist the services of special-purpose Forwarding 380 Agents to offload data plane traffic. 382 3.3. AERO Addresses 384 An AERO address is an IPv6 link-local address with an embedded ACP 385 and assigned to a Client's AERO interface. The AERO address remains 386 stable as the Client moves between topological locations, i.e., even 387 if its link-layer addresses change. 389 For IPv6, the AERO address begins with the prefix fe80::/64 and 390 includes in its interface identifier (i.e., the lower 64 bits) the 391 base prefix taken from the Client's IPv6 ACP. The base prefix is 392 determined by masking the ACP with the prefix length. For example, 393 if the AERO Client receives the IPv6 ACP: 395 2001:db8:1000:2000::/56 397 it constructs its AERO address as: 399 fe80::2001:db8:1000:2000 401 For IPv4, the AERO address is based on an IPv4-mapped IPv6 address 402 [RFC4291] formed from the ACP and with a Prefix Length of 96 plus the 403 ACP prefix length. For example, for the IPv4 ACP 192.0.2.32/28 the 404 IPv4-mapped IPv6 address is: 406 0:0:0:0:0:FFFF:192.0.2.32/124 408 The Client then constructs its AERO address with the prefix fe80::/64 409 and with the lower 64 bits of the IPv4-mapped IPv6 address in the 410 interface identifier as: 412 fe80::FFFF:192.0.2.32 414 NOTE: In some cases, prospective neighbors may not have advanced 415 knowledge of the Client's ACP length and may therefore send initial 416 IPv6 ND messages with an AERO destination address that matches the 417 ACP but does not correspond to the base prefix. For example, if the 418 Client receives the IPv6 ACP 2001:db8:1000:2000::/56 then 419 subsequently receives an IPv6 ND message with destination address 420 fe80::2001:db8:1000:2001, it accepts the message as though it were 421 addressed to fe80::2001:db8:1000:2000. 423 3.4. AERO Interface Characteristics 425 AERO interfaces use encapsulation (see: Section 3.10) to exchange 426 packets with neighbors attached to the AERO link. 428 AERO interfaces maintain a neighbor cache, and AERO nodes use both 429 DHCPv6 and IPv6 ND control messaging to manage the creation, 430 modification and deletion of neighbor cache entries. 432 AERO Clients send DHCPv6 Solicit, Rebind, Renew and Release messages 433 to AERO Servers, which respond with DHCPv6 Reply messages. AERO 434 nodes use unicast IPv6 ND Neighbor Solicitation (NS), Neighbor 435 Advertisement (NA), Router Solicitation (RS) and Router Advertisement 436 (RA) messages the same as for any IPv6 link. 438 AERO interfaces use two IPv6 ND redirection message types -- the 439 first known as a Predirect message and the second being the standard 440 Redirect message (see Section 3.17). 442 AERO interface ND messages include one or more Source/Target Link- 443 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type | Length = 5 | Reserved1 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Reserved2 | Interface ID | UDP Port Number | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 + + 454 | | 455 + IP Address + 456 | | 457 + + 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |P00|P01|P02|P03|P04|P05|P06|P07|P08|P09|P10|P11|P12|P13|P14|P15| 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |P16|P17|P18|P19|P20|P21|P22|P23|P24|P25|P26|P27|P28|P29|P30|P31| 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |P32|P33|P34|P35|P36|P37|P38|P39|P40|P41|P42|P43|P44|P45|P46|P47| 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 |P48|P49|P50|P51|P52|P53|P54|P55|P56|P57|P58|P59|P60|P61|P62|P63| 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 470 Format 472 In this format: 474 o Type is set to '1' for SLLAO or '2' for TLLAO the same as for IPv6 475 ND. 477 o Length is set to the constant value '5' (i.e., 5 units of 8 478 octets). 480 o Both Reserved fields are set to the value '0' on transmission and 481 ignored on receipt. 483 o Interface ID is set to an integer value between 0 and 255 484 corresponding to an underlying interface of the AERO node. 486 o UDP Port Number and IP Address are set to the addresses used by 487 the AERO node when it sends encapsulated packets over the 488 underlying interface. When UDP is not used as part of the 489 encapsulation, UDP Port Number is set to the value '0'. When the 490 encapsulation IP address family is IPv4, IP Address is formed as 491 an IPv4-mapped IPv6 address as specified in Section 3.3. 493 o P[i] is a set of 64 Preference values that correspond to the 64 494 Differentiated Service Code Point (DSCP) values [RFC2474]. Each 495 P(i) is set to the value '0' ("disabled"), '1' ("low"), '2' 496 ("medium") or '3' ("high") to indicate a preference level for 497 packet forwarding purposes. 499 AERO interfaces may be configured over multiple underlying 500 interfaces. For example, common mobile handheld devices have both 501 wireless local area network ("WLAN") and cellular wireless links. 502 These links are typically used "one at a time" with low-cost WLAN 503 preferred and highly-available cellular wireless as a standby. In a 504 more complex example, aircraft frequently have many wireless data 505 link types (e.g. satellite-based, cellular, terrestrial, air-to-air 506 directional, etc.) with diverse performance and cost properties. 508 If a Client's multiple underlying interfaces are used "one at a time" 509 (i.e., all other interfaces are in standby mode while one interface 510 is active), then IPv6 ND messages include only a single S/TLLAO with 511 Interface ID set to a constant value. 513 If the Client has multiple active underlying interfaces, then from 514 the perspective of IPv6 ND it would appear to have multiple link- 515 layer addresses. In that case, IPv6 ND messages MAY include multiple 516 S/TLLAOs -- each with an Interface ID that corresponds to a specific 517 underlying interface of the AERO node. 519 3.5. AERO Link Registration 521 When an administrative authority first deploys a set of AERO Relays 522 and Servers that comprise an AERO link, they also assign a unique 523 domain name for the link, e.g., "linkupnetworks.example.com". Next, 524 if administrative policy permits Clients within the domain to serve 525 as correspondent nodes for Internet mobile nodes, the administrative 526 authority adds a Fully Qualified Domain Name (FQDN) for each of the 527 AERO link's ASPs to the Domain Name System (DNS) [RFC1035]. The FQDN 528 is based on the suffix "aero.linkupnetworks.net" with a prefix formed 529 from the wildcard-terminated reverse mapping of the ASP 530 [RFC3596][RFC4592], and resolves to a DNS PTR resource record. For 531 example, for the ASP '2001:db8:1::/48' within the domain name 532 "linkupnetworks.example.com", the DNS database contains: 534 '*.1.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net. PTR 535 linkupnetworks.example.com' 537 This DNS registration advertises the AERO link's ASPs to prospective 538 correspondent nodes. 540 3.6. AERO Interface Initialization 542 3.6.1. AERO Relay Behavior 544 When a Relay enables an AERO interface, it first assigns an 545 administratively provisioned link-local address fe80::ID to the 546 interface. Each fe80::ID address MUST be unique among all AERO nodes 547 on the link, and MUST NOT collide with any potential AERO addresses 548 nor the special addresses fe80:: and fe80::ffff:ffff:ffff:ffff. (The 549 fe80::ID addresses are typically taken from the available range 550 fe80::/96, e.g., as fe80::1, fe80::2, fe80::3, etc.) The Relay then 551 engages in a dynamic routing protocol session with all Servers on the 552 link (see: Section 3.7), and advertises its assigned ASPs into the 553 native IP Internetwork. 555 Each Relay subsequently maintains an IP forwarding table entry for 556 each ACP covered by its ASP(s), and maintains a neighbor cache entry 557 for each Server on the link. Relays exchange NS/NA messages with 558 AERO link neighbors the same as for any AERO node, however they 559 typically do not perform explicit Neighbor Unreachability Detection 560 (NUD) (see: Section 3.18) since the dynamic routing protocol already 561 provides reachability confirmation. 563 3.6.2. AERO Server Behavior 565 When a Server enables an AERO interface, it assigns an 566 administratively provisioned link-local address fe80::ID the same as 567 for Relays. The Server further configures a DHCPv6 server function 568 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 569 maintains a neighbor cache entry for each Relay on the link, and 570 manages per-ACP neighbor cache entries and IP forwarding table 571 entries based on control message exchanges. Each Server also engages 572 in a dynamic routing protocol with each Relay on the link (see: 573 Section 3.7). 575 When the Server receives an NS/RS message from a Client on the AERO 576 interface it returns an NA/RA message. The Server further provides a 577 simple link-layer conduit between AERO interface neighbors. In 578 particular, when a packet sent by a source Client arrives on the 579 Server's AERO interface and is destined to another of the Server's 580 Clients, the Server forwards the packet at the link layer without 581 ever disturbing the network layer and without ever leaving the AERO 582 interface. 584 3.6.3. AERO Client Behavior 586 When a Client enables an AERO interface, it uses the special address 587 fe80::ffff:ffff:ffff:ffff to obtain one or more ACPs from an AERO 588 Server via DHCPv6 PD. Next, it assigns the corresponding AERO 589 address(es) to the AERO interface and creates a neighbor cache entry 590 for the Server, i.e., the DHCPv6 PD exchange bootstraps 591 autoconfiguration of unique link-local address(es). The Client 592 maintains a neighbor cache entry for each of its Servers and each of 593 its active correspondent Clients. When the Client receives Redirect/ 594 Predirect messages on the AERO interface it updates or creates 595 neighbor cache entries, including link-layer address information. 597 3.6.4. AERO Forwarding Agent Behavior 599 When a Forwarding Agent enables an AERO interface, it assigns the 600 same link-local address(es) as the companion AERO Server. The 601 Forwarding Agent thereafter provides data plane forwarding services 602 based solely on the forwarding information assigned to it by the 603 companion AERO Server. 605 3.7. AERO Routing System 607 The AERO routing system is based on a private instance of the Border 608 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 609 and Servers and does not interact with either the public Internet BGP 610 routing system or the native IP Internetwork interior routing system. 612 Relays advertise only a small and unchanging set of ASPs to the 613 native routing system instead of the full dynamically changing set of 614 ACPs. 616 In a reference deployment, each AERO Server is configured as an 617 Autonomous System Border Router (ASBR) for a stub Autonomous System 618 (AS) using an AS Number (ASN) that is unique within the BGP instance, 619 and each Server further peers with each Relay but does not peer with 620 other Servers. Similarly, Relays do not peer with each other, since 621 they will reliably receive all updates from all Servers and will 622 therefore have a consistent view of the AERO link ACP delegations. 624 Each Server maintains a working set of associated ACPs, and 625 dynamically announces new ACPs and withdraws departed ACPs in its BGP 626 updates to Relays. Clients are expected to remain associated with 627 their current Servers for extended timeframes, however Servers SHOULD 628 selectively suppress BGP updates for impatient Clients that 629 repeatedly associate and disassociate with them in order to dampen 630 routing churn. 632 Each Relay configures a black-hole route for each of its ASPs. By 633 black-holing the ASPs, the Relay will maintain forwarding table 634 entries only for the ACPs that are currently active, and all other 635 ACPs will correctly result in destination unreachable failures due to 636 the black hole route. Relays do not send BGP updates for ACPs to 637 Servers, but instead originate a default route. In this way, Servers 638 have only partial topology knowledge (i.e., they know only about the 639 ACPs of their directly associated Cliens) and they forward all other 640 packets to Relays which have full topology knowledge. 642 Scaling properties of the AERO routing system are limited by the 643 number of BGP routes that can be carried by Relays. Assuming O(10^6) 644 as a reasonable maximum number of BGP routes, this means that O(10^6) 645 Clients can be serviced by a single set of Relays. A means of 646 increasing scaling would be to assign a different set of Relays for 647 each set of ASPs. In that case, each Server still peers with each 648 Relay, but the Server institutes route filters so that each set of 649 Relays only receives BGP updates for the ASPs they aggregate. For 650 example, if the ASP for the AERO link is 2001:db8::/32, a first set 651 of Relays could service the ASP segment 2001:db8::/40, a second set 652 of Relays could service 2001:db8:0100::/40, a third set could service 653 2001:db8:0200::/40, etc. 655 Assuming up to O(10^3) sets of Relays, the AERO routing system can 656 then accommodate O(10^9) ACPs with no additional overhead for Servers 657 and Relays (for example, it should be possible to service 4 billion 658 /64 ACPs taken from a /32 ASP and even more for shorter ASPs). In 659 this way, each set of Relays services a specific set of ASPs that 660 they advertise to the native routing system, and each Server 661 configures ASP-specific routes that list the correct set of Relays as 662 next hops. This arrangement also allows for natural incremental 663 deployment, and can support small scale initial deployments followed 664 by dynamic deployment of additional Clients, Servers and Relays 665 without disturbing the already-deployed base. 667 Note that in an alternate routing arrangement each set of Relays 668 could advertise the aggregated ASP for the link into the native 669 routing system even though each Relay services only a segment of the 670 ASP. In that case, a Relay upon receiving a packet with a 671 destination address covered by the ASP segment of another Relay can 672 simply tunnel the packet to the correct Relay. The tradeoff then is 673 the penalty for Relay-to-Relay tunneling compared with reduced 674 routing information in the native routing system. 676 Finally, Realys can express preferences for ACPs learned from 677 multiple Servers by assigning a BGP weight to each Server's peering 678 configuration. In this way Relays can choose the Serevr with the 679 highest weight as the preferred path, and then fail over to a Server 680 with lower weight in case of ACP withdrawl or Server failure. 682 3.8. AERO Interface Neighbor Cache Maintenace 684 Each AERO interface maintains a conceptual neighbor cache that 685 includes an entry for each neighbor it communicates with on the AERO 686 link, the same as for any IPv6 interface [RFC4861]. AERO interface 687 neighbor cache entires are said to be one of "permanent", "static" or 688 "dynamic". 690 Permanent neighbor cache entries are created through explicit 691 administrative action; they have no timeout values and remain in 692 place until explicitly deleted. AERO Relays maintain a permanent 693 neighbor cache entry for each Server on the link, and AERO Servers 694 maintain a permanent neighbor cache entry for each Relay. Each entry 695 maintains the mapping between the neighbor's fe80::ID network-layer 696 address and corresponding link-layer address. 698 Static neighbor cache entries are created through DHCPv6 PD exchanges 699 as specified in Section 3.15 and remain in place for durations 700 bounded by prefix lifetimes. AERO Servers maintain static neighbor 701 cache entries for the ACPs of each of their associated Clients, and 702 AERO Clients maintain a static neighbor cache entry for each of their 703 associated Servers. When an AERO Server sends a Reply message 704 response to a Client's Solicit, Rebind or Renew message, it creates 705 or updates a static neighbor cache entry based on the Client's DHCP 706 Unique Identifier (DUID) as the Client identifier, the AERO 707 address(es) corresponding to the Client's ACP(s) as the network-layer 708 address(es), the prefix lifetime as the neighbor cache entry 709 lifetime, the Client's encapsulation IP address and UDP port number 710 as the link-layer address and the prefix length(s) as the length to 711 apply to the AERO address(es). When an AERO Client receives a Reply 712 message from a Server, it creates or updates a static neighbor cache 713 entry based on the Reply message link-local source address as the 714 network-layer address, the prefix lifetime as the neighbor cache 715 entry lifetime, and the encapsulation IP source address and UDP 716 source port number as the link-layer address. 718 Dynamic neighbor cache entries are created or updated based on 719 receipt of a Predirect/Redirect message as specified in Section 3.17, 720 and are garbage-collected when keepalive timers expire. AERO Clients 721 maintain dynamic neighbor cache entries for each of their active 722 correspondent Client ACPs with lifetimes based on IPv6 ND messaging 723 constants. When an AERO Client receives a valid Predirect message it 724 creates or updates a dynamic neighbor cache entry for the Predirect 725 target network-layer and link-layer addresses plus prefix length. 726 The node then sets an "AcceptTime" variable in the neighbor cache 727 entry to ACCEPT_TIME seconds and uses this value to determine whether 728 packets received from the correspondent can be accepted. When an 729 AERO Client receives a valid Redirect message it creates or updates a 730 dynamic neighbor cache entry for the Redirect target network-layer 731 and link-layer addresses plus prefix length. The Client then sets a 732 "ForwardTime" variable in the neighbor cache entry to FORWARD_TIME 733 seconds and uses this value to determine whether packets can be sent 734 directly to the correspondent. The Client also sets a "MaxRetry" 735 variable to MAX_RETRY to limit the number of keepalives sent when a 736 correspondent may have gone unreachable. 738 It is RECOMMENDED that FORWARD_TIME be set to the default constant 739 value 30 seconds to match the default REACHABLE_TIME value specified 740 for IPv6 ND [RFC4861]. 742 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 743 value 40 seconds to allow a 10 second window so that the AERO 744 redirection procedure can converge before AcceptTime decrements below 745 FORWARD_TIME. 747 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 748 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 750 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 751 administratively set, if necessary, to better match the AERO link's 752 performance characteristics; however, if different values are chosen, 753 all nodes on the link MUST consistently configure the same values. 754 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 755 sufficiently longer than FORWARD_TIME to allow the AERO redirection 756 procedure to converge. 758 When there may be a Network Address Translator (NAT) between the 759 Client and the Server, or if the path from the Client to the Server 760 should be tested for reachability, the Client can send periodic RS 761 messages to the Server to receive RA replies. The RS/RA messaging 762 will keep NAT state alive and test Server reachability without 763 disturbing the DHCPv6 server. 765 3.9. AERO Interface Sending Algorithm 767 IP packets enter a node's AERO interface either from the network 768 layer (i.e., from a local application or the IP forwarding system), 769 or from the link layer (i.e., from the AERO tunnel virtual link). 770 Packets that enter the AERO interface from the network layer are 771 encapsulated and admitted into the AERO link, i.e., they are 772 tunnelled to an AERO interface neighbor. Packets that enter the AERO 773 interface from the link layer are either re-admitted into the AERO 774 link or delivered to the network layer where they are subject to 775 either local delivery or IP forwarding. Since each AERO node may 776 have only partial information about neighbors on the link, AERO 777 interfaces may forward packets with link-local destination addresses 778 at a layer below the network layer. This means that AERO nodes act 779 as both IP routers/hosts and sub-IP layer forwarding nodes. AERO 780 interface sending considerations for Clients, Servers and Relays are 781 given below. 783 When an IP packet enters a Client's AERO interface from the network 784 layer, if the destination is covered by an ASP the Client searches 785 for a dynamic neighbor cache entry with a non-zero ForwardTime and an 786 AERO address that matches the packet's destination address. (The 787 destination address may be either an address covered by the 788 neighbor's ACP or the (link-local) AERO address itself.) If there is 789 a match, the Client uses a link-layer address in the entry as the 790 link-layer address for encapsulation then admits the packet into the 791 AERO link. If there is no match, the Client instead uses the link- 792 layer address of a neighboring Server as the link-layer address for 793 encapsulation. 795 When an IP packet enters a Server's AERO interface from the link 796 layer, if the destination is covered by an ASP the Server searches 797 for a neighbor cache entry with an AERO address that matches the 798 packet's destination address. (The destination address may be either 799 an address covered by the neighbor's ACP or the AERO address itself.) 800 If there is a match, the Server uses a link-layer address in the 801 entry as the link-layer address for encapsulation and re-admits the 802 packet into the AERO link. If there is no match, the Server instead 803 uses the link-layer address in a permanent neighbor cache entry for a 804 Relay selected through longest-prefix-match as the link-layer address 805 for encapsulation. 807 When an IP packet enters a Relay's AERO interface from the network 808 layer, the Relay searches its IP forwarding table for an entry that 809 is covered by an ASP and also matches the destination. If there is a 810 match, the Relay uses the link-layer address in the corresponding 811 neighbor cache entry as the link-layer address for encapsulation and 812 admits the packet into the AERO link. When an IP packet enters a 813 Relay's AERO interface from the link-layer, if the destination is not 814 a link-local address and does not match an ASP the Relay removes the 815 packet from the AERO interface and uses IP forwarding to forward the 816 packet to the Internetwork. If the destination address is a link- 817 local address or a non-link-local address that matches an ASP, and 818 there is a more-specific ACP entry in the IP forwarding table, the 819 Relay uses the link-layer address in the corresponding neighbor cache 820 entry as the link-layer address for encapsulation and re-admits the 821 packet into the AERO link. When an IP packet enters a Relay's AERO 822 interface from either the network layer or link-layer, and the 823 packet's destination address matches an ASP but there is no more- 824 specific ACP entry, the Relay drops the packet and returns an ICMP 825 Destination Unreachable message (see: Section 3.14). 827 When an AERO Server receives a packet from a Relay via the AERO 828 interface, the Server MUST NOT forward the packet back to the same or 829 a different Relay. 831 When an AERO Relay receives a packet from a Server via the AERO 832 interface, the Relay MUST NOT forward the packet back to the same 833 Server. 835 When an AERO node re-admits a packet into the AERO link without 836 involving the network layer, the node MUST NOT decrement the network 837 layer TTL/Hop-count. 839 When an AERO node forwards a data packet to the primary link-layer 840 address of a Server, it may receive Redirect messages with an SLLAO 841 that include the link-layer address of an AERO Forwarding Agent. The 842 AERO node SHOULD record the link-layer address in the neighbor cache 843 entry for the neighbor and send subsequent data packets via this 844 address instead of the Server's primary address (see: Section 3.16). 846 AERO nodes may have multiple underlying interfaces and/or neighbor 847 cache entries for Clients with multiple Interface ID registrations 848 (see Section 3.4). The AERO node uses the packet's DSCP value to 849 select the outgoing underlying interface based on its own Interface 850 ID preference values and to select the destination link-layer address 851 based on the neighbor's Interface ID with the highest preference 852 value. If multiple Interface IDs have a preference of "high", the 853 AERO node sends one copy of the packet to each of the link-layer 854 addresses (i.e., it replicates the packet); otherwise, the node sends 855 a single copy of the packet. 857 3.10. AERO Interface Encapsulation and Re-encapsulation 859 AERO interfaces encapsulate IP packets according to whether they are 860 entering the AERO interface from the network layer or if they are 861 being re-admitted into the same AERO link they arrived on. This 862 latter form of encapsulation is known as "re-encapsulation". 864 The AERO interface encapsulates packets per the Generic UDP 865 Encapsulation (GUE) encapsulation procedures in 866 [I-D.ietf-nvo3-gue][I-D.herbert-gue-fragmentation], or through an 867 alternate encapsulation format (see: Appendix A). For packets 868 entering the AERO link from the IP layer, the AERO interface copies 869 the "TTL/Hop Limit", "Type of Service/Traffic Class" [RFC2983], "Flow 870 Label"[RFC6438].(for IPv6) and "Congestion Experienced" [RFC3168] 871 values in the packet's IP header into the corresponding fields in the 872 encapsulation IP header. For packets undergoing re-encapsulation 873 within the AERO link, the AERO interface instead copies the "TTL/Hop 874 Limit", "Type of Service/Traffic Class", "Flow Label" and "Congestion 875 Experienced" values in the original encapsulation IP header into the 876 corresponding fields in the new encapsulation IP header, i.e., the 877 values are transferred between encapsulation headers and *not* copied 878 from the encapsulated packet's network-layer header. 880 When GUE encapsulation is used, the AERO interface next sets the UDP 881 source port to a constant value that it will use in each successive 882 packet it sends, and sets the UDP length field to the length of the 883 encapsulated packet plus 8 bytes for the UDP header itself plus the 884 length of the GUE header (or 0 if GUE direct IP encapsulation is 885 used). For packets sent to a Server, the AERO interface sets the UDP 886 destination port to 8060, i.e., the IANA-registered port number for 887 AERO. For packets sent to a correspondent Client, the AERO interface 888 sets the UDP destination port to the port value stored in the 889 neighbor cache entry for this correspondent. The AERO interface then 890 either includes or omits the UDP checksum according to the GUE 891 specification. 893 For IPv4 encapsulation, the AERO interface sets the DF bit as 894 discussed in Section 3.13. 896 3.11. AERO Interface Decapsulation 898 AERO interfaces decapsulate packets destined either to the AERO node 899 itself or to a destination reached via an interface other than the 900 AERO interface the packet was received on. Decapsulation is per the 901 procedures specified for the appropriate encapsulation format. 903 3.12. AERO Interface Data Origin Authentication 905 AERO nodes employ simple data origin authentication procedures for 906 encapsulated packets they receive from other nodes on the AERO link. 907 In particular: 909 o AERO Servers and Relays accept encapsulated packets with a link- 910 layer source address that matches a permanent neighbor cache 911 entry. 913 o AERO Servers accept authentic encapsulated DHCPv6 messages from 914 Clients, and create or update a static neighbor cache entry for 915 the Client based on the specific DHCPv6 message type. 917 o AERO Clients and Servers accept encapsulated packets if there is a 918 static neighbor cache entry with a link-layer address that matches 919 the packet's link-layer source address. 921 o AERO Clients, Servers and Relays accept encapsulated packets if 922 there is a dynamic neighbor cache entry with an AERO address that 923 matches the packet's network-layer source address, with a link- 924 layer address that matches the packet's link-layer source address, 925 and with a non-zero AcceptTime. 927 Note that this simple data origin authentication is effective in 928 environments in which link-layer addresses cannot be spoofed. In 929 other environments, each AERO message must include a signature that 930 the recipient can use to authenticate the message origin. 932 3.13. AERO Interface Packet Size Issues 934 The AERO interface is the node's attachment to the AERO link. The 935 AERO interface acts as a tunnel ingress when it sends a packet to an 936 AERO link neighbor and as a tunnel egress when it receives a packet 937 from an AERO link neighbor. AERO interfaces observe the packet 938 sizing considerations for tunnels discussed in 939 [I-D.ietf-intarea-tunnels] and as specified below. 941 IPv6 specifies a minimum link Maximum Transmission Unit (MTU) of 1280 942 bytes [RFC2460]. Although IPv4 specifies a smaller minimum link MTU 943 of 68 bytes [RFC0791], AERO interfaces also observe the IPv6 minimum 944 for IPv4 even if the packet may incur fragmentation in the network. 946 IPv6 specifies a minimum Maximum Reassembly Unit (MRU) of 1500 bytes 947 [RFC2460], while the minimum MRU for IPv4 is only 576 bytes [RFC1122] 948 (note that IPv6 over IPv4 tunnels assume a larger MRU than the IPv4 949 minimum). 951 Original sources expect that IP packets will either be delivered to 952 the final destination or a suitable Packet Too Big (PTB) message 953 returned. However, PTB messages may be crafted for malicious 954 purposes such as denial of service, or lost in the network [RFC2923] 955 resulting in failure of the IP Path MTU Discovery (PMTUD) mechanisms 956 [RFC1191][RFC1981]. For these reasons, AERO links employ operational 957 procedures that avoid all interactions with PMTUD. 959 AERO Servers advertise an MTU that MUST be no smaller than 1280 960 bytes, MUST be no larger than the minimum MRU among all nodes on the 961 AERO link minus the encapsulation overhead ("ENCAPS"), and SHOULD be 962 no smaller than 1500 bytes. AERO Servers advertise a Maximum 963 Fragment Unit (MFU) as the maximum size for the fragments of an 964 encapsulated packet that require fragmentation. The MFU value MUST 965 NOT be larger than (MTU+ENCAPS) and MUST NOT be larger than 1280 966 bytes unless there is operational assurance that a larger size can 967 traverse the link along all paths without fragmentation. 969 AERO Clients set the AERO interface MTU/MFU based on the values 970 advertised by their Server, and configure an MRU large enough to 971 reassemble packets up to (MTU+ENCAPS) bytes. 973 All AERO nodes on the link MUST configure the same MTU/MFU values for 974 reasons cited in [RFC3819][RFC4861] (in particular, multicast support 975 requires a common MTU value among all nodes on the link). 977 All AERO nodes on the link MUST configure a minimum MRU of 978 (1500+ENCAPS) bytes, and SHOULD be capable of setting a larger MRU 979 accoding to the Server's advertised MTU. 981 In accordnace with these requirements, the ingress accommodates 982 packets of various sizes as follows: 984 o First, for each original IPv4 packet that is larger than the AERO 985 interface MTU and with the DF bit set to 0, the ingress uses IPv4 986 fragmentation to break the packet into a minimum number of non- 987 overlapping fragments where the first fragment is no larger than 988 (MFU-ENCAPS) bytes and the remaining fragments are no larger than 989 the first. 991 o Next, for each original IP packet or fragment that is no larger 992 than (MFU-ENCAPS) bytes, the ingress encapsulates the packet and 993 admits it into the tunnel. For IPv4 AERO links, the ingress sets 994 the Don't Fragment (DF) bit to 0 so that these packets will be 995 delivered to the egress even if some fragmentation occurs in the 996 network. 998 o For all other original IP packets or fragments, if the packet is 999 larger than the AERO interface MTU, the ingress drops the packet 1000 and returns a PTB message to the original source. Otherwise, the 1001 ingress encapsulates the packet and fragments the encapsulated 1002 packet into a minimum number of non-overlapping fragments where 1003 the first fragment is no larger than MFU bytes and the remaining 1004 fragments are no larger than the first. The ingress then admits 1005 the fragments into the tunnel, and for IPv4 sets the DF bit to 0 1006 in the IP encapsulation header. These fragmented encapsulated 1007 packets will be delivered to the egress, which reassembles them 1008 into a whole packet. 1010 Several factors must be considered when fragmentation of the 1011 encapsulated packet is needed. For AERO links over IPv4, the IP ID 1012 field is only 16 bits in length, meaning that fragmentation at high 1013 data rates could result in data corruption due to reassembly 1014 misassociations [RFC6864][RFC4963]. For AERO links over both IPv4 1015 and IPv6, studies have also shown that IP fragments are dropped 1016 unconditionally over some network paths [I-D.taylor-v6ops-fragdrop]. 1017 In environments where IP fragmentation issues could result in 1018 operational problems, the ingress SHOULD employ intermediate-layer 1019 fragmentation (see: [RFC2764] and [I-D.herbert-gue-fragmentation]) 1020 before appending the outer encapsulation headers to each fragment. 1022 Since the encapsulation fragment header reduces the room available 1023 for packet data, but the original source has no way to control its 1024 insertion, the ingress MUST include the fragment header length in the 1025 ENCAPS length even for packets in which the header is absent. 1027 3.14. AERO Interface Error Handling 1029 When an AERO node admits encapsulated packets into the AERO 1030 interface, it may receive link-layer (L2) or network-layer (L3) error 1031 indications. 1033 An L2 error indication is an ICMP error message generated by a router 1034 on the path to the neighbor or by the neighbor itself. The message 1035 includes an IP header with the address of the node that generated the 1036 error as the source address and with the link-layer address of the 1037 AERO node as the destination address. 1039 The IP header is followed by an ICMP header that includes an error 1040 Type, Code and Checksum. Valid type values include "Destination 1041 Unreachable", "Time Exceeded" and "Parameter Problem" 1042 [RFC0792][RFC4443]. (AERO interfaces ignore all L2 IPv4 1043 "Fragmentation Needed" and IPv6 "Packet Too Big" messages since they 1044 only emit packets that are guaranteed to be no larger than the IP 1045 minimum link MTU.) 1047 The ICMP header is followed by the leading portion of the packet that 1048 generated the error, also known as the "packet-in-error". For 1049 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1050 much of invoking packet as possible without the ICMPv6 packet 1051 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1052 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1053 "Internet Header + 64 bits of Original Data Datagram", however 1054 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1055 ICMP datagram SHOULD contain as much of the original datagram as 1056 possible without the length of the ICMP datagram exceeding 576 1057 bytes". 1059 The L2 error message format is shown in Figure 3: 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 ~ ~ 1063 | L2 IP Header of | 1064 | error message | 1065 ~ ~ 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | L2 ICMP Header | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1069 ~ ~ P 1070 | IP and other encapsulation | a 1071 | headers of original L3 packet | c 1072 ~ ~ k 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1074 ~ ~ t 1075 | IP header of | 1076 | original L3 packet | i 1077 ~ ~ n 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 ~ ~ e 1080 | Upper layer headers and | r 1081 | leading portion of body | r 1082 | of the original L3 packet | o 1083 ~ ~ r 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1086 Figure 3: AERO Interface L2 Error Message Format 1088 The AERO node rules for processing these L2 error messages is as 1089 follows: 1091 o When an AERO node receives an L2 Parameter Problem message, it 1092 processes the message the same as described as for ordinary ICMP 1093 errors in the normative references [RFC0792][RFC4443]. 1095 o When an AERO node receives persistent L2 IPv4 Time Exceeded 1096 messages, the IP ID field may be wrapping before earlier fragments 1097 have been processed. In that case, the node SHOULD begin 1098 including integrity checks and/or institute rate limits for 1099 subseqent packets. 1101 o When an AERO Client receives persistent L2 Destination Unreachable 1102 messages in response to tunneled packets that it sends to one of 1103 its dynamic neighbor correspondents, the Client SHOULD test the 1104 path to the correspondent using Neighbor Unreachability Detection 1105 (NUD) (see Section 3.18). If NUD fails, the Client SHOULD set 1106 ForwardTime for the corresponding dynamic neighbor cache entry to 1107 0 and allow future packets destined to the correspondent to flow 1108 through a Server. 1110 o When an AERO Client receives persistent L2 Destination Unreachable 1111 messages in response to tunneled packets that it sends to one of 1112 its static neighbor Servers, the Client SHOULD test the path to 1113 the Server using NUD. If NUD fails, the Client SHOULD delete the 1114 neighbor cache entry and attempt to associate with a new Server. 1116 o When an AERO Server receives persistent L2 Destination Unreachable 1117 messages in response to tunneled packets that it sends to one of 1118 its static neighbor Clients, the Server SHOULD test the path to 1119 the Client using NUD. If NUD fails, the Server SHOULD cancel the 1120 DHCPv6 PD for the Client's ACP, withdraw its route for the ACP 1121 from the AERO routing system and delete the neighbor cache entry 1122 (see Section 3.18 and Section 3.19). 1124 o When an AERO Relay or Server receives an L2 Destination 1125 Unreachable message in response to a tunneled packet that it sends 1126 to one of its permanent neighbors, it discards the message since 1127 the AERO routing system is likely in a temporary transitional 1128 state that will soon re-converge. In case of a prolonged outage, 1129 however, the AERO routing system will compensate for Relays or 1130 Servers that have fallen silent. 1132 When an AERO Relay receives an L3 packet for which the destination 1133 address is covered by an ASP, if there is no more-specific routing 1134 information for the destination the Relay drops the packet and 1135 returns an L3 Destination Unreachable message. The Relay first 1136 writes the IP source address of the original L3 packet as the 1137 destination address of the L3 Destination Unreachable message and 1138 determines the next hop to the destination. If the next hop is 1139 reached via the AERO interface, the Relay uses the IPv6 address "::" 1140 or the IPv4 address "0.0.0.0" as the IP source address of the L3 1141 Destination Unreachable message and forwards the message to the next 1142 hop within the AERO interface. Otherwise, the Relay uses one of its 1143 non link-local addresses as the source address of the L3 Destination 1144 Unreachable message and forwards the message via a link outside the 1145 AERO interface. 1147 When an AERO node receives an encapsulated packet for which the 1148 reassembly buffer it too small, it drops the packet and returns an L3 1149 Packet To Big (PTB) message. The node first writes the IP source 1150 address of the original L3 packet as the destination address of the 1151 L3 PTB message and determines the next hop to the destination. If 1152 the next hop is reached via the AERO interface, the node uses the 1153 IPv6 address "::" or the IPv4 address "0.0.0.0" as the IP source 1154 address of the L3 PTB message and forwards the message to the next 1155 hop within the AERO interface. Otherwise, the node uses one of its 1156 non link-local addresses as the source address of the L3 PTB message 1157 and forwards the message via a link outside the AERO interface. 1159 When an AERO node receives any L3 error message via the AERO 1160 interface, it examines the destination address in the L3 IP header of 1161 the message. If the next hop toward the destination address of the 1162 error message is via the AERO interface, the node re-encapsulates and 1163 forwards the message to the next hop within the AERO interface. 1164 Otherwise, if the source address in the L3 IP header of the message 1165 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1166 writes one of its non link-local addresses as the source address of 1167 the L3 message and recalculates the IP and/or ICMP checksums. The 1168 node finally forwards the message via a link outside of the AERO 1169 interface. 1171 3.15. AERO Router Discovery, Prefix Delegation and Address 1172 Configuration 1174 AERO Router Discovery, Prefix Delegation and Address Configuration 1175 are coordinated by the DHCPv6 control messaging protocol as discussed 1176 in the following Sections. 1178 3.15.1. AERO DHCPv6 Service Model 1180 Each AERO Server configures a DHCPv6 server function to facilitate PD 1181 requests from Clients. Each Server is provisioned with a database of 1182 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1183 system, as well as any information necessary to authenticate each 1184 Client. The Client database is maintained by a central 1185 administrative authority for the AERO link and securely distributed 1186 to all Servers, e.g., via the Lightweight Directory Access Protocol 1187 (LDAP) [RFC4511] or a similar distributed database service. 1189 Therefore, no Server-to-Server DHCPv6 PD state synchronization is 1190 necessary, and Clients can optionally hold separate PDs for the same 1191 ACPs from multiple Servers. In this way, Clients can associate with 1192 multiple Servers, and can receive new PDs from new Servers before 1193 deprecating PDs received from existing Servers. This provides the 1194 Client with a natural fault-tolerance and/or load balancing profile. 1196 AERO Clients and Servers exchange configuration information using an 1197 AERO Vendor-Specific Information Option (AVSIO) formatted as follows: 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | OPTION_VENDOR_OPTS | option-len | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | enterprise-number = 45282 | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 . . 1207 . option-data . 1208 . . 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Figure 4: AERO Vendor-Specific Information Option (AVSIO) 1213 In this format, "enterprise-number" is set to 45282 (i.e., the IANA- 1214 reserved enterprise number for AERO) and "option-length" is set to 1215 the total length of the option. A single AVSIO may include one or 1216 more AERO-specific (sub)options as defined in the following sections. 1218 AERO Clients MUST include an AVSIO in DHCPv6 Solicit and Rebind 1219 messages to manage the Server's cached link-layer addresses and 1220 preferences. AERO Servers MUST include an AVSIO in DHCPv6 Reply 1221 messages that correspond to a Client's DHCPv6 message that also 1222 included an AVSIO option. 1224 The following sections specify the Client and Server behavior in more 1225 detail. 1227 3.15.2. AERO Client Behavior 1229 AERO Clients discover the link-layer addresses of AERO Servers via 1230 static configuration (e.g., from a flat-file map of Server addresses 1231 and locations), or through an automated means such as DNS name 1232 resolution. In the absence of other information, the Client resolves 1233 the FQDN "linkupnetworks.[domainname]" where "linkupnetworks" is a 1234 constant text string and "[domainname]" is a DNS suffix for the 1235 Client's underlying network (e.g., "example.com"). After discovering 1236 the link-layer addresses, the Client associates with one or more of 1237 the corresponding Servers. 1239 To associate with a Server, the Client acts as a requesting router to 1240 request ACPs through a two-message (i.e., Solicit/Reply) DHCPv6 PD 1241 exchange [RFC3315][RFC3633]. The Client's includes 1242 fe80::ffff:ffff:ffff:ffff as the IPv6 source address of the Solicit 1243 message, 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination 1244 address, an underlying interface address of the Client (i.e., the 1245 link-layer address) as the link-layer source address and the link- 1246 layer address of the Server as the link-layer destination address. 1247 The Client also includes a Rapid Commit option, a Client Identifier 1248 option with the Client's DUID, and an Identity Association for Prefix 1249 Delegation (IA_PD) option. If the Client is pre-provisioned with 1250 ACPs associated with the AERO service, it MAY also include the ACPs 1251 in the IA_PD to indicate its preferences to the DHCPv6 server. 1253 The Client also includes an AVSIO option with one or more AERO Client 1254 Link-Layer Address Options (ACLLAOs) to register its link-layer 1255 address(es) with the Server. The first ACLLAO MUST be specific to 1256 the underlying interface over which the Client will send the Solicit. 1257 The Client MAY include additonal ACLLAOs specific to other underlying 1258 interfaces, but if so it MUST have assurance that there will be no 1259 NATs on the paths to the Server via those interfaces. (Otherwise, 1260 the Client MAY issue subsequent Rebind messages after the initial 1261 Solicit/Reply exchange to register additional link-layer addresses). 1262 The Server will echo the ACLLAOs in the corresponding Reply message 1263 as specified in Section 3.15.3. 1265 The format for the ACLLAO is shown in Figure 5: 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | opt-code = OPTION_ACLLAO (0) | option-len | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 . . 1273 . AERO Client Link-Layer Address . 1274 . . 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 Figure 5: AERO Client Link-Layer Address Option (ACLLAO) 1279 In the above format, the Client sets 'opt-code' to 0 1280 ("OPTION_ACLLAO") and sets 'option-len' to 36 (i.e., the length of 1281 the option following this field). The Client then includes an "AERO 1282 Client Link-Layer Address" in the same format as for S/TLLAOs in 1283 Figure 2 beginning with the 'Reserved2' field and extending to the 1284 end of the S/TLLAO. The Client then sets 'Reserved2', 'Interface 1285 ID', 'UDP Port Number', 'IP address' and 'P(i)' values for the 1286 specific underlying interface the same as for S/TLLAO options (see 1287 Section 3.4). The Client finally includes any additional DHCPv6 1288 options (including any necessary authentication options to identify 1289 itself to the DHCPv6 server), and sends the encapsulated Solicit 1290 message via the underlying interface corresponding to the Interface 1291 ID of the first ACLLAO. 1293 When the Client attempts to perform a DHCPv6 PD exchange with a 1294 Server that is too busy to service the request, the Client may 1295 receive an error status code such as "NoPrefixAvail" in the Server's 1296 Reply [RFC3633] or no Reply at all. In that case, the Client SHOULD 1297 discontinue DHCPv6 PD attempts through this Server and try another 1298 Server. 1300 When the Client receives a Reply from the AERO Server with an AVSIO 1301 option and no error status codes, it can compare the UDP Port Number 1302 and IP Address values in the first ACLLAO with the values the Client 1303 provided in its request. If the values are different, the Client can 1304 infer that there is a NAT on the path to the Server via that 1305 underlying interface. If the AVSIO option also includes an ALINFO 1306 sub-option, the Client also assigns the MTU/MFU values in the ALINFO 1307 option to its AERO interface, then caches any ASPs included in the 1308 ALINFO option as ASPs to associate with the AERO link (see 1309 Section 3.15.3). This configuration information applies to the AERO 1310 link as a whole, and all Clients will receive the same information. 1312 The Client next creates a static neighbor cache entry with the 1313 Server's link-local address as the network-layer address and the 1314 Server's encapsulation address as the link-layer address. Next, the 1315 Client autoconfigures an AERO address for each of the delegated ACPs, 1316 assigns the address(es) to the AERO interface and sub-delegates the 1317 ACPs to its attached EUNs and/or the Client's own internal virtual 1318 interfaces. The Client can then configure as many addresses as it 1319 wants from /64 prefixes taken from the ACPs and assign them to either 1320 an internal virtual interface ("weak end-system") or to the AERO 1321 interface itself ("strong end-system") [RFC1122] while black-holing 1322 the remaining portions of the /64s. Finally, the Client assigns a 1323 default IP route to the AERO interface with the link-local address of 1324 the Server as the next hop and with the PD lifetime as the default 1325 router lifetime. 1327 After the initial Solicit/Reply exchange, the Client SHOULD begin 1328 using the AERO address as the source address for further DHCPv6 1329 messaging. The Client subsequently renews its ACP delegations 1330 through each of its Servers by sending Renew messages with the link- 1331 layer address of a Server as the link-layer destination address. The 1332 Client MAY subsequently issue Rebind messages with additional ACLLAOs 1333 if it wishes to register additional Interface IDs and/or update the 1334 link-layer address information for existing Interface IDs. In that 1335 case, the Rebind message MUST be sent over the underlying interface 1336 corresponding to the first ACLLAO in the message, i.e., the same as 1337 for Solicits. 1339 After an AERO Client registers its Interface IDs and their associated 1340 'P(i)' values with the AERO Server, the Client may wish to change one 1341 or more Interface ID registrations, e.g., if an underlying interface 1342 becomes unavailable, if cost profiles change, etc. To do so, the 1343 Client prepares a Rebind message to send over any available 1344 underlying interface. The Rebind MUST include the ACLLAO specific to 1345 the selected avaialble underlying interface as the first ACLLAO and 1346 MAY include any additional ACLLAOs specific to other underlying 1347 interfaces. The Client includes fresh 'P(i)' values in each ACLLAO 1348 to update the Server's neighbor cache entry. If the Client wishes to 1349 disable some or all DSCPs for an underlying interface, it includes an 1350 ACLLAO with 'P(i)' values set to 0 ("disabled"). 1352 If the Client wishes to discontinue use of a Server it issues a 1353 Release to delete the Server's neighbor cache entry. 1355 3.15.3. AERO Server Behavior 1357 AERO Servers configure a DHCPv6 server function on their AERO links. 1358 AERO Servers arrange to add their encapsulation layer IP addresses 1359 (i.e., their link-layer addresses) to a static map of Server 1360 addresses for the link and/or the DNS resource records for the FQDN 1361 "linkupnetworks.[domainname]" before entering service. 1363 When an AERO Server receives a prospective Client's Solicit on its 1364 AERO interface, and the Server is too busy to service the message, it 1365 SHOULD return a Reply with status code "NoPrefixAvail" per [RFC3633]. 1366 Otherwise, the Server authenticates the message. If authentication 1367 succeeds, the Server determines the correct ACPs to delegate to the 1368 Client by searching the Client database. 1370 When the Server delegates the ACPs, it also creates IP forwarding 1371 table entries so that the AERO BGP-based routing system will 1372 propagate the ACPs to all Relays that aggregate the corresponding ASP 1373 (see: Section 3.7). Next, the Server prepares a Reply message to 1374 send to the Client while using fe80::ID as the IPv6 source address, 1375 the link-local address taken from the Client's Solicit as the IPv6 1376 destination address, the Server's link-layer address as the source 1377 link-layer address, and the Client's link-layer address as the 1378 destination link-layer address. The Server also includes IA_PD 1379 options with the delegated ACPs. For IPv4 ACPs, the prefix included 1380 in the IA_PD option is in IPv4-mapped IPv6 address format and with 1381 prefix length set as specified in Section 3.3. For AERO links where 1382 a Client may experience a fault that prevents it from issuing a 1383 Release before departing from the network, Servers should set a short 1384 prefix lifetime (e.g., 40 seconds) so that stale PD state can be 1385 flushed out of the network. 1387 For Replies to Client DHCPv6 messages that include an AVSIO, the 1388 Server prepares a new AVSIO to include in the Reply. The Server 1389 first copies the ACLLAOs in the body of the Client's AVSIO into the 1390 AVSIO that the Server will supply in the Reply message. For the 1391 initial ACLLAO, the Server sets 'UDP Port Number' and 'IP address' to 1392 the values observed in the outer encapsulating headers of the 1393 Client's DHCPv6 message, i.e., even if these values are different 1394 than the ones included by the Client. 1396 The Server next copies an ALINFO option into the body of the AVSIO 1397 (i.e., following the ACLLAO options) formatted as shown in Figure 6: 1399 0 1 2 3 1400 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 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | opt-code = OPTION_ALINFO (1) | option-len | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 |Maximum Transmission Unit (MTU)| Maximum Fragment Unit (MFU) | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Prefix Len #1 | AERO Service Prefix (ASP) #1 (1 to 8 bytes) | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Prefix Len #2 | AERO Service Prefix (ASP) #2 (1 to 8 bytes) | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Prefix Len #3 | AERO Service Prefix (ASP) #3 (1 to 8 bytes) | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 ~ ~ 1413 ~ ~ 1415 Figure 6: AERO Link Information (ALINFO) Option 1417 In the ALINFO option, the Server sets sets 'opt-code' to 1 1418 ("OPTION_ALINFO") and sets 'option-len' to the length of the 1419 remainder of the option. The Server next sets MTU and MFU according 1420 to the considerations specified in Section 3.13. The Server finally 1421 includes one or more ASPs with 'Prefix Len' set to the ASP prefix 1422 length (between 0 and 64), and 'AERO Service Prefix' set to the ASP 1423 (between 1 and 8 bytes). 1425 When the Server sends the Reply message, it creates or updates a 1426 static neighbor cache entry for the Client based on the DUID and AERO 1427 addresses with lifetime set to no more than the PD lifetimes and 1428 updates the Client's link-layer addresses according to the ACLLAOs. 1429 The Server then uses the Client link-layer addresses as the link- 1430 layer addresses for encapsulation and uses the 'P(i)' values included 1431 in ACLLAOs as preference levels for each DSCP value. 1433 After the initial DHCPv6 PD Solicit/Reply exchange, the AERO Server 1434 maintains the neighbor cache entry for the Client until the PD 1435 lifetimes expire. If the Client issues a Rebind, the Server uses any 1436 included ACLLAOs to update the link-layer information in the Client's 1437 neighbor cache entry. If the Client issues a Renew, the Server 1438 extends the PD lifetimes. If the Client issues a Release, or if the 1439 Client does not issue a Renew before the lifetime expires, the Server 1440 deletes the neighbor cache entry for the Client and withdraws the IP 1441 routes from the AERO routing system. 1443 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1445 AERO Clients and Servers are always on the same link (i.e., the AERO 1446 link) from the perspective of DHCPv6. However, in some 1447 implementations the DHCPv6 server and AERO interface driver may be 1448 located in separate modules. In that case, the Server's AERO 1449 interface driver module can act as a Lightweight DHCPv6 Relay Agent 1450 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1451 server module. 1453 When the LDRA receives a DHCPv6 message from a client, it prepares an 1454 AVSIO (including any ACLLAO and ALINFO options as described above) 1455 and copies the option into a DHCPv6 Relay-Supplied Option Option 1456 (RSOO) [RFC6422]. The LDRA then incorporates the RSOO into the 1457 Relay-Forward message and forwards the message to the DHCPv6 server. 1459 When the DHCPv6 server receives the Relay-Forward message, it caches 1460 the AVSIO included in the RSOO and discards the AVSIO included within 1461 the Client's message itself. Next, the server authenticates the 1462 Client's message and prepares a Reply message if authentication 1463 succeeds. 1465 When the DHCPv6 server prepares a Reply message, it then includes the 1466 relay-supplied AVSIO in the body of the message along with any other 1467 options, then wraps the message in a Relay-Reply message. The DHCPv6 1468 server then delivers the Relay-Reply message to the LDRA, which 1469 discards the Relay-Reply wrapper and delivers the DHCPv6 message to 1470 the Client. 1472 3.16. AERO Forwarding Agent Behavior 1474 AERO Servers MAY associate with one or more companion AERO Forwarding 1475 Agents as platforms for offloading high-speed data plane traffic. 1476 When an AERO Server receives a Client's Solicit/Renew/Rebind/Release 1477 message, it services the message then forwards the corresponding 1478 Reply message to the Forwarding Agent. When the Forwarding Agent 1479 receives the Reply message, it creates, updates or deletes a neighbor 1480 cache entry with the Client's AERO address and link-layer information 1481 included in the Reply message. The Forwarding Agent then forwards 1482 the Reply message back to the AERO Server, which forwards the message 1483 to the Client. In this way, Forwarding Agent state is managed in 1484 conjunction with Server state, with the Client responsible for 1485 reliability. 1487 When an AERO Server receives a data packet on an AERO interface with 1488 a network layer destination address for which it has distributed 1489 forwarding information to a Forwarding Agent, the Server returns a 1490 Redirect message to the source neighbor (subject to rate limiting) 1491 then forwards the data packet as usual. The Redirect message 1492 includes a TLLAO with the link-layer address of the Forwarding 1493 Engine. 1495 When the source neighbor receives the Redirect message, it SHOULD 1496 record the link-layer address in the TLLAO as the encapsulation 1497 addresses to use for sending subsequent data packets. However, the 1498 source MUST continue to use the primary link-layer address of the 1499 Server as the encapsulation address for sending control messages. 1501 3.17. AERO Link Route Optimization 1503 When a source Client forwards packets to a prospective correspondent 1504 Client within the same AERO link domain (i.e., one for which the 1505 packet's destination address is covered by an ASP), the source Client 1506 MAY initiate an AERO link route optimization procedure. It is 1507 important to note that this procedure is initiated by the Client; if 1508 the procedure were initiated by the Server, the Server would have no 1509 way of knowing whether the Client was actually able to contact the 1510 correspondent over the route-optimized path. 1512 The procedure is based on an exchange of IPv6 ND messages using a 1513 chain of AERO Servers and Relays as a trust basis. This procedure is 1514 in contrast to the Return Routability procedure required for route 1515 optimization to a correspondent Client located in the Internet as 1516 described in Section 3.22. The following sections specify the AERO 1517 link route optimization procedure. 1519 3.17.1. Reference Operational Scenario 1521 Figure 7 depicts the AERO link route optimization reference 1522 operational scenario, using IPv6 addressing as the example (while not 1523 shown, a corresponding example for IPv4 addressing can be easily 1524 constructed). The figure shows an AERO Relay ('R1'), two AERO 1525 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1526 IPv6 hosts ('H1', 'H2'): 1528 +--------------+ +--------------+ +--------------+ 1529 | Server S1 | | Relay R1 | | Server S2 | 1530 +--------------+ +--------------+ +--------------+ 1531 fe80::2 fe80::1 fe80::3 1532 L2(S1) L2(R1) L2(S2) 1533 | | | 1534 X-----+-----+------------------+-----------------+----+----X 1535 | AERO Link | 1536 L2(A) L2(B) 1537 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1538 +--------------+ +--------------+ 1539 |AERO Client C1| |AERO Client C2| 1540 +--------------+ +--------------+ 1541 2001:DB8:0::/48 2001:DB8:1::/48 1542 | | 1543 .-. .-. 1544 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1545 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1546 (__ EUN )--| Host H1 | | Host H2 |--(__ EUN ) 1547 `-(______)-' +---------+ +---------+ `-(______)-' 1549 Figure 7: AERO Reference Operational Scenario 1551 In Figure 7, Relay ('R1') assigns the address fe80::1 to its AERO 1552 interface with link-layer address L2(R1), Server ('S1') assigns the 1553 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1554 assigns the address fe80::3 with link-layer address L2(S2). Servers 1555 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1556 published list of valid Servers for the AERO link. 1558 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1559 exchange via AERO Server ('S1') then assigns the address 1560 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1561 L2(C1). Client ('C1') configures a default route and neighbor cache 1562 entry via the AERO interface with next-hop address fe80::2 and link- 1563 layer address L2(S1), then sub-delegates the ACP to its attached 1564 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1565 address 2001:db8:0::1. 1567 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1568 exchange via AERO Server ('S2') then assigns the address 1569 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1570 L2(C2). Client ('C2') configures a default route and neighbor cache 1571 entry via the AERO interface with next-hop address fe80::3 and link- 1572 layer address L2(S2), then sub-delegates the ACP to its attached 1573 EUNs. IPv6 host ('H2') connects to the EUN, and configures the 1574 address 2001:db8:1::1. 1576 3.17.2. Concept of Operations 1578 Again, with reference to Figure 7, when source host ('H1') sends a 1579 packet to destination host ('H2'), the packet is first forwarded over 1580 the source host's attached EUN to Client ('C1'). Client ('C1') then 1581 forwards the packet via its AERO interface to Server ('S1') and also 1582 sends a Predirect message toward Client ('C2') via Server ('S1'). 1583 Server ('S1') then re-encapsulates and forwards both the packet and 1584 the Predirect message out the same AERO interface toward Client 1585 ('C2') via Relay ('R1'). 1587 When Relay ('R1') receives the packet and Predirect message, it 1588 consults its forwarding table to discover Server ('S2') as the next 1589 hop toward Client ('C2'). Relay ('R1') then forwards both the packet 1590 and the Predirect message to Server ('S2'), which then forwards them 1591 to Client ('C2'). 1593 After Client ('C2') receives the Predirect message, it process the 1594 message and returns a Redirect message toward Client ('C1') via 1595 Server ('S2'). During the process, Client ('C2') also creates or 1596 updates a dynamic neighbor cache entry for Client ('C1'). 1598 When Server ('S2') receives the Redirect message, it re-encapsulates 1599 the message and forwards it on to Relay ('R1'), which forwards the 1600 message on to Server ('S1') which forwards the message on to Client 1601 ('C1'). After Client ('C1') receives the Redirect message, it 1602 processes the message and creates or updates a dynamic neighbor cache 1603 entry for Client ('C2'). 1605 Following the above Predirect/Redirect message exchange, forwarding 1606 of packets from Client ('C1') to Client ('C2') without involving any 1607 intermediate nodes is enabled. The mechanisms that support this 1608 exchange are specified in the following sections. 1610 3.17.3. Message Format 1612 AERO Redirect/Predirect messages use the same format as for IPv6 ND 1613 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1614 include a new "Prefix Length" field taken from the low-order 8 bits 1615 of the Redirect message Reserved field. For IPv6, valid values for 1616 the Prefix Length field are 0 through 64; for IPv4, valid values are 1617 0 through 32. The Redirect/Predirect messages are formatted as shown 1618 in Figure 8: 1620 0 1 2 3 1621 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 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | Type (=137) | Code (=0/1) | Checksum | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 | Reserved | Prefix Length | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | | 1628 + + 1629 | | 1630 + Target Address + 1631 | | 1632 + + 1633 | | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | | 1636 + + 1637 | | 1638 + Destination Address + 1639 | | 1640 + + 1641 | | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Options ... 1644 +-+-+-+-+-+-+-+-+-+-+-+- 1646 Figure 8: AERO Redirect/Predirect Message Format 1648 3.17.4. Sending Predirects 1650 When a Client forwards a packet with a source address from one of its 1651 ACPs toward a destination address covered by an ASP (i.e., toward 1652 another AERO Client connected to the same AERO link), the source 1653 Client MAY send a Predirect message forward toward the destination 1654 Client via the Server. 1656 In the reference operational scenario, when Client ('C1') forwards a 1657 packet toward Client ('C2'), it MAY also send a Predirect message 1658 forward toward Client ('C2'), subject to rate limiting (see 1659 Section 8.2 of [RFC4861]). Client ('C1') prepares the Predirect 1660 message as follows: 1662 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1663 layer address of Client ('C1')). 1665 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1666 link-layer address of Server ('S1')). 1668 o the network-layer source address is set to fe80::2001:db8:0:0 1669 (i.e., the AERO address of Client ('C1')). 1671 o the network-layer destination address is set to fe80::2001:db8:1:0 1672 (i.e., the AERO address of Client ('C2')). 1674 o the Type is set to 137. 1676 o the Code is set to 1 to indicate "Predirect". 1678 o the Prefix Length is set to the length of the prefix to be 1679 assigned to the Target Address. 1681 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1682 address of Client ('C1')). 1684 o the Destination Address is set to the source address of the 1685 originating packet that triggered the Predirection event. (If the 1686 originating packet is an IPv4 packet, the address is constructed 1687 in IPv4-mapped IPv6 address format). 1689 o the message includes one or more TLLAOs set to appropriate values 1690 for Client ('C1')'s underlying interfaces, and with UDP Port 1691 Number and IP Address set to 0'. 1693 o the message SHOULD include a Timestamp option and a Nonce option. 1695 o the message includes a Redirected Header Option (RHO) that 1696 contains the originating packet truncated if necessary to ensure 1697 that at least the network-layer header is included but the size of 1698 the message does not exceed 1280 bytes. 1700 Note that the act of sending Predirect messages is cited as "MAY", 1701 since Client ('C1') may have advanced knowledge that the direct path 1702 to Client ('C2') would be unusable or otherwise undesirable. If the 1703 direct path later becomes unusable after the initial route 1704 optimization, Client ('C1') simply allows packets to again flow 1705 through Server ('S1'). 1707 3.17.5. Re-encapsulating and Relaying Predirects 1709 When Server ('S1') receives a Predirect message from Client ('C1'), 1710 it first verifies that the TLLAOs in the Predirect are a proper 1711 subset of the Interface IDs in Client ('C1')'s neighbor cache entry. 1712 If the Client's TLLAOs are not acceptable, Server ('S1') discards the 1713 message. Otherwise, Server ('S1') validates the message according to 1714 the Redirect message validation rules in Section 8.1 of [RFC4861], 1715 except that the Predirect has Code=1. Server ('S1') also verifies 1716 that Client ('C1') is authorized to use the Prefix Length in the 1717 Predirect when applied to the AERO address in the network-layer 1718 source address by searching for the AERO address in the neighbor 1719 cache. If validation fails, Server ('S1') discards the Predirect; 1720 otherwise, it copies the correct UDP Port numbers and IP Addresses 1721 for Client ('C1')'s links into the (previously empty) TLLAOs. 1723 Server ('S1') then examines the network-layer destination address of 1724 the Predirect to determine the next hop toward Client ('C2') by 1725 searching for the AERO address in the neighbor cache. Since Client 1726 ('C2') is not one of its neighbors, Server ('S1') re-encapsulates the 1727 Predirect and relays it via Relay ('R1') by changing the link-layer 1728 source address of the message to 'L2(S1)' and changing the link-layer 1729 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1730 re-encapsulated message to Relay ('R1') without decrementing the 1731 network-layer TTL/Hop Limit field. 1733 When Relay ('R1') receives the Predirect message from Server ('S1') 1734 it determines that Server ('S2') is the next hop toward Client ('C2') 1735 by consulting its forwarding table. Relay ('R1') then re- 1736 encapsulates the Predirect while changing the link-layer source 1737 address to 'L2(R1)' and changing the link-layer destination address 1738 to 'L2(S2)'. Relay ('R1') then relays the Predirect via Server 1739 ('S2'). 1741 When Server ('S2') receives the Predirect message from Relay ('R1') 1742 it determines that Client ('C2') is a neighbor by consulting its 1743 neighbor cache. Server ('S2') then re-encapsulates the Predirect 1744 while changing the link-layer source address to 'L2(S2)' and changing 1745 the link-layer destination address to 'L2(C2)'. Server ('S2') then 1746 forwards the message to Client ('C2'). 1748 3.17.6. Processing Predirects and Sending Redirects 1750 When Client ('C2') receives the Predirect message, it accepts the 1751 Predirect only if the message has a link-layer source address of one 1752 of its Servers (e.g., L2(S2)). Client ('C2') further accepts the 1753 message only if it is willing to serve as a redirection target. 1754 Next, Client ('C2') validates the message according to the Redirect 1755 message validation rules in Section 8.1 of [RFC4861], except that it 1756 accepts the message even though Code=1 and even though the network- 1757 layer source address is not that of it's current first-hop router. 1759 In the reference operational scenario, when Client ('C2') receives a 1760 valid Predirect message, it either creates or updates a dynamic 1761 neighbor cache entry that stores the Target Address of the message as 1762 the network-layer address of Client ('C1') , stores the link-layer 1763 addresses found in the TLLAOs as the link-layer addresses of Client 1764 ('C1') and stores the Prefix Length as the length to be applied to 1765 the network-layer address for forwarding purposes. Client ('C2') 1766 then sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1768 After processing the message, Client ('C2') prepares a Redirect 1769 message response as follows: 1771 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1772 layer address of Client ('C2')). 1774 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1775 link-layer address of Server ('S2')). 1777 o the network-layer source address is set to fe80::2001:db8:1:0 1778 (i.e., the AERO address of Client ('C2')). 1780 o the network-layer destination address is set to fe80::2001:db8:0:0 1781 (i.e., the AERO address of Client ('C1')). 1783 o the Type is set to 137. 1785 o the Code is set to 0 to indicate "Redirect". 1787 o the Prefix Length is set to the length of the prefix to be applied 1788 to the Target Address. 1790 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1791 address of Client ('C2')). 1793 o the Destination Address is set to the destination address of the 1794 originating packet that triggered the Redirection event. (If the 1795 originating packet is an IPv4 packet, the address is constructed 1796 in IPv4-mapped IPv6 address format). 1798 o the message includes one or more TLLAOs set to appropriate values 1799 for Client ('C2')'s underlying interfaces, and with UDP Port 1800 Number and IP Address set to '0'. 1802 o the message SHOULD include a Timestamp option and MUST echo the 1803 Nonce option received in the Predirect (i.e., if a Nonce option is 1804 included). 1806 o the message includes as much of the RHO copied from the 1807 corresponding Predirect message as possible such that at least the 1808 network-layer header is included but the size of the message does 1809 not exceed 1280 bytes. 1811 After Client ('C2') prepares the Redirect message, it sends the 1812 message to Server ('S2'). 1814 3.17.7. Re-encapsulating and Relaying Redirects 1816 When Server ('S2') receives a Redirect message from Client ('C2'), it 1817 first verifies that the TLLAOs in the Redirect are a proper subset of 1818 the Interface IDs in Client ('C2')'s neighbor cache entry. If the 1819 Client's TLLAOs are not acceptable, Server ('S2') discards the 1820 message. Otherwise, Server ('S2') validates the message according to 1821 the Redirect message validation rules in Section 8.1 of [RFC4861]. 1822 Server ('S2') also verifies that Client ('C2') is authorized to use 1823 the Prefix Length in the Redirect when applied to the AERO address in 1824 the network-layer source address by searching for the AERO address in 1825 the neighbor cache. If validation fails, Server ('S2') discards the 1826 Redirect; otherwise, it copies the correct UDP Port numbers and IP 1827 Addresses for Client ('C2')'s links into the (previously empty) 1828 TLLAOs. 1830 Server ('S2') then examines the network-layer destination address of 1831 the Redirect to determine the next hop toward Client ('C1') by 1832 searching for the AERO address in the neighbor cache. Since Client 1833 ('C1') is not a neighbor, Server ('S2') re-encapsulates the Redirect 1834 and relays it via Relay ('R1') by changing the link-layer source 1835 address of the message to 'L2(S2)' and changing the link-layer 1836 destination address to 'L2(R1)'. Server ('S2') finally forwards the 1837 re-encapsulated message to Relay ('R1') without decrementing the 1838 network-layer TTL/Hop Limit field. 1840 When Relay ('R1') receives the Redirect message from Server ('S2') it 1841 determines that Server ('S1') is the next hop toward Client ('C1') by 1842 consulting its forwarding table. Relay ('R1') then re-encapsulates 1843 the Redirect while changing the link-layer source address to 'L2(R1)' 1844 and changing the link-layer destination address to 'L2(S1)'. Relay 1845 ('R1') then relays the Redirect via Server ('S1'). 1847 When Server ('S1') receives the Redirect message from Relay ('R1') it 1848 determines that Client ('C1') is a neighbor by consulting its 1849 neighbor cache. Server ('S1') then re-encapsulates the Redirect 1850 while changing the link-layer source address to 'L2(S1)' and changing 1851 the link-layer destination address to 'L2(C1)'. Server ('S1') then 1852 forwards the message to Client ('C1'). 1854 3.17.8. Processing Redirects 1856 When Client ('C1') receives the Redirect message, it accepts the 1857 message only if it has a link-layer source address of one of its 1858 Servers (e.g., ''L2(S1)'). Next, Client ('C1') validates the message 1859 according to the Redirect message validation rules in Section 8.1 of 1860 [RFC4861], except that it accepts the message even though the 1861 network-layer source address is not that of it's current first-hop 1862 router. Following validation, Client ('C1') then processes the 1863 message as follows. 1865 In the reference operational scenario, when Client ('C1') receives 1866 the Redirect message, it either creates or updates a dynamic neighbor 1867 cache entry that stores the Target Address of the message as the 1868 network-layer address of Client ('C2'), stores the link-layer 1869 addresses found in the TLLAOs as the link-layer addresses of Client 1870 ('C2') and stores the Prefix Length as the length to be applied to 1871 the network-layer address for forwarding purposes. Client ('C1') 1872 then sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 1874 Now, Client ('C1') has a neighbor cache entry with a valid 1875 ForwardTime value, while Client ('C2') has a neighbor cache entry 1876 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 1877 ordinary network-layer data packets directly to Client ('C2') without 1878 involving any intermediate nodes, and Client ('C2') can verify that 1879 the packets came from an acceptable source. (In order for Client 1880 ('C2') to forward packets to Client ('C1'), a corresponding 1881 Predirect/Redirect message exchange is required in the reverse 1882 direction; hence, the mechanism is asymmetric.) 1884 3.17.9. Server-Oriented Redirection 1886 In some environments, the Server nearest the target Client may need 1887 to serve as the redirection target, e.g., if direct Client-to-Client 1888 communications are not possible. In that case, the Server prepares 1889 the Redirect message the same as if it were the destination Client 1890 (see: Section 3.17.6), except that it writes its own link-layer 1891 address in the TLLAO option. The Server must then maintain a dynamic 1892 neighbor cache entry for the redirected source Client. 1894 3.17.10. Route Optimization Policy 1896 Although the Client is responsible for initiating route optimization 1897 through the transmission of Predirect messages, the Server is the 1898 policy enforcement point that determines whether route optimization 1899 is permitted. For example, on some AERO links route optimization 1900 would allow traffic to circumvent critical network-based traffic 1901 interception points. In those cases, the Server can deny route 1902 optimization requests by simply discarding any Predirect messages 1903 instead of forwarding them. 1905 3.17.11. Route Optimization and Multiple ACPs 1907 Clients that receive multiple non-contiguous ACP delegations must 1908 perform route optimization for each of the individual ACPs based on 1909 demand of traffic with source addresses taken from those prefixes. 1910 For example, if Client C1 has already performed route optimization 1911 for destination ACP X on behalf of its source ACP Y, it must also 1912 perform route optimization for X on behalf of its source ACP Z. As a 1913 result, source route optimization state cannot be shared between non- 1914 contiguous ACPs and must be managed separately. 1916 3.18. Neighbor Unreachability Detection (NUD) 1918 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1919 unicast NS messages to elicit solicited NA messages from neighbors 1920 the same as described in [RFC4861]. NUD is performed either 1921 reactively in response to persistent L2 errors (see Section 3.14) or 1922 proactively to test existing neighbor cache entries. 1924 When an AERO node sends an NS/NA message, it MUST use its link-local 1925 address as the IPv6 source address and the link-local address of the 1926 neighbor as the IPv6 destination address. When an AERO node receives 1927 an NS message or a solicited NA message, it accepts the message if it 1928 has a neighbor cache entry for the neighbor; otherwise, it ignores 1929 the message. 1931 When a source Client is redirected to a target Client it SHOULD 1932 proactively test the direct path by sending an initial NS message to 1933 elicit a solicited NA response. While testing the path, the source 1934 Client can optionally continue sending packets via the Server, 1935 maintain a small queue of packets until target reachability is 1936 confirmed, or (optimistically) allow packets to flow directly to the 1937 target. The source Client SHOULD thereafter continue to test the 1938 direct path to the target Client (see Section 7.3 of [RFC4861]) 1939 periodically in order to keep dynamic neighbor cache entries alive. 1941 In particular, while the source Client is actively sending packets to 1942 the target Client it SHOULD also send NS messages separated by 1943 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 1944 If the source Client is unable to elicit a solicited NA response from 1945 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 1946 to 0 and resume sending packets via one of its Servers. Otherwise, 1947 the source Client considers the path usable and SHOULD thereafter 1948 process any link-layer errors as a hint that the direct path to the 1949 target Client has either failed or has become intermittent. 1951 When ForwardTime for a dynamic neighbor cache entry expires, the 1952 source Client resumes sending any subsequent packets via a Server and 1953 may (eventually) attempt to re-initiate the AERO redirection process. 1954 When AcceptTime for a dynamic neighbor cache entry expires, the 1955 target Client discards any subsequent packets received directly from 1956 the source Client. When both ForwardTime and AcceptTime for a 1957 dynamic neighbor cache entry expire, the Client deletes the neighbor 1958 cache entry. 1960 3.19. Mobility Management 1962 3.19.1. Announcing Link-Layer Address Changes 1964 When a Client needs to change its link-layer address, e.g., due to a 1965 mobility event, it issues an immediate Rebind to each of its Servers 1966 using the new link-layer address as the source address and with an 1967 ACLLAO that includes the updated client link-layer information. If 1968 authentication succeeds, the Server then updates its neighbor cache 1969 and sends a Reply. Note that if the Client does not issue a Rebind 1970 before the PD lifetime expires (e.g., if the Client has been out of 1971 touch with the Server for a considerable amount of time), the 1972 Server's Reply will report NoBinding and the Client must re-initiate 1973 the DHCPv6 PD procedure. 1975 Next, the Client sends Predirect messages to each of its 1976 correspondent Client neighbors using the same procedures as specified 1977 in Section 3.17.4. The Client sends the Predirect messages via a 1978 Server the same as if it was performing the initial route 1979 optimization procedure with the correspondent. The Predirect message 1980 will update the correspondent's link layer address mapping for the 1981 Client. 1983 3.19.2. Bringing New Links Into Service 1985 When a Client needs to bring a new underlying interface into service 1986 (e.g., when it activates a new data link), it issues an immediate 1987 Rebind to each of its Servers using the new link-layer address as the 1988 source address and with an ACLLAO that includes the new client link- 1989 layer information. If authentication succeeds, the Server then 1990 updates its neighbor cache and sends a Reply. The Client MAY then 1991 send Predirect messages to each of its correspondent Clients to 1992 inform them of the new link-layer address as described in 1993 Section 3.19.1. 1995 3.19.3. Removing Existing Links from Service 1997 When a Client needs to remove an existing underlying interface from 1998 service (e.g., when it de-activates an existing data link), it issues 1999 an immediate Rebind to each of its Servers over any available link 2000 with an ACLLAO that includes P(i) values set to "disabled". If 2001 authentication succeeds, the Server then updates its neighbor cache 2002 and sends a Reply. The Client SHOULD then send Predirect messages to 2003 each of its correspondent Clients to inform them of the deprecated 2004 link-layer address as described in Section 3.19.1. 2006 3.19.4. Implicit Mobility Management 2008 AERO Clients and Servers MAY include a configuration knob that allows 2009 them to perform implicit mobility management in which no DHCPv6 2010 messaging is used. In that case, the Client only transmits packets 2011 over a single interface at a time, and the Server always observes 2012 packets arriving from the Client from the same link-layer source 2013 address. 2015 If the Client's underlying interface address changes (either due to a 2016 readdressing of the original interface or switching to a new 2017 interface) the Server immediately updates the neighbor cache entry 2018 for the Client and begins accepting and sending packets to the 2019 Client's new link-layer address. This implicit mobility method 2020 applies to use cases such as cellphones with both WiFi and Cellular 2021 interfaces where only one of the interfaces is active at a given 2022 time, and the Client automatically switches over to the backup 2023 interface if the primary interface fails. 2025 3.19.5. Moving to a New Server 2027 When a Client associates with a new Server, it performs the Client 2028 procedures specified in Section 3.15.2. 2030 When a Client disassociates with an existing Server, it sends a 2031 Release message via a new Server to the unicast link-local network 2032 layer address of the old Server. The new Server then writes its own 2033 link-layer address in the Release message IP source address and 2034 forwards the message to the old Server. 2036 When the old Server receives the Release, it first authenticates the 2037 message. Next, it resets the Client's neighbor cache entry lifetime 2038 to 3 seconds, rewrites the link-layer address in the neighbor cache 2039 entry to the address of the new Server, then returns a Reply message 2040 to the Client via the old Server. When the lifetime expires, the old 2041 Server withdraws the IP route from the AERO routing system and 2042 deletes the neighbor cache entry for the Client. The Client can then 2043 use the Reply message to verify that the termination signal has been 2044 processed, and can delete both the default route and the neighbor 2045 cache entry for the old Server. (Note that since Release/Reply 2046 messages may be lost in the network the Client SHOULD retry until it 2047 gets a Reply indicating that the Release was successful. If the 2048 Client does not receive a Reply after MAX_RETRY attempts, the old 2049 Server may have failed and the Client should discontinue its Release 2050 attempts.) 2052 Clients SHOULD NOT move rapidly between Servers in order to avoid 2053 causing excessive oscillations in the AERO routing system. Such 2054 oscillations could result in intermittent reachability for the Client 2055 itself, while causing little harm to the network. Examples of when a 2056 Client might wish to change to a different Server include a Server 2057 that has gone unreachable, topological movements of significant 2058 distance, etc. 2060 3.19.6. Packet Queueing for Mobility 2062 AERO Clients and Servers should maintain a samll queue of packets 2063 they have recently sent to an AERO neighbor, e.g., a 1 second window. 2064 If the AERO neighbor moves, the AERO node MAY retransmit the queued 2065 packets to ensure that they are delviered to the AERO neighbor's new 2066 location. 2068 Note that this may have performance implications for asymmetric 2069 paths. For example, if the AERO neighbor moves from a 50mbps link to 2070 a 128kbps link, retransmitting a 1 second window could cause 2071 significant congestion. However, any retransmission bursts will 2072 subside after the 1 second window. 2074 3.20. Proxy AERO 2076 Proxy Mobile IPv6 (PMIPv6) [RFC5213][RFC5844][RFC5949] presents a 2077 network-based localized mobility management scheme for use within an 2078 access network domain. It is typically used in WiFi and cellular 2079 wireless access networks, and allows Mobile Nodes (MNs) to receive 2080 and retain an IP address that remains stable within the access 2081 network domain without needing to implement any special mobility 2082 protocols. In the PMIPv6 architecture, access network devices known 2083 as Mobility Access Gateways (MAGs) provide MNs with an access link 2084 abstraction and receive prefixes for the MNs from a Local Mobility 2085 Anchor (LMA). 2087 In a proxy AERO domain, a proxy AERO Client (acting as a MAG) can 2088 similarly provide proxy services for MNs that do not participate in 2089 AERO messaging. The proxy Client presents an access link abstraction 2090 to MNs, and performs DHCPv6 PD exchanges over the AERO interface with 2091 an AERO Server (acting as an LMA) to receive ACPs for address 2092 provisioning of new MNs that come onto an access link. This scheme 2093 assumes that proxy Clients act as fixed (non-mobile) infrastructure 2094 elements under the same administrative trust basis as for Relays and 2095 Servers. 2097 When an MN comes onto an access link within a proxy AERO domain for 2098 the first time, the proxy Client authenticates the MN and obtains a 2099 unique identifier that it can use as a DHCPv6 DUID then sends a 2100 Solicit message to its Server. When the Server delegates an ACP and 2101 returns a Reply, the proxy Client creates an AERO address for the MN 2102 and assigns the ACP to the MN's access link. The proxy Client then 2103 configures itself as a default router for the MN and provides address 2104 autoconfiguration services (e.g., SLAAC, DHCPv6, DHCPv4, etc.) for 2105 provisioning MN addresses from the ACP over the access link. Since 2106 the proxy Client may serve many such MNs simultaneously, it may 2107 receive multiple ACP delegations and configure multiple AERO 2108 addresses, i.e., one for each MN. 2110 When two MNs are associated with the same proxy Client, the Client 2111 can forward traffic between the MNs without involving a Server since 2112 it configures the AERO addresses of both MNs and therefore also has 2113 the necessary routing information. When two MNs are associated with 2114 different proxy Clients, the source MN's Client can initiate standard 2115 AERO link route optimization to discover a direct path to the target 2116 MN's Client through the exchange of Predirect/Redirect messages. 2118 When an MN in a proxy AERO domain leaves an access link provided by 2119 an old proxy Client, the MN issues an access link-specific "leave" 2120 message that informs the old Client of the link-layer address of a 2121 new Client on the planned new access link. This is known as a 2122 "predictive handover". When an MN comes onto an access link provided 2123 by a new proxy Client, the MN issues an access link-specific "join" 2124 message that informs the new Client of the link-layer address of the 2125 old Client on the actual old access link. This is known as a 2126 "reactive handover". 2128 Upon receiving a predictive handover indication, the old proxy Client 2129 sends a Solicit message directly to the new Client and queues any 2130 arriving data packets addressed to the departed MN. The Solicit 2131 message includes the MN's ID as the DUID, the ACP in an IA_PD option, 2132 the old Client's address as the link-layer source address and the new 2133 Client's address as the link-layer destination address. When the new 2134 Client receives the Solicit message, it changes the link-layer source 2135 address to its own address, changes the link-layer destination 2136 address to the address of its Server, and forwards the message to the 2137 Server. At the same time, the new Client creates access link state 2138 for the ACP in anticipation of the MN's arrival (while queuing any 2139 data packets until the MN arrives), creates a neighbor cache entry 2140 for the old Client with AcceptTime set to ACCEPT_TIME, then sends a 2141 Redirect message back to the old Client. When the old Client 2142 receives the Redirect message, it creates a neighbor cache entry for 2143 the new Client with ForwardTime set to FORWARD_TIME, then forwards 2144 any queued data packets to the new Client. At the same time, the old 2145 Client sends a Release message to its Server. Finally, the old 2146 Client sends unsolicited Redirect messages to any of the ACP's 2147 correspondents with a TLLAO containing the link-layer address of the 2148 new Client. 2150 Upon receiving a reactive handover indication, the new proxy Client 2151 creates access link state for the MN's ACP, sends a Solicit message 2152 to its Server, and sends a Release message directly to the old 2153 Client. The Release message includes the MN's ID as the DUID, the 2154 ACP in an IA_PD option, the new Client's address as the link-layer 2155 source address and the old Client's address as the link-layer 2156 destination address. When the old Client receives the Release 2157 message, it changes the link-layer source address to its own address, 2158 changes the link-layer destination address to the address of its 2159 Server, and forwards the message to the Server. At the same time, 2160 the old Client sends a Predirect message back to the new Client and 2161 queues any arriving data packets addressed to the departed MN. When 2162 the new Client receives the Predirect, it creates a neighbor cache 2163 entry for the old Client with AcceptTime set to ACCEPT_TIME, then 2164 sends a Redirect message back to the old Client. When the old Client 2165 receives the Redirect message, it creates a neighbor cache entry for 2166 the new Client with ForwardTime set to FORWARD_TIME, then forwards 2167 any queued data packets to the new Client. Finally, the old Client 2168 sends unsolicited Redirect messages to correspondents the same as for 2169 the predictive case. 2171 When a Server processes a Solicit message, it creates a neighbor 2172 cache entry for this ACP if none currently exists. If a neighbor 2173 cache entry already exists, however, the Server changes the link- 2174 layer address to the address of the new proxy Client (this satisfies 2175 the case of both the old Client and new Client using the same 2176 Server). 2178 When a Server processes a Release message, it resets the neighbor 2179 cache entry lifetime for this ACP to 3 seconds if the cached link- 2180 layer address matches the old proxy Client's address. Otherwise, the 2181 Server ignores the Release message (this satisfies the case of both 2182 the old Client and new Client using the same Server). 2184 When a correspondent Client receives an unsolicited Redirect message, 2185 it changes the link-layer address for the ACP's neighbor cache entry 2186 to the address of the new proxy Client. 2188 From an architectural perspective, in addition to the use of DHCPv6 2189 PD and IPv6 ND signaling the AERO approach differs from PMIPv6 in its 2190 use of the NBMA virtual link model instead of point-to-point tunnels. 2191 This provides a more agile interface for Client/Server and Client/ 2192 Client coordinations, and also facilitates simple route optimization. 2193 The AERO routing system is also arranged in such a fashion that 2194 Clients get the same service from any Server they happen to associate 2195 with. This provides a natural fault tolerance and load balancing 2196 capability such as desired for distributed mobility management. 2198 3.21. Extending AERO Links Through Security Gateways 2200 When an enterprise mobile device moves from a campus LAN connection 2201 to a public Internet link, it must re-enter the enterprise via a 2202 security gateway that has both a physical interface connection to the 2203 Internet and a physical interface connection to the enterprise 2204 internetwork. This most often entails the establishment of a Virtual 2205 Private Network (VPN) link over the public Internet from the mobile 2206 device to the security gateway. During this process, the mobile 2207 device supplies the security gateway with its public Internet address 2208 as the link-layer address for the VPN. The mobile device then acts 2209 as an AERO Client to negotiate with the security gateway to obtain 2210 its ACP. 2212 In order to satisfy this need, the security gateway also operates as 2213 an AERO Server with support for AERO Client proxying. In particular, 2214 when a mobile device (i.e., the Client) connects via the security 2215 gateway (i.e., the Server), the Server provides the Client with an 2216 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2217 enterprise campus access link. The Server then replaces the Client's 2218 link-layer source address with the Server's enterprise-facing link- 2219 layer address in all AERO messages the Client sends toward neighbors 2220 on the AERO link. The AERO messages are then delivered to other 2221 devices on the AERO link as if they were originated by the security 2222 gateway instead of by the AERO Client. In the reverse direction, the 2223 AERO messages sourced by devices within the enterprise network can be 2224 forwarded to the security gateway, which then replaces the link-layer 2225 destination address with the Client's link-layer address and replaces 2226 the link-layer source address with its own (Internet-facing) link- 2227 layer address. 2229 After receiving the ACP, the Client can send IP packets that use an 2230 address taken from the ACP as the network layer source address, the 2231 Client's link-layer address as the link-layer source address, and the 2232 Server's Internet-facing link-layer address as the link-layer 2233 destination address. The Server will then rewrite the link-layer 2234 source address with the Server's own enterprise-facing link-layer 2235 address and rewrite the link-layer destination address with the 2236 target AERO node's link-layer address, and the packets will enter the 2237 enterprise network as though they were sourced from a device located 2238 within the enterprise. In the reverse direction, when a packet 2239 sourced by a node within the enterprise network uses a destination 2240 address from the Client's ACP, the packet will be delivered to the 2241 security gateway which then rewrites the link-layer destination 2242 address to the Client's link-layer address and rewrites the link- 2243 layer source address to the Server's Internet-facing link-layer 2244 address. The Server then delivers the packet across the VPN to the 2245 AERO Client. In this way, the AERO virtual link is essentially 2246 extended *through* the security gateway to the point at which the VPN 2247 link and AERO link are effectively grafted together by the link-layer 2248 address rewriting performed by the security gateway. All AERO 2249 messaging services (including route optimization and mobility 2250 signaling) are therefore extended to the Client. 2252 In order to support this virtual link grafting, the security gateway 2253 (acting as an AERO Server) must keep static neighbor cache entries 2254 for all of its associated Clients located on the public Internet. 2255 The neighbor cache entry is keyed by the AERO Client's AERO address 2256 the same as if the Client were located within the enterprise 2257 internetwork. The neighbor cache is then managed in all ways as 2258 though the Client were an ordinary AERO Client. This includes the 2259 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2260 Unreachability Detection. 2262 Note that the main difference between a security gateway acting as an 2263 AERO Server and an enterprise-internal AERO Server is that the 2264 security gateway has at least one enterprise-internal physical 2265 interface and at least one public Internet physical interface. 2266 Conversely, the enterprise-internal AERO Server has only enterprise- 2267 internal physical interfaces. For this reason security gateway 2268 proxying is needed to ensure that the public Internet link-layer 2269 addressing space is kept separate from the enterprise-internal link- 2270 layer addressing space. This is afforded through a natural extension 2271 of the security association caching already performed for each VPN 2272 client by the security gateway. 2274 3.22. Extending IPv6 AERO Links to the Internet 2276 When an IPv6 host ('H1') with an address from an ACP owned by AERO 2277 Client ('C1') sends packets to a correspondent IPv6 host ('H2'), the 2278 packets eventually arrive at the IPv6 router that owns ('H2')s 2279 prefix. This IPv6 router may or may not be an AERO Client ('C2') 2280 either within the same home network as ('C1') or in a different home 2281 network. 2283 If Client ('C1') is currently located outside the boundaries of its 2284 home network, it will connect back into the home network via a 2285 security gateway acting as an AERO Server. The packets sent by 2286 ('H1') via ('C1') will then be forwarded through the security gateway 2287 then through the home network and finally to ('C2') where they will 2288 be delivered to ('H2'). This could lead to sub-optimal performance 2289 when ('C2') could instead be reached via a more direct route without 2290 involving the security gateway. 2292 Consider the case when host ('H1') has the IPv6 address 2293 2001:db8:1::1, and Client ('C1') has the ACP 2001:db8:1::/64 with 2294 underlying IPv6 Internet address of 2001:db8:1000::1. Also, host 2295 ('H2') has the IPv6 address 2001:db8:2::1, and Client ('C2') has the 2296 ACP 2001:db8:2::/64 with underlying IPv6 address of 2001:db8:2000::1. 2297 Client ('C1') can determine whether 'C2' is indeed also an AERO 2298 Client willing to serve as a route optimization correspondent by 2299 resolving the AAAA records for the DNS FQDN that matches ('H2')s 2300 prefix, i.e.: 2302 '0.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net' 2304 If ('C2') is indeed a candidate correspondent, the FQDN lookup will 2305 return a PTR resource record that contains the domain name for the 2306 AERO link that manages ('C2')s ASP. Client ('C1') can then attempt 2307 route optimization using an approach similar to the Return 2308 Routability procedure specified for Mobile IPv6 (MIPv6) [RFC6275]. 2309 In order to support this process, both Clients MUST intercept and 2310 decapsulate packets that have a subnet router anycast address 2311 corresponding to any of the /64 prefixes covered by their respective 2312 ACPs. 2314 To initiate the process, Client ('C1') creates a specially-crafted 2315 encapsulated Predirect message that will be routed through its home 2316 network then through ('C2')s home network and finally to ('C2') 2317 itself. Client ('C1') prepares the initial message in the exchange 2318 as follows: 2320 o The encapsulating IPv6 header source address is set to 2321 2001:db8:1:: (i.e., the IPv6 subnet router anycast address for 2322 ('C1')s ACP) 2324 o The encapsulating IPv6 header destination address is set to 2325 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2326 ('C2')s ACP) 2328 o The encapsulating IPv6 header is followed by any additional 2329 encapsulation headers 2331 o The encapsulated IPv6 header source address is set to 2332 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2334 o The encapsulated IPv6 header destination address is set to 2335 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2337 o The encapsulated Predirect message includes all of the securing 2338 information that would occur in a MIPv6 "Home Test Init" message 2339 (format TBD) 2341 Client ('C1') then further encapsulates the message in the 2342 encapsulating headers necessary to convey the packet to the security 2343 gateway (e.g., through IPsec encapsulation) so that the message now 2344 appears "double-encapsulated". ('C1') then sends the message to the 2345 security gateway, which re-encapsulates and forwards it over the home 2346 network from where it will eventually reach ('C2'). 2348 At the same time, ('C1') creates and sends a second encapsulated 2349 Predirect message that will be routed through the IPv6 Internet 2350 without involving the security gateway. Client ('C1') prepares the 2351 message as follows: 2353 o The encapsulating IPv6 header source address is set to 2354 2001:db8:1000:1 (i.e., the Internet IPv6 address of ('C1')) 2356 o The encapsulating IPv6 header destination address is set to 2357 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2358 ('C2')s ACP) 2360 o The encapsulating IPv6 header is followed by any additional 2361 encapsulation headers 2363 o The encapsulated IPv6 header source address is set to 2364 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2366 o The encapsulated IPv6 header destination address is set to 2367 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2369 o The encapsulated Predirect message includes all of the securing 2370 information that would occur in a MIPv6 "Care-of Test Init" 2371 message (format TBD) 2373 ('C2') will receive both Predirect messages through its home network 2374 then return a corresponding Redirect for each of the Predirect 2375 messages with the source and destination addresses in the inner and 2376 outer headers reversed. The first message includes all of the 2377 securing information that would occur in a MIPv6 "Home Test" message, 2378 while the second message includes all of the securing information 2379 that would occur in a MIPv6 "Care-of Test" message (formats TBD). 2381 When ('C1') receives the Redirect messages, it performs the necessary 2382 security procedures per the MIPv6 specification. It then prepares an 2383 encapsulated NS message that includes the same source and destination 2384 addresses as for the "Care-of Test Init" Predirect message, and 2385 includes all of the securing information that would occur in a MIPv6 2386 "Binding Update" message (format TBD) and sends the message to 2387 ('C2'). 2389 When ('C2') receives the NS message, if the securing information is 2390 correct it creates or updates a neighbor cache entry for ('C1') with 2391 fe80::2001:db8:1:0 as the network-layer address, 2001:db8:1000::1 as 2392 the link-layer address and with AcceptTime set to ACCEPT_TIME. 2393 ('C2') then sends an encapsulated NA message back to ('C1') that 2394 includes the same source and destination addresses as for the "Care- 2395 of Test" Redirect message, and includes all of the securing 2396 information that would occur in a MIPv6 "Binding Acknowledgement" 2397 message (format TBD) and sends the message to ('C1'). 2399 When ('C1') receives the NA message, it creates or updates a neighbor 2400 cache entry for ('C2') with fe80::2001:db8:2:0 as the network-layer 2401 address and 2001:db8:2:: as the link-layer address and with 2402 ForwardTime set to FORWARD_TIME, thus completing the route 2403 optimization in the forward direction. 2405 ('C1') subsequently forwards encapsulated packets with outer source 2406 address 2001:db8:1000::1, with outer destination address 2407 2001:db8:2::, with inner source address taken from the 2001:db8:1::, 2408 and with inner destination address taken from 2001:db8:2:: due to the 2409 fact that it has a securely-established neighbor cache entry with 2410 non-zero ForwardTime. ('C2') subsequently accepts any such 2411 encapsulated packets due to the fact that it has a securely- 2412 established neighbor cache entry with non-zero AcceptTime. 2414 In order to keep neighbor cache entries alive, ('C1') periodically 2415 sends additional NS messages to ('C2') and receives any NA responses. 2416 If ('C1') moves to a different point of attachment after the initial 2417 route optimization, it sends a new secured NS message to ('C2') as 2418 above to update ('C2')s neighbor cache. 2420 If ('C2') has packets to send to ('C1'), it performs a corresponding 2421 route optimization in the opposite direction following the same 2422 procedures described above. In the process, the already-established 2423 unidirectional neighbor cache entries within ('C1') and ('C2') are 2424 updated to include the now-bidirectional information. In particular, 2425 the AcceptTime and ForwardTime variables for both neighbor cache 2426 entries are updated to non-zero values, and the link-layer address 2427 for ('C1')s neighbor cache entry for ('C2') is reset to 2428 2001:db8:2000::1. 2430 Note that two AERO Clients can use full security protocol messaging 2431 instead of Return Routability, e.g., if strong authentication and/or 2432 confidentiality are desired. In that case, security protocol key 2433 exchanges such as specified for MOBIKE [RFC4555] would be used to 2434 establish security associations and neighbor cache entries between 2435 the AERO clients. Thereafter, NS/NA messaging can be used to 2436 maintain neighbor cache entries, test reachability, and to announce 2437 mobility events. If reachability testing fails, e.g., if both 2438 Clients move at roughly the same time, the Clients can tear down the 2439 security association and neighbor cache entries and again allow 2440 packets to flow through their home network. 2442 3.23. Operation on AERO Links Without DHCPv6 Services 2444 When Servers on the AERO link do not provide DHCPv6 services, 2445 operation can still be accommodated through administrative 2446 configuration of ACPs on AERO Clients. In that case, administrative 2447 configurations of AERO interface neighbor cache entries on both the 2448 Server and Client are also necessary. However, this may interfere 2449 with the ability for Clients to dynamically change to new Servers, 2450 and can expose the AERO link to misconfigurations unless the 2451 administrative configurations are carefully coordinated. 2453 3.24. Operation on Server-less AERO Links 2455 In some AERO link scenarios, there may be no Servers on the link and/ 2456 or no need for Clients to use a Server as an intermediary trust 2457 anchor. In that case, each Client acts as a Server unto itself to 2458 establish neighbor cache entries by performing direct Client-to- 2459 Client IPv6 ND message exchanges, and some other form of trust basis 2460 must be applied so that each Client can verify that the prospective 2461 neighbor is authorized to use its claimed ACP. 2463 When there is no Server on the link, Clients must arrange to receive 2464 ACPs and publish them via a secure alternate PD authority through 2465 some means outside the scope of this document. 2467 3.25. AERO Operation without DHCPv6 Client/Server Exchanges 2469 In some environments, the AERO service may be useful for mobile nodes 2470 that do not implement the AERO Client function and do not perform 2471 encapsulation. For example, if the mobile node has a way of 2472 injecting its ACP into the access network routing system an AERO 2473 Server connected to the same access network can accept the ACP prefix 2474 injection as an indication that a new mobile node has come onto the 2475 link. The Server can then inject the ACP into the BGP routing system 2476 the same as if an AERO Client/Server DHCPv6 exchange had occurred. 2477 If the mobile node subsequently withdraws the ACP from the access 2478 network routing system, the Server can then withrdaw the ACP from the 2479 BGP routing system. 2481 In this arrangement, AERO Servers and Relays are used in exactly the 2482 same ways as for environments where DHCPv6 Client/Server exchanges 2483 are supported. However, the access network routing systems must be 2484 capable of accommodating rapid ACP injections and withrawls from 2485 mobile nodes with the understanding that the information must be 2486 propagated to all routers in the system. Operational expereince has 2487 shown that this kind of routing system "churn" can lead to overall 2488 instability and inconsistency in the routing system. 2490 3.26. Manually-Configured AERO Tunnels 2492 In addition to the dynamic neighbor discovery procedures for AERO 2493 link neighbors described above, AERO encapsulation can be applied to 2494 manually-configured tunnels. In that case, the tunnel endpoints use 2495 an administratively-assigned link-local address and exchange NS/NA 2496 messages the same as for dynamically-established tunnels. 2498 3.27. Encapsulation Avoidance on Relay-Server Dedicated Links 2500 In some environments, AERO Servers and Relays may be connected by 2501 dedicated point-to-point links, e.g., high speed fiberoptic leased 2502 lines. In that case, the Servers and Relays can participate in the 2503 AERO link the same as specified above but can avoid encapsulation 2504 over the dedicated links. In that case, however, the links would be 2505 dedicated for AERO and could not be multiplexed for both AERO and 2506 non-AERO communications. 2508 3.28. Encapsulation Protocol Version Considerations 2510 A source Client may connect only to an IPvX underlying network, while 2511 the target Client connects only to an IPvY underlying network. In 2512 that case, the target and source Clients have no means for reaching 2513 each other directly (since they connect to underlying networks of 2514 different IP protocol versions) and so must ignore any redirection 2515 messages and continue to send packets via their Servers. 2517 3.29. Multicast Considerations 2519 When the underlying network does not support multicast, AERO Clients 2520 map link-scoped multicast addresses to the link-layer address of a 2521 Server, which acts as a multicast forwarding agent. The AERO Client 2522 also serves as an IGMP/MLD Proxy for its EUNs and/or hosted 2523 applications per [RFC4605] while using the link-layer address of the 2524 Server as the link-layer address for all multicast packets. 2526 When the underlying network supports multicast, AERO nodes use the 2527 multicast address mapping specification found in [RFC2529] for IPv4 2528 underlying networks and use a TBD site-scoped multicast mapping for 2529 IPv6 underlying networks. In that case, border routers must ensure 2530 that the encapsulated site-scoped multicast packets do not leak 2531 outside of the site spanned by the AERO link. 2533 4. Implementation Status 2535 User-level and kernel-level AERO implementations have been developed 2536 and are undergoing internal testing within Boeing. 2538 An initial public release of the AERO source code was announced on 2539 the intarea mailing list on August 21, 2015, and a pointer to the 2540 code is available in the list archives. 2542 5. IANA Considerations 2544 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2545 AERO in the "enterprise-numbers" registry. 2547 The IANA has assigned the UDP port number "8060" for an earlier 2548 experimental version of AERO [RFC6706]. This document obsoletes 2549 [RFC6706] and claims the UDP port number "8060" for all future use. 2551 No further IANA actions are required. 2553 6. Security Considerations 2555 AERO link security considerations are the same as for standard IPv6 2556 Neighbor Discovery [RFC4861] except that AERO improves on some 2557 aspects. In particular, AERO uses a trust basis between Clients and 2558 Servers, where the Clients only engage in the AERO mechanism when it 2559 is facilitated by a trust anchor. 2561 Redirect, Predirect and unsolicited NA messages SHOULD include a 2562 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2563 can use to verify the message time of origin. Predirect, NS and RS 2564 messages SHOULD include a Nonce option (see Section 5.3 of [RFC3971]) 2565 that recipients echo back in corresponding responses. 2567 AERO links must be protected against link-layer address spoofing 2568 attacks in which an attacker on the link pretends to be a trusted 2569 neighbor. Links that provide link-layer securing mechanisms (e.g., 2570 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2571 enterprise network wired LANs) provide a first line of defense, 2572 however AERO nodes SHOULD also use DHCPv6 securing services (e.g., 2573 Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6], etc.) for Client 2574 authentication and network admission control. 2576 AERO Clients MUST ensure that their connectivity is not used by 2577 unauthorized nodes on their EUNs to gain access to a protected 2578 network, i.e., AERO Clients that act as routers MUST NOT provide 2579 routing services for unauthorized nodes. (This concern is no 2580 different than for ordinary hosts that receive an IP address 2581 delegation but then "share" the address with unauthorized nodes via 2582 some form of Internet connection sharing.) 2584 AERO Clients, Servers and Relays on the open Internet are suceptible 2585 to the same attack profiles as for any Internet nodes. For this 2586 reason, IP security MUST be used when AERO is employed over 2587 unmanaged/unsecured links using securing mechanisms such as IPsec 2588 [RFC4301], IKE [RFC5996] and/or TLS [RFC5246]. 2590 AERO Servers and Relays present targets for traffic amplification 2591 Denial of Service (DoS) attacks. This concern is no different than 2592 for widely-deployed VPN security gateways in the Internet, where 2593 attackers could send spoofed packets to the gateways at high data 2594 rates. This becomes less of a problem when Relays and Servers are 2595 connected by dedicated links with no connections to the Internet and/ 2596 or when connections to the Internet asre only permitted through well- 2597 managed firewalls. 2599 Traffic amplfication DoS attacks can also target an AERO Client's low 2600 data rate links. This is a concern not only for Clients located on 2601 the open Internet but also for Clients in protected enclaves. AERO 2602 Servers can institute rate limits that protect Clients from receiving 2603 packet floods that could DoS low data rate links. 2605 7. Acknowledgements 2607 Discussions both on IETF lists and in private exchanges helped shape 2608 some of the concepts in this work. Individuals who contributed 2609 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, 2610 Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, Adrian 2611 Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom Herbert, 2612 Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, 2613 Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2614 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. 2615 Members of the IESG also provided valuable input during their review 2616 process that greatly improved the document. Discussions on the v6ops 2617 list in the December 2015 through January 2016 timeframe further 2618 helped clarify AERO multi-addressing capabilities. Special thanks go 2619 to Stewart Bryant, Joel Halpern and Brian Haberman for their 2620 shepherding guidance during the publication of the AERO first 2621 edition. 2623 This work has further been encouraged and supported by Boeing 2624 colleagues including M. Wayne Benson, Dave Bernhardt, Cam Brodie, 2625 Balaguruna Chidambaram, Irene Chin, Bruce Cornish, Claudiu Danilov, 2626 Wen Fang, Anthony Gregory, Jeff Holland, Ed King, Gen MacLean, Rob 2627 Muszkiewicz, Sean O'Sullivan, Kent Shuey, Brian Skeen, Mike Slane, 2628 Brendan Williams, Julie Wulff, Yueli Yang, and other members of the 2629 BR&T and BIT mobile networking teams. Wayne Benson is especially 2630 acknowledged for his outstanding work in converting the AERO proof- 2631 of-concept implementation into production-ready code. 2633 Earlier works on NBMA tunneling approaches are found in 2634 [RFC2529][RFC5214][RFC5569]. 2636 Many of the constructs presented in this second edition of AERO are 2637 based on the author's earlier works, including: 2639 o The Internet Routing Overlay Network (IRON) 2640 [RFC6179][I-D.templin-ironbis] 2642 o Virtual Enterprise Traversal (VET) 2643 [RFC5558][I-D.templin-intarea-vet] 2645 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2646 [RFC5320][I-D.templin-intarea-seal] 2648 o AERO, First Edition [RFC6706] 2649 Note that these works cite numerous earlier efforts that are not also 2650 cited here due to space limitations. The authors of those earlier 2651 works are acknowledged for their insights. 2653 8. References 2655 8.1. Normative References 2657 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2658 DOI 10.17487/RFC0768, August 1980, 2659 . 2661 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2662 DOI 10.17487/RFC0791, September 1981, 2663 . 2665 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2666 RFC 792, DOI 10.17487/RFC0792, September 1981, 2667 . 2669 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2670 DOI 10.17487/RFC2003, October 1996, 2671 . 2673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2674 Requirement Levels", BCP 14, RFC 2119, 2675 DOI 10.17487/RFC2119, March 1997, 2676 . 2678 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2679 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2680 December 1998, . 2682 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2683 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2684 December 1998, . 2686 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2687 "Definition of the Differentiated Services Field (DS 2688 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2689 DOI 10.17487/RFC2474, December 1998, 2690 . 2692 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2693 C., and M. Carney, "Dynamic Host Configuration Protocol 2694 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2695 2003, . 2697 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2698 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2699 DOI 10.17487/RFC3633, December 2003, 2700 . 2702 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2703 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2704 DOI 10.17487/RFC3971, March 2005, 2705 . 2707 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2708 for IPv6 Hosts and Routers", RFC 4213, 2709 DOI 10.17487/RFC4213, October 2005, 2710 . 2712 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2713 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2714 DOI 10.17487/RFC4861, September 2007, 2715 . 2717 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2718 Address Autoconfiguration", RFC 4862, 2719 DOI 10.17487/RFC4862, September 2007, 2720 . 2722 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2723 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2724 2011, . 2726 8.2. Informative References 2728 [I-D.herbert-gue-fragmentation] 2729 Herbert, T. and F. Templin, "Fragmentation option for 2730 Generic UDP Encapsulation", draft-herbert-gue- 2731 fragmentation-02 (work in progress), October 2015. 2733 [I-D.ietf-dhc-sedhcpv6] 2734 Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. 2735 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-13 (work 2736 in progress), July 2016. 2738 [I-D.ietf-intarea-tunnels] 2739 Touch, D. and W. Townsley, "IP Tunnels in the Internet 2740 Architecture", draft-ietf-intarea-tunnels-03 (work in 2741 progress), July 2016. 2743 [I-D.ietf-nvo3-gue] 2744 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2745 Encapsulation", draft-ietf-nvo3-gue-04 (work in progress), 2746 July 2016. 2748 [I-D.templin-intarea-grefrag] 2749 Templin, F., "GRE Tunnel Level Fragmentation", draft- 2750 templin-intarea-grefrag-04 (work in progress), July 2016. 2752 [I-D.templin-intarea-seal] 2753 Templin, F., "The Subnetwork Encapsulation and Adaptation 2754 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2755 progress), January 2014. 2757 [I-D.templin-intarea-vet] 2758 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2759 templin-intarea-vet-40 (work in progress), May 2013. 2761 [I-D.templin-ironbis] 2762 Templin, F., "The Interior Routing Overlay Network 2763 (IRON)", draft-templin-ironbis-16 (work in progress), 2764 March 2014. 2766 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 2767 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 2768 . 2770 [RFC1035] Mockapetris, P., "Domain names - implementation and 2771 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2772 November 1987, . 2774 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2775 Communication Layers", STD 3, RFC 1122, 2776 DOI 10.17487/RFC1122, October 1989, 2777 . 2779 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2780 DOI 10.17487/RFC1191, November 1990, 2781 . 2783 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2784 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2785 . 2787 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2788 selection, and registration of an Autonomous System (AS)", 2789 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 2790 . 2792 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2793 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2794 1996, . 2796 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2797 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2798 . 2800 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2801 Domains without Explicit Tunnels", RFC 2529, 2802 DOI 10.17487/RFC2529, March 1999, 2803 . 2805 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2806 RFC 2675, DOI 10.17487/RFC2675, August 1999, 2807 . 2809 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2810 Malis, "A Framework for IP Based Virtual Private 2811 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2812 . 2814 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2815 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2816 DOI 10.17487/RFC2784, March 2000, 2817 . 2819 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2820 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2821 . 2823 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2824 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2825 . 2827 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2828 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2829 . 2831 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2832 of Explicit Congestion Notification (ECN) to IP", 2833 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2834 . 2836 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2837 "DNS Extensions to Support IP Version 6", RFC 3596, 2838 DOI 10.17487/RFC3596, October 2003, 2839 . 2841 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2842 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2843 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2844 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2845 . 2847 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2848 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2849 DOI 10.17487/RFC4271, January 2006, 2850 . 2852 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2853 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2854 2006, . 2856 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2857 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2858 December 2005, . 2860 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2861 Control Message Protocol (ICMPv6) for the Internet 2862 Protocol Version 6 (IPv6) Specification", RFC 4443, 2863 DOI 10.17487/RFC4443, March 2006, 2864 . 2866 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 2867 Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2868 2006, . 2870 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2871 Protocol (LDAP): The Protocol", RFC 4511, 2872 DOI 10.17487/RFC4511, June 2006, 2873 . 2875 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 2876 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 2877 . 2879 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 2880 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 2881 . 2883 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 2884 "Internet Group Management Protocol (IGMP) / Multicast 2885 Listener Discovery (MLD)-Based Multicast Forwarding 2886 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 2887 August 2006, . 2889 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2890 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 2891 . 2893 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2894 Errors at High Data Rates", RFC 4963, 2895 DOI 10.17487/RFC4963, July 2007, 2896 . 2898 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 2899 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 2900 DOI 10.17487/RFC4994, September 2007, 2901 . 2903 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 2904 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 2905 RFC 5213, DOI 10.17487/RFC5213, August 2008, 2906 . 2908 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2909 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2910 DOI 10.17487/RFC5214, March 2008, 2911 . 2913 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2914 (TLS) Protocol Version 1.2", RFC 5246, 2915 DOI 10.17487/RFC5246, August 2008, 2916 . 2918 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 2919 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 2920 February 2010, . 2922 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 2923 for the Address Resolution Protocol (ARP)", RFC 5494, 2924 DOI 10.17487/RFC5494, April 2009, 2925 . 2927 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2928 Route Optimization Requirements for Operational Use in 2929 Aeronautics and Space Exploration Mobile Networks", 2930 RFC 5522, DOI 10.17487/RFC5522, October 2009, 2931 . 2933 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 2934 RFC 5558, DOI 10.17487/RFC5558, February 2010, 2935 . 2937 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2938 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 2939 January 2010, . 2941 [RFC5720] Templin, F., "Routing and Addressing in Networks with 2942 Global Enterprise Recursion (RANGER)", RFC 5720, 2943 DOI 10.17487/RFC5720, February 2010, 2944 . 2946 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 2947 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 2948 . 2950 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 2951 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 2952 DOI 10.17487/RFC5949, September 2010, 2953 . 2955 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2956 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2957 RFC 5996, DOI 10.17487/RFC5996, September 2010, 2958 . 2960 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2961 NAT64: Network Address and Protocol Translation from IPv6 2962 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2963 April 2011, . 2965 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 2966 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 2967 . 2969 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2970 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 2971 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 2972 . 2974 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2975 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2976 DOI 10.17487/RFC6221, May 2011, 2977 . 2979 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2980 and A. Bierman, Ed., "Network Configuration Protocol 2981 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2982 . 2984 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2985 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2986 2011, . 2988 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2989 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 2990 DOI 10.17487/RFC6355, August 2011, 2991 . 2993 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 2994 RFC 6422, DOI 10.17487/RFC6422, December 2011, 2995 . 2997 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2998 for Equal Cost Multipath Routing and Link Aggregation in 2999 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3000 . 3002 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 3003 RFC 6691, DOI 10.17487/RFC6691, July 2012, 3004 . 3006 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3007 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3008 . 3010 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 3011 RFC 6864, DOI 10.17487/RFC6864, February 2013, 3012 . 3014 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3015 UDP Checksums for Tunneled Packets", RFC 6935, 3016 DOI 10.17487/RFC6935, April 2013, 3017 . 3019 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3020 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3021 RFC 6936, DOI 10.17487/RFC6936, April 2013, 3022 . 3024 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 3025 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 3026 May 2013, . 3028 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 3029 with IPv6 Neighbor Discovery", RFC 6980, 3030 DOI 10.17487/RFC6980, August 2013, 3031 . 3033 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 3034 Address Selection Policy Using DHCPv6", RFC 7078, 3035 DOI 10.17487/RFC7078, January 2014, 3036 . 3038 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 3039 October 2014. 3041 Appendix A. AERO Alternate Encapsulations 3043 When GUE encapsulation is not needed, AERO can use common 3044 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 3045 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 3046 encapsulation is therefore only differentiated from non-AERO tunnels 3047 through the application of AERO control messaging and not through, 3048 e.g., a well-known UDP port number. 3050 As for GUE encapsulation, alternate AERO encapsulation formats may 3051 require encapsulation layer fragmentation. For simple IP-in-IP 3052 encapsulation, an IPv6 fragment header is inserted directly between 3053 the inner and outer IP headers when needed, i.e., even if the outer 3054 header is IPv4. The IPv6 Fragment Header is identified to the outer 3055 IP layer by its IP protocol number, and the Next Header field in the 3056 IPv6 Fragment Header identifies the inner IP header version. For GRE 3057 encapsulation, a GRE fragment header is inserted within the GRE 3058 header [I-D.templin-intarea-grefrag]. 3060 Figure 9 shows the AERO IP-in-IP encapsulation format before any 3061 fragmentation is applied: 3063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3064 | Outer IPv4 Header | | Outer IPv6 Header | 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 | Inner IP Header | | Inner IP Header | 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 | | | | 3071 ~ ~ ~ ~ 3072 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 3073 ~ ~ ~ ~ 3074 | | | | 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 3079 Figure 9: Minimal Encapsulation Format using IP-in-IP 3081 Figure 10 shows the AERO GRE encapsulation format before any 3082 fragmentation is applied: 3084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3085 | Outer IP Header | 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 | GRE Header | 3088 | (with checksum, key, etc..) | 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3090 | GRE Fragment Header (optional)| 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3092 | Inner IP Header | 3093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 | | 3095 ~ ~ 3096 ~ Inner Packet Body ~ 3097 ~ ~ 3098 | | 3099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3101 Figure 10: Minimal Encapsulation Using GRE 3103 Alternate encapsulation may be preferred in environments where GUE 3104 encapsulation would add unnecessary overhead. For example, certain 3105 low-bandwidth wireless data links may benefit from a reduced 3106 encapsulation overhead. 3108 GUE encapsulation can traverse network paths that are inaccessible to 3109 non-UDP encapsulations, e.g., for crossing Network Address 3110 Translators (NATs). More and more, network middleboxes are also 3111 being configured to discard packets that include anything other than 3112 a well-known IP protocol such as UDP and TCP. It may therefore be 3113 necessary to determine the potential for middlebox filtering before 3114 enabling alternate encapsulation in a given environment. 3116 In addition to IP-in-IP, GRE and GUE, AERO can also use security 3117 encapsulations such as IPsec and SSL/TLS. In that case, AERO control 3118 messaging and route determination occur before security encapsulation 3119 is applied for outgoing packets and after security decapsulation is 3120 applied for incoming packets. 3122 Appendix B. When to Insert an Encapsulation Fragment Header 3124 An encapsulation fragment header is inserted when the AERO tunnel 3125 ingress needs to apply fragmentation to accommodate packets that must 3126 be delivered without loss due to a size restriction. Fragmentation 3127 is performed on the inner packet while encapsulating each inner 3128 packet fragment in outer IP and encapsulation layer headers that 3129 differ only in the fragment header fields. 3131 The fragment header can also be inserted in order to include a 3132 coherent Identification value with each packet, e.g., to aid in 3133 Duplicate Packet Detection (DPD). In this way, network nodes can 3134 cache the Identification values of recently-seen packets and use the 3135 cached values to determine whether a newly-arrived packet is in fact 3136 a duplicate. The Identification value within each packet could 3137 further provide a rough indicator of packet reordering, e.g., in 3138 cases when the tunnel egress wishes to discard packets that are 3139 grossly out of order. 3141 In some use cases, there may be operational assurance that no 3142 fragmentation of any kind will be necessary, or that only occasional 3143 large control messages will require fragmentation. In that case, the 3144 encapsulation fragment header can be omitted and ordinary 3145 fragmentation of the outer IP protocol version can be applied when 3146 necessary. 3148 Appendix C. Autoconfiguration for Constrained Platforms 3150 On some platforms (e.g., popular cell phone operating systems), the 3151 act of assigning a default IPv6 route and/or assigning an address to 3152 an interface may not be permitted from a user application due to 3153 security policy. Typically, those platforms include a TUN/TAP 3154 interface [TUNTAP] that acts as a point-to-point conduit between user 3155 applications and the AERO interface. In that case, the Client can 3156 instead generate a "synthesized RA" message. The message conforms to 3157 [RFC4861] and is prepared as follows: 3159 o the IPv6 source address is the Client's AERO address 3161 o the IPv6 destination address is all-nodes multicast 3163 o the Router Lifetime is set to a time that is no longer than the 3164 ACP DHCPv6 lifetime 3166 o the message does not include a Source Link Layer Address Option 3167 (SLLAO) 3169 o the message includes a Prefix Information Option (PIO) with a /64 3170 prefix taken from the ACP as the prefix for autoconfiguration 3172 The Client then sends the synthesized RA message via the TUN/TAP 3173 interface, where the operating system kernel will interpret it as 3174 though it were generated by an actual router. The operating system 3175 will then install a default route and use StateLess Address 3176 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 3177 interface. Methods for similarly installing an IPv4 default route 3178 and IPv4 address on the TUN/TAP interface are based on synthesized 3179 DHCPv4 messages [RFC2131]. 3181 Author's Address 3183 Fred L. Templin (editor) 3184 Boeing Research & Technology 3185 P.O. Box 3707 3186 Seattle, WA 98124 3187 USA 3189 Email: fltemplin@acm.org