idnits 2.17.1 draft-templin-aerolink-65.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 (January 19, 2016) is 3020 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 959, but not defined == Unused Reference: 'RFC0768' is defined on line 2785, but no explicit reference was found in the text == Unused Reference: 'I-D.vandevelde-idr-remote-next-hop' is defined on line 2889, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2894, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 2915, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 3022, but no explicit reference was found in the text == Unused Reference: 'RFC5494' is defined on line 3046, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 3065, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 3084, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 3093, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 3103, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 3112, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 3126, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 3138, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 3143, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 3152, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 3157, 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-10 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-02 == Outdated reference: A later version (-04) exists of draft-templin-intarea-grefrag-01 -- 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 (~~), 22 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, January 19, 2016 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: July 22, 2016 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-65.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, provisioning and mobility 23 are supported by the Dynamic Host Configuration Protocol for IPv6 24 (DHCPv6), and route optimization is naturally supported through 25 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 using standard control messaging exchanges as described in 29 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 July 22, 2016. 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 . . . . . . . . . . . . . . . . . 11 73 3.6. AERO Interface Initialization . . . . . . . . . . . . . . 12 74 3.6.1. AERO Relay Behavior . . . . . . . . . . . . . . . . . 12 75 3.6.2. AERO Server Behavior . . . . . . . . . . . . . . . . 12 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 . . . . . . . . 14 80 3.9. AERO Interface Sending Algorithm . . . . . . . . . . . . 16 81 3.10. AERO Interface Encapsulation and Re-encapsulation . . . . 18 82 3.11. AERO Interface Decapsulation . . . . . . . . . . . . . . 19 83 3.12. AERO Interface Data Origin Authentication . . . . . . . . 19 84 3.13. AERO Interface MTU and Fragmentation . . . . . . . . . . 19 85 3.13.1. All Elements in Same Administrative Domain . . . . . 20 86 3.13.2. Not All Elements in Same Administrative Domain . . . 21 87 3.13.3. Accommodating Large Control Messages . . . . . . . . 22 88 3.13.4. Integrity . . . . . . . . . . . . . . . . . . . . . 23 89 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 24 90 3.15. AERO Router Discovery, Prefix Delegation and Address 91 Configuration . . . . . . . . . . . . . . . . . . . . . . 28 92 3.15.1. AERO DHCPv6 Service Model . . . . . . . . . . . . . 28 93 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 29 94 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 32 95 3.15.4. Deleting Link Registrations . . . . . . . . . . . . 35 97 3.16. AERO Forwarding Agent Behavior . . . . . . . . . . . . . 35 98 3.17. AERO Intradomain Route Optimization . . . . . . . . . . . 36 99 3.17.1. Reference Operational Scenario . . . . . . . . . . . 36 100 3.17.2. Concept of Operations . . . . . . . . . . . . . . . 38 101 3.17.3. Message Format . . . . . . . . . . . . . . . . . . . 38 102 3.17.4. Sending Predirects . . . . . . . . . . . . . . . . . 39 103 3.17.5. Re-encapsulating and Relaying Predirects . . . . . . 40 104 3.17.6. Processing Predirects and Sending Redirects . . . . 41 105 3.17.7. Re-encapsulating and Relaying Redirects . . . . . . 43 106 3.17.8. Processing Redirects . . . . . . . . . . . . . . . . 43 107 3.17.9. Server-Oriented Redirection . . . . . . . . . . . . 44 108 3.17.10. Route Optimization Policy . . . . . . . . . . . . . 44 109 3.17.11. Route Optimization and Multiple ACPs . . . . . . . . 45 110 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 45 111 3.19. Mobility Management . . . . . . . . . . . . . . . . . . . 46 112 3.19.1. Announcing Link-Layer Address Changes . . . . . . . 46 113 3.19.2. Bringing New Links Into Service . . . . . . . . . . 46 114 3.19.3. Removing Existing Links from Service . . . . . . . . 46 115 3.19.4. Moving to a New Server . . . . . . . . . . . . . . . 47 116 3.20. Proxy AERO . . . . . . . . . . . . . . . . . . . . . . . 47 117 3.21. Extending AERO Links Through Security Gateways . . . . . 50 118 3.22. Extending IPv6 AERO Links to the Internet . . . . . . . . 52 119 3.23. Encapsulation Protocol Version Considerations . . . . . . 55 120 3.24. Multicast Considerations . . . . . . . . . . . . . . . . 55 121 3.25. Operation on AERO Links Without DHCPv6 Services . . . . . 56 122 3.26. Operation on Server-less AERO Links . . . . . . . . . . . 56 123 3.27. Manually-Configured AERO Tunnels . . . . . . . . . . . . 56 124 3.28. Intradomain Routing . . . . . . . . . . . . . . . . . . . 56 125 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 56 126 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 127 6. Security Considerations . . . . . . . . . . . . . . . . . . . 57 128 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 129 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 130 8.1. Normative References . . . . . . . . . . . . . . . . . . 59 131 8.2. Informative References . . . . . . . . . . . . . . . . . 61 132 Appendix A. AERO Minimal Encapsulation . . . . . . . . . . . . . 67 133 Appendix B. When to Insert an Encapsulation Fragment Header . . 69 134 Appendix C. AERO Operation Over Native Links . . . . . . . . . . 69 135 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69 137 1. Introduction 139 This document specifies the operation of IP over tunnel virtual links 140 using Asymmetric Extended Route Optimization (AERO). The AERO link 141 can be used for tunneling to neighboring nodes over either IPv6 or 142 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 143 equivalent links for tunneling. Nodes attached to AERO links can 144 exchange packets via trusted intermediate routers that provide 145 forwarding services to reach off-link destinations and redirection 146 services for route optimization [RFC5522]. 148 AERO provides an IPv6 link-local address format known as the AERO 149 address that supports operation of the IPv6 Neighbor Discovery (ND) 150 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 151 control, provisioning and mobility are supported by the Dynamic Host 152 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and route 153 optimization is naturally supported through dynamic neighbor cache 154 updates. Although DHCPv6 and IPv6 ND messaging are used in the 155 control plane, both IPv4 and IPv6 can be used in the data plane. 156 AERO is a widely-applicable tunneling solution using standard control 157 messaging exchanges as described in this document. The remainder of 158 this document presents the AERO specification. 160 2. Terminology 162 The terminology in the normative references applies; the following 163 terms are defined within the scope of this document: 165 AERO link 166 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 167 configured over a node's attached IPv6 and/or IPv4 networks. All 168 nodes on the AERO link appear as single-hop neighbors from the 169 perspective of the virtual overlay. 171 AERO interface 172 a node's attachment to an AERO link. Nodes typically have a 173 single AERO interface; support for multiple AERO interfaces is 174 also possible but out of scope for this document. AERO interfaces 175 do not require Duplicate Address Detection (DAD) and therefore set 176 the administrative variable DupAddrDetectTransmits to zero 177 [RFC4862]. 179 AERO address 180 an IPv6 link-local address constructed as specified in Section 3.3 181 and assigned to a Client's AERO interface. 183 AERO node 184 a node that is connected to an AERO link and that participates in 185 IPv6 ND and DHCPv6 messaging over the link. 187 AERO Client ("Client") 188 a node that issues DHCPv6 messages to receive IP Prefix 189 Delegations (PDs) from one or more AERO Servers. Following PD, 190 the Client assigns an AERO address to the AERO interface for use 191 in IPv6 ND exchanges with other AERO nodes. 193 AERO Server ("Server") 194 a node that configures an AERO interface to provide default 195 forwarding and DHCPv6 services for AERO Clients. The Server 196 assigns an administratively provisioned IPv6 link-local unicast 197 address to support the operation of DHCPv6 and the IPv6 ND 198 protocol. An AERO Server can also act as an AERO Relay. 200 AERO Relay ("Relay") 201 a node that configures an AERO interface to relay IP packets 202 between nodes on the same AERO link and/or forward IP packets 203 between the AERO link and the native Internetwork. The Relay 204 assigns an administratively provisioned IPv6 link-local unicast 205 address to the AERO interface the same as for a Server. An AERO 206 Relay can also act as an AERO Server. 208 AERO Forwarding Agent ("Forwarding Agent") 209 a node that performs data plane forwarding services as a companion 210 to an AERO Server. 212 ingress tunnel endpoint (ITE) 213 an AERO interface endpoint that injects tunneled packets into an 214 AERO link. 216 egress tunnel endpoint (ETE) 217 an AERO interface endpoint that receives tunneled packets from an 218 AERO link. 220 underlying network 221 a connected IPv6 or IPv4 network routing region over which the 222 tunnel virtual overlay is configured. A typical example is an 223 enterprise network, but many other use cases are also in scope. 225 underlying interface 226 an AERO node's interface point of attachment to an underlying 227 network. 229 link-layer address 230 an IP address assigned to an AERO node's underlying interface. 231 When UDP encapsulation is used, the UDP port number is also 232 considered as part of the link-layer address; otherwise, UDP port 233 number is set to the constant value '0'. Link-layer addresses are 234 used as the encapsulation header source and destination addresses. 236 network layer address 237 the source or destination address of the encapsulated IP packet. 239 end user network (EUN) 240 an internal virtual or external edge IP network that an AERO 241 Client connects to the rest of the network via the AERO interface. 243 AERO Service Prefix (ASP) 244 an IP prefix associated with the AERO link and from which AERO 245 Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 246 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 248 AERO Client Prefix (ACP) 249 a more-specific IP prefix taken from an ASP and delegated to a 250 Client. 252 Throughout the document, the simple terms "Client", "Server" and 253 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 254 respectively. Capitalization is used to distinguish these terms from 255 DHCPv6 client/server/relay [RFC3315]. 257 The terminology of [RFC4861] (including the names of node variables 258 and protocol constants) applies to this document. Also throughout 259 the document, the term "IP" is used to generically refer to either 260 Internet Protocol version (i.e., IPv4 or IPv6). 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 264 document are to be interpreted as described in [RFC2119]. Lower case 265 uses of these words are not to be interpreted as carrying RFC2119 266 significance. 268 3. Asymmetric Extended Route Optimization (AERO) 270 The following sections specify the operation of IP over Asymmetric 271 Extended Route Optimization (AERO) links: 273 3.1. AERO Link Reference Model 274 .-(::::::::) 275 .-(:::: IP ::::)-. 276 (:: Internetwork ::) 277 `-(::::::::::::)-' 278 `-(::::::)-' 279 | 280 +--------------+ +--------+-------+ +--------------+ 281 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 282 | Nbr: C1; R1 | | Nbr: S1; S2 | | Nbr: C2; R1 | 283 | default->R1 | |(P1->S1; P2->S2)| | default->R1 | 284 | P1->C1 | | ASP A1 | | P2->C2 | 285 +-------+------+ +--------+-------+ +------+-------+ 286 | | | 287 X---+---+-------------------+------------------+---+---X 288 | AERO Link | 289 +-----+--------+ +--------+-----+ 290 |AERO Client C1| |AERO Client C2| 291 | Nbr: S1 | | Nbr: S2 | 292 | default->S1 | | default->S2 | 293 | ACP P1 | | ACP P2 | 294 +--------------+ +--------------+ 295 .-. .-. 296 ,-( _)-. ,-( _)-. 297 .-(_ IP )-. .-(_ IP )-. 298 (__ EUN ) (__ EUN ) 299 `-(______)-' `-(______)-' 300 | | 301 +--------+ +--------+ 302 | Host H1| | Host H2| 303 +--------+ +--------+ 305 Figure 1: AERO Link Reference Model 307 Figure 1 presents the AERO link reference model. In this model: 309 o Relay R1 aggregates AERO Service Prefix (ASP) A1, acts as a 310 default router for its associated Servers S1 and S2, and connects 311 the AERO link to the rest of the IP Internetwork. 313 o Servers S1 and S2 associate with Relay R1 and also act as default 314 routers for their associated Clients C1 and C2. 316 o Clients C1 and C2 associate with Servers S1 and S2, respectively. 317 They receive AERO Client Prefix (ACP) delegations P1 and P2, and 318 also act as default routers for their associated physical or 319 internal virtual EUNs. (Alternatively, clients can act as multi- 320 addressed hosts without serving any EUNs). 322 o Hosts H1 and H2 attach to the EUNs served by Clients C1 and C2, 323 respectively. 325 Each node maintains a neighbor cache and IP forwarding table. For 326 example, AERO Relay R1 in the diagram has neighbor cache entries for 327 Servers S1 and S2 as well as IP forwarding table entries for the ACPs 328 delegated to Clients C1 and C2. In common operational practice, 329 there may be many additional Relays, Servers and Clients. (Although 330 not shown in the figure, AERO Forwarding Agents may also be provided 331 for data plane forwarding offload services.) 333 3.2. AERO Link Node Types 335 AERO Relays provide default forwarding services to AERO Servers. 336 Relays forward packets between Servers connected to the same AERO 337 link and also forward packets between the AERO link and the native IP 338 Internetwork. Relays present the AERO link to the native 339 Internetwork as a set of one or more AERO Service Prefixes (ASPs) and 340 serve as a gateway between the AERO link and the Internetwork. AERO 341 Relays maintain an AERO interface neighbor cache entry for each AERO 342 Server, and maintain an IP forwarding table entry for each AERO 343 Client Prefix (ACP). AERO Relays can also be configured to act as 344 AERO Servers. 346 AERO Servers provide default forwarding services to AERO Clients. 347 Each Server also peers with each Relay in a dynamic routing protocol 348 instance to advertise its list of associated ACPs. Servers configure 349 a DHCPv6 server function to facilitate Prefix Delegation (PD) 350 exchanges with Clients. Each delegated prefix becomes an ACP taken 351 from an ASP. Servers forward packets between AERO interface 352 neighbors only, i.e., and not between the AERO link and the native IP 353 Internetwork. AERO Servers maintain an AERO interface neighbor cache 354 entry for each AERO Relay. They also maintain both neighbor cache 355 entries and IP forwarding table entries for each of their associated 356 Clients. AERO Servers can also be configured to act as AERO Relays. 358 AERO Clients act as requesting routers to receive ACPs through DHCPv6 359 PD exchanges with AERO Servers over the AERO link. Each Client MAY 360 associate with a single Server or with multiple Servers, e.g., for 361 fault tolerance, load balancing, etc. Each IPv6 Client receives at 362 least a /64 IPv6 ACP, and may receive even shorter prefixes. 363 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 364 singleton IPv4 address), and may receive even shorter prefixes. AERO 365 Clients maintain an AERO interface neighbor cache entry for each of 366 their associated Servers as well as for each of their correspondent 367 Clients. 369 AERO Forwarding Agents provide data plane forwarding services as 370 companions to AERO Servers. Note that while Servers are required to 371 perform both control and data plane operations on their own behalf, 372 they may optionally enlist the services of special-purpose Forwarding 373 Agents to offload data plane traffic. 375 3.3. AERO Addresses 377 An AERO address is an IPv6 link-local address with an embedded ACP 378 and assigned to a Client's AERO interface. The AERO address is 379 formed as follows: 381 fe80::[ACP] 383 For IPv6, the AERO address begins with the prefix fe80::/64 and 384 includes in its interface identifier the base prefix taken from the 385 Client's IPv6 ACP. The base prefix is determined by masking the ACP 386 with the prefix length. For example, if the AERO Client receives the 387 IPv6 ACP: 389 2001:db8:1000:2000::/56 391 it constructs its AERO address as: 393 fe80::2001:db8:1000:2000 395 For IPv4, the AERO address is formed from the lower 64 bits of an 396 IPv4-mapped IPv6 address [RFC4291] that includes the base prefix 397 taken from the Client's IPv4 ACP. For example, if the AERO Client 398 receives the IPv4 ACP: 400 192.0.2.32/28 402 it constructs its AERO address as: 404 fe80::FFFF:192.0.2.32 406 The AERO address remains stable as the Client moves between 407 topological locations, i.e., even if its link-layer addresses change. 409 NOTE: In some cases, prospective neighbors may not have advanced 410 knowledge of the Client's ACP length and may therefore send initial 411 IPv6 ND messages with an AERO destination address that matches the 412 ACP but does not correspond to the base prefix. In that case, the 413 Client MUST accept the address as equivalent to the base address, but 414 then use the base address as the source address of any IPv6 ND 415 message replies. For example, if the Client receives the IPv6 ACP 416 2001:db8:1000:2000::/56 then subsequently receives an IPv6 ND message 417 with destination address fe80::2001:db8:1000:2001, it accepts the 418 message but uses fe80::2001:db8:1000:2000 as the source address of 419 any IPv6 ND replies. 421 3.4. AERO Interface Characteristics 423 AERO interfaces use encapsulation (see: Section 3.10) to exchange 424 packets with neighbors attached to the AERO link. AERO interfaces 425 maintain a neighbor cache, and AERO Clients and Servers use unicast 426 IPv6 ND messaging. AERO interfaces use unicast Neighbor Solicitation 427 (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and 428 Router Advertisement (RA) messages the same as for any IPv6 link. 429 AERO interfaces use two redirection message types -- the first known 430 as a Predirect message and the second being the standard Redirect 431 message (see Section 3.17). AERO links further use link-local-only 432 addressing; hence, AERO nodes ignore any Prefix Information Options 433 (PIOs) they may receive in RA messages over an AERO interface. 435 AERO interface ND messages include one or more Source/Target Link- 436 Layer Address Options (S/TLLAOs) formatted as shown in Figure 2: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type = 2 | Length = 3 | Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Link ID | NDSCPs | DSCP #1 |Prf| DSCP #2 |Prf| 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | DSCP #3 |Prf| DSCP #4 |Prf| .... 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | UDP Port Number | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 449 | | 450 + + 451 | IP Address | 452 + + 453 | | 454 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 2: AERO Source/Target Link-Layer Address Option (S/TLLAO) 459 Format 461 In this format, Link ID is an integer value between 0 and 255 462 corresponding to an underlying interface of the target node, NDSCPs 463 encodes an integer value between 0 and 64 indicating the number of 464 Differentiated Services Code Point (DSCP) octets that follow. Each 465 DSCP octet is a 6-bit integer DSCP value followed by a 2-bit 466 Preference ("Prf") value. Each DSCP value encodes an integer between 467 0 and 63 associated with this Link ID, where the value 0 means 468 "default" and other values are interpreted as specified in [RFC2474]. 469 The 'Prf' qualifier for each DSCP value is set to the value 0 470 ("deprecated'), 1 ("low"), 2 ("medium"), or 3 ("high") to indicate a 471 preference level for packet forwarding purposes. When NDSCP encodes 472 the value 0, no DSCP octets follow and the preference level for all 473 DSCPs is set to "medium". 475 UDP Port Number and IP Address are set to the addresses used by the 476 target node when it sends encapsulated packets over the underlying 477 interface. When UDP is not used as part of the encapsulation, UDP 478 Port Number is set to the value '0'. When the encapsulation IP 479 address family is IPv4, IP Address is formed as an IPv4-mapped IPv6 480 address [RFC4291]. 482 AERO interfaces may be configured over multiple underlying 483 interfaces. For example, common mobile handheld devices have both 484 wireless local area network ("WLAN") and cellular wireless links. 485 These links are typically used "one at a time" with low-cost WLAN 486 preferred and highly-available cellular wireless as a standby. In a 487 more complex example, aircraft frequently have many wireless data 488 link types (e.g. satellite-based, terrestrial, air-to-air 489 directional, etc.) with diverse performance and cost properties. 491 If a Client's multiple underlying interfaces are used "one at a time" 492 (i.e., all other interfaces are in standby mode while one interface 493 is active), then Redirect, Predirect and unsolicited NA messages 494 include only a single TLLAO with Link ID set to a constant value. 496 If the Client has multiple active underlying interfaces, then from 497 the perspective of IPv6 ND it would appear to have multiple link- 498 layer addresses. In that case, Redirect and Predirect messages MAY 499 include multiple TLLAOs -- each with a Link ID that corresponds to a 500 specific underlying interface of the Client. 502 3.5. AERO Link Registration 504 When an administrative authority first deploys a set of AERO Relays 505 and Servers that comprise an AERO link, they also assign a unique 506 domain name for the link, e.g., "linkupnetworks.example.com". Next, 507 if administrative policy permits Clients within the domain to serve 508 as correspondent nodes for Internet mobile nodes, the administrative 509 authority adds a Fully Qualified Domain Name (FQDN) for each of the 510 AERO link's ASPs to the Domain Name System (DNS) [RFC1035]. The FQDN 511 is based on the suffix "aero.linkupnetworks.net" with a prefix formed 512 from the wildcard-terminated reverse mapping of the ASP 514 [RFC3596][RFC4592], and resolves to a DNS PTR resource record. For 515 example, for the ASP '2001:db8:1::/48' within the domain name 516 "linkupnetworks.example.com", the DNS database contains: 518 '*.1.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net. PTR 519 linkupnetworks.example.com' 521 This DNS registration advertises the AERO link's ASPs to prospective 522 correspondent nodes. 524 3.6. AERO Interface Initialization 526 3.6.1. AERO Relay Behavior 528 When a Relay enables an AERO interface, it first assigns an 529 administratively provisioned link-local address fe80::ID to the 530 interface. Each fe80::ID address MUST be unique among all AERO nodes 531 on the link, and MUST NOT collide with any potential AERO addresses 532 nor the special addresses fe80:: and fe80::ffff:ffff:ffff:ffff. (The 533 fe80::ID addresses are typically taken from the available range 534 fe80::/96, e.g., as fe80::1, fe80::2, fe80::3, etc.) The Relay then 535 engages in a dynamic routing protocol session with all Servers on the 536 link (see: Section 3.7), and advertises its assigned ASP prefixes 537 into the native IP Internetwork. 539 Each Relay subsequently maintains an IP forwarding table entry for 540 each ACP, and maintains a neighbor cache entry for each Server on the 541 link. Relays exchange NS/NA messages with AERO link neighbors the 542 same as for any AERO node, however they typically do not perform 543 explicit Neighbor Unreachability Detection (NUD) (see: Section 3.18) 544 since the dynamic routing protocol already provides reachability 545 confirmation. 547 3.6.2. AERO Server Behavior 549 When a Server enables an AERO interface, it assigns an 550 administratively provisioned link-local address fe80::ID the same as 551 for Relays. The Server further configures a DHCPv6 server function 552 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 553 maintains a neighbor cache entry for each Relay on the link, and 554 manages per-Client neighbor cache entries and IP forwarding table 555 entries based on control message exchanges. Each Server also engages 556 in a dynamic routing protocol with each Relay on the link (see: 557 Section 3.7). 559 When the Server receives an NS/RS message from a Client on the AERO 560 interface it returns an NA/RA message. The Server further provides a 561 simple link-layer conduit between AERO interface neighbors. 563 Therefore, packets enter the Server's AERO interface from the link 564 layer and are forwarded back out the link layer without ever leaving 565 the AERO interface and therefore without ever disturbing the network 566 layer. 568 3.6.3. AERO Client Behavior 570 When a Client enables an AERO interface, it uses the special address 571 fe80::ffff:ffff:ffff:ffff to obtain one or more ACPs from an AERO 572 Server via DHCPv6 PD. Next, it assigns the corresponding AERO 573 address(es) to the AERO interface and creates a neighbor cache entry 574 for the Server, i.e., the DHCPv6 PD exchange bootstraps 575 autoconfiguration of unique link-local address(es). The Client 576 maintains a neighbor cache entry for each of its Servers and each of 577 its active correspondent Clients. When the Client receives Redirect/ 578 Predirect messages on the AERO interface it updates or creates 579 neighbor cache entries, including link-layer address information. 581 3.6.4. AERO Forwarding Agent Behavior 583 When a Forwarding Agent enables an AERO interface, it assigns the 584 same link-local address(es) as the companion AERO Server. The 585 Forwarding Agent thereafter provides data plane forwarding services 586 based solely on the forwarding information assigned to it by the 587 companion AERO Server. 589 3.7. AERO Routing System 591 The AERO routing system is based on a private instance of the Border 592 Gateway Protocol (BGP) [RFC4271] that is coordinated between Relays 593 and Servers and does not interact with either the public Internet BGP 594 routing system or the native IP Internetwork interior routing system. 595 Relays advertise only a small and unchanging set of ASPs to the 596 native routing system instead of the full dynamically changing set of 597 ACPs. 599 In a reference deployment, each AERO Server is configured as an 600 Autonomous System Border Router (ASBR) for a stub Autonomous System 601 (AS) using an AS Number (ASN) that is unique within the BGP instance, 602 and each Server further peers with each Relay but does not peer with 603 other Servers. Similarly, Relays do not peer with each other, since 604 they will reliably receive all updates from all Servers and will 605 therefore have a consistent view of the AERO link ACP delegations. 607 Each Server maintains a working set of associated ACPs, and 608 dynamically announces new ACPs and withdraws departed ACPs in its BGP 609 updates to Relays. Clients are expected to remain associated with 610 their current Servers for extended timeframes, however Servers SHOULD 611 selectively suppress BGP updates for impatient Clients that 612 repeatedly associate and disassociate with them in order to dampen 613 routing churn. 615 Each Relay configures a black-hole route for each of its ASPs. By 616 black-holing the ASPs, the Relay will maintain forwarding table 617 entries only for the ACPs that are currently active, and all other 618 ACPs will correctly result in destination unreachable failures due to 619 the black hole route. 621 Scaling properties of the AERO routing system are limited by the 622 number of BGP routes that can be carried by Relays. Assuming O(10^6) 623 as a reasonable maximum number of BGP routes, this means that O(10^6) 624 Clients can be serviced by a single set of Relays. A means of 625 increasing scaling would be to assign a different set of Relays for 626 each set of ASPs. In that case, each Server still peers with each 627 Relay, but the Server institutes route filters so that each set of 628 Relays only receives BGP updates for the ASPs they aggregate. For 629 example, if the ASP for the AERO link is 2001:db8::/32, a first set 630 of Relays could service the ASP segment 2001:db8::/40, a second set 631 of Relays could service 2001:db8:0100::/40, a third set could service 632 2001:db8:0200::/40, etc. 634 Assuming up to O(10^3) sets of Relays, the AERO routing system can 635 then accommodate O(10^9) ACPs with no additional overhead for Servers 636 and Relays. In this way, each set of Relays services a specific set 637 of ASPs that they advertise to the native routing system, and each 638 Server configures ASP-specific routes that list the correct set of 639 Relays as next hops. This arrangement also allows for natural 640 incremental deployment, and can support small scale initial 641 deployments followed by dynamic deployment of additional Clients, 642 Servers and Relays without disturbing the already-deployed base. 644 Note that in an alternate routing arrangement each set of Relays 645 could advertise the aggregated ASP for the link into the native 646 routing system even though each Relay services only a segment of the 647 ASP. In that case, a Relay upon receiving a packet with a 648 destination address covered by the ASP segment of another Relay can 649 simply tunnel the packet to the correct Relay. The tradeoff then is 650 the penalty for Relay-to-Relay tunneling compared with reduced 651 routing information in the native routing system. 653 3.8. AERO Interface Neighbor Cache Maintenace 655 Each AERO interface maintains a conceptual neighbor cache that 656 includes an entry for each neighbor it communicates with on the AERO 657 link, the same as for any IPv6 interface [RFC4861]. AERO interface 658 neighbor cache entires are said to be one of "permanent", "static" or 659 "dynamic". 661 Permanent neighbor cache entries are created through explicit 662 administrative action; they have no timeout values and remain in 663 place until explicitly deleted. AERO Relays maintain a permanent 664 neighbor cache entry for each Server on the link, and AERO Servers 665 maintain a permanent neighbor cache entry for each Relay. Each entry 666 maintains the mapping between the neighbor's fe80::ID network-layer 667 address and corresponding link-layer address. 669 Static neighbor cache entries are created through DHCPv6 PD exchanges 670 and remain in place for durations bounded by prefix lifetimes. AERO 671 Servers maintain static neighbor cache entries for the ACPs of each 672 of their associated Clients, and AERO Clients maintain a static 673 neighbor cache entry for each of their associated Servers. When an 674 AERO Server sends a DHCPv6 Reply message response to a Client's 675 DHCPv6 Solicit/Request, Rebind or Renew message, it creates or 676 updates a static neighbor cache entry based on the Client's DHCP 677 Unique Identifier (DUID) as the Client identifier, the AERO 678 address(es) corresponding to the Client's ACP(s) as the network-layer 679 address(es), the prefix lifetime as the neighbor cache entry 680 lifetime, the Client's encapsulation IP address and UDP port number 681 as the link-layer address and the prefix length(s) as the length to 682 apply to the AERO address(es). When an AERO Client receives a DHCPv6 683 Reply message from a Server, it creates or updates a static neighbor 684 cache entry based on the Reply message link-local source address as 685 the network-layer address, the prefix lifetime as the neighbor cache 686 entry lifetime, and the encapsulation IP source address and UDP 687 source port number as the link-layer address. 689 Dynamic neighbor cache entries are created or updated based on 690 receipt of an IPv6 ND Predirect/Redirect message, and are garbage- 691 collected if not used within a bounded timescale. AERO Clients 692 maintain dynamic neighbor cache entries for each of their active 693 correspondent Client ACPs with lifetimes based on IPv6 ND messaging 694 constants. When an AERO Client receives a valid Predirect message it 695 creates or updates a dynamic neighbor cache entry for the Predirect 696 target network-layer and link-layer addresses plus prefix length. 697 The node then sets an "AcceptTime" variable in the neighbor cache 698 entry to ACCEPT_TIME seconds and uses this value to determine whether 699 packets received from the correspondent can be accepted. When an 700 AERO Client receives a valid Redirect message it creates or updates a 701 dynamic neighbor cache entry for the Redirect target network-layer 702 and link-layer addresses plus prefix length. The Client then sets a 703 "ForwardTime" variable in the neighbor cache entry to FORWARD_TIME 704 seconds and uses this value to determine whether packets can be sent 705 directly to the correspondent. The Client also sets a "MaxRetry" 706 variable to MAX_RETRY to limit the number of keepalives sent when a 707 correspondent may have gone unreachable. 709 It is RECOMMENDED that FORWARD_TIME be set to the default constant 710 value 30 seconds to match the default REACHABLE_TIME value specified 711 for IPv6 ND [RFC4861]. 713 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 714 value 40 seconds to allow a 10 second window so that the AERO 715 redirection procedure can converge before AcceptTime decrements below 716 FORWARD_TIME. 718 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 719 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 721 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 722 administratively set, if necessary, to better match the AERO link's 723 performance characteristics; however, if different values are chosen, 724 all nodes on the link MUST consistently configure the same values. 725 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 726 sufficiently longer than FORWARD_TIME to allow the AERO redirection 727 procedure to converge. 729 3.9. AERO Interface Sending Algorithm 731 IP packets enter a node's AERO interface either from the network 732 layer (i.e., from a local application or the IP forwarding system), 733 or from the link layer (i.e., from the AERO tunnel virtual link). 734 Packets that enter the AERO interface from the network layer are 735 encapsulated and admitted into the AERO link, i.e., they are 736 tunnelled to an AERO interface neighbor. Packets that enter the AERO 737 interface from the link layer are either re-admitted into the AERO 738 link or delivered to the network layer where they are subject to 739 either local delivery or IP forwarding. Since each AERO node may 740 have only partial information about neighbors on the link, AERO 741 interfaces may forward packets with link-local destination addresses 742 at a layer below the network layer. This means that AERO nodes act 743 as both IP routers/hosts and sub-IP layer forwarding nodes. AERO 744 interface sending considerations for Clients, Servers and Relays are 745 given below. 747 When an IP packet enters a Client's AERO interface from the network 748 layer, if the destination is covered by an ASP the Client searches 749 for a dynamic neighbor cache entry with a non-zero ForwardTime and an 750 AERO address that matches the packet's destination address. (The 751 destination address may be either an address covered by the 752 neighbor's ACP or the (link-local) AERO address itself.) If there is 753 a match, the Client uses a link-layer address in the entry as the 754 link-layer address for encapsulation then admits the packet into the 755 AERO link. If there is no match, the Client instead uses the link- 756 layer address of a neighboring Server as the link-layer address for 757 encapsulation. 759 When an IP packet enters a Server's AERO interface from the link 760 layer, if the destination is covered by an ASP the Server searches 761 for a neighbor cache entry with an AERO address that matches the 762 packet's destination address. (The destination address may be either 763 an address covered by the neighbor's ACP or the AERO address itself.) 764 If there is a match, the Server uses a link-layer address in the 765 entry as the link-layer address for encapsulation and re-admits the 766 packet into the AERO link. If there is no match, the Server instead 767 uses the link-layer address in a permanent neighbor cache entry for a 768 Relay selected through longest-prefix-match as the link-layer address 769 for encapsulation. 771 When an IP packet enters a Relay's AERO interface from the network 772 layer, the Relay searches its IP forwarding table for an entry that 773 is covered by an ASP and also matches the destination. If there is a 774 match, the Relay uses the link-layer address in the corresponding 775 neighbor cache entry as the link-layer address for encapsulation and 776 admits the packet into the AERO link. When an IP packet enters a 777 Relay's AERO interface from the link-layer, if the destination is not 778 a link-local address and does not match an ASP the Relay removes the 779 packet from the AERO interface and uses IP forwarding to forward the 780 packet to the Internetwork. If the destination address is a link- 781 local address or a non-link-local address that matches an ASP, and 782 there is a more-specific ACP entry in the IP forwarding table, the 783 Relay uses the link-layer address in the corresponding neighbor cache 784 entry as the link-layer address for encapsulation and re-admits the 785 packet into the AERO link. When an IP packet enters a Relay's AERO 786 interface from either the network layer or link-layer, and the 787 packet's destination address matches an ASP but there is no more- 788 specific ACP entry, the Relay drops the packet and returns an ICMP 789 Destination Unreachable message (see: Section 3.14). 791 When an AERO Server receives a packet from a Relay via the AERO 792 interface, the Server MUST NOT forward the packet back to the same or 793 a different Relay. 795 When an AERO Relay receives a packet from a Server via the AERO 796 interface, the Relay MUST NOT forward the packet back to the same 797 Server. 799 When an AERO node re-admits a packet into the AERO link without 800 involving the network layer, the node MUST NOT decrement the network 801 layer TTL/Hop-count. 803 When an AERO node forwards a data packet to the primary link-layer 804 address of a Server, it may receive Redirect messages with an SLLAO 805 that include the link-layer address of an AERO Forwarding Agent. The 806 AERO node SHOULD record the link-layer address in the neighbor cache 807 entry for the neighbor and send subsequent data packets via this 808 address instead of the Server's primary address (see: Section 3.16). 810 3.10. AERO Interface Encapsulation and Re-encapsulation 812 AERO interfaces encapsulate IP packets according to whether they are 813 entering the AERO interface from the network layer or if they are 814 being re-admitted into the same AERO link they arrived on. This 815 latter form of encapsulation is known as "re-encapsulation". 817 The AERO interface encapsulates packets per the Generic UDP 818 Encapsulation (GUE) encapsulation procedures in 819 [I-D.ietf-nvo3-gue][I-D.herbert-gue-fragmentation], or through an 820 alternate minimal encapsulation format (see: Appendix A). During 821 encapsulation, the AERO interface copies the "TTL/Hop Limit", "Type 822 of Service/Traffic Class" [RFC2983], "Flow Label"[RFC6438].(for IPv6) 823 and "Congestion Experienced" [RFC3168] values in the packet's IP 824 header into the corresponding fields in the encapsulation IP header. 825 For packets undergoing re-encapsulation, the AERO interface instead 826 copies the "TTL/Hop Limit", "Type of Service/Traffic Class", "Flow 827 Label" and "Congestion Experienced" values in the original 828 encapsulation IP header into the corresponding fields in the new 829 encapsulation IP header, i.e., the values are transferred between 830 encapsulation headers and *not* copied from the encapsulated packet's 831 network-layer header. 833 When GUE encapsulation is used, the AERO interface next sets the UDP 834 source port to a constant value that it will use in each successive 835 packet it sends, and sets the UDP length field to the length of the 836 encapsulated packet plus 8 bytes for the UDP header itself plus the 837 length of the GUE header. For packets sent via a Server, the AERO 838 interface sets the UDP destination port to 8060, i.e., the IANA- 839 registered port number for AERO. For packets sent to a correspondent 840 Client, the AERO interface sets the UDP destination port to the port 841 value stored in the neighbor cache entry for this correspondent. The 842 AERO interface then either includes or omits the UDP checksum 843 according to the GUE specification. 845 For IPv4 encapsulation, the AERO interface sets the DF bit as 846 discussed in Section 3.13. 848 3.11. AERO Interface Decapsulation 850 AERO interfaces decapsulate packets destined either to the node 851 itself or to a destination reached via an interface other than the 852 AERO interface the packet was received on. Decapsulation is per the 853 procedures specified for the appropriate encapsulation format. 855 3.12. AERO Interface Data Origin Authentication 857 AERO nodes employ simple data origin authentication procedures for 858 encapsulated packets they receive from other nodes on the AERO link. 859 In particular: 861 o AERO Servers and Relays accept encapsulated packets with a link- 862 layer source address that matches a permanent neighbor cache 863 entry. 865 o AERO Servers accept authentic encapsulated DHCPv6 messages from 866 Clients, and create or update a static neighbor cache entry for 867 the Client based on the specific message type. 869 o AERO Clients and Servers accept encapsulated packets if there is a 870 static neighbor cache entry with a link-layer source address that 871 matches the packet's link-layer source address. 873 o AERO Clients, Servers and Relays accept encapsulated packets if 874 there is a dynamic neighbor cache entry with an AERO address that 875 matches the packet's network-layer source address, with a link- 876 layer address that matches the packet's link-layer source address, 877 and with a non-zero AcceptTime. 879 Note that this simple data origin authentication is effective in 880 environments in which link-layer addresses cannot be spoofed. In 881 other environments, each AERO message must include a signature that 882 the recipient can use to authenticate the message origin. 884 3.13. AERO Interface MTU and Fragmentation 886 The AERO interface is the node's attachment to the AERO link. The 887 AERO interface acts as a tunnel ingress when it sends a packet to an 888 AERO link neighbor and as a tunnel egress when it receives a packet 889 from an AERO link neighbor. AERO links over IP networks have a 890 maximum link MTU of 64KB minus the encapsulation overhead (i.e., 891 64KB-ENCAPS), since the maximum packet size in the base IP 892 specifications is 64KB [RFC0791][RFC2460]. While IPv6 jumbograms can 893 be up to 4GB [RFC2675], they are considered optional for IPv6 nodes 894 [RFC6434] and therefore out of scope for this document. 896 The AERO interface is considered to have an indefinite MTU , i.e., 897 instead of clamping the MTU to a fixed size. The MTU for each AERO 898 interface neighbor is therefore constrained by the minimum of 64KB, 899 the MTU of the underlying interface used for tunneling, and the path 900 MTU within the tunnel (minus ENCAPS in each case). 902 IPv6 specifies a minimum link MTU of 1280 bytes [RFC2460]. This is 903 the minimum packet size the AERO interface MUST admit without 904 returning an ICMP Packet Too Big (PTB) message. Although IPv4 905 specifies a smaller minimum link MTU of 68 bytes [RFC0791], AERO 906 interfaces also observe a 1280 byte minimum for IPv4 even if some 907 fragmentation is needed. 909 The vast majority of links in the Internet configure an MTU of at 910 least 1500 bytes. Original source hosts have therefore become 911 conditioned to expect that IP packets up to 1500 bytes in length will 912 either be delivered to the final destination or a suitable PTB 913 message returned. However, PTB messages may be crafted for malicious 914 purposes such as denial of service, or lost in the network [RFC2923] 915 resulting in failure of the IP Path MTU Discovery (PMTUD) mechanisms 916 [RFC1191][RFC1981]. For these reasons, the tunnel ingress sends 917 encapsulated packets to the tunnel egress subject to whether standard 918 PMTUD can be leveraged within the specific deployment model. The two 919 cases for consideration are as follows: 921 3.13.1. All Elements in Same Administrative Domain 923 When the original source, ingress and egress are all within the same 924 well-managed administrative domain, the ingress admits a packet into 925 the tunnel if it is no larger than the current path MTU estimate for 926 this egress (initially set to the MTU of the underlying link to be 927 used for tunneling minus ENCAPS). Otherwise, the ingress drops the 928 packet and sends a network layer (L3) PTB message back to the 929 original source. Additionally, the ingress SHOULD cache the MTU 930 value in any link-layer (L2) PTB messages it receives from a router 931 on the path to the egress as a new path MTU estimate. Thereafter, 932 the ingress SHOULD periodically reset the path MTU estimate to the 933 MTU of the underlying link minus ENCAPS to detect path MTU increases. 935 These procedures apply when the path MTU for this egress is no 936 smaller than (1280+ENCAPS) bytes; otherwise, the ingress can either 937 shut down the tunnel or commence fragmentation in a manner that 938 parallels the standard behavior specified in [RFC2473]. In that 939 case, the ingress encapsulates all packets that are no larger than 940 1280 bytes and uses encapsulation layer fragmentation if necessary as 941 specified in Section 3.13.2. (For IPv4 packets with DF=0 that are 942 larger than 1280 bytes, the ingress instead uses IPv4 fragmentation 943 before encapsulation.) 945 3.13.2. Not All Elements in Same Administrative Domain 947 When the original source, ingress and egress are not all within the 948 same well-managed administrative domain, the ingress admits all 949 packets up to 1500 bytes in length even if some fragmentation is 950 needed, and admits larger packets without fragmentation in case they 951 are able to traverse the tunnel in one piece. 953 Several factors must be considered when fragmentation is needed. For 954 AERO links over IPv4, the IP ID field is only 16 bits in length, 955 meaning that fragmentation at high data rates could result in data 956 corruption due to reassembly misassociations [RFC6864][RFC4963] (see: 957 Section 3.13.4). For AERO links over both IPv4 and IPv6, studies 958 have also shown that IP fragments are dropped unconditionally over 959 some network paths [I-D.taylor-v6ops-fragdrop]. For these reasons, 960 when fragmentation is needed the ingress inserts an encapsulation 961 layer fragment header and applies tunnel fragmentation as described 962 in Section 3.1.7 of [RFC2764] instead of IP fragmentation. Since the 963 fragment header reduces the room available for packet data, but the 964 original source has no way to control its insertion, the ingress MUST 965 include the fragment header length in the ENCAPS length even for 966 packets in which the header is absent. 968 The ingress therefore sends encapsulated packets to the egress 969 according to the following algorithm: 971 o For IP packets that are no larger than (1280-ENCAPS) bytes, the 972 ingress encapsulates the packet and admits it into the tunnel 973 without fragmentation. For IPv4 AERO links, the ingress sets the 974 Don't Fragment (DF) bit to 0 so that these packets will be 975 delivered to the egress even if there is a restricting link in the 976 path, i.e., unless lost due to congestion or routing errors. 978 o For IP packets that are larger than (1280-ENCAPS) bytes but no 979 larger than 1500 bytes, the ingress encapsulates the packet and 980 inserts an encapsulation layer fragment header. Next, the ingress 981 fragments the packet into a minimum number of non-overlapping 982 fragments where the first fragment (including ENCAPS) is no larger 983 than 1024 bytes and the remaining fragments are no larger than the 984 first. Each fragment consists of corresponding encapsulation 985 headers followed by the fragment of the encapsulated packet 986 itself. The ingress then admits the fragments into the tunnel, 987 and for IPv4 sets the DF bit to 0 in the IP encapsulation header. 988 These fragmented encapsulated packets will be delivered to the 989 egress, which reassembles them into a whole packet. The egress 990 therefore MUST be capable of reassembling packets up to 991 (1500+ENCAPS) bytes in length; hence, it is RECOMMENDED that the 992 egress be capable of reassembling at least 2KB. 994 o For IPv4 packets that are larger than 1500 bytes and with the DF 995 bit set to 0, the ingress uses ordinary IPv4 fragmentation to 996 break the unencapsulated packet into a minimum number of non- 997 overlapping fragments where the first fragment (including ENCAPS) 998 is no larger than 1024 bytes and the remaining fragments are no 999 larger than the first. The ingress then encapsulates each 1000 fragment (and for IPv4 sets the DF bit to 0) then admits them into 1001 the tunnel. These fragments will be delivered to the final 1002 destination via the egress. 1004 o For all other IP packets, if the packet is larger than the current 1005 path MTU estimate for this egress, the ingress drops the packet 1006 and returns an L3 PTB message to the original source with MTU set 1007 to the larger of 1500 bytes or the current path MTU estimate. 1008 Otherwise, the ingress encapsulates the packet and admits it into 1009 the tunnel without fragmentation (and for IPv4 sets the DF bit to 1010 1). Since PTB messages may either be lost or contain insufficient 1011 information, however, it is RECOMMENDED that original sources that 1012 send unfragmentable IP packets larger than 1500 bytes use 1013 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821]. 1015 A first exception to these procedures occurs when the ingress and 1016 egress are both within the same well-managed administrative domain. 1017 In that case, the ingress MAY initially admit all packets into the 1018 tunnel without fragmentation. If the ingress subsequently receives 1019 an L2 PTB message reporting a size smaller than (1500+ENCAPS) it can 1020 commence fragmentation per the above algorithm. 1022 A second exception occurs when the original source and ingress are 1023 both within the same well-managed administrative domain. In that 1024 case, if the underlying interface used by the ingress for tunneling 1025 configures an MTU smaller than (1500+HLEN) bytes, the ingress MAY 1026 drop packets that are larger than 1280 bytes and larger than the 1027 underlying interface MTU following encapsulation, and return an L3 1028 PTB message to the original source. 1030 3.13.3. Accommodating Large Control Messages 1032 The tunnel ingress MUST accommodate control messages (i.e., IPv6 ND, 1033 DHCPv6, etc.) even if the path MTU is insufficient to deliver the 1034 message without fragmentation. For control messages that are larger 1035 than the known or assumed minimum path MTU, the ingress encapsulates 1036 the packet and inserts an encapsulation layer fragment header. Next, 1037 the ingress breaks the packet into a minimum number of non- 1038 overlapping fragments where the first fragment (including ENCAPS) is 1039 no larger than 1024 bytes and the remaining fragments are no larger 1040 than the first. The ingress then encapsulates each fragment (and for 1041 IPv4 sets the DF bit to 0) then admits them into the tunnel. 1043 Control messages that exceed the 2KB minimum reassembly size rarely 1044 occur in current operational practices, however the egress SHOULD be 1045 able to reassemble them if they appear in future applications. This 1046 means that the egress SHOULD include a configuration knob allowing 1047 the operator to set a larger reassembly buffer size if large control 1048 messages become more common in the future. 1050 The ingress MAY send large control messages without fragmentation if 1051 there is assurance that large packets can traverse the tunnel without 1052 fragmentation. 1054 3.13.4. Integrity 1056 When fragmentation is needed, there must be assurance that reassembly 1057 can be safely conducted without incurring data corruption. Sources 1058 of corruption can include implementation errors, memory errors and 1059 misassociations of fragments from a first datagram with fragments of 1060 another datagram. The first two conditions (implementation and 1061 memory errors) are mitigated by modern systems and implementations 1062 that have demonstrated integrity through decades of operational 1063 practice. The third condition (reassembly misassociations) must be 1064 accounted for by AERO. 1066 The fragmentation procedure described in the above algorithms can 1067 reuse standard IPv6 fragmentation and reassembly code. Since 1068 encapsulation layer fragment headers include a 32-bit ID field, there 1069 would need to be 2^32 packets alive in the network before a second 1070 packet with a duplicate ID enters the system with the (remote) 1071 possibility for a reassembly misassociation. For 1280 byte packets, 1072 and for a maximum network lifetime value of 60 seconds[RFC2460], this 1073 means that the ingress would need to produce ~(7 *10^12) bits/sec in 1074 order for a duplication event to be possible. This exceeds the 1075 bandwidth of data link technologies of the modern era, but not 1076 necessarily so going forward into the future. Although wireless data 1077 links commonly used by AERO Clients support vastly lower data rates, 1078 the aggregate data rates between AERO Servers and Relays may be 1079 substantial. However, high speed data links in the network core are 1080 expected to configure larger MTUs (e.g., 4KB, 8KB or even larger) 1081 such that unfragmented packets can be used. Hence, no integrity 1082 check is included to cover fragmentation and reassembly procedures. 1084 When the ingress sends an IPv4-encapsulated packet with the DF bit 1085 set to 0 in the above algorithms, there is a chance that the packet 1086 may be fragmented by an IPv4 router somewhere within the tunnel. 1087 Since the largest such packet is only 1280 bytes, however, it is very 1088 likely that the packet will traverse the tunnel without incurring a 1089 restricting link. Even when a link within the tunnel configures an 1090 MTU smaller than 1280 bytes, it is very likely that it does so due to 1091 limited performance characteristics [RFC3819]. This means that the 1092 tunnel would not be able to convey fragmented IPv4-encapsulated 1093 packets fast enough to produce reassembly misassociations, as 1094 discussed above. However, AERO must also account for the possibility 1095 of tunnel paths that include "poorly managed" IPv4 link MTUs due to 1096 misconfigurations. 1098 Since the IPv4 header includes only a 16-bit ID field, there would 1099 only need to be 2^16 packets alive in the network before a second 1100 packet with a duplicate ID enters the system. For 1280 byte packets, 1101 and for a maximum network lifetime value of 120 seconds[RFC0791], 1102 this means that the ingress would only need to produce ~(5 *10^6) 1103 bits/sec in order for a duplication event to be possible - a value 1104 that is well within range for modern wired and wireless data link 1105 technologies. 1107 Therefore, if there is strong operational assurance that no IPv4 1108 links capable of supporting data rates of 5Mbps or more configure an 1109 MTU smaller than 1280 the ingress MAY omit an integrity check for the 1110 IPv4 fragmentation and reassembly procedures; otherwise, the ingress 1111 SHOULD include an integrity check. When an upper layer encapsulation 1112 (e.g., IPsec) already includes an integrity check, the ingress need 1113 not include an additional check. Otherwise, the ingress calculates 1114 the encapsulation layer checksum over the encapsulated packet and 1115 writes the value into the encapsulation layer checksum header. The 1116 egress will then verify the checksum and discard the packet if the 1117 checksum is incorrect. 1119 3.14. AERO Interface Error Handling 1121 When an AERO node admits encapsulated packets into the AERO 1122 interface, it may receive link-layer (L2) or network-layer (L3) error 1123 indications. 1125 An L2 error indication is an ICMP error message generated by a router 1126 on the path to the neighbor or by the neighbor itself. The message 1127 includes an IP header with the address of the node that generated the 1128 error as the source address and with the link-layer address of the 1129 AERO node as the destination address. 1131 The IP header is followed by an ICMP header that includes an error 1132 Type, Code and Checksum. For ICMPv6 [RFC4443], the error Types 1133 include "Destination Unreachable", "Packet Too Big (PTB)", "Time 1134 Exceeded" and "Parameter Problem". For ICMPv4 [RFC0792], the error 1135 Types include "Destination Unreachable", "Fragmentation Needed" (a 1136 Destination Unreachable Code that is analogous to the ICMPv6 PTB), 1137 "Time Exceeded" and "Parameter Problem". 1139 The ICMP header is followed by the leading portion of the packet that 1140 generated the error, also known as the "packet-in-error". For 1141 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1142 much of invoking packet as possible without the ICMPv6 packet 1143 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1144 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1145 "Internet Header + 64 bits of Original Data Datagram", however 1146 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1147 ICMP datagram SHOULD contain as much of the original datagram as 1148 possible without the length of the ICMP datagram exceeding 576 1149 bytes". 1151 The L2 error message format is shown in Figure 3: 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 ~ ~ 1155 | L2 IP Header of | 1156 | error message | 1157 ~ ~ 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | L2 ICMP Header | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1161 ~ ~ P 1162 | IP and other encapsulation | a 1163 | headers of original L3 packet | c 1164 ~ ~ k 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1166 ~ ~ t 1167 | IP header of | 1168 | original L3 packet | i 1169 ~ ~ n 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 ~ ~ e 1172 | Upper layer headers and | r 1173 | leading portion of body | r 1174 | of the original L3 packet | o 1175 ~ ~ r 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1178 Figure 3: AERO Interface L2 Error Message Format 1180 The AERO node rules for processing these L2 error messages is as 1181 follows: 1183 o When an AERO node receives an L2 Parameter Problem message, it 1184 processes the message the same as described as for ordinary ICMP 1185 errors in the normative references [RFC0792][RFC4443]. 1187 o When an AERO node receives persistent L2 IPv4 Time Exceeded 1188 messages, the IP ID field may be wrapping before earlier fragments 1189 have been processed. In that case, the node SHOULD begin 1190 including IPv4 integrity checks (see: Section 3.13.4). 1192 o When an AERO Client receives persistent L2 Destination Unreachable 1193 messages in response to tunneled packets that it sends to one of 1194 its dynamic neighbor correspondents, the Client SHOULD test the 1195 path to the correspondent using Neighbor Unreachability Detection 1196 (NUD) (see Section 3.18). If NUD fails, the Client SHOULD set 1197 ForwardTime for the corresponding dynamic neighbor cache entry to 1198 0 and allow future packets destined to the correspondent to flow 1199 through a Server. 1201 o When an AERO Client receives persistent L2 Destination Unreachable 1202 messages in response to tunneled packets that it sends to one of 1203 its static neighbor Servers, the Client SHOULD test the path to 1204 the Server using NUD. If NUD fails, the Client SHOULD delete the 1205 neighbor cache entry and attempt to associate with a new Server. 1207 o When an AERO Server receives persistent L2 Destination Unreachable 1208 messages in response to tunneled packets that it sends to one of 1209 its static neighbor Clients, the Server SHOULD test the path to 1210 the Client using NUD. If NUD fails, the Server SHOULD cancel the 1211 DHCPv6 PD for the Client's ACP, withdraw its route for the ACP 1212 from the AERO routing system and delete the neighbor cache entry 1213 (see Section 3.18 and Section 3.19). 1215 o When an AERO Relay or Server receives an L2 Destination 1216 Unreachable message in response to a tunneled packet that it sends 1217 to one of its permanent neighbors, it discards the message since 1218 the AERO routing system is likely in a temporary transitional 1219 state that will soon re-converge. In case of a prolonged outage, 1220 however, dynamic routing protocols will compensate for Relays or 1221 Servers that fallen silent. 1223 o When an AERO node receives an L2 PTB message, it translates the 1224 message into an L3 PTB message if possible and forwards the 1225 message toward the original source as described below. Note that 1226 in some instances the packet-in-error field of an L2 PTB message 1227 may not include enough information for translation to an L3 PTB 1228 message. In that case, the AERO interface simply discards the L2 1229 PTB message since translation of L2 PTB messages to L3 PTB 1230 messages can provide a useful optimization when possible, but is 1231 not critical for sources that correctly use PLPMTUD. 1233 To translate an L2 PTB message to an L3 PTB message, the AERO node 1234 first caches the MTU field value of the L2 ICMP header. The node 1235 next discards the L2 IP and ICMP headers, and also discards the 1236 encapsulation headers of the original L3 packet. Next the node 1237 encapsulates the included segment of the original L3 packet in an L3 1238 IP and ICMP header, and sets the ICMP header Type and Code values to 1239 appropriate values for the L3 IP protocol. When the AERO node, AERO 1240 link neighbor and original source are all within the same 1241 administrative domain, the node writes the maximum of 1280 bytes and 1242 (L2 MTU - ENCAPS) into the MTU field of the L3 ICMP header. 1243 (Otherwise, the node translates L2 PTB messages for which (L2 MTU - 1244 ENCAPS) is no less than 1500 bytes and discards all other L2 PTBs.) 1246 The node next writes the IP source address of the original L3 packet 1247 as the destination address of the L3 PTB message and determines the 1248 next hop to the destination. If the next hop is reached via the AERO 1249 interface, the node uses the IPv6 address "::" or the IPv4 address 1250 "0.0.0.0" as the IP source address of the L3 PTB message. Otherwise, 1251 the node uses one of its non link-local addresses as the source 1252 address of the L3 PTB message. The node finally calculates the ICMP 1253 checksum over the L3 PTB message and writes the Checksum in the 1254 corresponding field of the L3 ICMP header. The L3 PTB message 1255 therefore is formatted as follows: 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 ~ ~ 1259 | L3 IP Header of | 1260 | error message | 1261 ~ ~ 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | L3 ICMP Header | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1265 ~ ~ p 1266 | IP header of | k 1267 | original L3 packet | t 1268 ~ ~ 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1270 ~ ~ n 1271 | Upper layer headers and | 1272 | leading portion of body | e 1273 | of the original L3 packet | r 1274 ~ ~ r 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1277 Figure 4: AERO Interface L3 Error Message Format 1279 After the node has prepared the L3 PTB message, it either forwards 1280 the message via a link outside of the AERO interface without 1281 encapsulation, or encapsulates and forwards the message to the next 1282 hop via the AERO interface. 1284 When an AERO Relay receives an L3 packet for which the destination 1285 address is covered by an ASP, if there is no more-specific routing 1286 information for the destination the Relay drops the packet and 1287 returns an L3 Destination Unreachable message. The Relay first 1288 writes the IP source address of the original L3 packet as the 1289 destination address of the L3 Destination Unreachable message and 1290 determines the next hop to the destination. If the next hop is 1291 reached via the AERO interface, the Relay uses the IPv6 address "::" 1292 or the IPv4 address "0.0.0.0" as the IP source address of the L3 1293 Destination Unreachable message and forwards the message to the next 1294 hop within the AERO interface. Otherwise, the Relay uses one of its 1295 non link-local addresses as the source address of the L3 Destination 1296 Unreachable message and forwards the message via a link outside the 1297 AERO interface. 1299 When an AERO node receives any L3 error message via the AERO 1300 interface, it examines the destination address in the L3 IP header of 1301 the message. If the next hop toward the destination address of the 1302 error message is via the AERO interface, the node re-encapsulates and 1303 forwards the message to the next hop within the AERO interface. 1304 Otherwise, if the source address in the L3 IP header of the message 1305 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1306 writes one of its non link-local addresses as the source address of 1307 the L3 message and recalculates the IP and/or ICMP checksums. The 1308 node finally forwards the message via a link outside of the AERO 1309 interface. 1311 3.15. AERO Router Discovery, Prefix Delegation and Address 1312 Configuration 1314 3.15.1. AERO DHCPv6 Service Model 1316 Each AERO Server configures a DHCPv6 server function to facilitate PD 1317 requests from Clients. Each Server is provisioned with a database of 1318 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1319 system, as well as any information necessary to authenticate each 1320 Client. The Client database is maintained by a central 1321 administrative authority for the AERO link and securely distributed 1322 to all Servers, e.g., via the Lightweight Directory Access Protocol 1323 (LDAP) [RFC4511] or a similar distributed database service. 1325 Therefore, no Server-to-Server DHCPv6 PD delegation state 1326 synchronization is necessary, and Clients can optionally hold 1327 separate delegations for the same ACPs from multiple Servers. In 1328 this way, Clients can associate with multiple Servers, and can 1329 receive new delegations from new Servers before deprecating 1330 delegations received from existing Servers. This provides the Client 1331 with a natural fault-tolerance and/or load balancing profile. 1333 AERO Clients and Servers exchange Client link-layer address 1334 information using an option format similar to the Client Link Layer 1335 Address Option (CLLAO) defined in [RFC6939]. Due to practical 1336 limitations of CLLAO, however, AERO interfaces instead use Vendor- 1337 Specific Information Options as described in the following sections. 1339 3.15.2. AERO Client Behavior 1341 AERO Clients discover the link-layer addresses of AERO Servers via 1342 static configuration, or through an automated means such as DNS name 1343 resolution. In the absence of other information, the Client resolves 1344 the FQDN "linkupnetworks.[domainname]" where "linkupnetworks" is a 1345 constant text string and "[domainname]" is the connection-specific 1346 DNS suffix for the Client's underlying network connection (e.g., 1347 "example.com"). After discovering the link-layer addresses, the 1348 Client associates with one or more of the corresponding Servers. 1350 To associate with a Server, the Client acts as a requesting router to 1351 request ACPs through a two-message (i.e., Solicit/Reply) or four- 1352 message (i.e., Solicit/Advertise/Request/Reply) DHCPv6 PD exchange 1353 [RFC3315][RFC3633]. The Client's Solicit/Request message includes 1354 fe80::ffff:ffff:ffff:ffff as the IPv6 source address, 1355 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 1356 and the link-layer address of the Server as the link-layer 1357 destination address. The Solicit/Request message also includes a 1358 Client Identifier option with a DUID and an Identity Association for 1359 Prefix Delegation (IA_PD) option. If the Client is pre-provisioned 1360 with ACPs associated with the AERO service, it MAY also include the 1361 ACPs in the IA_PD to indicate its preferences to the DHCPv6 server. 1363 The Client also SHOULD include an AERO Link-registration Request 1364 (ALREQ) option to register one or more links with the Server. The 1365 Server will include an AERO Link-registration Reply (ALREP) option in 1366 the corresponding DHCPv6 Reply message as specified in 1367 Section 3.15.3. (The Client MAY omit the ALREQ option, in which case 1368 the Server will still include an ALREP option in its Reply with "Link 1369 ID" set to 0.) 1371 The format for the ALREQ option is shown in Figure 5: 1373 0 1 2 3 1374 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 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | OPTION_VENDOR_OPTS | option-len (1) | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | enterprise-number = 45282 | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | opt-code = OPTION_ALREQ (0) | option-len (2) | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Link ID | DSCP #1 |Prf| DSCP #2 |Prf| ... 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1385 Figure 5: AERO Link-registration Request (ALREQ) Option 1387 In the above format, the Client sets 'option-code' to 1388 OPTION_VENDOR_OPTS, sets 'option-len (1)' to the length of the option 1389 following this field, sets 'enterprise-number' to 45282 (see: "IANA 1390 Considerations"), sets opt-code to the value 0 ("OPTION_ALREQ") and 1391 sets 'option-len (2)' to the length of the remainder of the option. 1392 The Client includes appropriate 'Link ID, 'DSCP' and 'Prf' values for 1393 the underlying interface over which the DHCPv6 PD Solicit/Request 1394 message will be issued the same as specified for an S/TLLAO 1395 Section 3.4. The Client MAY include multiple (DSCP, Prf) values with 1396 this Link ID, with the number of values indicated by option-len (2). 1397 The Server will register each value with the Link ID in the Client's 1398 neighbor cache entry. The Client finally includes any necessary 1399 authentication options to identify itself to the DHCPv6 server, and 1400 sends the encapsulated DHCPv6 PD Solicit/Request message via the 1401 underlying interface corresponding to Link ID. (Note that this 1402 implies that the Client must perform additional Rebind/Reply DHCPv6 1403 exchanges with the server following the initial PD exchange using 1404 different underlying interfaces and their corresponding Link IDs if 1405 it wishes to register additional link-layer addresses and their 1406 associated DSCPs.) 1408 When the Client receives its ACP via a DHCPv6 Reply from the AERO 1409 Server, it creates a static neighbor cache entry with the Server's 1410 link-local address as the network-layer address and the Server's 1411 encapsulation address as the link-layer address. The Client then 1412 considers the link-layer address of the Server as the primary default 1413 encapsulation address for forwarding packets for which no more- 1414 specific forwarding information is available. The Client further 1415 caches any ASPs included in the ALREP option as ASPs to apply to the 1416 AERO link. 1418 Next, the Client autoconfigures an AERO address for each of the 1419 delegated ACPs, assigns the address(es) to the AERO interface and 1420 sub-delegates the ACPs to its attached EUNs and/or the Client's own 1421 internal virtual interfaces. Alternatively, the Client can configure 1422 as many addresses as it wants from /64 prefixes taken from the ACPs 1423 and assign them to either an internal virtual interface ("weak end- 1424 system" [RFC1122]) or to the AERO interface itself ("strong end- 1425 system") while black-holing the remaining portions of the /64s. 1426 Finally, the Client assigns one or more default IP routes to the AERO 1427 interface with the link-local address of a Server as the next hop. 1429 After AERO address autoconfiguration, the Client SHOULD begin using 1430 the AERO address as the source address for further DHCPv6 messaging. 1431 The Client subsequently renews its ACP delegations through each of 1432 its Servers by performing DHCPv6 Renew/Reply exchanges with the link- 1433 layer address of a Server as the link-layer destination address and 1434 the same options that were used in the initial PD request. Note that 1435 if the Client does not issue a DHCPv6 Renew before the delegations 1436 expire (e.g., if the Client has been out of touch with the Server for 1437 a considerable amount of time) it must re-initiate the DHCPv6 PD 1438 procedure. 1440 Since the addresses assigned to the Client's AERO interface are 1441 obtained from the unique ACP delegations it receives, there is no 1442 need for DAD on AERO links. Other nodes maliciously attempting to 1443 hijack addresses from an authorized Client's ACPs will be denied 1444 access to the network by the DHCPv6 server due to an unacceptable 1445 link-layer address and/or security parameters (see: Security 1446 Considerations). 1448 When a Client attempts to perform a DHCPv6 PD exchange with a Server 1449 that is too busy to service the request, the Client may receive 1450 either a "NoPrefixAvail" status code in the Server's Reply per 1451 [RFC3633] or no reply at all. In that case, the Client SHOULD 1452 discontinue DHCPv6 PD attempts through this Server and try another 1453 Server. 1455 3.15.2.1. Autoconfiguration for Constrained Platforms 1457 On some platforms (e.g., popular cell phone operating systems), the 1458 act of assigning a default IPv6 route and/or assigning an address to 1459 an interface may not be permitted from a user application due to 1460 security policy. Typically, those platforms include a TUN/TAP 1461 interface [TUNTAP] that acts as a point-to-point conduit between user 1462 applications and the AERO interface. In that case, the Client can 1463 instead generate a "synthesized RA" message. The message conforms to 1464 [RFC4861] and is prepared as follows: 1466 o the IPv6 source address is the Client's AERO address 1468 o the IPv6 destination address is all-nodes multicast 1469 o the Router Lifetime is set to a time that is no longer than the 1470 ACP DHCPv6 lifetime 1472 o the message does not include a Source Link Layer Address Option 1473 (SLLAO) 1475 o the message includes a Prefix Information Option (PIO) with a /64 1476 prefix taken from the ACP as the prefix for autoconfiguration 1478 The Client then sends the synthesized RA message via the TUN/TAP 1479 interface, where the operating system kernel will interpret it as 1480 though it were generated by an actual router. The operating system 1481 will then install a default route and use StateLess Address 1482 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 1483 interface. Methods for similarly installing an IPv4 default route 1484 and IPv4 address on the TUN/TAP interface are based on synthesized 1485 DHCPv4 messages [RFC2131]. 1487 3.15.3. AERO Server Behavior 1489 AERO Servers configure a DHCPv6 server function on their AERO links. 1490 AERO Servers arrange to add their encapsulation layer IP addresses 1491 (i.e., their link-layer addresses) to the DNS resource records for 1492 the FQDN "linkupnetworks.[domainname]" before entering service. 1494 When an AERO Server receives a prospective Client's DHCPv6 PD 1495 Solicit/Request on its AERO interface, and the Server is too busy to 1496 service the message, it SHOULD return a Reply with status code 1497 "NoPrefixAvail" per [RFC3633]. Otherwise, the Server authenticates 1498 the message. If authentication succeeds, the Server determines the 1499 correct ACPs to delegate to the Client by searching the Client 1500 database. 1502 When the Server delegates the ACPs, it also creates IP forwarding 1503 table entries so that the AERO routing system will propagate the ACPs 1504 to all Relays that aggregate the corresponding ASP (see: 1505 Section 3.7). Next, the Server prepares a DHCPv6 Reply message to 1506 send to the Client while using fe80::ID as the IPv6 source address, 1507 the link-local address taken from the Client's Solicit/Request as the 1508 IPv6 destination address, the Server's link-layer address as the 1509 source link-layer address, and the Client's link-layer address as the 1510 destination link-layer address. The server also includes IA_PD 1511 options with the delegated ACPs. Since the Client may experience a 1512 fault that prevents it from issuing a DHCPv6 Release before departing 1513 from the network, Servers should set a short prefix lifetime (e.g., 1514 40 seconds) so that stale prefix delegation state can be flushed out 1515 of the network. 1517 The Server also includes an ALREP option that includes the UDP Port 1518 Number and IP Address values it observed when it received the ALREQ 1519 in the Client's original DHCPv6 message (if present) followed by the 1520 ASP(s) for the AERO link. The ALREP option is formatted as shown in 1521 Figure 6: 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | OPTION_VENDOR_OPTS | option-len (1) | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | enterprise-number = 45282 | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | opt-code = OPTION_ALREP (1) | option-len (2) | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Link ID | Reserved | UDP Port Number | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | | 1535 + + 1536 | | 1537 + IP Address + 1538 | | 1539 + + 1540 | | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | | 1543 + AERO Service Prefix (ASP) #1 +-+-+-+-+-+-+-+-+ 1544 | | Prefix Len | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | | 1547 + AERO Service Prefix (ASP) #2 +-+-+-+-+-+-+-+-+ 1548 | | Prefix Len | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 ~ ~ 1551 ~ ~ 1553 Figure 6: AERO Link-registration Reply (ALREP) Option 1555 In the ALREP, the Server sets 'option-code' to OPTION_VENDOR_OPTS, 1556 sets 'option-length (1)' to the length of the option, sets 1557 'enterprise-number' to 45282 (see: "IANA Considerations"), sets opt- 1558 code to OPTION_ALREP (1), and sets 'option-len (2)' to the length of 1559 the remainder of the option. Next, the Server sets 'Link ID' to the 1560 same value that appeared in the ALREQ, sets Reserved to 0 and sets 1561 'UDP Port Number' and 'IP address' to the Client's link-layer 1562 address. The Server next includes one or more ASP with the IP prefix 1563 as it would appear in the interface identifier portion of the 1564 corresponding AERO address (see: Section 3.3), except that the low- 1565 order 8 bits of the ASP field encode the prefix length instead of the 1566 low-order 8 bits of the prefix. The longest prefix that can 1567 therefore appear as an ASP is /56 for IPv6 or /24 for IPv4. (Note 1568 that if the Client did not include an ALREQ option in its DHCPv6 1569 message, the Server MUST still include an ALREP option in the 1570 corresponding reply with 'Link ID' set to 0.) 1572 When the Server admits the DHCPv6 Reply message into the AERO 1573 interface, it creates a static neighbor cache entry for the Client 1574 based on the DUID and AERO addresses with lifetime set to no more 1575 than the delegation lifetimes and the Client's link-layer address as 1576 the link-layer address for the Link ID specified in the ALREQ. The 1577 Server then uses the Client link-layer address information in the 1578 ALREQ option as the link-layer address for encapsulation based on the 1579 (DSCP, Prf) information. 1581 After the initial DHCPv6 PD exchange, the AERO Server maintains the 1582 neighbor cache entry for the Client until the delegation lifetimes 1583 expire. If the Client issues a Renew/Reply exchange, the Server 1584 extends the lifetimes. If the Client issues a Release/Reply, or if 1585 the Client does not issue a Renew/Reply before the lifetime expires, 1586 the Server deletes the neighbor cache entry for the Client and 1587 withdraws the IP routes from the AERO routing system. 1589 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1591 AERO Clients and Servers are always on the same link (i.e., the AERO 1592 link) from the perspective of DHCPv6. However, in some 1593 implementations the DHCPv6 server and AERO interface driver may be 1594 located in separate modules. In that case, the Server's AERO 1595 interface driver module can act as a Lightweight DHCPv6 Relay Agent 1596 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1597 server module. 1599 When the LDRA receives a DHCPv6 message from a client, it prepares an 1600 ALREP option the same as described above then wraps the option in a 1601 Relay-Supplied DHCP Option option (RSOO) [RFC6422]. The LDRA then 1602 incorporates the option into the Relay-Forward message and forwards 1603 the message to the DHCPv6 server. 1605 When the DHCPv6 server receives the Relay-Forward message, it caches 1606 the ALREP option and authenticates the encapsulated DHCPv6 message. 1607 The DHCPv6 server subsequently ignores the ALREQ option itself, since 1608 the relay has already included the ALREP option. 1610 When the DHCPv6 server prepares a Reply message, it then includes the 1611 ALREP option in the body of the message along with any other options, 1612 then wraps the message in a Relay-Reply message. The DHCPv6 server 1613 then delivers the Relay-Reply message to the LDRA, which discards the 1614 Relay-Reply wrapper and delivers the DHCPv6 message to the Client. 1616 3.15.4. Deleting Link Registrations 1618 After an AERO Client registers its Link IDs and their associated 1619 (DSCP,Prf) values with the AERO Server, the Client may wish to delete 1620 one or more Link registrations, e.g., if an underlying link becomes 1621 unavailable. To do so, the Client prepares a DHCPv6 Rebind message 1622 that includes an AERO Link-registration Delete (ALDEL) option and 1623 sends the Rebind message to the Server over any available underlying 1624 link. The ALDEL option is formatted as shown in Figure 7: 1626 0 1 2 3 1627 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 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | OPTION_VENDOR_OPTS | option-len (1) | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | enterprise-number = 45282 | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | opt-code = OPTION_ALDEL (2) | option-len (2) | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Link ID #1 | Link ID #2 | Link ID #3 | ... 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1638 Figure 7: AERO Link-registration Delete (ALDEL) Option 1640 In the ALDEL, the Client sets 'option-code' to OPTION_VENDOR_OPTS, 1641 sets 'option-length (1)' to the length of the option, sets 1642 'enterprise-number' to 45282 (see: "IANA Considerations"), sets 1643 optcode to OPTION_ALDEL (2), and sets 'option-len (2)' to the length 1644 of the remainder of the option. Next, the Server includes each 'Link 1645 ID' value that it wishes to delete. 1647 If the Client wishes to discontinue use of a Server and thereby 1648 delete all of its Link ID associations, it must use a DHCPv6 Release/ 1649 Reply exchange to delete the entire neighbor cache entry, i.e., 1650 instead of using a DHCPv6 Rebind/Reply exchange with one or more 1651 ALDEL options. 1653 3.16. AERO Forwarding Agent Behavior 1655 AERO Servers MAY associate with one or more companion AERO Forwarding 1656 Agents as platforms for offloading high-speed data plane traffic. 1657 When an AERO Server receives a Client's DHCPv6 1658 Solicit/Request/Renew/Rebind/Release message, it services the message 1659 then forwards the corresponding Reply message to the Forwarding 1660 Agent. When the Forwarding Agent receives the Reply message, it 1661 creates, updates or deletes a neighbor cache entry with the Client's 1662 AERO address and link-layer information included in the Reply 1663 message. The Forwarding Agent then forwards the Reply message back 1664 to the AERO Server, which forwards the message to the Client. In 1665 this way, Forwarding Agent state is managed in conjunction with 1666 Server state, with the Client responsible for reliability. 1668 When an AERO Server receives a data packet on an AERO interface with 1669 a network layer destination address for which it has distributed 1670 forwarding information to a Forwarding Agent, the Server returns a 1671 Redirect message to the source neighbor (subject to rate limiting) 1672 then forwards the data packet as usual. The Redirect message 1673 includes a TLLAO with the link-layer address of the Forwarding 1674 Engine. 1676 When the source neighbor receives the Redirect message, it SHOULD 1677 record the link-layer address in the TLLAO as the encapsulation 1678 addresses to use for sending subsequent data packets. However, the 1679 source MUST continue to use the primary link-layer address of the 1680 Server as the encapsulation address for sending control messages. 1682 3.17. AERO Intradomain Route Optimization 1684 When a source Client forwards packets to a prospective correspondent 1685 Client within the same AERO link domain (i.e., one for which the 1686 packet's destination address is covered by an ASP), the source Client 1687 MAY initiate an intra-domain AERO route optimization procedure. It 1688 is important to note that this procedure is initiated by the Client; 1689 if the procedure were initiated by the Server, the Server would have 1690 no way of knowing whether the Client was actually able to contact the 1691 correspondent over the route-optimized path. 1693 The procedure is based on an exchange of IPv6 ND messages using a 1694 chain of AERO Servers and Relays as a trust basis. This procedure is 1695 in contrast to the Return Routability procedure required for route 1696 optimization to a correspondent Client located in the Internet as 1697 described in Section 3.22. The following sections specify the AERO 1698 intradomain route optimization procedure. 1700 3.17.1. Reference Operational Scenario 1702 Figure 8 depicts the AERO intradomain route optimization reference 1703 operational scenario, using IPv6 addressing as the example (while not 1704 shown, a corresponding example for IPv4 addressing can be easily 1705 constructed). The figure shows an AERO Relay ('R1'), two AERO 1706 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1707 IPv6 hosts ('H1', 'H2'): 1709 +--------------+ +--------------+ +--------------+ 1710 | Server S1 | | Relay R1 | | Server S2 | 1711 +--------------+ +--------------+ +--------------+ 1712 fe80::2 fe80::1 fe80::3 1713 L2(S1) L2(R1) L2(S2) 1714 | | | 1715 X-----+-----+------------------+-----------------+----+----X 1716 | AERO Link | 1717 L2(A) L2(B) 1718 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1719 +--------------+ +--------------+ 1720 |AERO Client C1| |AERO Client C2| 1721 +--------------+ +--------------+ 1722 2001:DB8:0::/48 2001:DB8:1::/48 1723 | | 1724 .-. .-. 1725 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1726 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1727 (__ EUN )--| Host H1 | | Host H2 |--(__ EUN ) 1728 `-(______)-' +---------+ +---------+ `-(______)-' 1730 Figure 8: AERO Reference Operational Scenario 1732 In Figure 8, Relay ('R1') assigns the address fe80::1 to its AERO 1733 interface with link-layer address L2(R1), Server ('S1') assigns the 1734 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1735 assigns the address fe80::3 with link-layer address L2(S2). Servers 1736 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1737 published list of valid Servers for the AERO link. 1739 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1740 exchange via AERO Server ('S1') then assigns the address 1741 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1742 L2(C1). Client ('C1') configures a default route and neighbor cache 1743 entry via the AERO interface with next-hop address fe80::2 and link- 1744 layer address L2(S1), then sub-delegates the ACP to its attached 1745 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1746 address 2001:db8:0::1. 1748 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1749 exchange via AERO Server ('S2') then assigns the address 1750 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1751 L2(C2). Client ('C2') configures a default route and neighbor cache 1752 entry via the AERO interface with next-hop address fe80::3 and link- 1753 layer address L2(S2), then sub-delegates the ACP to its attached 1754 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1755 address 2001:db8:1::1. 1757 3.17.2. Concept of Operations 1759 Again, with reference to Figure 8, when source host ('H1') sends a 1760 packet to destination host ('H2'), the packet is first forwarded over 1761 the source host's attached EUN to Client ('C1'). Client ('C1') then 1762 forwards the packet via its AERO interface to Server ('S1') and also 1763 sends a Predirect message toward Client ('C2') via Server ('S1'). 1764 Server ('S1') then re-encapsulates and forwards both the packet and 1765 the Predirect message out the same AERO interface toward Client 1766 ('C2') via Relay ('R1'). 1768 When Relay ('R1') receives the packet and Predirect message, it 1769 consults its forwarding table to discover Server ('S2') as the next 1770 hop toward Client ('C2'). Relay ('R1') then forwards both the packet 1771 and the Predirect message to Server ('S2'), which then forwards them 1772 to Client ('C2'). 1774 After Client ('C2') receives the Predirect message, it process the 1775 message and returns a Redirect message toward Client ('C1') via 1776 Server ('S2'). During the process, Client ('C2') also creates or 1777 updates a dynamic neighbor cache entry for Client ('C1'). 1779 When Server ('S2') receives the Redirect message, it re-encapsulates 1780 the message and forwards it on to Relay ('R1'), which forwards the 1781 message on to Server ('S1') which forwards the message on to Client 1782 ('C1'). After Client ('C1') receives the Redirect message, it 1783 processes the message and creates or updates a dynamic neighbor cache 1784 entry for Client ('C2'). 1786 Following the above Predirect/Redirect message exchange, forwarding 1787 of packets from Client ('C1') to Client ('C2') without involving any 1788 intermediate nodes is enabled. The mechanisms that support this 1789 exchange are specified in the following sections. 1791 3.17.3. Message Format 1793 AERO Redirect/Predirect messages use the same format as for ICMPv6 1794 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1795 include a new "Prefix Length" field taken from the low-order 8 bits 1796 of the Redirect message Reserved field. For IPv6, valid values for 1797 the Prefix Length field are 0 through 64; for IPv4, valid values are 1798 0 through 32. The Redirect/Predirect messages are formatted as shown 1799 in Figure 9: 1801 0 1 2 3 1802 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 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Type (=137) | Code (=0/1) | Checksum | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Reserved | Prefix Length | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | | 1809 + + 1810 | | 1811 + Target Address + 1812 | | 1813 + + 1814 | | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | | 1817 + + 1818 | | 1819 + Destination Address + 1820 | | 1821 + + 1822 | | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | Options ... 1825 +-+-+-+-+-+-+-+-+-+-+-+- 1827 Figure 9: AERO Redirect/Predirect Message Format 1829 3.17.4. Sending Predirects 1831 When a Client forwards a packet with a source address from one of its 1832 ACPs toward a destination address covered by an ASP (i.e., toward 1833 another AERO Client connected to the same AERO link), the source 1834 Client MAY send a Predirect message forward toward the destination 1835 Client via the Server. 1837 In the reference operational scenario, when Client ('C1') forwards a 1838 packet toward Client ('C2'), it MAY also send a Predirect message 1839 forward toward Client ('C2'), subject to rate limiting (see 1840 Section 8.2 of [RFC4861]). Client ('C1') prepares the Predirect 1841 message as follows: 1843 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1844 layer address of Client ('C1')). 1846 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1847 link-layer address of Server ('S1')). 1849 o the network-layer source address is set to fe80::2001:db8:0:0 1850 (i.e., the AERO address of Client ('C1')). 1852 o the network-layer destination address is set to fe80::2001:db8:1:0 1853 (i.e., the AERO address of Client ('C2')). 1855 o the Type is set to 137. 1857 o the Code is set to 1 to indicate "Predirect". 1859 o the Prefix Length is set to the length of the prefix to be 1860 assigned to the Target Address. 1862 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1863 address of Client ('C1')). 1865 o the Destination Address is set to the source address of the 1866 originating packet that triggered the Predirection event. (If the 1867 originating packet is an IPv4 packet, the address is constructed 1868 in IPv4-compatible IPv6 address format). 1870 o the message includes one or more TLLAOs with Link ID and DSCPs set 1871 to appropriate values for Client ('C1')'s underlying interfaces, 1872 and with UDP Port Number and IP Address set to 0'. 1874 o the message SHOULD include a Timestamp option and a Nonce option. 1876 o the message includes a Redirected Header Option (RHO) that 1877 contains the originating packet truncated if necessary to ensure 1878 that at least the network-layer header is included but the size of 1879 the message does not exceed 1280 bytes. 1881 Note that the act of sending Predirect messages is cited as "MAY", 1882 since Client ('C1') may have advanced knowledge that the direct path 1883 to Client ('C2') would be unusable or otherwise undesirable. If the 1884 direct path later becomes unusable after the initial route 1885 optimization, Client ('C1') simply allows packets to again flow 1886 through Server ('S1'). 1888 3.17.5. Re-encapsulating and Relaying Predirects 1890 When Server ('S1') receives a Predirect message from Client ('C1'), 1891 it first verifies that the TLLAOs in the Predirect are a proper 1892 subset of the Link IDs in Client ('C1')'s neighbor cache entry. If 1893 the Client's TLLAOs are not acceptable, Server ('S1') discards the 1894 message. Otherwise, Server ('S1') validates the message according to 1895 the ICMPv6 Redirect message validation rules in Section 8.1 of 1896 [RFC4861], except that the Predirect has Code=1. Server ('S1') also 1897 verifies that Client ('C1') is authorized to use the Prefix Length in 1898 the Predirect when applied to the AERO address in the network-layer 1899 source address by searching for the AERO address in the neighbor 1900 cache. If validation fails, Server ('S1') discards the Predirect; 1901 otherwise, it copies the correct UDP Port numbers and IP Addresses 1902 for Client ('C1')'s links into the (previously empty) TLLAOs. 1904 Server ('S1') then examines the network-layer destination address of 1905 the Predirect to determine the next hop toward Client ('C2') by 1906 searching for the AERO address in the neighbor cache. Since Client 1907 ('C2') is not one of its neighbors, Server ('S1') re-encapsulates the 1908 Predirect and relays it via Relay ('R1') by changing the link-layer 1909 source address of the message to 'L2(S1)' and changing the link-layer 1910 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1911 re-encapsulated message to Relay ('R1') without decrementing the 1912 network-layer TTL/Hop Limit field. 1914 When Relay ('R1') receives the Predirect message from Server ('S1') 1915 it determines that Server ('S2') is the next hop toward Client ('C2') 1916 by consulting its forwarding table. Relay ('R1') then re- 1917 encapsulates the Predirect while changing the link-layer source 1918 address to 'L2(R1)' and changing the link-layer destination address 1919 to 'L2(S2)'. Relay ('R1') then relays the Predirect via Server 1920 ('S2'). 1922 When Server ('S2') receives the Predirect message from Relay ('R1') 1923 it determines that Client ('C2') is a neighbor by consulting its 1924 neighbor cache. Server ('S2') then re-encapsulates the Predirect 1925 while changing the link-layer source address to 'L2(S2)' and changing 1926 the link-layer destination address to 'L2(C2)'. Server ('S2') then 1927 forwards the message to Client ('C2'). 1929 3.17.6. Processing Predirects and Sending Redirects 1931 When Client ('C2') receives the Predirect message, it accepts the 1932 Predirect only if the message has a link-layer source address of one 1933 of its Servers (e.g., L2(S2)). Client ('C2') further accepts the 1934 message only if it is willing to serve as a redirection target. 1935 Next, Client ('C2') validates the message according to the ICMPv6 1936 Redirect message validation rules in Section 8.1 of [RFC4861], except 1937 that it accepts the message even though Code=1 and even though the 1938 network-layer source address is not that of it's current first-hop 1939 router. 1941 In the reference operational scenario, when Client ('C2') receives a 1942 valid Predirect message, it either creates or updates a dynamic 1943 neighbor cache entry that stores the Target Address of the message as 1944 the network-layer address of Client ('C1') , stores the link-layer 1945 addresses found in the TLLAOs as the link-layer addresses of Client 1946 ('C1') and stores the Prefix Length as the length to be applied to 1947 the network-layer address for forwarding purposes. Client ('C2') 1948 then sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1950 After processing the message, Client ('C2') prepares a Redirect 1951 message response as follows: 1953 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 1954 layer address of Client ('C2')). 1956 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1957 link-layer address of Server ('S2')). 1959 o the network-layer source address is set to fe80::2001:db8:1:0 1960 (i.e., the AERO address of Client ('C2')). 1962 o the network-layer destination address is set to fe80::2001:db8:0:0 1963 (i.e., the AERO address of Client ('C1')). 1965 o the Type is set to 137. 1967 o the Code is set to 0 to indicate "Redirect". 1969 o the Prefix Length is set to the length of the prefix to be applied 1970 to the Target Address. 1972 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1973 address of Client ('C2')). 1975 o the Destination Address is set to the destination address of the 1976 originating packet that triggered the Redirection event. (If the 1977 originating packet is an IPv4 packet, the address is constructed 1978 in IPv4-compatible IPv6 address format). 1980 o the message includes one or more TLLAOs with Link ID and DSCPs set 1981 to appropriate values for Client ('C2')'s underlying interfaces, 1982 and with UDP Port Number and IP Address set to '0'. 1984 o the message SHOULD include a Timestamp option and MUST echo the 1985 Nonce option received in the Predirect (i.e., if a Nonce option is 1986 included). 1988 o the message includes as much of the RHO copied from the 1989 corresponding AERO Predirect message as possible such that at 1990 least the network-layer header is included but the size of the 1991 message does not exceed 1280 bytes. 1993 After Client ('C2') prepares the Redirect message, it sends the 1994 message to Server ('S2'). 1996 3.17.7. Re-encapsulating and Relaying Redirects 1998 When Server ('S2') receives a Redirect message from Client ('C2'), it 1999 first verifies that the TLLAOs in the Redirect are a proper subset of 2000 the Link IDs in Client ('C2')'s neighbor cache entry. If the 2001 Client's TLLAOs are not acceptable, Server ('S2') discards the 2002 message. Otherwise, Server ('S2') validates the message according to 2003 the ICMPv6 Redirect message validation rules in Section 8.1 of 2004 [RFC4861]. Server ('S2') also verifies that Client ('C2') is 2005 authorized to use the Prefix Length in the Redirect when applied to 2006 the AERO address in the network-layer source address by searching for 2007 the AERO address in the neighbor cache. If validation fails, Server 2008 ('S2') discards the Redirect; otherwise, it copies the correct UDP 2009 Port numbers and IP Addresses for Client ('C2')'s links into the 2010 (previously empty) TLLAOs. 2012 Server ('S2') then examines the network-layer destination address of 2013 the Redirect to determine the next hop toward Client ('C1') by 2014 searching for the AERO address in the neighbor cache. Since Client 2015 ('C1') is not a neighbor, Server ('S2') re-encapsulates the Redirect 2016 and relays it via Relay ('R1') by changing the link-layer source 2017 address of the message to 'L2(S2)' and changing the link-layer 2018 destination address to 'L2(R1)'. Server ('S2') finally forwards the 2019 re-encapsulated message to Relay ('R1') without decrementing the 2020 network-layer TTL/Hop Limit field. 2022 When Relay ('R1') receives the Redirect message from Server ('S2') it 2023 determines that Server ('S1') is the next hop toward Client ('C1') by 2024 consulting its forwarding table. Relay ('R1') then re-encapsulates 2025 the Redirect while changing the link-layer source address to 'L2(R1)' 2026 and changing the link-layer destination address to 'L2(S1)'. Relay 2027 ('R1') then relays the Redirect via Server ('S1'). 2029 When Server ('S1') receives the Redirect message from Relay ('R1') it 2030 determines that Client ('C1') is a neighbor by consulting its 2031 neighbor cache. Server ('S1') then re-encapsulates the Redirect 2032 while changing the link-layer source address to 'L2(S1)' and changing 2033 the link-layer destination address to 'L2(C1)'. Server ('S1') then 2034 forwards the message to Client ('C1'). 2036 3.17.8. Processing Redirects 2038 When Client ('C1') receives the Redirect message, it accepts the 2039 message only if it has a link-layer source address of one of its 2040 Servers (e.g., ''L2(S1)'). Next, Client ('C1') validates the message 2041 according to the ICMPv6 Redirect message validation rules in 2042 Section 8.1 of [RFC4861], except that it accepts the message even 2043 though the network-layer source address is not that of it's current 2044 first-hop router. Following validation, Client ('C1') then processes 2045 the message as follows. 2047 In the reference operational scenario, when Client ('C1') receives 2048 the Redirect message, it either creates or updates a dynamic neighbor 2049 cache entry that stores the Target Address of the message as the 2050 network-layer address of Client ('C2'), stores the link-layer 2051 addresses found in the TLLAOs as the link-layer addresses of Client 2052 ('C2') and stores the Prefix Length as the length to be applied to 2053 the network-layer address for forwarding purposes. Client ('C1') 2054 then sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 2056 Now, Client ('C1') has a neighbor cache entry with a valid 2057 ForwardTime value, while Client ('C2') has a neighbor cache entry 2058 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 2059 ordinary network-layer data packets directly to Client ('C2') without 2060 involving any intermediate nodes, and Client ('C2') can verify that 2061 the packets came from an acceptable source. (In order for Client 2062 ('C2') to forward packets to Client ('C1'), a corresponding 2063 Predirect/Redirect message exchange is required in the reverse 2064 direction; hence, the mechanism is asymmetric.) 2066 3.17.9. Server-Oriented Redirection 2068 In some environments, the Server nearest the target Client may need 2069 to serve as the redirection target, e.g., if direct Client-to-Client 2070 communications are not possible. In that case, the Server prepares 2071 the Redirect message the same as if it were the destination Client 2072 (see: Section 3.17.6), except that it writes its own link-layer 2073 address in the TLLAO option. The Server must then maintain a dynamic 2074 neighbor cache entry for the redirected source Client. 2076 3.17.10. Route Optimization Policy 2078 Although the Client is responsible for initiating route optimization 2079 through the transmission of Predirect messages, the Server is the 2080 policy enforcement point that determines whether route optimization 2081 is permitted. For example, on some AERO links route optimization 2082 would allow traffic to circumvent critical network-based traffic 2083 interception points. In those cases, the Server can deny route 2084 optimization requests by simply discarding any Predirect messages 2085 instead of forwarding them. 2087 3.17.11. Route Optimization and Multiple ACPs 2089 Clients that receive multiple non-contiguous ACP delegations must 2090 perform route optimization for each of the individual ACPs based on 2091 demand of traffic with source addresses taken from those prefixes. 2092 For example, if Client C1 has already performed route optimization 2093 for destination ACP X on behalf of its source ACP Y, it must also 2094 perform route optimization for X on behalf of its source ACP Z. As a 2095 result, source route optimization state cannot be shared between non- 2096 contiguous ACPs and must be managed separately. 2098 3.18. Neighbor Unreachability Detection (NUD) 2100 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 2101 unicast NS messages to elicit solicited NA messages from neighbors 2102 the same as described in [RFC4861]. NUD is performed either 2103 reactively in response to persistent L2 errors (see Section 3.14) or 2104 proactively to refresh existing neighbor cache entries. 2106 When an AERO node sends an NS/NA message, it MUST use its link-local 2107 address as the IPv6 source address and the link-local address of the 2108 neighbor as the IPv6 destination address. When an AERO node receives 2109 an NS message or a solicited NA message, it accepts the message if it 2110 has a neighbor cache entry for the neighbor; otherwise, it ignores 2111 the message. 2113 When a source Client is redirected to a target Client it SHOULD 2114 proactively test the direct path by sending an initial NS message to 2115 elicit a solicited NA response. While testing the path, the source 2116 Client can optionally continue sending packets via the Server, 2117 maintain a small queue of packets until target reachability is 2118 confirmed, or (optimistically) allow packets to flow directly to the 2119 target. The source Client SHOULD thereafter continue to test the 2120 direct path to the target Client (see Section 7.3 of [RFC4861]) 2121 periodically in order to keep dynamic neighbor cache entries alive. 2123 In particular, while the source Client is actively sending packets to 2124 the target Client it SHOULD also send NS messages separated by 2125 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 2126 If the source Client is unable to elicit a solicited NA response from 2127 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 2128 to 0 and resume sending packets via one of its Servers. Otherwise, 2129 the source Client considers the path usable and SHOULD thereafter 2130 process any link-layer errors as a hint that the direct path to the 2131 target Client has either failed or has become intermittent. 2133 When ForwardTime for a dynamic neighbor cache entry expires, the 2134 source Client resumes sending any subsequent packets via a Server and 2135 may (eventually) attempt to re-initiate the AERO redirection process. 2136 When AcceptTime for a dynamic neighbor cache entry expires, the 2137 target Client discards any subsequent packets received directly from 2138 the source Client. When both ForwardTime and AcceptTime for a 2139 dynamic neighbor cache entry expire, the Client deletes the neighbor 2140 cache entry. 2142 3.19. Mobility Management 2144 3.19.1. Announcing Link-Layer Address Changes 2146 When a Client needs to change its link-layer address, e.g., due to a 2147 mobility event, it performs an immediate DHCPv6 Rebind/Reply exchange 2148 via each of its Servers using the new link-layer address as the 2149 source address and with an ALREQ that includes the correct Link ID 2150 and DSCP values. If authentication succeeds, the Server then update 2151 its neighbor cache and sends a DHCPv6 Reply. Note that if the Client 2152 does not issue a DHCPv6 Rebind before the prefix delegation lifetime 2153 expires (e.g., if the Client has been out of touch with the Server 2154 for a considerable amount of time), the Server's Reply will report 2155 NoBinding and the Client must re-initiate the DHCPv6 PD procedure. 2157 Next, the Client sends Predirect messages to each of its 2158 correspondent Client neighbors using the same procedures as specified 2159 in Section 3.17.4. The Client sends the Predirect messages via a 2160 Server the same as if it was performing the initial route 2161 optimization procedure with the correspondent. The Predirect message 2162 will update the correspondent' link layer address mapping for the 2163 Client. 2165 3.19.2. Bringing New Links Into Service 2167 When a Client needs to bring a new underlying interface into service 2168 (e.g., when it activates a new data link), it performs an immediate 2169 Rebind/Reply exchange via each of its Servers using the new link- 2170 layer address as the source address and with an ALREQ that includes 2171 the new Link ID and DSCP values. If authentication succeeds, the 2172 Server then updates its neighbor cache and sends a DHCPv6 Reply. The 2173 Client MAY then send Predirect messages to each of its correspondent 2174 Clients to inform them of the new link-layer address as described in 2175 Section 3.19.1. 2177 3.19.3. Removing Existing Links from Service 2179 When a Client needs to remove an existing underlying interface from 2180 service (e.g., when it de-activates an existing data link), it 2181 performs an immediate Rebind/Reply exchange via each of its Servers 2182 over any available link with an ALDEL that includes the deprecated 2183 Link ID. If authentication succeeds, the Server then updates its 2184 neighbor cache and sends a DHCPv6 Reply. The Client SHOULD then send 2185 Predirect messages to each of its correspondent Clients to inform 2186 them of the deprecated link-layer address as described in 2187 Section 3.19.1. 2189 3.19.4. Moving to a New Server 2191 When a Client associates with a new Server, it performs the Client 2192 procedures specified in Section 3.15.2. 2194 When a Client disassociates with an existing Server, it sends a 2195 DHCPv6 Release message via a new Server to the unicast link-local 2196 network layer address of the old Server. The new Server then writes 2197 its own link-layer address in the DHCPv6 Release message IP source 2198 address and forwards the message to the old Server. 2200 When the old Server receives the DHCPv6 Release, it first 2201 authenticates the message. Next, it resets the Client's neighbor 2202 cache entry lifetime to 3 seconds, rewrites the link-layer address in 2203 the neighbor cache entry to the address of the new Server, then 2204 returns a DHCPv6 Reply message to the Client via the old Server. 2205 When the lifetime expires, the old Server withdraws the IP route from 2206 the AERO routing system and deletes the neighbor cache entry for the 2207 Client. The Client can then use the Reply message to verify that the 2208 termination signal has been processed, and can delete both the 2209 default route and the neighbor cache entry for the old Server. (Note 2210 that since Release/Reply messages may be lost in the network the 2211 Client MUST retry until it gets a Reply indicating that the Release 2212 was successful. If the Client does not receive a Reply after 2213 MAX_RETRY attempts, the old Server may have failed and the Client 2214 should discontinue its Release attempts.) 2216 Clients SHOULD NOT move rapidly between Servers in order to avoid 2217 causing excessive oscillations in the AERO routing system. Such 2218 oscillations could result in intermittent reachability for the Client 2219 itself, while causing little harm to the network. Examples of when a 2220 Client might wish to change to a different Server include a Server 2221 that has gone unreachable, topological movements of significant 2222 distance, etc. 2224 3.20. Proxy AERO 2226 Proxy Mobile IPv6 (PMIPv6) [RFC5213][RFC5844][RFC5949] presents a 2227 localized mobility management scheme for use within an access network 2228 domain. It is typically used in WiFi and cellular wireless access 2229 networks, and allows Mobile Nodes (MNs) to receive and retain an IP 2230 address that remains stable within the access network domain without 2231 needing to implement any special mobility protocols. In the PMIPv6 2232 architecture, access network devices known as Mobility Access 2233 Gateways (MAGs) provide MNs with an access link abstraction and 2234 receive prefixes for the MNs from a Local Mobility Anchor (LMA). 2236 In a proxy AERO domain, a proxy AERO Client (acting as a MAG) can 2237 similarly provide proxy services for MNs that do not participate in 2238 AERO messaging. The proxy Client presents an access link abstraction 2239 to MNs, and performs DHCPv6 PD exchanges over the AERO interface with 2240 an AERO Server (acting as an LMA) to receive ACPs for address 2241 provisioning of new MNs that come onto an access link. This scheme 2242 assumes that proxy Clients act as fixed (non-mobile) infrastructure 2243 elements under the same administrative trust basis as for Relays and 2244 Servers. 2246 When an MN comes onto an access link within a proxy AERO domain for 2247 the first time, the proxy Client authenticates the MN and obtains a 2248 unique identifier that it can use as a DHCPv6 DUID then issues a 2249 DHCPv6 PD Solicit/Request to its Server. When the Server delegates 2250 an ACP, the proxy Client creates an AERO address for the MN and 2251 assigns the ACP to the MN's access link. The proxy Client then 2252 configures itself as a default router for the MN and provides address 2253 autoconfiguration services (e.g., SLAAC, DHCPv6, DHCPv4, etc.) for 2254 provisioning MN addresses from the ACP over the access link. Since 2255 the proxy Client may serve many such MNs simultaneously, it may 2256 receive multiple ACP prefix delegations and configure multiple AERO 2257 addresses, i.e., one for each MN. 2259 When two MNs are associated with the same proxy Client, the Client 2260 can forward traffic between the MNs without involving a Server since 2261 it configures the AERO addresses of both MNs and therefore also has 2262 the necessary routing information. When two MNs are associated with 2263 different proxy Clients, the source MN's Client can initiate standard 2264 AERO intradomain route optimization to discover a direct path to the 2265 target MN's Client through the exchange of Predirect/Redirect 2266 messages. 2268 When an MN in a proxy AERO domain leaves an access link provided by 2269 an old proxy Client, the MN issues an access link-specific "leave" 2270 message that informs the old Client of the link-layer address of a 2271 new Client on the planned new access link. This is known as a 2272 "predictive handover". When an MN comes onto an access link provided 2273 by a new proxy Client, the MN issues an access link-specific "join" 2274 message that informs the new Client of the link-layer address of the 2275 old Client on the actual old access link. This is known as a 2276 "reactive handover". 2278 Upon receiving a predictive handover indication, the old proxy Client 2279 sends a DHCPv6 PD Solicit message directly to the new Client and 2280 queues any arriving data packets addressed to the departed MN. The 2281 Solicit message includes the MN's ID as the DUID, the ACP in an IA_PD 2282 option, the old Client's address as the link-layer source address and 2283 the new Client's address as the link-layer destination address. When 2284 the new Client receives the Solicit message, it changes the link- 2285 layer source address to its own address, changes the link-layer 2286 destination address to the address of its Server, and forwards the 2287 message to the Server. At the same time, the new Client creates 2288 access link state for the ACP in anticipation of the MN's arrival 2289 (while queuing any data packets until the MN arrives), creates a 2290 neighbor cache entry for the old Client with AcceptTime set to 2291 ACCEPT_TIME, then sends a Redirect message back to the old Client. 2292 When the old Client receives the Redirect message, it creates a 2293 neighbor cache entry for the new Client with ForwardTime set to 2294 FORWARD_TIME, then forwards any queued data packets to the new 2295 Client. At the same time, the old Client sends a DHCPv6 PD Release 2296 message to its Server. Finally, the old Client sends unsolicited 2297 Redirect messages to any of the ACP's correspondents with a TLLAO 2298 containing the link-layer address of the new Client. 2300 Upon receiving a reactive handover indication, the new proxy Client 2301 creates access link state for the MN's ACP, sends a DHCPv6 PD Solicit 2302 message to its Server, and sends a DHCPv6 PD Release message directly 2303 to the old Client. The Release message includes the MN's ID as the 2304 DUID, the ACP in an IA_PD option, the new Client's address as the 2305 link-layer source address and the old Client's address as the link- 2306 layer destination address. When the old Client receives the Release 2307 message, it changes the link-layer source address to its own address, 2308 changes the link-layer destination address to the address of its 2309 Server, and forwards the message to the Server. At the same time, 2310 the old Client sends a Predirect message back to the new Client and 2311 queues any arriving data packets addressed to the departed MN. When 2312 the new Client receives the Predirect, it creates a neighbor cache 2313 entry for the old Client with AcceptTime set to ACCEPT_TIME, then 2314 sends a Redirect message back to the old Client. When the old Client 2315 receives the Redirect message, it creates a neighbor cache entry for 2316 the new Client with ForwardTime set to FORWARD_TIME, then forwards 2317 any queued data packets to the new Client. Finally, the old Client 2318 sends unsolicited Redirect messages to correspondents the same as for 2319 the predictive case. 2321 When a Server processes a DHCPv6 Solicit message, it creates a 2322 neighbor cache entry for this ACP if none currently exists. If a 2323 neighbor cache entry already exists, however, the Server changes the 2324 link-layer address to the address of the new proxy Client (this 2325 satisfies the case of both the old Client and new Client using the 2326 same Server). 2328 When a Server processes a DHCPv6 Release message, it resets the 2329 neighbor cache entry lifetime for this ACP to 3 seconds if the cached 2330 link-layer address matches the old proxy Client's address. 2331 Otherwise, the Server ignores the Release message (this satisfies the 2332 case of both the old Client and new Client using the same Server). 2334 When a correspondent Client receives an unsolicited Redirect message, 2335 it changes the link-layer address for the ACP's neighbor cache entry 2336 to the address of the new proxy Client. 2338 From an architectural perspective, in addition to the use of DHCPv6 2339 PD and IPv6 ND signaling the AERO approach differs from PMIPv6 in its 2340 use of the NBMA virtual link model instead of point-to-point tunnels. 2341 This provides a more agile interface for Client/Server and Client/ 2342 Client coordinations, and also facilitates simple route optimization. 2343 The AERO routing system is also arranged in such a fashion that 2344 Clients get the same service from any Server they happen to associate 2345 with. This provides a natural fault tolerance and load balancing 2346 capability such as desired for distributed mobility management. 2348 3.21. Extending AERO Links Through Security Gateways 2350 When an enterprise mobile device moves from a campus LAN connection 2351 to a public Internet link, it must re-enter the enterprise via a 2352 security gateway that has both a physical interface connection to the 2353 Internet and a physical interface connection to the enterprise 2354 internetwork. This most often entails the establishment of a Virtual 2355 Private Network (VPN) link over the public Internet from the mobile 2356 device to the security gateway. During this process, the mobile 2357 device supplies the security gateway with its public Internet address 2358 as the link-layer address for the VPN. The mobile device then acts 2359 as an AERO Client to negotiate with the security gateway to obtain 2360 its ACP. 2362 In order to satisfy this need, the security gateway also operates as 2363 an AERO Server with support for AERO Client proxying. In particular, 2364 when a mobile device (i.e., the Client) connects via the security 2365 gateway (i.e., the Server), the Server provides the Client with an 2366 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2367 enterprise campus access link. The Server then replaces the Client's 2368 link-layer source address with the Server's enterprise-facing link- 2369 layer address in all AERO messages the Client sends toward neighbors 2370 on the AERO link. The AERO messages are then delivered to other 2371 devices on the AERO link as if they were originated by the security 2372 gateway instead of by the AERO Client. In the reverse direction, the 2373 AERO messages sourced by devices within the enterprise network can be 2374 forwarded to the security gateway, which then replaces the link-layer 2375 destination address with the Client's link-layer address and replaces 2376 the link-layer source address with its own (Internet-facing) link- 2377 layer address. 2379 After receiving the ACP, the Client can send IP packets that use an 2380 address taken from the ACP as the network layer source address, the 2381 Client's link-layer address as the link-layer source address, and the 2382 Server's Internet-facing link-layer address as the link-layer 2383 destination address. The Server will then rewrite the link-layer 2384 source address with the Server's own enterprise-facing link-layer 2385 address and rewrite the link-layer destination address with the 2386 target AERO node's link-layer address, and the packets will enter the 2387 enterprise network as though they were sourced from a device located 2388 within the enterprise. In the reverse direction, when a packet 2389 sourced by a node within the enterprise network uses a destination 2390 address from the Client's ACP, the packet will be delivered to the 2391 security gateway which then rewrites the link-layer destination 2392 address to the Client's link-layer address and rewrites the link- 2393 layer source address to the Server's Internet-facing link-layer 2394 address. The Server then delivers the packet across the VPN to the 2395 AERO Client. In this way, the AERO virtual link is essentially 2396 extended *through* the security gateway to the point at which the VPN 2397 link and AERO link are effectively grafted together by the link-layer 2398 address rewriting performed by the security gateway. All AERO 2399 messaging services (including route optimization and mobility 2400 signaling) are therefore extended to the Client. 2402 In order to support this virtual link grafting, the security gateway 2403 (acting as an AERO Server) must keep static neighbor cache entries 2404 for all of its associated Clients located on the public Internet. 2405 The neighbor cache entry is keyed by the AERO Client's AERO address 2406 the same as if the Client were located within the enterprise 2407 internetwork. The neighbor cache is then managed in all ways as 2408 though the Client were an ordinary AERO Client. This includes the 2409 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2410 Unreachability Detection. 2412 Note that the main difference between a security gateway acting as an 2413 AERO Server and an enterprise-internal AERO Server is that the 2414 security gateway has at least one enterprise-internal physical 2415 interface and at least one public Internet physical interface. 2416 Conversely, the enterprise-internal AERO Server has only enterprise- 2417 internal physical interfaces. For this reason security gateway 2418 proxying is needed to ensure that the public Internet link-layer 2419 addressing space is kept separate from the enterprise-internal link- 2420 layer addressing space. This is afforded through a natural extension 2421 of the security association caching already performed for each VPN 2422 client by the security gateway. 2424 3.22. Extending IPv6 AERO Links to the Internet 2426 When an IPv6 host ('H1') with an address from an ACP owned by AERO 2427 Client ('C1') sends packets to a correspondent IPv6 host ('H2'), the 2428 packets eventually arrive at the IPv6 router that owns ('H2')s 2429 prefix. This IPv6 router may or may not be an AERO Client ('C2') 2430 either within the same home network as ('C1') or in a different home 2431 network. 2433 If Client ('C1') is currently located outside the boundaries of its 2434 home network, it will connect back into the home network via a 2435 security gateway acting as an AERO Server. The packets sent by 2436 ('H1') via ('C1') will then be forwarded through the security gateway 2437 then through the home network and finally to ('C2') where they will 2438 be delivered to ('H2'). This could lead to sub-optimal performance 2439 when ('C2') could instead be reached via a more direct route without 2440 involving the security gateway. 2442 Consider the case when host ('H1') has the IPv6 address 2443 2001:db8:1::1, and Client ('C1') has the ACP 2001:db8:1::/64 with 2444 underlying IPv6 Internet address of 2001:db8:1000::1. Also, host 2445 ('H2') has the IPv6 address 2001:db8:2::1, and Client ('C2') has the 2446 ACP 2001:db8:2::/64 with underlying IPv6 address of 2001:db8:2000::1. 2447 Client ('C1') can determine whether 'C2' is indeed also an AERO 2448 Client willing to serve as a route optimization correspondent by 2449 resolving the AAAA records for the DNS FQDN that matches ('H2')s 2450 prefix, i.e.: 2452 '0.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net' 2454 If ('C2') is indeed a candidate correspondent, the FQDN lookup will 2455 return a PTR resource record that contains the domain name for the 2456 AERO link that manages ('C2')s ASP. Client ('C1') can then attempt 2457 route optimization using an approach similar to the Return 2458 Routability procedure specified for Mobile IPv6 (MIPv6) [RFC6275]. 2459 In order to support this process, both Clients MUST intercept and 2460 decapsulate packets that have a subnet router anycast address 2461 corresponding to any of the /64 prefixes covered by their respective 2462 ACPs. 2464 To initiate the process, Client ('C1') creates a specially-crafted 2465 encapsulated AERO Predirect message that will be routed through its 2466 home network then through ('C2')s home network and finally to ('C2') 2467 itself. Client ('C1') prepares the initial message in the exchange 2468 as follows: 2470 o The encapsulating IPv6 header source address is set to 2471 2001:db8:1:: (i.e., the IPv6 subnet router anycast address for 2472 ('C1')s ACP) 2474 o The encapsulating IPv6 header destination address is set to 2475 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2476 ('C2')s ACP) 2478 o The encapsulating IPv6 header is followed by any additional 2479 encapsulation headers 2481 o The encapsulated IPv6 header source address is set to 2482 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2484 o The encapsulated IPv6 header destination address is set to 2485 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2487 o The encapsulated AERO Predirect message includes all of the 2488 securing information that would occur in a MIPv6 "Home Test Init" 2489 message (format TBD) 2491 Client ('C1') then further encapsulates the message in the 2492 encapsulating headers necessary to convey the packet to the security 2493 gateway (e.g., through IPsec encapsulation) so that the message now 2494 appears "double-encapsulated". ('C1') then sends the message to the 2495 security gateway, which re-encapsulates and forwards it over the home 2496 network from where it will eventually reach ('C2'). 2498 At the same time, ('C1') creates and sends a second encapsulated AERO 2499 Predirect message that will be routed through the IPv6 Internet 2500 without involving the security gateway. Client ('C1') prepares the 2501 message as follows: 2503 o The encapsulating IPv6 header source address is set to 2504 2001:db8:1000:1 (i.e., the Internet IPv6 address of ('C1')) 2506 o The encapsulating IPv6 header destination address is set to 2507 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2508 ('C2')s ACP) 2510 o The encapsulating IPv6 header is followed by any additional 2511 encapsulation headers 2513 o The encapsulated IPv6 header source address is set to 2514 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2516 o The encapsulated IPv6 header destination address is set to 2517 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2519 o The encapsulated AERO Predirect message includes all of the 2520 securing information that would occur in a MIPv6 "Care-of Test 2521 Init" message (format TBD) 2523 ('C2') will receive both Predirect messages through its home network 2524 then return a corresponding Redirect for each of the Predirect 2525 messages with the source and destination addresses in the inner and 2526 outer headers reversed. The first message includes all of the 2527 securing information that would occur in a MIPv6 "Home Test" message, 2528 while the second message includes all of the securing information 2529 that would occur in a MIPv6 "Care-of Test" message (formats TBD). 2531 When ('C1') receives the Redirect messages, it performs the necessary 2532 security procedures per the MIPv6 specification. It then prepares an 2533 encapsulated NS message that includes the same source and destination 2534 addresses as for the "Care-of Test Init" Predirect message, and 2535 includes all of the securing information that would occur in a MIPv6 2536 "Binding Update" message (format TBD) and sends the message to 2537 ('C2'). 2539 When ('C2') receives the NS message, if the securing information is 2540 correct it creates or updates a neighbor cache entry for ('C1') with 2541 fe80::2001:db8:1:0 as the network-layer address, 2001:db8:1000::1 as 2542 the link-layer address and with AcceptTime set to ACCEPT_TIME. 2543 ('C2') then sends an encapsulated NA message back to ('C1') that 2544 includes the same source and destination addresses as for the "Care- 2545 of Test" Redirect message, and includes all of the securing 2546 information that would occur in a MIPv6 "Binding Acknowledgement" 2547 message (format TBD) and sends the message to ('C1'). 2549 When ('C1') receives the NA message, it creates or updates a neighbor 2550 cache entry for ('C2') with fe80::2001:db8:2:0 as the network-layer 2551 address and 2001:db8:2:: as the link-layer address and with 2552 ForwardTime set to FORWARD_TIME, thus completing the route 2553 optimization in the forward direction. 2555 ('C1') subsequently forwards encapsulated packets with outer source 2556 address 2001:db8:1000::1, with outer destination address 2557 2001:db8:2::, with inner source address taken from the 2001:db8:1::, 2558 and with inner destination address taken from 2001:db8:2:: due to the 2559 fact that it has a securely-established neighbor cache entry with 2560 non-zero ForwardTime. ('C2') subsequently accepts any such 2561 encapsulated packets due to the fact that it has a securely- 2562 established neighbor cache entry with non-zero AcceptTime. 2564 In order to keep neighbor cache entries alive, ('C1') periodically 2565 sends additional NS messages to ('C2') and receives any NA responses. 2566 If ('C1') moves to a different point of attachment after the initial 2567 route optimization, it sends a new secured NS message to ('C2') as 2568 above to update ('C2')s neighbor cache. 2570 If ('C2') has packets to send to ('C1'), it performs a corresponding 2571 route optimization in the opposite direction following the same 2572 procedures described above. In the process, the already-established 2573 unidirectional neighbor cache entries within ('C1') and ('C2') are 2574 updated to include the now-bidirectional information. In particular, 2575 the AcceptTime and ForwardTime variables for both neighbor cache 2576 entries are updated to non-zero values, and the link-layer address 2577 for ('C1')s neighbor cache entry for ('C2') is reset to 2578 2001:db8:2000::1. 2580 Note that two AERO Clients can use full security protocol messaging 2581 instead of Return Routability, e.g., if strong authentication and/or 2582 confidentiality are desired. In that case, security protocol key 2583 exchanges such as specified for MOBIKE [RFC4555] would be used to 2584 establish security associations and neighbor cache entries between 2585 the AERO clients. Thereafter, AERO NS/NA messaging can be used to 2586 maintain neighbor cache entries, test reachability, and to announce 2587 mobility events. If reachability testing fails, e.g., if both 2588 Clients move at roughly the same time, the Clients can tear down the 2589 security association and neighbor cache entries and again allow 2590 packets to flow through their home network. 2592 3.23. Encapsulation Protocol Version Considerations 2594 A source Client may connect only to an IPvX underlying network, while 2595 the target Client connects only to an IPvY underlying network. In 2596 that case, the target and source Clients have no means for reaching 2597 each other directly (since they connect to underlying networks of 2598 different IP protocol versions) and so must ignore any redirection 2599 messages and continue to send packets via their Servers. 2601 3.24. Multicast Considerations 2603 When the underlying network does not support multicast, AERO Clients 2604 map link-scoped multicast addresses (including 2605 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 2606 Server. The AERO Client also serves as an IGMP/MLD Proxy for its 2607 EUNs and/or hosted applications per [RFC4605] while using the link- 2608 layer address of the Server as the link-layer address for all 2609 multicast packets. 2611 When the underlying network supports multicast, AERO nodes use the 2612 multicast address mapping specification found in [RFC2529] for IPv4 2613 underlying networks and use a TBD site-scoped multicast mapping for 2614 IPv6 underlying networks. In that case, border routers must ensure 2615 that the encapsulated site-scoped multicast packets do not leak 2616 outside of the site spanned by the AERO link. 2618 3.25. Operation on AERO Links Without DHCPv6 Services 2620 When Servers on the AERO link do not provide DHCPv6 services, 2621 operation can still be accommodated through administrative 2622 configuration of ACPs on AERO Clients. In that case, administrative 2623 configurations of AERO interface neighbor cache entries on both the 2624 Server and Client are also necessary. However, this may interfere 2625 with the ability for Clients to dynamically change to new Servers, 2626 and can expose the AERO link to misconfigurations unless the 2627 administrative configurations are carefully coordinated. 2629 3.26. Operation on Server-less AERO Links 2631 In some AERO link scenarios, there may be no Servers on the link and/ 2632 or no need for Clients to use a Server as an intermediary trust 2633 anchor. In that case, each Client acts as a Server unto itself to 2634 establish neighbor cache entries by performing direct Client-to- 2635 Client IPv6 ND message exchanges, and some other form of trust basis 2636 must be applied so that each Client can verify that the prospective 2637 neighbor is authorized to use its claimed ACP. 2639 When there is no Server on the link, Clients must arrange to receive 2640 ACPs and publish them via a secure alternate prefix delegation 2641 authority through some means outside the scope of this document. 2643 3.27. Manually-Configured AERO Tunnels 2645 In addition to the dynamic neighbor discovery procedures for AERO 2646 link neighbors described above, AERO encapsulation can be applied to 2647 manually-configured tunnels. In that case, the tunnel endpoints use 2648 an administratively-assigned link-local address and exchange NS/NA 2649 messages the same as for dynamically-established tunnels. 2651 3.28. Intradomain Routing 2653 After a tunnel neighbor relationship has been established, neighbors 2654 can use a traditional dynamic routing protocol over the tunnel to 2655 exchange routing information without having to inject the routes into 2656 the AERO routing system. 2658 4. Implementation Status 2660 User-level and kernel-level AERO implementations have been developed 2661 and are undergoing internal testing within Boeing. 2663 An initial public release of the AERO source code was announced on 2664 the intarea mailing list on August 21, 2015, and a pointer to the 2665 code is available in the list archives. 2667 5. IANA Considerations 2669 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2670 AERO in the "enterprise-numbers" registry. 2672 The IANA has assigned the UDP port number "8060" for an earlier 2673 experimental version of AERO [RFC6706]. This document obsoletes 2674 [RFC6706] and claims the UDP port number "8060" for all future use. 2676 No further IANA actions are required. 2678 6. Security Considerations 2680 AERO link security considerations are the same as for standard IPv6 2681 Neighbor Discovery [RFC4861] except that AERO improves on some 2682 aspects. In particular, AERO uses a trust basis between Clients and 2683 Servers, where the Clients only engage in the AERO mechanism when it 2684 is facilitated by a trust anchor. Unless there is some other means 2685 of authenticating the Client's identity (e.g., link-layer security), 2686 AERO nodes SHOULD also use DHCPv6 securing services (e.g., DHCPv6 2687 authentication, Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6], etc.) for 2688 Client authentication and network admission control. In particular, 2689 Clients SHOULD include authenticating information on each 2690 Solicit/Request/Rebind/Release message they send, but omit 2691 authenticating information on Renew messages. Renew messages are 2692 exempt due to the fact that the Renew must already be checked for 2693 having a correct link-layer address and does not update any link- 2694 layer addresses. Therefore, asking the Server to also authenticate 2695 the Renew message would be unnecessary and could result in excessive 2696 processing overhead. 2698 AERO Redirect, Predirect and unsolicited NA messages SHOULD include a 2699 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2700 can use to verify the message time of origin. AERO Predirect, NS and 2701 RS messages SHOULD include a Nonce option (see Section 5.3 of 2702 [RFC3971]) that recipients echo back in corresponding responses. 2704 AERO links must be protected against link-layer address spoofing 2705 attacks in which an attacker on the link pretends to be a trusted 2706 neighbor. Links that provide link-layer securing mechanisms (e.g., 2707 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2708 enterprise network wired LANs) provide a first line of defense that 2709 is often sufficient. In other instances, additional securing 2710 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 2711 [RFC4301] or TLS [RFC5246] may be necessary. 2713 AERO Clients MUST ensure that their connectivity is not used by 2714 unauthorized nodes on their EUNs to gain access to a protected 2715 network, i.e., AERO Clients that act as routers MUST NOT provide 2716 routing services for unauthorized nodes. (This concern is no 2717 different than for ordinary hosts that receive an IP address 2718 delegation but then "share" the address with unauthorized nodes via a 2719 NAT function.) 2721 On some AERO links, establishment and maintenance of a direct path 2722 between neighbors requires secured coordination such as through the 2723 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 2724 security association. 2726 An AERO Client's link-layer address could be rewritten by a link- 2727 layer switching element on the path from the Client to the Server and 2728 not detected by the DHCPv6 security mechanism. However, such a 2729 condition would only be a matter of concern on unmanaged/unsecured 2730 links where the link-layer switching elements themselves present a 2731 man-in-the-middle attack threat. For this reason, IP security MUST 2732 be used when AERO is employed over unmanaged/unsecured links. 2734 7. Acknowledgements 2736 Discussions both on IETF lists and in private exchanges helped shape 2737 some of the concepts in this work. Individuals who contributed 2738 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, 2739 Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, Adrian 2740 Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom Herbert, 2741 Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, 2742 Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2743 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. 2744 Members of the IESG also provided valuable input during their review 2745 process that greatly improved the document. Discussions on the v6ops 2746 list in the December 2015 through January 2016 timeframe further 2747 helped clarify AERO multi-addressing capabilities. Special thanks go 2748 to Stewart Bryant, Joel Halpern and Brian Haberman for their 2749 shepherding guidance during the publication of the AERO first 2750 edition. 2752 This work has further been encouraged and supported by Boeing 2753 colleagues including Dave Bernhardt, Cam Brodie, Balaguruna 2754 Chidambaram, Irene Chin, Bruce Cornish, Claudiu Danilov, Wen Fang, 2755 Anthony Gregory, Jeff Holland, Ed King, Gen MacLean, Rob Muszkiewicz, 2756 Sean O'Sullivan, Kent Shuey, Brian Skeen, Mike Slane, Brendan 2757 Williams, Julie Wulff, Yueli Yang, and other members of the BR&T and 2758 BIT mobile networking teams. 2760 Earlier works on NBMA tunneling approaches are found in 2761 [RFC2529][RFC5214][RFC5569]. 2763 Many of the constructs presented in this second edition of AERO are 2764 based on the author's earlier works, including: 2766 o The Internet Routing Overlay Network (IRON) 2767 [RFC6179][I-D.templin-ironbis] 2769 o Virtual Enterprise Traversal (VET) 2770 [RFC5558][I-D.templin-intarea-vet] 2772 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2773 [RFC5320][I-D.templin-intarea-seal] 2775 o AERO, First Edition [RFC6706] 2777 Note that these works cite numerous earlier efforts that are not also 2778 cited here due to space limitations. The authors of those earlier 2779 works are acknowledged for their insights. 2781 8. References 2783 8.1. Normative References 2785 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2786 DOI 10.17487/RFC0768, August 1980, 2787 . 2789 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2790 DOI 10.17487/RFC0791, September 1981, 2791 . 2793 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2794 RFC 792, DOI 10.17487/RFC0792, September 1981, 2795 . 2797 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2798 DOI 10.17487/RFC2003, October 1996, 2799 . 2801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2802 Requirement Levels", BCP 14, RFC 2119, 2803 DOI 10.17487/RFC2119, March 1997, 2804 . 2806 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2807 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2808 December 1998, . 2810 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2811 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2812 December 1998, . 2814 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2815 "Definition of the Differentiated Services Field (DS 2816 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2817 DOI 10.17487/RFC2474, December 1998, 2818 . 2820 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2821 C., and M. Carney, "Dynamic Host Configuration Protocol 2822 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2823 2003, . 2825 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2826 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2827 DOI 10.17487/RFC3633, December 2003, 2828 . 2830 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2831 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2832 DOI 10.17487/RFC3971, March 2005, 2833 . 2835 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2836 for IPv6 Hosts and Routers", RFC 4213, 2837 DOI 10.17487/RFC4213, October 2005, 2838 . 2840 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2841 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2842 DOI 10.17487/RFC4861, September 2007, 2843 . 2845 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2846 Address Autoconfiguration", RFC 4862, 2847 DOI 10.17487/RFC4862, September 2007, 2848 . 2850 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2851 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2852 2011, . 2854 8.2. Informative References 2856 [I-D.herbert-gue-fragmentation] 2857 Herbert, T. and F. Templin, "Fragmentation option for 2858 Generic UDP Encapsulation", draft-herbert-gue- 2859 fragmentation-02 (work in progress), October 2015. 2861 [I-D.ietf-dhc-sedhcpv6] 2862 Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. 2863 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-10 (work 2864 in progress), December 2015. 2866 [I-D.ietf-nvo3-gue] 2867 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2868 Encapsulation", draft-ietf-nvo3-gue-02 (work in progress), 2869 December 2015. 2871 [I-D.templin-intarea-grefrag] 2872 Templin, F., "GRE Tunnel Fragmentation", draft-templin- 2873 intarea-grefrag-01 (work in progress), August 2015. 2875 [I-D.templin-intarea-seal] 2876 Templin, F., "The Subnetwork Encapsulation and Adaptation 2877 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2878 progress), January 2014. 2880 [I-D.templin-intarea-vet] 2881 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2882 templin-intarea-vet-40 (work in progress), May 2013. 2884 [I-D.templin-ironbis] 2885 Templin, F., "The Interior Routing Overlay Network 2886 (IRON)", draft-templin-ironbis-16 (work in progress), 2887 March 2014. 2889 [I-D.vandevelde-idr-remote-next-hop] 2890 Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, 2891 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 2892 hop-09 (work in progress), March 2015. 2894 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 2895 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 2896 . 2898 [RFC1035] Mockapetris, P., "Domain names - implementation and 2899 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2900 November 1987, . 2902 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2903 Communication Layers", STD 3, RFC 1122, 2904 DOI 10.17487/RFC1122, October 1989, 2905 . 2907 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2908 DOI 10.17487/RFC1191, November 1990, 2909 . 2911 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 2912 RFC 1812, DOI 10.17487/RFC1812, June 1995, 2913 . 2915 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2916 selection, and registration of an Autonomous System (AS)", 2917 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 2918 . 2920 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 2921 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 2922 1996, . 2924 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2925 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2926 . 2928 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2929 Domains without Explicit Tunnels", RFC 2529, 2930 DOI 10.17487/RFC2529, March 1999, 2931 . 2933 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2934 RFC 2675, DOI 10.17487/RFC2675, August 1999, 2935 . 2937 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 2938 Malis, "A Framework for IP Based Virtual Private 2939 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 2940 . 2942 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2943 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2944 DOI 10.17487/RFC2784, March 2000, 2945 . 2947 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 2948 RFC 2890, DOI 10.17487/RFC2890, September 2000, 2949 . 2951 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2952 RFC 2923, DOI 10.17487/RFC2923, September 2000, 2953 . 2955 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2956 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2957 . 2959 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2960 of Explicit Congestion Notification (ECN) to IP", 2961 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2962 . 2964 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 2965 "DNS Extensions to Support IP Version 6", RFC 3596, 2966 DOI 10.17487/RFC3596, October 2003, 2967 . 2969 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2970 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2971 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2972 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2973 . 2975 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2976 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2977 DOI 10.17487/RFC4271, January 2006, 2978 . 2980 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2981 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2982 2006, . 2984 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2985 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2986 December 2005, . 2988 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2989 Control Message Protocol (ICMPv6) for the Internet 2990 Protocol Version 6 (IPv6) Specification", RFC 4443, 2991 DOI 10.17487/RFC4443, March 2006, 2992 . 2994 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2995 Protocol (LDAP): The Protocol", RFC 4511, 2996 DOI 10.17487/RFC4511, June 2006, 2997 . 2999 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3000 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 3001 . 3003 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 3004 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 3005 . 3007 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3008 "Internet Group Management Protocol (IGMP) / Multicast 3009 Listener Discovery (MLD)-Based Multicast Forwarding 3010 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 3011 August 2006, . 3013 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3014 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 3015 . 3017 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3018 Errors at High Data Rates", RFC 4963, 3019 DOI 10.17487/RFC4963, July 2007, 3020 . 3022 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 3023 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 3024 DOI 10.17487/RFC4994, September 2007, 3025 . 3027 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 3028 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 3029 RFC 5213, DOI 10.17487/RFC5213, August 2008, 3030 . 3032 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3033 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3034 DOI 10.17487/RFC5214, March 2008, 3035 . 3037 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3038 (TLS) Protocol Version 1.2", RFC 5246, 3039 DOI 10.17487/RFC5246, August 2008, 3040 . 3042 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 3043 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 3044 February 2010, . 3046 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 3047 for the Address Resolution Protocol (ARP)", RFC 5494, 3048 DOI 10.17487/RFC5494, April 2009, 3049 . 3051 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 3052 Route Optimization Requirements for Operational Use in 3053 Aeronautics and Space Exploration Mobile Networks", 3054 RFC 5522, DOI 10.17487/RFC5522, October 2009, 3055 . 3057 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 3058 RFC 5558, DOI 10.17487/RFC5558, February 2010, 3059 . 3061 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 3062 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 3063 January 2010, . 3065 [RFC5720] Templin, F., "Routing and Addressing in Networks with 3066 Global Enterprise Recursion (RANGER)", RFC 5720, 3067 DOI 10.17487/RFC5720, February 2010, 3068 . 3070 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 3071 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 3072 . 3074 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 3075 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 3076 DOI 10.17487/RFC5949, September 2010, 3077 . 3079 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 3080 "Internet Key Exchange Protocol Version 2 (IKEv2)", 3081 RFC 5996, DOI 10.17487/RFC5996, September 2010, 3082 . 3084 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3085 NAT64: Network Address and Protocol Translation from IPv6 3086 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3087 April 2011, . 3089 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 3090 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 3091 . 3093 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 3094 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 3095 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 3096 . 3098 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 3099 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 3100 DOI 10.17487/RFC6221, May 2011, 3101 . 3103 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3104 and A. Bierman, Ed., "Network Configuration Protocol 3105 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3106 . 3108 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 3109 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 3110 2011, . 3112 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 3113 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 3114 DOI 10.17487/RFC6355, August 2011, 3115 . 3117 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 3118 RFC 6422, DOI 10.17487/RFC6422, December 2011, 3119 . 3121 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 3122 for Equal Cost Multipath Routing and Link Aggregation in 3123 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3124 . 3126 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 3127 RFC 6691, DOI 10.17487/RFC6691, July 2012, 3128 . 3130 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3131 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3132 . 3134 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 3135 RFC 6864, DOI 10.17487/RFC6864, February 2013, 3136 . 3138 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3139 UDP Checksums for Tunneled Packets", RFC 6935, 3140 DOI 10.17487/RFC6935, April 2013, 3141 . 3143 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3144 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3145 RFC 6936, DOI 10.17487/RFC6936, April 2013, 3146 . 3148 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 3149 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 3150 May 2013, . 3152 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 3153 with IPv6 Neighbor Discovery", RFC 6980, 3154 DOI 10.17487/RFC6980, August 2013, 3155 . 3157 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 3158 Address Selection Policy Using DHCPv6", RFC 7078, 3159 DOI 10.17487/RFC7078, January 2014, 3160 . 3162 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 3163 October 2014. 3165 Appendix A. AERO Minimal Encapsulation 3167 When GUE encapsulation is not needed, AERO can use common minimal 3168 encapsulations such as IP-in-IP [RFC2003][RFC2473][RFC4213], Generic 3169 Routing Encapsulation (GRE) [RFC2784][RFC2890] and others. The 3170 encapsulation is therefore only differentiated from non-AERO tunnels 3171 through the application of AERO control messaging and not through, 3172 e.g., a well-known UDP port number. 3174 As for GUE encapsulation, AERO minimal encapsulation formats may 3175 require encapsulation layer fragmentation. For simple IP-in-IP 3176 encapsulation, an IPv6 fragment header is inserted directly between 3177 the inner and outer IP headers when needed, i.e., even if the outer 3178 header is IPv4. The IPv6 Fragment Header is identified to the outer 3179 IP layer by its IP protocol number, and the Next Header field in the 3180 IPv6 Fragment Header identifies the inner IP header version. For GRE 3181 encapsulation, a GRE fragment header is inserted within the GRE 3182 header [I-D.templin-intarea-grefrag]. 3184 Figure 10 shows the AERO IP-in-IP minimal encapsulation format before 3185 any fragmentation is applied: 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3188 | Outer IPv4 Header | | Outer IPv6 Header | 3189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3190 |IPv6 Frag Header (optional)| |IPv6 Frag Header (optional)| 3191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 | Inner IP Header | | Inner IP Header | 3193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3194 | | | | 3195 ~ ~ ~ ~ 3196 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 3197 ~ ~ ~ ~ 3198 | | | | 3199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3201 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 3203 Figure 10: Minimal Encapsulation Format using IP-in-IP 3205 Figure 11 shows the AERO GRE minimal encapsulation format before any 3206 fragmentation is applied: 3208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 | Outer IP Header | 3210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3211 | GRE Header | 3212 | (with checksum, key, etc..) | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 | GRE Fragment Header (optional)| 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3216 | Inner IP Header | 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3218 | | 3219 ~ ~ 3220 ~ Inner Packet Body ~ 3221 ~ ~ 3222 | | 3223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3225 Figure 11: Minimal Encapsulation Using GRE 3227 Minimal encapsulation may be preferred in environments where GUE 3228 encapsulation would add unnecessary overhead. For example, certain 3229 low-bandwidth wireless data links may benefit from a reduced 3230 encapsulation overhead. 3232 GUE encapsulation can traverse network paths that are inaccessible to 3233 minimal encapsulation, e.g., for crossing Network Address Translators 3234 (NATs). More and more, network middleboxes are also being configured 3235 to discard packets that include anything other than a well-known IP 3236 protocol such as UDP and TCP. It may therefore be necessary to 3237 determine the potential for middlebox filtering before enabling 3238 minimal encapsulation in a given environment. 3240 Appendix B. When to Insert an Encapsulation Fragment Header 3242 An encapsulation fragment header is inserted when the AERO tunnel 3243 ingress needs to apply fragmentation to accommodate packets that must 3244 be delivered without loss due to a size restriction. Fragmentation 3245 is performed on the inner packet while encapsulating each inner 3246 packet fragment in outer IP and encapsulation layer headers that 3247 differ only in the Offset and MF values. 3249 The fragment header can also be inserted in order to include a 3250 coherent Identification value with each packet, e.g., to aid in 3251 Duplicate Packet Detection (DPD). In this way, network nodes can 3252 cache the Identification values of recently-seen packets and use the 3253 cached values to determine whether a newly-arrived packet is in fact 3254 a duplicate. The Identification value within each packet could 3255 further provide a rough indicator of packet reordering, e.g., in 3256 cases when the tunnel egress wishes to discard packets that are 3257 grossly out of order. 3259 In some use cases, there may be operational assurance that no 3260 fragmentation of any kind will be necessary, or that only occasional 3261 large control messages will require fragmentation. In that case, the 3262 encapsulation fragment header can be omitted and ordinary 3263 fragmentation of the outer IP protocol version can be applied when 3264 necessary. 3266 Appendix C. AERO Operation Over Native Links 3268 AERO can also operate over native links using no encapsulation at 3269 all. In that case, AERO Clients can identify AERO Servers on the 3270 link through their link-layer addresses, and the AERO prefix 3271 delegation, mobility management, fault tolerance and route 3272 optimization facilities operate on the native link the same as over 3273 an NBMA tunnel overlay. 3275 Author's Address 3276 Fred L. Templin (editor) 3277 Boeing Research & Technology 3278 P.O. Box 3707 3279 Seattle, WA 98124 3280 USA 3282 Email: fltemplin@acm.org