idnits 2.17.1 draft-templin-aerolink-60.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 (August 4, 2015) is 3181 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 974, but not defined == Unused Reference: 'RFC0768' is defined on line 2884, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 2896, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 2934, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 2944, but no explicit reference was found in the text == Unused Reference: 'I-D.vandevelde-idr-remote-next-hop' is defined on line 2984, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2989, but no explicit reference was found in the text == Unused Reference: 'RFC1930' is defined on line 3005, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 3032, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 3102, but no explicit reference was found in the text == Unused Reference: 'RFC5494' is defined on line 3126, but no explicit reference was found in the text == Unused Reference: 'RFC5720' is defined on line 3145, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 3164, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 3173, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 3183, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 3192, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 3206, but no explicit reference was found in the text == Unused Reference: 'RFC6935' is defined on line 3218, but no explicit reference was found in the text == Unused Reference: 'RFC6936' is defined on line 3223, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 3232, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 3237, 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 (-02) exists of draft-herbert-gue-fragmentation-00 == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-08 == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-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 (~~), 26 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc5320, rfc5558, rfc5720, August 4, 2015 5 rfc6179, rfc6706 (if 6 approved) 7 Intended status: Standards Track 8 Expires: February 5, 2016 10 Asymmetric Extended Route Optimization (AERO) 11 draft-templin-aerolink-60.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 February 5, 2016. 48 Copyright Notice 50 Copyright (c) 2015 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 Link Routing System . . . . . . . . . . . . . . . . 13 79 3.8. AERO Interface Neighbor Cache Maintenace . . . . . . . . 15 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 . . . . . . . . . . 20 85 3.13.1. All Elements in Same Administrative Domain . . . . . 20 86 3.13.2. Some Elements in Different Administrative Domain . . 21 87 3.13.3. Accommodating Large Control Messages . . . . . . . . 23 88 3.13.4. Integrity . . . . . . . . . . . . . . . . . . . . . 24 89 3.14. AERO Interface Error Handling . . . . . . . . . . . . . . 25 90 3.15. AERO Router Discovery, Prefix Delegation and Address 91 Configuration . . . . . . . . . . . . . . . . . . . . . . 29 92 3.15.1. AERO DHCPv6 Service Model . . . . . . . . . . . . . 29 93 3.15.2. AERO Client Behavior . . . . . . . . . . . . . . . . 30 94 3.15.3. AERO Server Behavior . . . . . . . . . . . . . . . . 33 95 3.15.4. Deleting Link Registrations . . . . . . . . . . . . 36 97 3.16. AERO Forwarding Agent Behavior . . . . . . . . . . . . . 37 98 3.17. AERO Intradomain Route Optimization . . . . . . . . . . . 37 99 3.17.1. Reference Operational Scenario . . . . . . . . . . . 38 100 3.17.2. Concept of Operations . . . . . . . . . . . . . . . 39 101 3.17.3. Message Format . . . . . . . . . . . . . . . . . . . 40 102 3.17.4. Sending Predirects . . . . . . . . . . . . . . . . . 40 103 3.17.5. Re-encapsulating and Relaying Predirects . . . . . . 42 104 3.17.6. Processing Predirects and Sending Redirects . . . . 42 105 3.17.7. Re-encapsulating and Relaying Redirects . . . . . . 44 106 3.17.8. Processing Redirects . . . . . . . . . . . . . . . . 45 107 3.17.9. Server-Oriented Redirection . . . . . . . . . . . . 45 108 3.18. Neighbor Unreachability Detection (NUD) . . . . . . . . . 46 109 3.19. Mobility Management . . . . . . . . . . . . . . . . . . . 47 110 3.19.1. Announcing Link-Layer Address Changes . . . . . . . 47 111 3.19.2. Bringing New Links Into Service . . . . . . . . . . 48 112 3.19.3. Removing Existing Links from Service . . . . . . . . 49 113 3.19.4. Moving to a New Server . . . . . . . . . . . . . . . 49 114 3.20. Proxy AERO . . . . . . . . . . . . . . . . . . . . . . . 50 115 3.21. Extending AERO Links Through Security Gateways . . . . . 52 116 3.22. Extending IPv6 AERO Links to the Internet . . . . . . . . 54 117 3.23. Encapsulation Protocol Version Considerations . . . . . . 57 118 3.24. Multicast Considerations . . . . . . . . . . . . . . . . 58 119 3.25. Operation on AERO Links Without DHCPv6 Services . . . . . 58 120 3.26. Operation on Server-less AERO Links . . . . . . . . . . . 58 121 3.27. Manually-Configured AERO Tunnels . . . . . . . . . . . . 58 122 3.28. Intradomain Routing . . . . . . . . . . . . . . . . . . . 59 123 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 59 124 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 59 125 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 126 7. Security Considerations . . . . . . . . . . . . . . . . . . . 59 127 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 128 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 129 9.1. Normative References . . . . . . . . . . . . . . . . . . 61 130 9.2. Informative References . . . . . . . . . . . . . . . . . 63 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69 133 1. Introduction 135 This document specifies the operation of IP over tunnel virtual links 136 using Asymmetric Extended Route Optimization (AERO). The AERO link 137 can be used for tunneling to neighboring nodes over either IPv6 or 138 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 139 equivalent links for tunneling. Nodes attached to AERO links can 140 exchange packets via trusted intermediate routers that provide 141 forwarding services to reach off-link destinations and redirection 142 services for route optimization that addresses the requirements 143 outlined in [RFC5522]. 145 AERO provides an IPv6 link-local address format known as the AERO 146 address that supports operation of the IPv6 Neighbor Discovery (ND) 147 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 148 control, provisioning and mobility are supported by the Dynamic Host 149 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and route 150 optimization is naturally supported through dynamic neighbor cache 151 updates. Although DHCPv6 and IPv6 ND messaging are used in the 152 control plane, both IPv4 and IPv6 can be used in the data plane. 153 AERO is a widely-applicable tunneling solution using standard control 154 messaging exchanges as described in this document. The remainder of 155 this document presents the AERO specification. 157 2. Terminology 159 The terminology in the normative references applies; the following 160 terms are defined within the scope of this document: 162 AERO link 163 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 164 configured over a node's attached IPv6 and/or IPv4 networks. All 165 nodes on the AERO link appear as single-hop neighbors from the 166 perspective of the virtual overlay. 168 AERO interface 169 a node's attachment to an AERO link. Nodes typically have a 170 single AERO interface; support for multiple AERO interfaces is 171 also possible but out of scope for this document. 173 AERO address 174 an IPv6 link-local address constructed as specified in Section 3.3 175 and assigned to a Client's AERO interface. 177 AERO node 178 a node that is connected to an AERO link and that participates in 179 IPv6 ND and DHCPv6 messaging over the link. 181 AERO Client ("Client") 182 a node that issues DHCPv6 messages using the special IPv6 link- 183 local address 'fe80::ffff:ffff:ffff:ffff' to receive IP Prefix 184 Delegations (PD) from one or more AERO Servers. Following PD, the 185 Client assigns an AERO address to the AERO interface which it uses 186 in IPv6 ND messaging to coordinate with other AERO nodes. 188 AERO Server ("Server") 189 a node that configures an AERO interface to provide default 190 forwarding and DHCPv6 services for AERO Clients. The Server 191 assigns an administratively provisioned IPv6 link-local unicast 192 address to support the operation of DHCPv6 and the IPv6 ND 193 protocol. An AERO Server can also act as an AERO Relay. 195 AERO Relay ("Relay") 196 a node that configures an AERO interface to relay IP packets 197 between nodes on the same AERO link and/or forward IP packets 198 between the AERO link and the native Internetwork. The Relay 199 assigns an administratively provisioned IPv6 link-local unicast 200 address to the AERO interface the same as for a Server. An AERO 201 Relay can also act as an AERO Server. 203 AERO Forwarding Agent ("Forwarding Agent") 204 a node that performs data plane forwarding services as a companion 205 to an AERO Server. 207 ingress tunnel endpoint (ITE) 208 an AERO interface endpoint that injects tunneled packets into an 209 AERO link. 211 egress tunnel endpoint (ETE) 212 an AERO interface endpoint that receives tunneled packets from an 213 AERO link. 215 underlying network 216 a connected IPv6 or IPv4 network routing region over which the 217 tunnel virtual overlay is configured. A typical example is an 218 enterprise network. 220 underlying interface 221 an AERO node's interface point of attachment to an underlying 222 network. 224 link-layer address 225 an IP address assigned to an AERO node's underlying interface. 226 When UDP encapsulation is used, the UDP port number is also 227 considered as part of the link-layer address. Link-layer 228 addresses are used as the encapsulation header source and 229 destination addresses. 231 network layer address 232 the source or destination address of the encapsulated IP packet. 234 end user network (EUN) 235 an internal virtual or external edge IP network that an AERO 236 Client connects to the rest of the network via the AERO interface. 238 AERO Service Prefix (ASP) 239 an IP prefix associated with the AERO link and from which AERO 240 Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 241 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 243 AERO Client Prefix (ACP) 244 a more-specific IP prefix taken from an ASP and delegated to a 245 Client. 247 Throughout the document, the simple terms "Client", "Server" and 248 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 249 respectively. Capitalization is used to distinguish these terms from 250 DHCPv6 client/server/relay [RFC3315]. 252 The terminology of [RFC4861] (including the names of node variables 253 and protocol constants) applies to this document. Also throughout 254 the document, the term "IP" is used to generically refer to either 255 Internet Protocol version (i.e., IPv4 or IPv6). 257 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 258 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 259 document are to be interpreted as described in [RFC2119]. Lower case 260 uses of these words are not to be interpreted as carrying RFC2119 261 significance. 263 3. Asymmetric Extended Route Optimization (AERO) 265 The following sections specify the operation of IP over Asymmetric 266 Extended Route Optimization (AERO) links: 268 3.1. AERO Link Reference Model 269 .-(::::::::) 270 .-(:::: IP ::::)-. 271 (:: Internetwork ::) 272 `-(::::::::::::)-' 273 `-(::::::)-' 274 | 275 +--------------+ +--------+-------+ +--------------+ 276 |AERO Server S1| | AERO Relay R1 | |AERO Server S2| 277 | Nbr: C1; R1 | | Nbr: S1; S2 | | Nbr: C2; R1 | 278 | default->R1 | |(H1->S1; H2->S2)| | default->R1 | 279 | H1->C1 | +--------+-------+ | H2->C2 | 280 +-------+------+ | +------+-------+ 281 | | | 282 X---+---+-------------------+------------------+---+---X 283 | AERO Link | 284 +-----+--------+ +--------+-----+ 285 |AERO Client C1| |AERO Client C2| 286 | Nbr: S1 | | Nbr: S2 | 287 | default->S1 | | default->S2 | 288 +--------------+ +--------------+ 289 .-. .-. 290 ,-( _)-. ,-( _)-. 291 .-(_ IP )-. .-(_ IP )-. 292 (__ EUN ) (__ EUN ) 293 `-(______)-' `-(______)-' 294 | | 295 +--------+ +--------+ 296 | Host H1| | Host H2| 297 +--------+ +--------+ 299 Figure 1: AERO Link Reference Model 301 Figure 1 presents the AERO link reference model. In this model: 303 o Relay R1 acts as a default router for its associated Servers S1 304 and S2, and connects the AERO link to the rest of the IP 305 Internetwork 307 o Servers S1 and S2 associate with Relay R1 and also act as default 308 routers for their associated Clients C1 and C2. 310 o Clients C1 and C2 associate with Servers S1 and S2, respectively 311 and also act as default routers for their associated EUNs 313 o Hosts H1 and H2 attach to the EUNs served by Clients C1 and C2, 314 respectively 316 Each node maintains a neighbor cache and IP forwarding table. (For 317 example, AERO Relay R1 in the diagram has neighbor cache entries for 318 Servers S1 and S2 and IP forwarding table entries for the ACPs 319 delegated to Clients C1 and C2.) In common operational practice, 320 there may be many additional Relays, Servers and Clients. (Although 321 not shown in the figure, AERO Forwarding Agents may also be provided 322 for data plane forwarding offload services.) 324 3.2. AERO Link Node Types 326 AERO Relays provide default forwarding services to AERO Servers. 327 Relays forward packets between Servers connected to the same AERO 328 link and also forward packets between the AERO link and the native IP 329 Internetwork. Relays present the AERO link to the native 330 Internetwork as a set of one or more AERO Service Prefixes (ASPs) and 331 serve as a gateway between the AERO link and the Internetwork. AERO 332 Relays maintain an AERO interface neighbor cache entry for each AERO 333 Server, and maintain an IP forwarding table entry for each AERO 334 Client Prefix (ACP). AERO Relays can also be configured to act as 335 AERO Servers. 337 AERO Servers provide default forwarding services to AERO Clients. 338 Each Server also peers with each Relay in a dynamic routing protocol 339 instance to advertise its list of associated ACPs. Servers configure 340 a DHCPv6 server function to facilitate Prefix Delegation (PD) 341 exchanges with Clients. Each delegated prefix becomes an ACP taken 342 from an ASP. Servers forward packets between AERO interface 343 neighbors only, i.e., and not between the AERO link and the native IP 344 Internetwork. AERO Servers maintain an AERO interface neighbor cache 345 entry for each AERO Relay. They also maintain both a neighbor cache 346 entry and an IP forwarding table entry for each of their associated 347 Clients. AERO Servers can also be configured to act as AERO Relays. 349 AERO Clients act as requesting routers to receive ACPs through DHCPv6 350 PD exchanges with AERO Servers over the AERO link and sub-delegate 351 portions of their ACPs to EUN interfaces. (Each Client MAY associate 352 with a single Server or with multiple Servers, e.g., for fault 353 tolerance, load balancing, etc.) Each IPv6 Client receives at least 354 a /64 IPv6 ACP, and may receive even shorter prefixes. Similarly, 355 each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a singleton 356 IPv4 address), and may receive even shorter prefixes. AERO Clients 357 maintain an AERO interface neighbor cache entry for each of their 358 associated Servers as well as for each of their correspondent 359 Clients. 361 AERO Clients typically configure a TUN/TAP interface [TUNTAP] as a 362 point-to-point linkage between the IP layer and the AERO interface. 363 The IP layer therefore sees only the TUN/TAP interface, while the 364 AERO interface provides an intermediate conduit between the TUN/TAP 365 interface and the underlying interfaces. AERO Clients that act as 366 hosts assign one or more IP addresses from their ACPs to the TUN/TAP 367 interface, i.e., and not to the AERO interface. 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 1 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. UDP Port Number and 472 IP Address are set to the addresses used by the target node when it 473 sends encapsulated packets over the underlying interface. When the 474 encapsulation IP address family is IPv4, IP Address is formed as an 475 IPv4-mapped IPv6 address [RFC4291]. 477 AERO interfaces may be configured over multiple underlying 478 interfaces. For example, common mobile handheld devices have both 479 wireless local area network ("WLAN") and cellular wireless links. 480 These links are typically used "one at a time" with low-cost WLAN 481 preferred and highly-available cellular wireless as a standby. In a 482 more complex example, aircraft frequently have many wireless data 483 link types (e.g. satellite-based, terrestrial, air-to-air 484 directional, etc.) with diverse performance and cost properties. 486 If a Client's multiple underlying interfaces are used "one at a time" 487 (i.e., all other interfaces are in standby mode while one interface 488 is active), then Redirect, Predirect and unsolicited NA messages 489 include only a single TLLAO with Link ID set to a constant value. 491 If the Client has multiple active underlying interfaces, then from 492 the perspective of IPv6 ND it would appear to have a single link- 493 local address with multiple link-layer addresses. In that case, 494 Redirect, Predirect and unsolicited NA messages MAY include multiple 495 TLLAOs -- each with a different Link ID that corresponds to a 496 specific underlying interface of the Client. 498 3.5. AERO Link Registration 500 When an administrative authority first deploys a set of AERO Relays 501 and Servers that comprise an AERO link, they also assign a unique 502 domain name for the link, e.g., "linkupnetworks.example.com". Next, 503 if administrative policy permits Clients within the domain to serve 504 as correspondent nodes for Internet mobile nodes, the administrative 505 authority adds a Fully Qualified Domain Name (FQDN) for each of the 506 AERO link's ASPs to the Domain Name System (DNS) [RFC1035]. The FQDN 507 is based on the suffix "aero.linkupnetworks.net" with a prefix formed 508 from the wildcard-terminated reverse mapping of the ASP 510 [RFC3596][RFC4592], and resolves to a DNS PTR resource record. For 511 example, for the ASP '2001:db8:1::/48' within the domain name 512 "linkupnetworks.example.com", the DNS database contains: 514 '*.1.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net. PTR 515 linkupnetworks.example.com' 517 This DNS registration advertises the AERO link's ASPs to prospective 518 correspondent nodes. 520 3.6. AERO Interface Initialization 522 3.6.1. AERO Relay Behavior 524 When a Relay enables an AERO interface, it first assigns an 525 administratively provisioned link-local address fe80::ID to the 526 interface. Each fe80::ID address MUST be unique among all AERO nodes 527 on the link, and MUST NOT collide with any potential AERO addresses 528 nor the special addresses fe80:: and fe80::ffff:ffff:ffff:ffff. (The 529 fe80::ID addresses are typically taken from the available range 530 fe80::/96, e.g., as fe80::1, fe80::2, fe80::3, etc.) The Relay then 531 engages in a dynamic routing protocol session with all Servers on the 532 link (see: Section 3.7), and advertises its assigned ASP prefixes 533 into the native IP Internetwork. 535 Each Relay subsequently maintains an IP forwarding table entry for 536 each Client-Server association, and maintains a neighbor cache entry 537 for each Server on the link. Relays exchange NS/NA messages with 538 AERO link neighbors the same as for any AERO node, however they 539 typically do not perform explicit Neighbor Unreachability Detection 540 (NUD) (see: Section 3.18) since the dynamic routing protocol already 541 provides reachability confirmation. 543 3.6.2. AERO Server Behavior 545 When a Server enables an AERO interface, it assigns an 546 administratively provisioned link-local address fe80::ID the same as 547 for Relays. The Server further configures a DHCPv6 server function 548 to facilitate DHCPv6 PD exchanges with AERO Clients. The Server 549 maintains a neighbor cache entry for each Relay on the link, and 550 manages per-Client neighbor cache entries and IP forwarding table 551 entries based on control message exchanges. Each Server also engages 552 in a dynamic routing protocol with each Relay on the link (see: 553 Section 3.7). 555 When the Server receives an NS/RS message from a Client on the AERO 556 interface it returns an NA/RA message but does not update the 557 neighbor cache. The Server further provides a simple conduit between 558 AERO interface neighbors. Therefore, packets enter the Server's AERO 559 interface from the link layer and are forwarded back out the link 560 layer without ever leaving the AERO interface and therefore without 561 ever disturbing the network layer. 563 3.6.3. AERO Client Behavior 565 When a Client enables an AERO interface, it uses the special address 566 fe80::ffff:ffff:ffff:ffff to obtain an ACP from an AERO Server via 567 DHCPv6 PD. Next, it assigns the corresponding AERO address to the 568 AERO interface and creates a neighbor cache entry for the Server, 569 i.e., the PD exchange bootstraps autoconfiguration of a unique link- 570 local address. The Client maintains a neighbor cache entry for each 571 of its Servers and each of its active correspondent Clients. When 572 the Client receives Redirect/Predirect messages on the AERO interface 573 it updates or creates neighbor cache entries, including link-layer 574 address information. Unsolicited NA messages update the cached link- 575 layer addresses for correspondent Clients (e.g., following a link- 576 layer address change due to node mobility) but do not create new 577 neighbor cache entries. NS/NA messages used for NUD update timers in 578 existing neighbor cache entires but do not update link-layer 579 addresses nor create new neighbor cache entries. 581 Finally, the Client need not maintain any IP forwarding table entries 582 for its Servers or correspondent Clients. Instead, it can set a 583 single "route-to-interface" default route in the IP forwarding table, 584 and all forwarding decisions can be made within the AERO interface 585 based on neighbor cache entries. (On systems in which adding a 586 default route would violate security policy, the default route could 587 instead be installed via a "synthesized RA", e.g., as discussed in 588 Section 3.15.2.) 590 3.6.4. AERO Forwarding Agent Behavior 592 When a Forwarding Agent enables an AERO interface, it assigns the 593 same link-local address(es) as the companion AERO Server. The 594 Forwarding Agent thereafter provides data plane forwarding services 595 based solely on the forwarding information assigned to it by the 596 companion AERO Server. 598 3.7. AERO Link Routing System 600 Relays require full topology knowledge of all ACP/Server associations 601 for the ASPs they service, while individual Servers at a minimum only 602 need to know the ACPs for their current set of associated Clients. 603 This is accomplished through the use of an internal instance of the 604 Border Gateway Protocol (BGP) [RFC4271] coordinated between Servers 605 and Relays. This internal BGP instance does not interact with the 606 public Internet BGP instance; therefore, the AERO link is presented 607 to the IP Internetwork as a small set of ASPs as opposed to the full 608 set of individual ACPs. 610 In a reference BGP arrangement, each AERO Server is configured as an 611 Autonomous System Border Router (ASBR) for a stub Autonomous System 612 (AS) using an AS Number (ASN) that is unique within the BGP instance, 613 and each Server further peers with each Relay but does not peer with 614 other Servers. Similarly, Relays do not peer with each other, since 615 they will reliably receive all updates from all Servers and will 616 therefore have a consistent view of the AERO link ACP delegations. 618 Each Server maintains a working set of associated ACPs, and 619 dynamically announces new ACPs and withdraws departed ACPs in its BGP 620 updates to Relays. Clients are expected to remain associated with 621 their current Servers for extended timeframes, however Servers SHOULD 622 selectively suppress BGP updates for impatient Clients that 623 repeatedly associate and disassociate with them in order to dampen 624 routing churn. 626 Each Relay configures a black-hole route for each ASP associated with 627 the AERO link. By black-holing the ASPs, the Relay will maintain 628 active forwarding table entries only for the ACPs that are currently 629 active, and all other ACPs will correctly result in destination 630 unreachable failures due to the black hole route. 632 Scaling properties of the AERO routing system are limited by the 633 number of BGP routes that can be carried by Relays. Assuming O(10^6) 634 as a reasonable maximum number of BGP routes, this means that O(10^6) 635 Clients can be serviced by a single set of Relays. A means of 636 increasing scaling would be to assign a different set of Relays for 637 each set of ASPs. In that case, each Server still peers with each 638 Relay, but the Server institutes route filters so that each set of 639 Relays only receives BGP updates for the ACPs they aggregate. For 640 example, if the ASP for the AERO link is 2001:db8::/32, a first set 641 of Relays could service the ASP segment 2001:db8::/40, a second set 642 of Relays could service 2001:db8:0100::/40, a third set could service 643 2001:db8:0200::/40, etc. 645 Assuming up to O(10^3) sets of Relays, the system can then 646 accommodate O(10^9) Clients with no additional overhead for Servers 647 and Relays. In this way, each set of Relays services a specific set 648 of ASPs that they advertise to the native routing system outside of 649 the AERO link, and each Server configures ASP-specific routes that 650 list the correct set of Relays as next hops. This arrangement also 651 allows for natural incremental deployment, and can support small 652 scale initial deployments followed by dynamic deployment of 653 additional Clients, Servers and Relays without disturbing the 654 already-deployed base. 656 3.8. AERO Interface Neighbor Cache Maintenace 658 Each AERO interface maintains a conceptual neighbor cache that 659 includes an entry for each neighbor it communicates with on the AERO 660 link, the same as for any IPv6 interface [RFC4861]. AERO interface 661 neighbor cache entires are said to be one of "permanent", "static" or 662 "dynamic". 664 Permanent neighbor cache entries are created through explicit 665 administrative action; they have no timeout values and remain in 666 place until explicitly deleted. AERO Relays maintain a permanent 667 neighbor cache entry for each Server on the link, and AERO Servers 668 maintain a permanent neighbor cache entry for each Relay. Each entry 669 maintains the mapping between the neighbor's fe80::ID network-layer 670 address and corresponding link-layer address. 672 Static neighbor cache entries are created though DHCPv6 PD exchanges 673 and remain in place for durations bounded by prefix lifetimes. AERO 674 Servers maintain static neighbor cache entries for the ACPs of each 675 of their associated Clients, and AERO Clients maintain a static 676 neighbor cache entry for each of their associated Servers. When an 677 AERO Server sends a DHCPv6 Reply message response to a Client's 678 DHCPv6 Solicit/Request, Rebind or Renew message, it creates or 679 updates a static neighbor cache entry based on the AERO address 680 corresponding to the Client's ACP as the network-layer address, the 681 prefix lifetime as the neighbor cache entry lifetime, the Client's 682 encapsulation IP address and UDP port number as the link-layer 683 address and the prefix length as the length to apply to the AERO 684 address. When an AERO Client receives a DHCPv6 Reply message from a 685 Server, it creates or updates a static neighbor cache entry based on 686 the Reply message link-local source address as the network-layer 687 address, the prefix lifetime as the neighbor cache entry lifetime, 688 and the encapsulation IP source address and UDP source port number as 689 the link-layer address. 691 Dynamic neighbor cache entries are created or updated based on 692 receipt of an IPv6 ND message, and are garbage-collected if not used 693 within a bounded timescale. AERO Clients maintain dynamic neighbor 694 cache entries for each of their active correspondent Client ACPs with 695 lifetimes based on IPv6 ND messaging constants. When an AERO Client 696 receives a valid Predirect message it creates or updates a dynamic 697 neighbor cache entry for the Predirect target network-layer and link- 698 layer addresses plus prefix length. The node then sets an 699 "AcceptTime" variable in the neighbor cache entry to ACCEPT_TIME 700 seconds and uses this value to determine whether packets received 701 from the correspondent can be accepted. When an AERO Client receives 702 a valid Redirect message it creates or updates a dynamic neighbor 703 cache entry for the Redirect target network-layer and link-layer 704 addresses plus prefix length. The Client then sets a "ForwardTime" 705 variable in the neighbor cache entry to FORWARD_TIME seconds and uses 706 this value to determine whether packets can be sent directly to the 707 correspondent. The Client also sets a "MaxRetry" variable to 708 MAX_RETRY to limit the number of keepalives sent when a correspondent 709 may have gone unreachable. 711 For dynamic neighbor cache entries, when an AERO Client receives a 712 valid NS message it (re)sets AcceptTime for the neighbor to 713 ACCEPT_TIME. When an AERO Client receives a valid solicited NA 714 message, it (re)sets ForwardTime for the neighbor to FORWARD_TIME and 715 sets MaxRetry to MAX_RETRY. When an AERO Client receives a valid 716 unsolicited NA message, it updates the correspondent's link-layer 717 addresses but DOES NOT reset AcceptTime, ForwardTime or MaxRetry. 719 It is RECOMMENDED that FORWARD_TIME be set to the default constant 720 value 30 seconds to match the default REACHABLE_TIME value specified 721 for IPv6 ND [RFC4861]. 723 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 724 value 40 seconds to allow a 10 second window so that the AERO 725 redirection procedure can converge before AcceptTime decrements below 726 FORWARD_TIME. 728 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 729 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 731 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 732 administratively set, if necessary, to better match the AERO link's 733 performance characteristics; however, if different values are chosen, 734 all nodes on the link MUST consistently configure the same values. 735 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 736 sufficiently longer than FORWARD_TIME to allow the AERO redirection 737 procedure to converge. 739 3.9. AERO Interface Sending Algorithm 741 IP packets enter a node's AERO interface either from the network 742 layer (i.e., from a local application or the IP forwarding system), 743 or from the link layer (i.e., from the AERO tunnel virtual link). 744 Packets that enter the AERO interface from the network layer are 745 encapsulated and admitted into the AERO link, i.e., they are 746 tunnelled to an AERO interface neighbor. Packets that enter the AERO 747 interface from the link layer are either re-admitted into the AERO 748 link or delivered to the network layer where they are subject to 749 either local delivery or IP forwarding. Since each AERO node may 750 have only partial information about neighbors on the link, AERO 751 interfaces may forward packets with link-local destination addresses 752 at a layer below the network layer. This means that AERO nodes act 753 as both IP routers and sub-IP layer forwarding agents. AERO 754 interface sending considerations for Clients, Servers and Relays are 755 given below. 757 When an IP packet enters a Client's AERO interface from the network 758 layer, if the destination is covered by an ASP the Client searches 759 for a dynamic neighbor cache entry with a non-zero ForwardTime and an 760 AERO address that matches the packet's destination address. (The 761 destination address may be either an address covered by the 762 neighbor's ACP or the (link-local) AERO address itself.) If there is 763 a match, the Client uses a link-layer address in the entry as the 764 link-layer address for encapsulation then admits the packet into the 765 AERO link. If there is no match, the Client instead uses the link- 766 layer address of a neighboring Server as the link-layer address for 767 encapsulation. 769 When an IP packet enters a Server's AERO interface from the link 770 layer, if the destination is covered by an ASP the Server searches 771 for a neighbor cache entry with an AERO address that matches the 772 packet's destination address. (The destination address may be either 773 an address covered by the neighbor's ACP or the AERO address itself.) 774 If there is a match, the Server uses a link-layer address in the 775 entry as the link-layer address for encapsulation and re-admits the 776 packet into the AERO link. If there is no match, the Server instead 777 uses the link-layer address in a permanent neighbor cache entry for a 778 Relay as the link-layer address for encapsulation. 780 When an IP packet enters a Relay's AERO interface from the network 781 layer, the Relay searches its IP forwarding table for an entry that 782 is covered by an ASP and also matches the destination. If there is a 783 match, the Relay uses the link-layer address in a permanent neighbor 784 cache entry for a Server as the link-layer address for encapsulation 785 and admits the packet into the AERO link. When an IP packet enters a 786 Relay's AERO interface from the link-layer, if the destination is not 787 a link-local address and does not match an ASP the Relay removes the 788 packet from the AERO interface and uses IP forwarding to forward the 789 packet to the Internetwork. If the destination address is a link- 790 local address or a non-link-local address that matches an ASP, and 791 there is a more-specific ACP entry in the IP forwarding table, the 792 Relay uses the link-layer address in the corresponding neighbor cache 793 entry as the link-layer address for encapsulation and re-admits the 794 packet into the AERO link. When an IP packet enters a Relay's AERO 795 interface from either the network layer or link-layer, and the 796 packet's destination address matches an ASP but there is no more- 797 specific ACP entry, the Relay drops the packet and returns an ICMP 798 Destination Unreachable message (see: Section 3.14). 800 When an AERO Server receives a packet from a Relay via the AERO 801 interface, the Server MUST NOT forward the packet back to the same or 802 a different Relay. 804 When an AERO Relay receives a packet from a Server via the AERO 805 interface, the Relay MUST NOT forward the packet back to the same 806 Server. 808 When an AERO node re-admits a packet into the AERO link without 809 involving the network layer, the node MUST NOT decrement the network 810 layer TTL/Hop-count. 812 When an AERO node forwards a data packet to the primary link-layer 813 address of a Server, it may receive Redirect messages with an SLLAO 814 that include the link-layer address of an AERO Forwarding Agent. The 815 AERO node SHOULD record the link-layer address in the neighbor cache 816 entry for the neighbor and send subsequent data packets via this 817 address instead of the Server's primary address (see: Section 3.16). 819 3.10. AERO Interface Encapsulation and Re-encapsulation 821 AERO interfaces encapsulate IP packets according to whether they are 822 entering the AERO interface from the network layer or if they are 823 being re-admitted into the same AERO link they arrived on. This 824 latter form of encapsulation is known as "re-encapsulation". 826 The AERO interface encapsulates packets per the Generic UDP 827 Encapsulation (GUE) encapsulation procedures in 828 [I-D.ietf-nvo3-gue][I-D.herbert-gue-fragmentation]. During 829 encapsulation, the AERO interface copies the "TTL/Hop Limit", "Type 830 of Service/Traffic Class" [RFC2983], "Fow Label"[RFC6438].(for IPv6) 831 and "Congestion Experienced" [RFC3168] values in the packet's IP 832 header into the corresponding fields in the encapsulation IP header. 833 For packets undergoing re-encapsulation, the AERO interface instead 834 copies the "TTL/Hop Limit", "Type of Service/Traffic Class", "Flow 835 Label" and "Congestion Experienced" values in the original 836 encapsulation IP header into the corresponding fields in the new 837 encapsulation IP header, i.e., the values are transferred between 838 encapsulation headers and *not* copied from the encapsulated packet's 839 network-layer header. 841 The AERO interface next sets the UDP source port to a constant value 842 that it will use in each successive packet it sends, and sets the UDP 843 length field to the length of the encapsulated packet plus 8 bytes 844 for the UDP header itself, plus the length of the GUE header. For 845 packets sent via a Server, the AERO interface sets the UDP 846 destination port to 8060, i.e., the IANA-registered port number for 847 AERO. For packets sent to a correspondent Client, the AERO interface 848 sets the UDP destination port to the port value stored in the 849 neighbor cache entry for this correspondent. The AERO interface also 850 sets the UDP checksum field per the procedures specified in 851 [I-D.ietf-nvo3-gue]. 853 The AERO interface next sets the IP protocol number in the 854 encapsulation header to 17 (i.e., the IP protocol number for UDP). 855 When IPv4 is used as the encapsulation protocol, the AERO interface 856 sets the DF bit as discussed in Section 3.13. 858 3.11. AERO Interface Decapsulation 860 AERO interfaces decapsulate packets destined either to the node 861 itself or to a destination reached via an interface other than the 862 AERO interface the packet was received on. Decapsulation is per the 863 procedures specified in [I-D.ietf-nvo3-gue]. 865 3.12. AERO Interface Data Origin Authentication 867 AERO nodes employ simple data origin authentication procedures for 868 encapsulated packets they receive from other nodes on the AERO link. 869 In particular: 871 o AERO Relays and Servers accept encapsulated packets with a link- 872 layer source address that matches a permanent neighbor cache 873 entry. 875 o AERO Servers accept authentic encapsulated DHCPv6 messages from 876 Clients, and create or update a static neighbor cache entry for 877 the source based on the specific message type. 879 o AERO Servers accept encapsulated packets if there is a neighbor 880 cache entry with an AERO address that matches the packet's 881 network-layer source address and with a link-layer address that 882 matches the packet's link-layer source address. 884 o AERO Clients accept encapsulated packets if there is a static 885 neighbor cache entry with a link-layer source address that matches 886 the packet's link-layer source address. 888 o AERO Clients and Servers accept encapsulated packets if there is a 889 dynamic neighbor cache entry with an AERO address that matches the 890 packet's network-layer source address, with a link-layer address 891 that matches the packet's link-layer source address, and with a 892 non-zero AcceptTime. 894 Note that this simple data origin authentication is effective in 895 environments in which link-layer addresses cannot be spoofed. In 896 other environments, each AERO message must include a signature that 897 the recipient can use to authenticate the message origin. 899 3.13. AERO Interface MTU and Fragmentation 901 The AERO interface is the node's point of attachment to the AERO 902 link. AERO links over IP networks have a maximum link MTU of 64KB 903 minus the encapsulation overhead (i.e., 64KB-ENCAPS), since the 904 maximum packet size in the base IP specifications is 64KB 905 [RFC0791][RFC2460]. While IPv6 jumbograms can be up to 4GB 906 [RFC2675], they are considered optional for IPv6 nodes [RFC6434] and 907 therefore out of scope for this document. 909 AERO interfaces are considered to have an indefinite MTU , i.e., 910 instead of clamping the MTU to a finite size. The MTU for each 911 destination AERO interface is therefore constrained by the minimum of 912 64KB, the MTU of the underlying interface used for tunneling, and the 913 path MTU within the tunnel (minus ENCAPS in each case). 915 IPv6 specifies a minimum link MTU of 1280 bytes [RFC2460]. This is 916 the minimum packet size the AERO interface MUST admit without 917 returning an ICMP Packet Too Big (PTB) message. Although IPv4 918 specifies a smaller minimum link MTU of 68 bytes [RFC0791], AERO 919 interfaces also observe a 1280 byte minimum for IPv4. 921 The vast majority of links in the Internet configure an MTU of at 922 least 1500 bytes. Original source hosts have therefore become 923 conditioned to expect that IP packets up to 1500 bytes in length will 924 either be delivered to the final destination or a suitable PTB 925 message returned. However, PTB messages may be lost in the network 926 [RFC2923] resulting in failure of the IP Path MTU Discovery (PMTUD) 927 mechanisms [RFC1191][RFC1981], or crafted for malicious purposes such 928 as denial of service. For these reasons, the source AERO interface 929 (i.e., the tunnel ingress) sends encapsulated packets to the 930 destination AERO interface (i.e., the tunnel egress) subject to 931 whether standard PMTUD can be leveraged within the specific 932 deployment model. The two cases for consideration are as follows: 934 3.13.1. All Elements in Same Administrative Domain 936 When the original source, ingress and egress are all within the same 937 well-managed administrative domain, the ingress admits a packet into 938 the tunnel if it is not too large to traverse the tunnel in one piece 939 or if the path MTU within the tunnel is not yet known. Otherwise, 940 the ingress drops the packet and sends a PTB message back to the 941 original source. Additionally, the ingress SHOULD translate any PTB 942 messages it receives from a router on the path to the egress and 943 cache the MTU value as a maximum size for large packet admission. 945 These procedures apply when the MTU for this egress is no smaller 946 than (1280+ENCAPS) bytes. Otherwise, the ingress can either shut 947 down the tunnel or begin fragmenting packets that are no larger than 948 1280 bytes but larger than the MTU minus ENCAPS using tunnel 949 fragmentation as specified in Section 3.13.2. This exactly parallels 950 the standard behavior specified in [RFC2473] except that, when the 951 original packet is an IPv4 packet with DF=0, the ingress uses IPv4 952 fragmentation to fragment the original packet when necessary before 953 encapsulation as specified in Section 3.13.2. 955 3.13.2. Some Elements in Different Administrative Domain 957 When the original source, ingress and egress are not all within the 958 same well-managed administrative domain, the ingress admits all 959 packets up to 1500 bytes in length even if some fragmentation is 960 necessary, and admits larger packets without fragmentation in case 961 they are able to traverse the tunnel in one piece. When the ingress 962 and egress are within the same well-managed administrative domain, 963 the ingress SHOULD translate any PTB messages it receives from a 964 router on the path to the egress and cache the MTU value as a maximum 965 size for large packet admission; otherwise, the ingress SHOULD ignore 966 any such PTB messages. 968 Several factors must be considered when fragmentation is needed. For 969 AERO links over IPv4, the IP ID field is only 16 bits in length, 970 meaning that fragmentation at high data rates could result in data 971 corruption due to reassembly misassociations [RFC6864][RFC4963] (see: 972 Section 3.13.4). For AERO links over both IPv4 and IPv6, studies 973 have also shown that IP fragments are dropped unconditionally over 974 some network paths [I-D.taylor-v6ops-fragdrop]. For these reasons, 975 when fragmentation is needed the ingress inserts a GUE fragment 976 header [I-D.herbert-gue-fragmentation] and applies tunnel 977 fragmentation as described in Section 3.1.7 of [RFC2764]. Since the 978 fragment header reduces the room available for packet data, but the 979 original source has no way to control its insertion, the ingress MUST 980 include the fragment header length in the ENCAPS length even for 981 packets in which the header does not appear. 983 The ingress therefore sends encapsulated packets to the egress 984 according to the following algorithm: 986 o For IP packets that are no larger than (1280-ENCAPS) bytes, the 987 ingress encapsulates the packet and admits it into the tunnel 988 without fragmentation. For IPv4 AERO links, the ingress sets the 989 Don't Fragment (DF) bit to 0 so that these packets will be 990 delivered to the egress even if there is a restricting link in the 991 path, i.e., unless lost due to congestion or routing errors. 993 o For IP packets that are larger than (1280-ENCAPS) bytes but no 994 larger than 1500 bytes, the ingress encapsulates the packet and 995 inserts a GUE fragment header. Next, the ingress fragments the 996 packet into two non-overlapping fragments where the first fragment 997 (including ENCAPS) is no larger than 1024 bytes and the second is 998 no larger than the first. Each fragment consists of identical 999 IP/UDP/GUE encapsulation headers followed by the fragment of the 1000 encapsulated packet itself. The ingress then admits both 1001 fragments into the tunnel, and for IPv4 sets the DF bit to 0 in 1002 the IP encapsulation header. These fragmented encapsulated 1003 packets will be delivered to the egress, which reassembles them 1004 into a whole packet. The egress therefore MUST be capable of 1005 reassembling packets up to 1500+ENCAPS bytes in length; hence, it 1006 is RECOMMENDED that the egress be capable of reassembling at least 1007 2KB. 1009 o For IPv4 packets that are larger than 1500 bytes and with the DF 1010 bit set to 0, the ingress uses ordinary IPv4 fragmentation to 1011 break the unencapsulated packet into a minimum number of non- 1012 overlapping fragments where the first fragment is no larger than 1013 1024-ENCAPS and all other fragments are no larger than the first 1014 fragment. The ingress then encapsulates each fragment (and for 1015 IPv4 sets the DF bit to 0) then admits them into the tunnel. 1016 These fragments will be delivered to the final destination via the 1017 egress. 1019 o For all other IP packets, if the packet is too large to enter the 1020 underlying interface following encapsulation, the ingress drops 1021 the packet and returns a network-layer (L3) PTB message to the 1022 original source with MTU set to the larger of 1500 bytes or the 1023 underlying interface MTU minus ENCAPS. Otherwise, the ingress 1024 encapsulates the packet and admits it into the tunnel without 1025 fragmentation (and for IPv4 sets the DF bit to 1) and translates 1026 any link-layer (L2) PTB messages it may receive from the network 1027 into corresponding L3 PTB messages to send to the original source 1028 as specified in Section 3.14. Since both L2 and L3 PTB messages 1029 may be either lost or contain insufficient information, however, 1030 it is RECOMMENDED that original sources that send unfragmentable 1031 IP packets larger than 1500 bytes use Packetization Layer Path MTU 1032 Discovery (PLPMTUD) [RFC4821]. 1034 While sending packets according to the above algorithm, the ingress 1035 MAY also send 1500 byte or larger probe packets to determine whether 1036 they can reach the egress without fragmentation. If the probes 1037 succeed, the ingress can discontinue fragmentation and (for IPv4) set 1038 DF to 1. Since the path MTU within the tunnel may fluctuate due to 1039 routing changes, the ingress SHOULD continue to send additional 1040 probes subject to rate limiting and SHOULD process any L2 PTB 1041 messages as an indication that the path MTU may have decreased. If 1042 the path MTU within the tunnel becomes insufficient, the source MUST 1043 resume fragmentation. 1045 To construct a probe, the ingress can prepare an NS message with a 1046 Nonce option plus trailing NULL padding octets added to the probe 1047 length without including the length of the padding in the IPv6 1048 Payload Length field, but with the length included in the 1049 encapsulating IP header. The ingress then encapsulates the padded NS 1050 message in the encapsulation headers (and for IPv4 sets DF to 1) then 1051 sends the message to the egress. If the egress returns a solicited 1052 NA message with a matching Nonce option, the ingress deems the probe 1053 successful. (Note that other means of probing such as sending a 1054 self-addressed data packet that will be looped back if received by 1055 the egress are also permissible.) 1057 When probing is used, it is essential that probes follow the same 1058 paths used to convey actual data packets to avoid path variations due 1059 to Equal Cost MultiPath (ECMP) and Link Aggregation Gateway (LAG) 1060 equipment in the path. In order to ensure that probes follow the 1061 same paths as data packets, the ingress sets both the Differentiated 1062 Service Code Point (DSCP) [RFC2983] and (for IPv6) Flow Label 1063 [RFC6438] fields to a constant value during encapsulation instead of 1064 copying these values from the original packet. In that case, it is 1065 RECOMMENDED that the ingress set these fields to the value 0. 1067 3.13.3. Accommodating Large Control Messages 1069 Control messages (i.e., IPv6 ND, DHCPv6, etc.) MUST be accommodated 1070 even if some fragmentation is necessary. These packets are therefore 1071 accommodated through a modification of the second rule in the above 1072 algorithm as follows: 1074 o For control messages that are larger than (1280-ENCAPS) bytes, the 1075 ingress encapsulates the packet and inserts a GUE fragment header. 1076 Next, the ingress uses GUE fragmentation 1077 [I-D.herbert-gue-fragmentation] to break the packet into a minimum 1078 number of non-overlapping fragments where the first fragment 1079 (including ENCAPS) is no larger than 1024 bytes and the remaining 1080 fragments are no larger than the first. The ingress then 1081 encapsulates each fragment (and for IPv4 sets the DF bit to 0) 1082 then admits them into the tunnel. 1084 Control messages that exceed the 2KB minimum reassembly size rarely 1085 occur in the modern era, however the egress SHOULD be able to 1086 reassemble them if they do. This means that the egress SHOULD 1087 include a configuration knob allowing the operator to set a larger 1088 reassembly buffer size if large control messages become more common 1089 in the future. 1091 The ingress MAY send large control messages without fragmentation if 1092 there is assurance that large packets can traverse the tunnel without 1093 fragmentation. 1095 The ingress MAY send 1500 byte or larger probe packets as specified 1096 in the previous section to determine a size for which fragmentation 1097 can be avoided. 1099 3.13.4. Integrity 1101 When fragmentation is needed, there must be assurance that reassembly 1102 can be safely conducted without incurring data corruption. Sources 1103 of corruption can include implementation errors, memory errors and 1104 misassociations of fragments from a first datagram with fragments of 1105 another datagram. The first two conditions (implementation and 1106 memory errors) are mitigated by modern systems and implementations 1107 that have demonstrated integrity through decades of operational 1108 practice. The third condition (reassembly misassociations) must be 1109 accounted for by AERO. 1111 The fragmentation procedure described in the above algorithms can 1112 reuse standard IPv6 fragmentation and reassembly code. Since the GUE 1113 fragment header includes a 32-bit ID field, there would need to be 1114 2^32 packets alive in the network before a second packet with a 1115 duplicate ID enters the system with the (remote) possibility for a 1116 reassembly misassociation. For 1280 byte packets, and for a maximum 1117 network lifetime value of 60 seconds[RFC2460], this means that the 1118 ingress would need to produce ~(7 *10^12) bits/sec in order for a 1119 duplication event to be possible. This exceeds the bandwidth of data 1120 link technologies of the modern era, but not necessarily so going 1121 forward into the future. Although wireless data links commonly used 1122 by AERO Clients support vastly lower data rates, the aggregate data 1123 rates between AERO Servers and Relays may be substantial. However, 1124 high speed data links in the network core are expected to configure 1125 larger MTUs, e.g., 4KB, 8KB or even larger such that unfragmented 1126 packets can be used. Hence, no integrity check is included to cover 1127 fragmentation and reassembly procedures. 1129 When the ingress sends an IPv4-encapsulated packet with the DF bit 1130 set to 0 in the above algorithms, there is a chance that the packet 1131 may be fragmented by an IPv4 router somewhere within the tunnel. 1132 Since the largest such packet is only 1280 bytes, however, it is very 1133 likely that the packet will traverse the tunnel without incurring a 1134 restricting link. Even when a link within the tunnel configures an 1135 MTU smaller than 1280 bytes, it is very likely that it does so due to 1136 limited performance characteristics [RFC3819]. This means that the 1137 tunnel would not be able to convey fragmented IPv4-encapsulated 1138 packets fast enough to produce reassembly misassociations, as 1139 discussed above. However, AERO must also account for the possibility 1140 of tunnel paths that include "poorly managed" IPv4 link MTUs due to 1141 misconfigurations. 1143 Since the IPv4 header includes only a 16-bit ID field, there would 1144 only need to be 2^16 packets alive in the network before a second 1145 packet with a duplicate ID enters the system. For 1280 byte packets, 1146 and for a maximum network lifetime value of 120 seconds[RFC0791], 1147 this means that the ingress would only need to produce ~(5 *10^6) 1148 bits/sec in order for a duplication event to be possible - a value 1149 that is well within range for many modern wired and wireless data 1150 link technologies. 1152 Therefore, if there is strong operational assurance that no IPv4 1153 links capable of supporting data rates of 5Mbps or more configure an 1154 MTU smaller than 1280 the ingress MAY omit an integrity check for the 1155 IPv4 fragmentation and reassembly procedures; otherwise, the ingress 1156 SHOULD include an integrity check. When an upper layer encapsulation 1157 (e.g., IPsec) already includes an integrity check, the ingress need 1158 not include an additional check. Otherwise, the ingress calculates 1159 the UDP checksum over the encapsulated packet and writes the value 1160 into the UDP encapsulation header, i.e., instead of writing the value 1161 0. The egress will then verify the UDP checksum and discard the 1162 packet if the checksum is incorrect. 1164 3.14. AERO Interface Error Handling 1166 When an AERO node admits encapsulated packets into the AERO 1167 interface, it may receive link-layer (L2) or network-layer (L3) error 1168 indications. 1170 An L2 error indication is an ICMP error message generated by a router 1171 on the path to the neighbor or by the neighbor itself. The message 1172 includes an IP header with the address of the node that generated the 1173 error as the source address and with the link-layer address of the 1174 AERO node as the destination address. 1176 The IP header is followed by an ICMP header that includes an error 1177 Type, Code and Checksum. For ICMPv6 [RFC4443], the error Types 1178 include "Destination Unreachable", "Packet Too Big (PTB)", "Time 1179 Exceeded" and "Parameter Problem". For ICMPv4 [RFC0792], the error 1180 Types include "Destination Unreachable", "Fragmentation Needed" (a 1181 Destination Unreachable Code that is analogous to the ICMPv6 PTB), 1182 "Time Exceeded" and "Parameter Problem". 1184 The ICMP header is followed by the leading portion of the packet that 1185 generated the error, also known as the "packet-in-error". For 1186 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 1187 much of invoking packet as possible without the ICMPv6 packet 1188 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 1189 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 1190 "Internet Header + 64 bits of Original Data Datagram", however 1191 [RFC1812] Section 4.3.2.3 updates this specification by stating: "the 1192 ICMP datagram SHOULD contain as much of the original datagram as 1193 possible without the length of the ICMP datagram exceeding 576 1194 bytes". 1196 The L2 error message format is shown in Figure 3: 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 ~ ~ 1200 | L2 IP Header of | 1201 | error message | 1202 ~ ~ 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | L2 ICMP Header | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1206 ~ ~ P 1207 | IP and other encapsulation | a 1208 | headers of original L3 packet | c 1209 ~ ~ k 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 1211 ~ ~ t 1212 | IP header of | 1213 | original L3 packet | i 1214 ~ ~ n 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 ~ ~ e 1217 | Upper layer headers and | r 1218 | leading portion of body | r 1219 | of the original L3 packet | o 1220 ~ ~ r 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1223 Figure 3: AERO Interface L2 Error Message Format 1225 The AERO node rules for processing these L2 error messages is as 1226 follows: 1228 o When an AERO node receives an L2 Parameter Problem message, it 1229 processes the message the same as described as for ordinary ICMP 1230 errors in the normative references [RFC0792][RFC4443]. 1232 o When an AERO node receives persistent L2 IPv4 Time Exceeded 1233 messages, the IP ID field may be wrapping before earlier fragments 1234 have been processed. In that case, the node SHOULD begin 1235 including IPv4 integrity checks (see: Section 3.13.4). 1237 o When an AERO Client receives persistent L2 Destination Unreachable 1238 messages in response to tunneled packets that it sends to one of 1239 its dynamic neighbor correspondents, the Client SHOULD test the 1240 path to the correspondent using Neighbor Unreachability Detection 1241 (NUD) (see Section 3.18). If NUD fails, the Client SHOULD set 1242 ForwardTime for the corresponding dynamic neighbor cache entry to 1243 0 and allow future packets destined to the correspondent to flow 1244 through a Server. 1246 o When an AERO Client receives persistent L2 Destination Unreachable 1247 messages in response to tunneled packets that it sends to one of 1248 its static neighbor Servers, the Client SHOULD test the path to 1249 the Server using NUD. If NUD fails, the Client SHOULD delete the 1250 neighbor cache entry and attempt to associate with a new Server. 1252 o When an AERO Server receives persistent L2 Destination Unreachable 1253 messages in response to tunneled packets that it sends to one of 1254 its static neighbor Clients, the Server SHOULD test the path to 1255 the Client using NUD. If NUD fails, the Server SHOULD cancel the 1256 DHCPv6 PD for the Client's ACP, withdraw its route for the ACP 1257 from the AERO routing system and delete the neighbor cache entry 1258 (see Section 3.18 and Section 3.19). 1260 o When an AERO Relay or Server receives an L2 Destination 1261 Unreachable message in response to a tunneled packet that it sends 1262 to one of its permanent neighbors, it discards the message since 1263 the routing system is likely in a temporary transitional state 1264 that will soon re-converge. 1266 o When an AERO node receives an L2 PTB message, it translates the 1267 message into an L3 PTB message if possible (*) and forwards the 1268 message toward the original source as described below. 1270 To translate an L2 PTB message to an L3 PTB message, the AERO node 1271 first caches the MTU field value of the L2 ICMP header. The node 1272 next discards the L2 IP and ICMP headers, and also discards the 1273 encapsulation headers of the original L3 packet. Next the node 1274 encapsulates the included segment of the original L3 packet in an L3 1275 IP and ICMP header, and sets the ICMP header Type and Code values to 1276 appropriate values for the L3 IP protocol. In the process, the node 1277 writes the maximum of 1500 bytes and (L2 MTU - ENCAPS) into the MTU 1278 field of the L3 ICMP header. 1280 The node next writes the IP source address of the original L3 packet 1281 as the destination address of the L3 PTB message and determines the 1282 next hop to the destination. If the next hop is reached via the AERO 1283 interface, the node uses the IPv6 address "::" or the IPv4 address 1284 "0.0.0.0" as the IP source address of the L3 PTB message. Otherwise, 1285 the node uses one of its non link-local addresses as the source 1286 address of the L3 PTB message. The node finally calculates the ICMP 1287 checksum over the L3 PTB message and writes the Checksum in the 1288 corresponding field of the L3 ICMP header. The L3 PTB message 1289 therefore is formatted as follows: 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 ~ ~ 1293 | L3 IP Header of | 1294 | error message | 1295 ~ ~ 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | L3 ICMP Header | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1299 ~ ~ p 1300 | IP header of | k 1301 | original L3 packet | t 1302 ~ ~ 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1304 ~ ~ n 1305 | Upper layer headers and | 1306 | leading portion of body | e 1307 | of the original L3 packet | r 1308 ~ ~ r 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1311 Figure 4: AERO Interface L3 Error Message Format 1313 After the node has prepared the L3 PTB message, it either forwards 1314 the message via a link outside of the AERO interface without 1315 encapsulation, or encapsulates and forwards the message to the next 1316 hop via the AERO interface. 1318 When an AERO Relay receives an L3 packet for which the destination 1319 address is covered by an ASP, if there is no more-specific routing 1320 information for the destination the Relay drops the packet and 1321 returns an L3 Destination Unreachable message. The Relay first 1322 writes the IP source address of the original L3 packet as the 1323 destination address of the L3 Destination Unreachable message and 1324 determines the next hop to the destination. If the next hop is 1325 reached via the AERO interface, the Relay uses the IPv6 address "::" 1326 or the IPv4 address "0.0.0.0" as the IP source address of the L3 1327 Destination Unreachable message and forwards the message to the next 1328 hop within the AERO interface. Otherwise, the Relay uses one of its 1329 non link-local addresses as the source address of the L3 Destination 1330 Unreachable message and forwards the message via a link outside the 1331 AERO interface. 1333 When an AERO node receives any L3 error message via the AERO 1334 interface, it examines the destination address in the L3 IP header of 1335 the message. If the next hop toward the destination address of the 1336 error message is via the AERO interface, the node re-encapsulates and 1337 forwards the message to the next hop within the AERO interface. 1338 Otherwise, if the source address in the L3 IP header of the message 1339 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1340 writes one of its non link-local addresses as the source address of 1341 the L3 message and recalculates the IP and/or ICMP checksums. The 1342 node finally forwards the message via a link outside of the AERO 1343 interface. 1345 (*) Note that in some instances the packet-in-error field of an L2 1346 PTB message may not include enough information for translation to an 1347 L3 PTB message. In that case, the AERO interface simply discards the 1348 L2 PTB message. It can therefore be said that translation of L2 PTB 1349 messages to L3 PTB messages can provide a useful optimization when 1350 possible, but is not critical for sources that correctly use PLPMTUD. 1352 3.15. AERO Router Discovery, Prefix Delegation and Address 1353 Configuration 1355 3.15.1. AERO DHCPv6 Service Model 1357 Each AERO Server configures a DHCPv6 server function to facilitate PD 1358 requests from Clients. Each Server is provisioned with a database of 1359 ACP-to-Client ID mappings for all Clients enrolled in the AERO 1360 system, as well as any information necessary to authenticate each 1361 Client. The Client database is maintained by a central 1362 administrative authority for the AERO link and securely distributed 1363 to all Servers, e.g., via the Lightweight Directory Access Protocol 1364 (LDAP) [RFC4511] or a similar distributed database service. 1366 Therefore, no Server-to-Server DHCPv6 PD delegation state 1367 synchronization is necessary, and Clients can optionally hold 1368 separate delegations for the same ACP from multiple Servers. In this 1369 way, Clients can associate with multiple Servers, and can receive new 1370 delegations from new Servers before deprecating delegations received 1371 from existing Servers. 1373 AERO Clients and Servers exchange Client link-layer address 1374 information using an option format similar to the Client Link Layer 1375 Address Option (CLLAO) defined in [RFC6939]. Due to practical 1376 limitations of CLLAO, however, AERO interfaces instead use Vendor- 1377 Specific Information Options as described in the following sections. 1379 3.15.2. AERO Client Behavior 1381 AERO Clients discover the link-layer addresses of AERO Servers via 1382 static configuration, or through an automated means such as DNS name 1383 resolution. In the absence of other information, the Client resolves 1384 the FQDN "linkupnetworks.[domainname]" where "linkupnetworks" is a 1385 constant text string and "[domainname]" is the connection-specific 1386 DNS suffix for the Client's underlying network connection (e.g., 1387 "example.com"). After discovering the link-layer addresses, the 1388 Client associates with one or more of the corresponding Servers. 1390 To associate with a Server, the Client acts as a requesting router to 1391 request an ACP through a two-message (i.e., Solicit/Reply) or four- 1392 message (i.e., Solicit/Advertise/Request/Reply) DHCPv6 PD exchange 1393 [RFC3315][RFC3633]. The Client's Solicit/Request message includes 1394 fe80::ffff:ffff:ffff:ffff as the IPv6 source address, 1395 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 1396 and the link-layer address of the Server as the link-layer 1397 destination address. The Solicit/Request message also includes a 1398 Rapid Commit option, a Client Identifier option with a DHCP Unique 1399 Identifier (DUID) and an Identity Association for Prefix Delegation 1400 (IA_PD) option. If the Client is pre-provisioned with an ACP 1401 associated with the AERO service, it MAY also include the ACP in the 1402 IA_PD to indicate its preference to the DHCPv6 server. 1404 The Client also SHOULD include an AERO Link-registration Request 1405 (ALREQ) option to register one or more links with the Server. The 1406 Server will include an AERO Link-registration Reply (ALREP) option in 1407 the corresponding DHCPv6 Reply message as specified in 1408 Section 3.15.3. (The Client MAY omit the ALREQ option, in which case 1409 the Server will still include an ALREP option in its Reply with "Link 1410 ID" set to 0, "DSCP" set to 0, and "Prf" set to 3.) 1412 The format for the ALREQ option is shown in Figure 5: 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | OPTION_VENDOR_OPTS | option-len (1) | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | enterprise-number = 45282 | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | opt-code = OPTION_ALREQ (0) | option-len (2) | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Link ID | DSCP #1 |Prf| DSCP #2 |Prf| ... 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1426 Figure 5: AERO Link-registration Request (ALREQ) Option 1428 In the above format, the Client sets 'option-code' to 1429 OPTION_VENDOR_OPTS, sets 'option-len (1)' to the length of the option 1430 following this field, sets 'enterprise-number' to 45282 (see: "IANA 1431 Considerations"), sets opt-code to the value 0 ("OPTION_ALREQ") and 1432 sets 'option-len (2)' to the length of the remainder of the option. 1433 The Client includes appropriate 'Link ID, 'DSCP' and 'Prf' values for 1434 the underlying interface over which the DHCPv6 PD Solicit/Request 1435 message will be issued the same as specified for an S/TLLAO 1436 Section 3.4. The Client MAY include multiple (DSCP, Prf) values with 1437 this Link ID, with the number of values indicated by option-len (2). 1438 The Server will register each value with the Link ID in the Client's 1439 neighbor cache entry. The Client finally includes any necessary 1440 authentication options to identify itself to the DHCPv6 server, and 1441 sends the encapsulated DHCPv6 PD Solicit/Request message via the 1442 underlying interface corresponding to Link ID. (Note that this 1443 implies that the Client must perform additional Rebind/Reply DHCPv6 1444 exchanges with the server following the initial PD exchange using 1445 different underlying interfaces and their corresponding Link IDs if 1446 it wishes to register additional link-layer addresses and their 1447 associated DSCPs.) 1449 When the Client receives its ACP via a DHCPv6 Reply from the AERO 1450 Server, it creates a static neighbor cache entry with the Server's 1451 link-local address as the network-layer address and the Server's 1452 encapsulation address as the link-layer address. The Client then 1453 considers the link-layer address of the Server as the primary default 1454 encapsulation address for forwarding packets for which no more- 1455 specific forwarding information is available. The Client further 1456 caches any ASPs included in the ALREP option as ASPs to apply to the 1457 AERO link. 1459 Next, the Client autoconfigures an AERO address from the delegated 1460 ACP, assigns the AERO address to the AERO interface and sub-delegates 1461 the ACP to its attached EUNs and/or the Client's own internal virtual 1462 interfaces. The Client also assigns a default IP route to the AERO 1463 interface as a route-to-interface, i.e., with no explicit next-hop. 1464 The Client can then determine the correct next hops for packets 1465 submitted to the AERO interface by inspecting the neighbor cache. 1467 The Client subsequently renews its ACP delegation through each of its 1468 Servers by performing DHCPv6 Renew/Reply exchanges with the link- 1469 layer address of a Server as the link-layer destination address and 1470 the same options that were used in the initial PD request. Note that 1471 if the Client does not issue a DHCPv6 Renew before the delegation 1472 expires (e.g., if the Client has been out of touch with the Server 1473 for a considerable amount of time) it must re-initiate the DHCPv6 PD 1474 procedure. 1476 Since the Client's AERO address is obtained from the unique ACP 1477 delegation it receives, there is no need for Duplicate Address 1478 Detection (DAD) on AERO links. Other nodes maliciously attempting to 1479 hijack an authorized Client's AERO address will be denied access to 1480 the network by the DHCPv6 server due to an unacceptable link-layer 1481 address and/or security parameters (see: Security Considerations). 1483 When a Client attempts to perform a DHCPv6 PD exchange with a Server 1484 that is too busy to service the request, the Client may receive a 1485 "NoPrefixAvail" status code in the Server's Reply per [RFC3633]. In 1486 that case, the Client SHOULD discontinue DHCPv6 PD attempts through 1487 this Server and try another Server. 1489 3.15.2.1. Autoconfiguration for Constrained Platforms 1491 On some platforms (e.g., popular cell phone operating systems), the 1492 act of assigning a default IPv6 route and/or assigning an address to 1493 an interface may not be permitted from a user application due to 1494 security policy. Typically, those platforms include a TUN/TAP 1495 interface that acts as a point-to-point conduit between user 1496 applications and the AERO interface. In that case, the Client can 1497 instead generate a "synthesized RA" message. The message conforms to 1498 [RFC4861] and is prepared as follows: 1500 o the IPv6 source address is the Client's AERO address 1502 o the IPv6 destination address is all-nodes multicast 1504 o the Router Lifetime is set to a time that is no longer than the 1505 ACP DHCPv6 lifetime 1507 o the message does not include a Source Link Layer Address Option 1508 (SLLAO) 1510 o the message includes a Prefix Information Option (PIO) with a /64 1511 prefix taken from the ACP as the prefix for autoconfiguration 1513 The Client then sends the synthesized RA message via the TUN/TAP 1514 interface, where the operating system kernel will interpret it as 1515 though it were generated by an actual router. The operating system 1516 will then install a default route and use StateLess Address 1517 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 1518 interface. Methods for similarly installing an IPv4 default route 1519 and IPv4 address on the TUN/TAP interface are based on synthesized 1520 DHCPv4 messages [RFC2131]. 1522 3.15.2.2. Client DHCPv6 Message Source Address 1524 In the initial DHCPv6 PD message exchanges, AERO Clients use the 1525 special IPv6 source address 'fe80::ffff:ffff:ffff:ffff' since their 1526 AERO addresses are not yet configured. After AERO address 1527 autoconfiguration, however, AERO Clients can either continue to use 1528 'fe80::ffff:ffff:ffff:ffff' as the source address for further DHCPv6 1529 messaging or begin using their AERO address as the source address. 1531 3.15.3. AERO Server Behavior 1533 AERO Servers configure a DHCPv6 server function on their AERO links. 1534 AERO Servers arrange to add their encapsulation layer IP addresses 1535 (i.e., their link-layer addresses) to the DNS resource records for 1536 the FQDN "linkupnetworks.[domainname]" before entering service. 1538 When an AERO Server receives a prospective Client's DHCPv6 PD 1539 Solicit/Request on its AERO interface, and the Server is too busy to 1540 service the message, it returns a Reply with status code 1541 "NoPrefixAvail" per [RFC3633]. Otherwise, the Server authenticates 1542 the message. 1544 If authentication succeeds, the Server determines the correct ACP to 1545 delegate to the Client by searching the Client database. In 1546 environments where spoofing is not considered a threat, the Server 1547 MAY use the Client's DUID as the identification value. Otherwise, 1548 the Server SHOULD use a signed certificate provided by the Client. 1550 When the Server delegates the ACP, it also creates an IP forwarding 1551 table entry so that the AERO routing system will propagate the ACP to 1552 all Relays that aggregate the corresponding ASP (see: Section 3.7). 1553 Next, the Server prepares a DHCPv6 Reply message to send to the 1554 Client while using fe80::ID as the IPv6 source address, the link- 1555 local address taken from the Client's Solicit/Request as the IPv6 1556 destination address, the Server's link-layer address as the source 1557 link-layer address, and the Client's link-layer address as the 1558 destination link-layer address. The server also includes an IA_PD 1559 option with the delegated ACP. Since the Client may experience a 1560 fault that prevents it from issuing a DHCPv6 Release before departing 1561 from the network, Servers should set a short prefix lifetime (e.g., 1562 40 seconds) so that stale prefix delegation state can be flushed out 1563 of the network. 1565 The Server also includes an ALREP option that includes the UDP Port 1566 Number and IP Address values it observed when it received the ALREQ 1567 in the Client's original DHCPv6 message (if present) followed by the 1568 ASP(s) for the AERO link. The ALREP option is formatted as shown in 1569 Figure 6: 1571 0 1 2 3 1572 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 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | OPTION_VENDOR_OPTS | option-len (1) | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | enterprise-number = 45282 | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | opt-code = OPTION_ALREP (1) | option-len (2) | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Link ID | Reserved | UDP Port Number | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | | 1583 + + 1584 | | 1585 + IP Address + 1586 | | 1587 + + 1588 | | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | | 1591 + AERO Service Prefix (ASP) #1 +-+-+-+-+-+-+-+-+ 1592 | | Prefix Len | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | | 1595 + AERO Service Prefix (ASP) #2 +-+-+-+-+-+-+-+-+ 1596 | | Prefix Len | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 ~ ~ 1599 ~ ~ 1601 Figure 6: AERO Link-registration Reply (ALREP) Option 1603 In the ALREP, the Server sets 'option-code' to OPTION_VENDOR_OPTS, 1604 sets 'option-length (1)' to the length of the option, sets 1605 'enterprise-number' to 45282 (see: "IANA Considerations"), sets opt- 1606 code to OPTION_ALREP (1), and sets 'option-len (2)' to the length of 1607 the remainder of the option. Next, the Server sets 'Link ID' to the 1608 same value that appeared in the ALREQ, sets Reserved to 0 and sets 1609 'UDP Port Number' and 'IP address' to the Client's link-layer 1610 address. The Server next includes one or more ASP with the IP prefix 1611 as it would appear in the interface identifier portion of the 1612 corresponding AERO address (see: Section 3.3), except that the low- 1613 order 8 bits of the ASP field encode the prefix length instead of the 1614 low-order 8 bits of the prefix. The longest prefix that can 1615 therefore appear as an ASP is /56 for IPv6 or /24 for IPv4. (Note 1616 that if the Client did not include an ALREQ option in its DHCPv6 1617 message, the Server MUST still include an ALREP option in the 1618 corresponding reply with 'Link ID' set to 0.) 1620 When the Server admits the DHCPv6 Reply message into the AERO 1621 interface, it creates a static neighbor cache entry for the Client's 1622 AERO address with lifetime set to no more than the delegation 1623 lifetime and the Client's link-layer address as the link-layer 1624 address for the Link ID specified in the ALREQ. The Server then uses 1625 the Client link-layer address information in the ALREQ option as the 1626 link-layer address for encapsulation based on the (DSCP, Prf) 1627 information. 1629 After the initial DHCPv6 PD exchange, the AERO Server maintains the 1630 neighbor cache entry for the Client until the delegation lifetime 1631 expires. If the Client issues a Renew/Reply exchange, the Server 1632 extends the lifetime. If the Client issues a Release/Reply, or if 1633 the Client does not issue a Renew/Reply before the lifetime expires, 1634 the Server deletes the neighbor cache entry for the Client and 1635 withdraws the IP route from the AERO routing system. 1637 3.15.3.1. Lightweight DHCPv6 Relay Agent (LDRA) 1639 AERO Clients and Servers are always on the same link (i.e., the AERO 1640 link) from the perspective of DHCPv6. However, in some 1641 implementations the DHCPv6 server and AERO interface driver may be 1642 located in separate modules. In that case, the Server's AERO 1643 interface driver module acts as a Lightweight DHCPv6 Relay Agent 1644 (LDRA)[RFC6221] to relay DHCPv6 messages to and from the DHCPv6 1645 server module. 1647 When the LDRA receives a DHCPv6 message from a client, it prepares an 1648 ALREP option the same as described above then wraps the option in a 1649 Relay-Supplied DHCP Option option (RSOO) [RFC6422]. The LDRA then 1650 incorporates the option into the Relay-Forward message and forwards 1651 the message to the DHCPv6 server. 1653 When the DHCPv6 server receives the Relay-Forward message, it caches 1654 the ALREP option and authenticates the encapsulated DHCPv6 message. 1655 The DHCPv6 server subsequently ignores the ALREQ option itself, since 1656 the relay has already included the ALREP option. 1658 When the DHCPv6 server prepares a Reply message, it then includes the 1659 ALREP option in the body of the message along with any other options, 1660 then wraps the message in a Relay-Reply message. The DHCPv6 server 1661 then delivers the Relay-Reply message to the LDRA, which discards the 1662 Relay-Reply wrapper and delivers the DHCPv6 message to the Client. 1664 3.15.4. Deleting Link Registrations 1666 After an AERO Client registers its Link IDs and their associated 1667 (DSCP,Prf) values with the AERO Server, the Client may wish to delete 1668 one or more Link registrations, e.g., if an underlying link becomes 1669 unavailable. To do so, the Client prepares a DHCPv6 Rebind message 1670 that includes an AERO Link-registration Delete (ALDEL) option and 1671 sends the Rebind message to the Server over any available underlying 1672 link. The ALDEL option is formatted as shown in Figure 7: 1674 0 1 2 3 1675 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 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | OPTION_VENDOR_OPTS | option-len (1) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | enterprise-number = 45282 | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | opt-code = OPTION_ALDEL (2) | option-len (2) | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Link ID #1 | Link ID #2 | Link ID #3 | ... 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1686 Figure 7: AERO Link-registration Delete (ALDEL) Option 1688 In the ALDEL, the Client sets 'option-code' to OPTION_VENDOR_OPTS, 1689 sets 'option-length (1)' to the length of the option, sets 1690 'enterprise-number' to 45282 (see: "IANA Considerations"), sets 1691 optcode to OPTION_ALDEL (2), and sets 'option-len (2)' to the length 1692 of the remainder of the option. Next, the Server includes each 'Link 1693 ID' value that it wishes to delete. 1695 If the Client wishes to discontinue use of a Server and thereby 1696 delete all of its Link ID associations, it must use a DHCPv6 Release/ 1697 Reply exchange to delete the entire neighbor cache entry, i.e., 1698 instead of using a DHCPv6 Rebind/Reply exchange with one or more 1699 ALDEL options. 1701 3.16. AERO Forwarding Agent Behavior 1703 AERO Servers MAY associate with one or more companion AERO Forwarding 1704 Agents as platforms for offloading high-speed data plane traffic. 1705 When an AERO Server receives a Client's DHCPv6 1706 Solicit/Request/Renew/Rebind/Release message, it services the message 1707 then forwards the corresponding Reply message to the Forwarding 1708 Agent. When the Forwarding Agent receives the Reply message, it 1709 creates, updates or deletes a neighbor cache entry with the Client's 1710 AERO address and link-layer information included in the Reply 1711 message. The Forwarding Agent then forwards the Reply message back 1712 to the AERO Server, which forwards the message to the Client. In 1713 this way, Forwarding Agent state is managed in conjunction with 1714 Server state, with the Client responsible for reliability. If the 1715 Client subsequently disappears without issuing a Release, the Server 1716 is responsible for purging stale state by sending synthesized Reply 1717 messages to the Forwarding Agent. 1719 When an AERO Server receives a data packet on an AERO interface with 1720 a network layer destination address for which it has distributed 1721 forwarding information to a Forwarding Agent, the Server returns a 1722 Redirect message to the source neighbor (subject to rate limiting) 1723 then forwards the data packet as usual. The Redirect message 1724 includes a TLLAO with the link-layer address of the Forwarding 1725 Engine. 1727 When the source neighbor receives the Redirect message, it SHOULD 1728 record the link-layer address in the TLLAO as the encapsulation 1729 addresses to use for sending subsequent data packets. However, the 1730 source MUST continue to use the primary link-layer address of the 1731 Server as the encapsulation address for sending control messages. 1733 3.17. AERO Intradomain Route Optimization 1735 When a source Client forwards packets to a prospective correspondent 1736 Client within the same AERO link domain (i.e., one for which the 1737 packet's destination address is covered by an ASP), the source Client 1738 initiates an intra-domain AERO route optimization procedure. It is 1739 important to note that this procedure is initiated by the Client; if 1740 the procedure were initiated by the Server, the Server would have no 1741 way of knowing whether the Client was actually able to contact the 1742 correspondent over the route-optimized path. 1744 The procedure is based on an exchange of IPv6 ND messages using a 1745 chain of AERO Servers and Relays as a trust basis. This procedure is 1746 in contrast to the Return Routability procedure required for route 1747 optimization to a correspondent Client located in the Internet as 1748 described in Section 3.22. The following sections specify the AERO 1749 intradomain route optimization procedure. 1751 3.17.1. Reference Operational Scenario 1753 Figure 8 depicts the AERO intradomain route optimization reference 1754 operational scenario, using IPv6 addressing as the example (while not 1755 shown, a corresponding example for IPv4 addressing can be easily 1756 constructed). The figure shows an AERO Relay ('R1'), two AERO 1757 Servers ('S1', 'S2'), two AERO Clients ('C1', 'C2') and two ordinary 1758 IPv6 hosts ('H1', 'H2'): 1760 +--------------+ +--------------+ +--------------+ 1761 | Server S1 | | Relay R1 | | Server S2 | 1762 +--------------+ +--------------+ +--------------+ 1763 fe80::2 fe80::1 fe80::3 1764 L2(S1) L2(R1) L2(S2) 1765 | | | 1766 X-----+-----+------------------+-----------------+----+----X 1767 | AERO Link | 1768 L2(A) L2(B) 1769 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1770 +--------------+ +--------------+ 1771 |AERO Client C1| |AERO Client C2| 1772 +--------------+ +--------------+ 1773 2001:DB8:0::/48 2001:DB8:1::/48 1774 | | 1775 .-. .-. 1776 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1777 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1778 (__ EUN )--| Host H1 | | Host H2 |--(__ EUN ) 1779 `-(______)-' +---------+ +---------+ `-(______)-' 1781 Figure 8: AERO Reference Operational Scenario 1783 In Figure 8, Relay ('R1') assigns the address fe80::1 to its AERO 1784 interface with link-layer address L2(R1), Server ('S1') assigns the 1785 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1786 assigns the address fe80::3 with link-layer address L2(S2). Servers 1787 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1788 published list of valid Servers for the AERO link. 1790 AERO Client ('C1') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1791 exchange via AERO Server ('S1') then assigns the address 1792 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1793 L2(C1). Client ('C1') configures a default route and neighbor cache 1794 entry via the AERO interface with next-hop address fe80::2 and link- 1795 layer address L2(S1), then sub-delegates the ACP to its attached 1796 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1797 address 2001:db8:0::1. 1799 AERO Client ('C2') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1800 exchange via AERO Server ('S2') then assigns the address 1801 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1802 L2(C2). Client ('C2') configures a default route and neighbor cache 1803 entry via the AERO interface with next-hop address fe80::3 and link- 1804 layer address L2(S2), then sub-delegates the ACP to its attached 1805 EUNs. IPv6 host ('H1') connects to the EUN, and configures the 1806 address 2001:db8:1::1. 1808 3.17.2. Concept of Operations 1810 Again, with reference to Figure 8, when source host ('H1') sends a 1811 packet to destination host ('H2'), the packet is first forwarded over 1812 the source host's attached EUN to Client ('C1'). Client ('C1') then 1813 forwards the packet via its AERO interface to Server ('S1') and also 1814 sends a Predirect message toward Client ('C2') via Server ('S1'). 1815 Server ('S1') then re-encapsulates and forwards both the packet and 1816 the Predirect message out the same AERO interface toward Client 1817 ('C2') via Relay ('R1'). 1819 When Relay ('R1') receives the packet and Predirect message, it 1820 consults its forwarding table to discover Server ('S2') as the next 1821 hop toward Client ('C2'). Relay ('R1') then forwards both the packet 1822 and the Predirect message to Server ('S2'), which then forwards them 1823 to Client ('C2'). 1825 After Client ('C2') receives the Predirect message, it process the 1826 message and returns a Redirect message toward Client ('C1') via 1827 Server ('S2'). During the process, Client ('C2') also creates or 1828 updates a dynamic neighbor cache entry for Client ('C1'). 1830 When Server ('S2') receives the Redirect message, it re-encapsulates 1831 the message and forwards it on to Relay ('R1'), which forwards the 1832 message on to Server ('S1') which forwards the message on to Client 1833 ('C1'). After Client ('C1') receives the Redirect message, it 1834 processes the message and creates or updates a dynamic neighbor cache 1835 entry for Client ('C2'). 1837 Following the above Predirect/Redirect message exchange, forwarding 1838 of packets from Client ('C1') to Client ('C2') without involving any 1839 intermediate nodes is enabled. The mechanisms that support this 1840 exchange are specified in the following sections. 1842 3.17.3. Message Format 1844 AERO Redirect/Predirect messages use the same format as for ICMPv6 1845 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1846 include a new "Prefix Length" field taken from the low-order 8 bits 1847 of the Redirect message Reserved field. For IPv6, valid values for 1848 the Prefix Length field are 0 through 64; for IPv4, valid values are 1849 0 through 32. The Redirect/Predirect messages are formatted as shown 1850 in Figure 9: 1852 0 1 2 3 1853 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 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Type (=137) | Code (=0/1) | Checksum | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Reserved | Prefix Length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | | 1860 + + 1861 | | 1862 + Target Address + 1863 | | 1864 + + 1865 | | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | | 1868 + + 1869 | | 1870 + Destination Address + 1871 | | 1872 + + 1873 | | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | Options ... 1876 +-+-+-+-+-+-+-+-+-+-+-+- 1878 Figure 9: AERO Redirect/Predirect Message Format 1880 3.17.4. Sending Predirects 1882 When a Client forwards a packet with a source address from one of its 1883 ACPs toward a destination address covered by an ASP (i.e., toward 1884 another AERO Client connected to the same AERO link), the source 1885 Client MAY send a Predirect message forward toward the destination 1886 Client via the Server. 1888 In the reference operational scenario, when Client ('C1') forwards a 1889 packet toward Client ('C2'), it MAY also send a Predirect message 1890 forward toward Client ('C2'), subject to rate limiting (see 1891 Section 8.2 of [RFC4861]). Client ('C1') prepares the Predirect 1892 message as follows: 1894 o the link-layer source address is set to 'L2(C1)' (i.e., the link- 1895 layer address of Client ('C1')). 1897 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1898 link-layer address of Server ('S1')). 1900 o the network-layer source address is set to fe80::2001:db8:0:0 1901 (i.e., the AERO address of Client ('C1')). 1903 o the network-layer destination address is set to fe80::2001:db8:1:0 1904 (i.e., the AERO address of Client ('C2')). 1906 o the Type is set to 137. 1908 o the Code is set to 1 to indicate "Predirect". 1910 o the Prefix Length is set to the length of the prefix to be 1911 assigned to the Target Address. 1913 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1914 address of Client ('C1')). 1916 o the Destination Address is set to the source address of the 1917 originating packet that triggered the Predirection event. (If the 1918 originating packet is an IPv4 packet, the address is constructed 1919 in IPv4-compatible IPv6 address format). 1921 o the message includes one or more TLLAOs with Link ID and DSCPs set 1922 to appropriate values for Client ('C1')'s underlying interfaces, 1923 and with UDP Port Number and IP Address set to 0'. 1925 o the message SHOULD include a Timestamp option and a Nonce option. 1927 o the message includes a Redirected Header Option (RHO) that 1928 contains the originating packet truncated if necessary to ensure 1929 that at least the network-layer header is included but the size of 1930 the message does not exceed 1280 bytes. 1932 Note that the act of sending Predirect messages is cited as "MAY", 1933 since Client ('C1') may have advanced knowledge that the direct path 1934 to Client ('C2') would be unusable or otherwise undesirable. If the 1935 direct path later becomes unusable after the initial route 1936 optimization, Client ('C1') simply allows packets to again flow 1937 through Server ('S1'). 1939 3.17.5. Re-encapsulating and Relaying Predirects 1941 When Server ('S1') receives a Predirect message from Client ('C1'), 1942 it first verifies that the TLLAOs in the Predirect are a proper 1943 subset of the Link IDs in Client ('C1')'s neighbor cache entry. If 1944 the Client's TLLAOs are not acceptable, Server ('S1') discards the 1945 message. Otherwise, Server ('S1') validates the message according to 1946 the ICMPv6 Redirect message validation rules in Section 8.1 of 1947 [RFC4861], except that the Predirect has Code=1. Server ('S1') also 1948 verifies that Client ('C1') is authorized to use the Prefix Length in 1949 the Predirect when applied to the AERO address in the network-layer 1950 source address by searching for the AERO address in the neighbor 1951 cache. If validation fails, Server ('S1') discards the Predirect; 1952 otherwise, it copies the correct UDP Port numbers and IP Addresses 1953 for Client ('C1')'s links into the (previously empty) TLLAOs. 1955 Server ('S1') then examines the network-layer destination address of 1956 the Predirect to determine the next hop toward Client ('C2') by 1957 searching for the AERO address in the neighbor cache. Since Client 1958 ('C2') is not one of its neighbors, Server ('S1') re-encapsulates the 1959 Predirect and relays it via Relay ('R1') by changing the link-layer 1960 source address of the message to 'L2(S1)' and changing the link-layer 1961 destination address to 'L2(R1)'. Server ('S1') finally forwards the 1962 re-encapsulated message to Relay ('R1') without decrementing the 1963 network-layer TTL/Hop Limit field. 1965 When Relay ('R1') receives the Predirect message from Server ('S1') 1966 it determines that Server ('S2') is the next hop toward Client ('C2') 1967 by consulting its forwarding table. Relay ('R1') then re- 1968 encapsulates the Predirect while changing the link-layer source 1969 address to 'L2(R1)' and changing the link-layer destination address 1970 to 'L2(S2)'. Relay ('R1') then relays the Predirect via Server 1971 ('S2'). 1973 When Server ('S2') receives the Predirect message from Relay ('R1') 1974 it determines that Client ('C2') is a neighbor by consulting its 1975 neighbor cache. Server ('S2') then re-encapsulates the Predirect 1976 while changing the link-layer source address to 'L2(S2)' and changing 1977 the link-layer destination address to 'L2(C2)'. Server ('S2') then 1978 forwards the message to Client ('C2'). 1980 3.17.6. Processing Predirects and Sending Redirects 1982 When Client ('C2') receives the Predirect message, it accepts the 1983 Predirect only if the message has a link-layer source address of one 1984 of its Servers (e.g., L2(S2)). Client ('C2') further accepts the 1985 message only if it is willing to serve as a redirection target. 1986 Next, Client ('C2') validates the message according to the ICMPv6 1987 Redirect message validation rules in Section 8.1 of [RFC4861], except 1988 that it accepts the message even though Code=1 and even though the 1989 network-layer source address is not that of it's current first-hop 1990 router. 1992 In the reference operational scenario, when Client ('C2') receives a 1993 valid Predirect message, it either creates or updates a dynamic 1994 neighbor cache entry that stores the Target Address of the message as 1995 the network-layer address of Client ('C1') , stores the link-layer 1996 addresses found in the TLLAOs as the link-layer addresses of Client 1997 ('C1') and stores the Prefix Length as the length to be applied to 1998 the network-layer address for forwarding purposes. Client ('C2') 1999 then sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 2001 After processing the message, Client ('C2') prepares a Redirect 2002 message response as follows: 2004 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 2005 layer address of Client ('C2')). 2007 o the link-layer destination address is set to 'L2(S2)' (i.e., the 2008 link-layer address of Server ('S2')). 2010 o the network-layer source address is set to fe80::2001:db8:1:0 2011 (i.e., the AERO address of Client ('C2')). 2013 o the network-layer destination address is set to fe80::2001:db8:0:0 2014 (i.e., the AERO address of Client ('C1')). 2016 o the Type is set to 137. 2018 o the Code is set to 0 to indicate "Redirect". 2020 o the Prefix Length is set to the length of the prefix to be applied 2021 to the Target Address. 2023 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 2024 address of Client ('C2')). 2026 o the Destination Address is set to the destination address of the 2027 originating packet that triggered the Redirection event. (If the 2028 originating packet is an IPv4 packet, the address is constructed 2029 in IPv4-compatible IPv6 address format). 2031 o the message includes one or more TLLAOs with Link ID and DSCPs set 2032 to appropriate values for Client ('C2')'s underlying interfaces, 2033 and with UDP Port Number and IP Address set to '0'. 2035 o the message SHOULD include a Timestamp option and MUST echo the 2036 Nonce option received in the Predirect (i.e., if a Nonce option is 2037 included). 2039 o the message includes as much of the RHO copied from the 2040 corresponding AERO Predirect message as possible such that at 2041 least the network-layer header is included but the size of the 2042 message does not exceed 1280 bytes. 2044 After Client ('C2') prepares the Redirect message, it sends the 2045 message to Server ('S2'). 2047 3.17.7. Re-encapsulating and Relaying Redirects 2049 When Server ('S2') receives a Redirect message from Client ('C2'), it 2050 first verifies that the TLLAOs in the Redirect are a proper subset of 2051 the Link IDs in Client ('C2')'s neighbor cache entry. If the 2052 Client's TLLAOs are not acceptable, Server ('S2') discards the 2053 message. Otherwise, Server ('S2') validates the message according to 2054 the ICMPv6 Redirect message validation rules in Section 8.1 of 2055 [RFC4861]. Server ('S2') also verifies that Client ('C2') is 2056 authorized to use the Prefix Length in the Redirect when applied to 2057 the AERO address in the network-layer source address by searching for 2058 the AERO address in the neighbor cache. If validation fails, Server 2059 ('S2') discards the Predirect; otherwise, it copies the correct UDP 2060 Port numbers and IP Addresses for Client ('C2')'s links into the 2061 (previously empty) TLLAOs. 2063 Server ('S2') then examines the network-layer destination address of 2064 the Predirect to determine the next hop toward Client ('C2') by 2065 searching for the AERO address in the neighbor cache. Since Client 2066 ('C2') is not a neighbor, Server ('S2') re-encapsulates the Predirect 2067 and relays it via Relay ('R1') by changing the link-layer source 2068 address of the message to 'L2(S2)' and changing the link-layer 2069 destination address to 'L2(R1)'. Server ('S2') finally forwards the 2070 re-encapsulated message to Relay ('R1') without decrementing the 2071 network-layer TTL/Hop Limit field. 2073 When Relay ('R1') receives the Predirect message from Server ('S2') 2074 it determines that Server ('S1') is the next hop toward Client ('C1') 2075 by consulting its forwarding table. Relay ('R1') then re- 2076 encapsulates the Predirect while changing the link-layer source 2077 address to 'L2(R1)' and changing the link-layer destination address 2078 to 'L2(S1)'. Relay ('R1') then relays the Predirect via Server 2079 ('S1'). 2081 When Server ('S1') receives the Predirect message from Relay ('R1') 2082 it determines that Client ('C1') is a neighbor by consulting its 2083 neighbor cache. Server ('S1') then re-encapsulates the Predirect 2084 while changing the link-layer source address to 'L2(S1)' and changing 2085 the link-layer destination address to 'L2(C1)'. Server ('S1') then 2086 forwards the message to Client ('C1'). 2088 3.17.8. Processing Redirects 2090 When Client ('C1') receives the Redirect message, it accepts the 2091 message only if it has a link-layer source address of one of its 2092 Servers (e.g., ''L2(S1)'). Next, Client ('C1') validates the message 2093 according to the ICMPv6 Redirect message validation rules in 2094 Section 8.1 of [RFC4861], except that it accepts the message even 2095 though the network-layer source address is not that of it's current 2096 first-hop router. Following validation, Client ('C1') then processes 2097 the message as follows. 2099 In the reference operational scenario, when Client ('C1') receives 2100 the Redirect message, it either creates or updates a dynamic neighbor 2101 cache entry that stores the Target Address of the message as the 2102 network-layer address of Client ('C2'), stores the link-layer 2103 addresses found in the TLLAOs as the link-layer addresses of Client 2104 ('C2') and stores the Prefix Length as the length to be applied to 2105 the network-layer address for forwarding purposes. Client ('C1') 2106 then sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 2108 Now, Client ('C1') has a neighbor cache entry with a valid 2109 ForwardTime value, while Client ('C2') has a neighbor cache entry 2110 with a valid AcceptTime value. Thereafter, Client ('C1') may forward 2111 ordinary network-layer data packets directly to Client ('C2') without 2112 involving any intermediate nodes, and Client ('C2') can verify that 2113 the packets came from an acceptable source. (In order for Client 2114 ('C2') to forward packets to Client ('C1'), a corresponding 2115 Predirect/Redirect message exchange is required in the reverse 2116 direction; hence, the mechanism is asymmetric.) 2118 3.17.9. Server-Oriented Redirection 2120 In some environments, the Server nearest the target Client may need 2121 to serve as the redirection target, e.g., if direct Client-to-Client 2122 communications are not possible. In that case, the Server prepares 2123 the Redirect message the same as if it were the destination Client 2124 (see: Section 3.17.6), except that it writes its own link-layer 2125 address in the TLLAO option. The Server must then maintain a dynamic 2126 neighbor cache entry for the redirected source Client. 2128 3.18. Neighbor Unreachability Detection (NUD) 2130 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 2131 unicast NS messages to elicit solicited NA messages from neighbors 2132 the same as described in [RFC4861]. NUD is performed either 2133 reactively in response to persistent L2 errors (see Section 3.14) or 2134 proactively to refresh existing neighbor cache entries. 2136 When an AERO node sends an NS/NA message, it MUST use its link-local 2137 address as the IPv6 source address and the link-local address of the 2138 neighbor as the IPv6 destination address. When an AERO node receives 2139 an NS message or a solicited NA message, it accepts the message if it 2140 has a neighbor cache entry for the neighbor; otherwise, it ignores 2141 the message. 2143 When a source Client is redirected to a target Client it SHOULD 2144 proactively test the direct path by sending an initial NS message to 2145 elicit a solicited NA response. While testing the path, the source 2146 Client can optionally continue sending packets via the Server, 2147 maintain a small queue of packets until target reachability is 2148 confirmed, or (optimistically) allow packets to flow directly to the 2149 target. The source Client SHOULD thereafter continue to proactively 2150 test the direct path to the target Client (see Section 7.3 of 2151 [RFC4861]) periodically in order to keep dynamic neighbor cache 2152 entries alive. 2154 In particular, while the source Client is actively sending packets to 2155 the target Client it SHOULD also send NS messages separated by 2156 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 2157 If the source Client is unable to elicit a solicited NA response from 2158 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 2159 to 0 and resume sending packets via one of its Servers. Otherwise, 2160 the source Client considers the path usable and SHOULD thereafter 2161 process any link-layer errors as a hint that the direct path to the 2162 target Client has either failed or has become intermittent. 2164 When a target Client receives an NS message from a source Client, it 2165 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 2166 otherwise, it discards the NS message. If ForwardTime is non-zero, 2167 the target Client then sends a solicited NA message to the link-layer 2168 address of the source Client; otherwise, it sends the solicited NA 2169 message to the link-layer address of one of its Servers. 2171 When a source Client receives a solicited NA message from a target 2172 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 2173 entry exists; otherwise, it discards the NA message. 2175 When ForwardTime for a dynamic neighbor cache entry expires, the 2176 source Client resumes sending any subsequent packets via a Server and 2177 may (eventually) attempt to re-initiate the AERO redirection process. 2178 When AcceptTime for a dynamic neighbor cache entry expires, the 2179 target Client discards any subsequent packets received directly from 2180 the source Client. When both ForwardTime and AcceptTime for a 2181 dynamic neighbor cache entry expire, the Client deletes the neighbor 2182 cache entry. 2184 3.19. Mobility Management 2186 3.19.1. Announcing Link-Layer Address Changes 2188 When a Client needs to change its link-layer address, e.g., due to a 2189 mobility event, it performs an immediate DHCPv6 Rebind/Reply exchange 2190 via each of its Servers using the new link-layer address as the 2191 source address and with an ALREQ that includes the correct Link ID 2192 and DSCP values. If authentication succeeds, the Server then update 2193 its neighbor cache and sends a DHCPv6 Reply. Note that if the Client 2194 does not issue a DHCPv6 Rebind before the prefix delegation lifetime 2195 expires (e.g., if the Client has been out of touch with the Server 2196 for a considerable amount of time), the Server's Reply will report 2197 NoBinding and the Client must re-initiate the DHCPv6 PD procedure. 2199 Next, the Client sends unsolicited NA messages to each of its 2200 correspondent Client neighbors using the same procedures as specified 2201 in Section 7.2.6 of [RFC4861], except that it sends the messages as 2202 unicast to each neighbor via a Server instead of multicast. In this 2203 process, the Client should send no more than 2204 MAX_NEIGHBOR_ADVERTISEMENT messages separated by no less than 2205 RETRANS_TIMER seconds to each neighbor. 2207 With reference to Figure 8, when Client ('C2') needs to change its 2208 link-layer address it sends unicast unsolicited NA messages to Client 2209 ('C1') via Server ('S2') as follows: 2211 o the link-layer source address is set to 'L2(C2)' (i.e., the link- 2212 layer address of Client ('C2')). 2214 o the link-layer destination address is set to 'L2(S2)' (i.e., the 2215 link-layer address of Server ('S2')). 2217 o the network-layer source address is set to fe80::2001:db8:1:0 2218 (i.e., the AERO address of Client ('C2')). 2220 o the network-layer destination address is set to fe80::2001:db8:0:0 2221 (i.e., the AERO address of Client ('C1')). 2223 o the Type is set to 136. 2225 o the Code is set to 0. 2227 o the Solicited flag is set to 0. 2229 o the Override flag is set to 1. 2231 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 2232 address of Client ('C2')). 2234 o the message includes one or more TLLAOs with Link ID and DSCPs set 2235 to appropriate values for Client ('C2')'s underlying interfaces, 2236 and with UDP Port Number and IP Address set to '0'. 2238 o the message SHOULD include a Timestamp option. 2240 When Server ('S1') receives the NA message, it relays the message in 2241 the same way as described for relaying Redirect messages in 2242 Section 3.17.7. In particular, Server ('S1') copies the correct UDP 2243 port numbers and IP addresses into the TLLAOs, changes the link-layer 2244 source address to its own address, changes the link-layer destination 2245 address to the address of Relay ('R1'), then forwards the NA message 2246 via the relaying chain the same as for a Redirect. 2248 When Client ('C1') receives the NA message, it accepts the message 2249 only if it already has a neighbor cache entry for Client ('C2') then 2250 updates the link-layer addresses for Client ('C2') based on the 2251 addresses in the TLLAOs. Next, Client ('C1') SHOULD initiate the NUD 2252 procedures specified in Section 3.18 to provide Client ('C2') with an 2253 indication that the link-layer source address has been updated, and 2254 to refresh ('C2')'s AcceptTime and ('C1')'s ForwardTime timers. 2256 If Client ('C2') receives an NS message from Client ('C1') indicating 2257 that an unsolicited NA has updated its neighbor cache, Client ('C2') 2258 need not send additional unsolicited NAs. If Client ('C2')'s 2259 unsolicited NA messages are somehow lost, however, Client ('C1') will 2260 soon learn of the mobility event via NUD. 2262 3.19.2. Bringing New Links Into Service 2264 When a Client needs to bring a new underlying interface into service 2265 (e.g., when it activates a new data link), it performs an immediate 2266 Rebind/Reply exchange via each of its Servers using the new link- 2267 layer address as the source address and with an ALREQ that includes 2268 the new Link ID and DSCP values. If authentication succeeds, the 2269 Server then updates its neighbor cache and sends a DHCPv6 Reply. The 2270 Client MAY then send unsolicited NA messages to each of its 2271 correspondent Clients to inform them of the new link-layer address as 2272 described in Section 3.19.1. 2274 3.19.3. Removing Existing Links from Service 2276 When a Client needs to remove an existing underlying interface from 2277 service (e.g., when it de-activates an existing data link), it 2278 performs an immediate Rebind/Reply exchange via each of its Servers 2279 over any available link with an ALDEL that includes the deprecated 2280 Link ID. If authentication succeeds, the Server then updates its 2281 neighbor cache and sends a DHCPv6 Reply. The Client SHOULD then send 2282 unsolicited NA messages to each of its correspondent Clients to 2283 inform them of the deprecated link-layer address as described in 2284 Section 3.19.1. 2286 3.19.4. Moving to a New Server 2288 When a Client associates with a new Server, it performs the Client 2289 procedures specified in Section 3.15.2. 2291 When a Client disassociates with an existing Server, it sends a 2292 DHCPv6 Release message via a new Server to the unicast link-local 2293 network layer address of the old Server. The new Server then writes 2294 its own link-layer address in the DHCPv6 Release message IP source 2295 address and forwards the message to the old Server. 2297 When the old Server receives the DHCPv6 Release, it first 2298 authenticates the message. The Server then resets the Client's 2299 neighbor cache entry lifetime to 5 seconds, rewrites the link-layer 2300 address in the neighbor cache entry to the address of the new Server, 2301 then returns a DHCPv6 Reply message to the Client via the old Server. 2302 When the lifetime expires, the old Server withdraws the IP route from 2303 the AERO routing system and deletes the neighbor cache entry for the 2304 Client. The Client can then use the Reply message to verify that the 2305 termination signal has been processed, and can delete both the 2306 default route and the neighbor cache entry for the old Server. (Note 2307 that since Release/Reply messages may be lost in the network the 2308 Client MUST retry until it gets Reply indicating that the Release was 2309 successful.) 2311 Clients SHOULD NOT move rapidly between Servers in order to avoid 2312 causing excessive oscillations in the AERO routing system. Such 2313 oscillations could result in intermittent reachability for the Client 2314 itself, while causing little harm to the network. Examples of when a 2315 Client might wish to change to a different Server include a Server 2316 that has gone unreachable, topological movements of significant 2317 distance, etc. 2319 3.20. Proxy AERO 2321 Proxy Mobile IPv6 (PMIPv6) [RFC5213][RFC5844][RFC5949] presents a 2322 localized mobility management scheme for use within an access network 2323 domain. It is typically used in WiFi and cellular wireless access 2324 networks, and allows Mobile Nodes (MNs) to receive and retain an IP 2325 address that remains stable within the access network domain without 2326 needing to implement any special mobility protocols. In the PMIPv6 2327 architecture, access network devices known as Mobility Access 2328 Gateways (MAGs) provide MNs with an access link abstraction and 2329 receive prefixes for the MNs from a Local Mobility Anchor (LMA). 2331 In a proxy AERO domain, a proxy AERO Client (acting as a MAG) can 2332 similarly provide proxy services for MNs that do not participate in 2333 AERO messaging. The proxy Client presents an access link abstraction 2334 to MNs, and performs DHCPv6 PD exchanges over the AERO interface with 2335 an AERO Server (acting as an LMA) to receive ACPs for address 2336 provisioning of new MNs that come onto an access link. This scheme 2337 assumes that proxy Clients act as fixed (non-mobile) infrastructure 2338 elements under the same administrative trust basis as for Relays and 2339 Servers. 2341 When an MN comes onto an access link within a proxy AERO domain for 2342 the first time, the proxy Client authenticates the MN and obtains a 2343 unique identifier that it can use as a DHCPv6 DUID then issues a 2344 DHCPv6 PD Solicit/Request to its Server. When the Server delegates 2345 an ACP, the proxy Client creates an AERO address for the MN and 2346 assigns the ACP to the MN's access link. The proxy Client then 2347 configures itself as a default router for the MN and provides address 2348 autoconfiguration services (e.g., SLAAC, DHCPv6, DHCPv4, etc.) for 2349 provisioning MN addresses from the ACP over the access link. Since 2350 the proxy Client may serve many such MNs simultaneously, it may 2351 receive multiple ACP prefix delegations and configure multiple AERO 2352 addresses, i.e., one for each MN. 2354 When two MNs are associated with the same proxy Client, the Client 2355 can forward traffic between the MNs without involving a Server since 2356 it configures the AERO addresses of both MNs and therefore also has 2357 the necessary routing information. When two MNs are associated with 2358 different proxy Clients, the source MN's Client can initiate standard 2359 AERO route optimization to discover a direct path to the target MN's 2360 Client through the exchange of Predirect/Redirect messages. 2362 When an MN in a proxy AERO domain leaves an access link provided by 2363 an old proxy Client, the MN issues an access link-specific "leave" 2364 message that informs the old Client of the link-layer address of a 2365 new Client on the planned new access link. This is known as a 2366 "predictive handover". When an MN comes onto an access link provided 2367 by a new proxy Client, the MN issues an access link-specific "join" 2368 message that informs the new Client of the link-layer address of the 2369 old Client on the actual old access link. This is known as a 2370 "reactive handover". 2372 Upon receiving a predictive handover indication, the old proxy Client 2373 sends a DHCPv6 PD Solicit/Request message directly to the new Client 2374 and queues any arriving data packets addressed to the departed MN. 2375 The Solicit/Request message includes the MN's ID as the DUID, the ACP 2376 in an IA_PD option, the old Client's address as the link-layer source 2377 address and the new Client's address as the link-layer destination 2378 address. When the new Client receives the Solicit/Request message, 2379 it changes the link-layer source address to its own address, changes 2380 the link-layer destination address to the address of its Server, and 2381 forwards the message to the Server. At the same time, the new Client 2382 creates access link state for the ACP in anticipation of the MN's 2383 arrival (while queuing any data packets until the MN arrives), 2384 creates a neighbor cache entry for the old Client with AcceptTime set 2385 to ACCEPT_TIME, then sends a Redirect message back to the old Client. 2386 When the old Client receives the Redirect message, it creates a 2387 neighbor cache entry for the new Client with ForwardTime set to 2388 FORWARD_TIME, then forwards any queued data packets to the new 2389 Client. At the same time, the old Client sends a DHCPv6 PD Release 2390 message to its Server. Finally, the old Client sends unsolicited NA 2391 messages to any of the ACP's correspondents with a TLLAO containing 2392 the link-layer address of the new Client. This follows the procedure 2393 specified in Section 3.19.1, except that it is the old Client and not 2394 the Server that supplies the link-layer address. 2396 Upon receiving a reactive handover indication, the new proxy Client 2397 creates access link state for the MN's ACP, sends a DHCPv6 PD 2398 Solicit/Request message to its Server, and sends a DHCPv6 PD Release 2399 message directly to the old Client. The Release message includes the 2400 MN's ID as the DUID, the ACP in an IA_PD option, the new Client's 2401 address as the link-layer source address and the old Client's address 2402 as the link-layer destination address. When the old Client receives 2403 the Release message, it changes the link-layer source address to its 2404 own address, changes the link-layer destination address to the 2405 address of its Server, and forwards the message to the Server. At 2406 the same time, the old Client sends a Predirect message back to the 2407 new Client and queues any arriving data packets addressed to the 2408 departed MN. When the new Client receives the Predirect, it creates 2409 a neighbor cache entry for the old Client with AcceptTime set to 2410 ACCEPT_TIME, then sends a Redirect message back to the old Client. 2411 When the old Client receives the Redirect message, it creates a 2412 neighbor cache entry for the new Client with ForwardTime set to 2413 FORWARD_TIME, then forwards any queued data packets to the new 2414 Client. Finally, the old Client sends unsolicited NA messages to 2415 correspondents the same as for the predictive case. 2417 When a Server processes a DHCPv6 Solicit/Request message, it creates 2418 a neighbor cache entry for this ACP if none currently exists. If a 2419 neighbor cache entry already exists, however, the Server changes the 2420 link-layer address to the address of the new proxy Client (this 2421 satisfies the case of both the old Client and new Client using the 2422 same Server). 2424 When a Server processes a DHCPv6 Release message, it resets the 2425 neighbor cache entry lifetime for this ACP to 5 seconds if the cached 2426 link-layer address matches the old proxy Client's address. 2427 Otherwise, the Server ignores the Release message (this satisfies the 2428 case of both the old Client and new Client using the same Server). 2430 When a correspondent Client receives an unsolicited NA message, it 2431 changes the link-layer address for the ACP's neighbor cache entry to 2432 the address of the new proxy Client. The correspondent Client then 2433 issues a Predirect/Redirect exchange to establish a new neighbor 2434 cache entry in the new Client. 2436 From an architectural perspective, in addition to the use of DHCPv6 2437 PD and IPv6 ND signaling the AERO approach differs from PMIPv6 in its 2438 use of the NBMA virtual link model instead of point-to-point tunnels. 2439 This provides a more agile interface for Client/Server and Client/ 2440 Client coordinations, and also facilitates simple route optimization. 2441 The AERO routing system is also arranged in such a fashion that 2442 Clients get the same service from any Server they happen to associate 2443 with. This provides a natural fault tolerance and load balancing 2444 capability such as desired for distributed mobility management. 2446 3.21. Extending AERO Links Through Security Gateways 2448 When an enterprise mobile device moves from a campus LAN connection 2449 to a public Internet link, it must re-enter the enterprise via a 2450 security gateway that has both a physical interface connection to the 2451 Internet and a physical interface connection to the enterprise 2452 internetwork. This most often entails the establishment of a Virtual 2453 Private Network (VPN) link over the public Internet from the mobile 2454 device to the security gateway. During this process, the mobile 2455 device supplies the security gateway with its public Internet address 2456 as the link-layer address for the VPN. The mobile device then acts 2457 as an AERO Client to negotiate with the security gateway to obtain 2458 its ACP. 2460 In order to satisfy this need, the security gateway also operates as 2461 an AERO Server with support for AERO Client proxying. In particular, 2462 when a mobile device (i.e., the Client) connects via the security 2463 gateway (i.e., the Server), the Server provides the Client with an 2464 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2465 enterprise campus access link. The Server then replaces the Client's 2466 link-layer source address with the Server's enterprise-facing link- 2467 layer address in all AERO messages the Client sends toward neighbors 2468 on the AERO link. The AERO messages are then delivered to other 2469 devices on the AERO link as if they were originated by the security 2470 gateway instead of by the AERO Client. In the reverse direction, the 2471 AERO messages sourced by devices within the enterprise network can be 2472 forwarded to the security gateway, which then replaces the link-layer 2473 destination address with the Client's link-layer address and replaces 2474 the link-layer source address with its own (Internet-facing) link- 2475 layer address. 2477 After receiving the ACP, the Client can send IP packets that use an 2478 address taken from the ACP as the network layer source address, the 2479 Client's link-layer address as the link-layer source address, and the 2480 Server's Internet-facing link-layer address as the link-layer 2481 destination address. The Server will then rewrite the link-layer 2482 source address with the Server's own enterprise-facing link-layer 2483 address and rewrite the link-layer destination address with the 2484 target AERO node's link-layer address, and the packets will enter the 2485 enterprise network as though they were sourced from a device located 2486 within the enterprise. In the reverse direction, when a packet 2487 sourced by a node within the enterprise network uses a destination 2488 address from the Client's ACP, the packet will be delivered to the 2489 security gateway which then rewrites the link-layer destination 2490 address to the Client's link-layer address and rewrites the link- 2491 layer source address to the Server's Internet-facing link-layer 2492 address. The Server then delivers the packet across the VPN to the 2493 AERO Client. In this way, the AERO virtual link is essentially 2494 extended *through* the security gateway to the point at which the VPN 2495 link and AERO link are effectively grafted together by the link-layer 2496 address rewriting performed by the security gateway. All AERO 2497 messaging services (including route optimization and mobility 2498 signaling) are therefore extended to the Client. 2500 In order to support this virtual link grafting, the security gateway 2501 (acting as an AERO Server) must keep static neighbor cache entries 2502 for all of its associated Clients located on the public Internet. 2503 The neighbor cache entry is keyed by the AERO Client's AERO address 2504 the same as if the Client were located within the enterprise 2505 internetwork. The neighbor cache is then managed in all ways as 2506 though the Client were an ordinary AERO Client. This includes the 2507 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2508 Unreachability Detection. 2510 Note that the main difference between a security gateway acting as an 2511 AERO Server and an enterprise-internal AERO Server is that the 2512 security gateway has at least one enterprise-internal physical 2513 interface and at least one public Internet physical interface. 2514 Conversely, the enterprise-internal AERO Server has only enterprise- 2515 internal physical interfaces. For this reason security gateway 2516 proxying is needed to ensure that the public Internet link-layer 2517 addressing space is kept separate from the enterprise-internal link- 2518 layer addressing space. This is afforded through a natural extension 2519 of the security association caching already performed for each VPN 2520 client by the security gateway. 2522 3.22. Extending IPv6 AERO Links to the Internet 2524 When an IPv6 host ('H1') with an address from an ACP owned by AERO 2525 Client ('C1') sends packets to a correspondent IPv6 host ('H2'), the 2526 packets eventually arrive at the IPv6 router that owns ('H2')s 2527 prefix. This IPv6 router may or may not be an AERO Client ('C2') 2528 either within the same home network as ('C1') or in a different home 2529 network. 2531 If Client ('C1') is currently located outside the boundaries of its 2532 home network, it will connect back into the home network via a 2533 security gateway acting as an AERO Server. The packets sent by 2534 ('H1') via ('C1') will then be forwarded through the security gateway 2535 then through the home network and finally to ('C2') where they will 2536 be delivered to ('H2'). This could lead to sub-optimal performance 2537 when ('C2') could instead be reached via a more direct route without 2538 involving the security gateway. 2540 Consider the case when host ('H1') has the IPv6 address 2541 2001:db8:1::1, and Client ('C1') has the ACP 2001:db8:1::/64 with 2542 underlying IPv6 Internet address of 2001:db8:1000::1. Also, host 2543 ('H2') has the IPv6 address 2001:db8:2::1, and Client ('C2') has the 2544 ACP 2001:db8:2::/64 with underlying IPv6 address of 2001:db8:2000::1. 2545 Client ('C1') can determine whether 'C2' is indeed also an AERO 2546 Client willing to serve as a route optimization correspondent by 2547 resolving the AAAA records for the DNS FQDN that matches ('H2')s 2548 prefix, i.e.: 2550 '0.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.aero.linkupnetworks.net' 2552 If ('C2') is indeed a candidate correspondent, the FQDN lookup will 2553 return a PTR resource record that contains the domain name for the 2554 AERO link that manages ('C2')s ASP. Client ('C1') can then attempt 2555 route optimization using an approach similar to the Return 2556 Routability procedure specified for Mobile IPv6 (MIPv6) [RFC6275]. 2557 In order to support this process, both Clients MUST intercept and 2558 decapsulate packets that have a subnet router anycast address 2559 corresponding to any of the /64 prefixes covered by their respective 2560 ACPs. 2562 To initiate the process, Client ('C1') creates a specially-crafted 2563 encapsulated AERO Predirect message that will be routed through its 2564 home network then through ('C2')s home network and finally to ('C2') 2565 itself. Client ('C1') prepares the initial message in the exchange 2566 as follows: 2568 o The encapsulating IPv6 header source address is set to 2569 2001:db8:1:: (i.e., the IPv6 subnet router anycast address for 2570 ('C1')s ACP) 2572 o The encapsulating IPv6 header destination address is set to 2573 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2574 ('C2')s ACP) 2576 o The encapsulating IPv6 header is followed by a UDP header with 2577 source and destination port set to 8060 2579 o The encapsulated IPv6 header source address is set to 2580 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2582 o The encapsulated IPv6 header destination address is set to 2583 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2585 o The encapsulated AERO Predirect message includes all of the 2586 securing information that would occur in a MIPv6 "Home Test Init" 2587 message (format TBD) 2589 Client ('C1') then further encapsulates the message in the 2590 encapsulating headers necessary to convey the packet to the security 2591 gateway (e.g., through IPsec encapsulation) so that the message now 2592 appears "double-encapsulated". ('C1') then sends the message to the 2593 security gateway, which re-encapsulates and forwards it over the home 2594 network from where it will eventually reach ('C2'). 2596 At the same time, ('C1') creates and sends a second encapsulated AERO 2597 Predirect message that will be routed through the IPv6 Internet 2598 without involving the security gateway. Client ('C1') prepares the 2599 message as follows: 2601 o The encapsulating IPv6 header source address is set to 2602 2001:db8:1000:1 (i.e., the Internet IPv6 address of ('C1')) 2604 o The encapsulating IPv6 header destination address is set to 2605 2001:db8:2:: (i.e., the IPv6 subnet router anycast address for 2606 ('C2')s ACP) 2608 o The encapsulating IPv6 header is followed by a UDP header with 2609 source and destination port set to 8060 2611 o The encapsulated IPv6 header source address is set to 2612 fe80::2001:db8:1:0 (i.e., the AERO address for ('C1')) 2614 o The encapsulated IPv6 header destination address is set to 2615 fe80::2001:db8:2:0 (i.e., the AERO address for ('C2')) 2617 o The encapsulated AERO Predirect message includes all of the 2618 securing information that would occur in a MIPv6 "Care-of Test 2619 Init" message (format TBD) 2621 ('C2') will receive both Predirect messages through its home network 2622 then return a corresponding Redirect for each of the Predirect 2623 messages with the source and destination addresses in the inner and 2624 outer headers reversed. The first message includes all of the 2625 securing information that would occur in a MIPv6 "Home Test" message, 2626 while the second message includes all of the securing information 2627 that would occur in a MIPv6 "Care-of Test" message (formats TBD). 2629 When ('C1') receives the Redirect messages, it performs the necessary 2630 security procedures per the MIPv6 specification. It then prepares an 2631 encapsulated NS message that includes the same source and destination 2632 addresses as for the "Care-of Test Init" Predirect message, and 2633 includes all of the securing information that would occur in a MIPv6 2634 "Binding Update" message (format TBD) and sends the message to 2635 ('C2'). 2637 When ('C2') receives the NS message, if the securing information is 2638 correct it creates or updates a neighbor cache entry for ('C1') with 2639 fe80::2001:db8:1:0 as the network-layer address, 2001:db8:1000::1 as 2640 the link-layer address and with AcceptTime set to ACCEPT_TIME. 2641 ('C2') then sends an encapsulated NA message back to ('C1') that 2642 includes the same source and destination addresses as for the "Care- 2643 of Test" Redirect message, and includes all of the securing 2644 information that would occur in a MIPv6 "Binding Acknowledgement" 2645 message (format TBD) and sends the message to ('C1'). 2647 When ('C1') receives the NA message, it creates or updates a neighbor 2648 cache entry for ('C2') with fe80::2001:db8:2:0 as the network-layer 2649 address and 2001:db8:2:: as the link-layer address and with 2650 ForwardTime set to FORWARD_TIME, thus completing the route 2651 optimization in the forward direction. 2653 ('C1') subsequently forwards encapsulated packets with outer source 2654 address 2001:db8:1000::1, with outer destination address 2655 2001:db8:2::, with inner source address taken from the 2001:db8:1::, 2656 and with inner destination address taken from 2001:db8:2:: due to the 2657 fact that it has a securely-established neighbor cache entry with 2658 non-zero ForwardTime. ('C2') subsequently accepts any such 2659 encapsulated packets due to the fact that it has a securely- 2660 established neighbor cache entry with non-zero AcceptTime. 2662 In order to keep neighbor cache entries alive, ('C1') periodically 2663 sends additional NS messages to ('C2') and receives any NA responses. 2664 If ('C1') moves to a different point of attachment after the initial 2665 route optimization, it sends a new secured NS message to ('C2') as 2666 above to update ('C2')s neighbor cache. 2668 If ('C2') has packets to send to ('C1'), it performs a corresponding 2669 route optimization in the opposite direction following the same 2670 procedures described above. In the process, the already-established 2671 unidirectional neighbor cache entries within ('C1') and ('C2') are 2672 updated to include the now-bidirectional information. In particular, 2673 the AcceptTime and ForwardTime variables for both neighbor cache 2674 entries are updated to non-zero values, and the link-layer address 2675 for ('C1')s neighbor cache entry for ('C2') is reset to 2676 2001:db8:2000::1. 2678 Note that two AERO Clients can use full security protocol messaging 2679 instead of Return Routability, e.g., if strong authentication and/or 2680 confidentiality are desired. In that case, security protocol key 2681 exchanges such as specified for MOBIKE [RFC4555] would be used to 2682 establish security associations and neighbor cache entries between 2683 the AERO clients. Thereafter, AERO NS/NA messaging can be used to 2684 maintain neighbor cache entries, test reachability, and to announce 2685 mobility events. If reachability testing fails, e.g., if both 2686 Clients move at roughly the same time, the Clients can tear down the 2687 security association and neighbor cache entries and again allow 2688 packets to flow through their home network. 2690 3.23. Encapsulation Protocol Version Considerations 2692 A source Client may connect only to an IPvX underlying network, while 2693 the target Client connects only to an IPvY underlying network. In 2694 that case, the target and source Clients have no means for reaching 2695 each other directly (since they connect to underlying networks of 2696 different IP protocol versions) and so must ignore any redirection 2697 messages and continue to send packets via the Server. 2699 3.24. Multicast Considerations 2701 When the underlying network does not support multicast, AERO nodes 2702 map IPv6 link-scoped multicast addresses (including 2703 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 2704 Server. 2706 When the underlying network supports multicast, AERO nodes use the 2707 multicast address mapping specification found in [RFC2529] for IPv4 2708 underlying networks and use a direct multicast mapping for IPv6 2709 underlying networks. (In the latter case, "direct multicast mapping" 2710 means that if the IPv6 multicast destination address of the 2711 encapsulated packet is "M", then the IPv6 multicast destination 2712 address of the encapsulating header is also "M".) 2714 3.25. Operation on AERO Links Without DHCPv6 Services 2716 When Servers on the AERO link do not provide DHCPv6 services, 2717 operation can still be accommodated through administrative 2718 configuration of ACPs on AERO Clients. In that case, administrative 2719 configurations of AERO interface neighbor cache entries on both the 2720 Server and Client are also necessary. However, this may interfere 2721 with the ability for Clients to dynamically change to new Servers, 2722 and can expose the AERO link to misconfigurations unless the 2723 administrative configurations are carefully coordinated. 2725 3.26. Operation on Server-less AERO Links 2727 In some AERO link scenarios, there may be no Servers on the link and/ 2728 or no need for Clients to use a Server as an intermediary trust 2729 anchor. In that case, each Client acts as a Server unto itself to 2730 establish neighbor cache entries by performing direct Client-to- 2731 Client IPv6 ND message exchanges, and some other form of trust basis 2732 must be applied so that each Client can verify that the prospective 2733 neighbor is authorized to use its claimed ACP. 2735 When there is no Server on the link, Clients must arrange to receive 2736 ACPs and publish them via a secure alternate prefix delegation 2737 authority through some means outside the scope of this document. 2739 3.27. Manually-Configured AERO Tunnels 2741 In addition to the dynamic neighbor discovery procedures for AERO 2742 link neighbors described above, AERO encapsulation can be applied to 2743 manually-configured tunnels. In that case, the tunnel endpoints use 2744 an administratively-assigned link-local address and exchange NS/NA 2745 messages the same as for dynamically-established tunnels. 2747 3.28. Intradomain Routing 2749 After a tunnel neighbor relationship has been established, neighbors 2750 can use a traditional dynamic routing protocol over the tunnel to 2751 exchange routing information without having to inject the routes into 2752 the AERO routing system. 2754 4. Implementation Status 2756 User-level and kernel-level AERO implementations have been developed 2757 and are undergoing internal testing within Boeing. 2759 5. Next Steps 2761 A new Generic UDP Encapsulation (GUE) format has been specified in 2762 [I-D.herbert-gue-fragmentation] [I-D.ietf-nvo3-gue]. The GUE 2763 encapsulation format will eventually supplant the native AERO UDP 2764 encapsulation format. 2766 Future versions of the spec will explore the subject of DSCP marking 2767 in more detail. 2769 6. IANA Considerations 2771 The IANA has assigned a 4-octet Private Enterprise Number "45282" for 2772 AERO in the "enterprise-numbers" registry. 2774 The IANA has assigned the UDP port number "8060" for an earlier 2775 experimental version of AERO [RFC6706]. This document obsoletes 2776 [RFC6706] and claims the UDP port number "8060" for all future use. 2778 No further IANA actions are required. 2780 7. Security Considerations 2782 AERO link security considerations are the same as for standard IPv6 2783 Neighbor Discovery [RFC4861] except that AERO improves on some 2784 aspects. In particular, AERO uses a trust basis between Clients and 2785 Servers, where the Clients only engage in the AERO mechanism when it 2786 is facilitated by a trust anchor. Unless there is some other means 2787 of authenticating the Client's identity (e.g., link-layer security), 2788 AERO nodes SHOULD also use DHCPv6 securing services (e.g., DHCPv6 2789 authentication, Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6], etc.) for 2790 Client authentication and network admission control. In particular, 2791 Clients SHOULD include authenticating information on each 2792 Solicit/Request/Rebind/Release message they send, but omit 2793 authenticating information on Renew messages. Renew messages are 2794 exempt due to the fact that the Renew must already be checked for 2795 having a correct link-layer address and does not update any link- 2796 layer addresses. Therefore, asking the Server to also authenticate 2797 the Renew message would be unnecessary and could result in excessive 2798 processing overhead. 2800 AERO Redirect, Predirect and unsolicited NA messages SHOULD include a 2801 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2802 can use to verify the message time of origin. AERO Predirect, NS and 2803 RS messages SHOULD include a Nonce option (see Section 5.3 of 2804 [RFC3971]) that recipients echo back in corresponding responses. 2806 AERO links must be protected against link-layer address spoofing 2807 attacks in which an attacker on the link pretends to be a trusted 2808 neighbor. Links that provide link-layer securing mechanisms (e.g., 2809 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2810 enterprise network wired LANs) provide a first line of defense that 2811 is often sufficient. In other instances, additional securing 2812 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 2813 [RFC4301] or TLS [RFC5246] may be necessary. 2815 AERO Clients MUST ensure that their connectivity is not used by 2816 unauthorized nodes on their EUNs to gain access to a protected 2817 network, i.e., AERO Clients that act as routers MUST NOT provide 2818 routing services for unauthorized nodes. (This concern is no 2819 different than for ordinary hosts that receive an IP address 2820 delegation but then "share" the address with unauthorized nodes via a 2821 NAT function.) 2823 On some AERO links, establishment and maintenance of a direct path 2824 between neighbors requires secured coordination such as through the 2825 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 2826 security association. 2828 An AERO Client's link-layer address could be rewritten by a link- 2829 layer switching element on the path from the Client to the Server and 2830 not detected by the DHCPv6 security mechanism. However, such a 2831 condition would only be a matter of concern on unmanaged/unsecured 2832 links where the link-layer switching elements themselves present a 2833 man-in-the-middle attack threat. For this reason, IP security MUST 2834 be used when AERO is employed over unmanaged/unsecured links. 2836 8. Acknowledgements 2838 Discussions both on IETF lists and in private exchanges helped shape 2839 some of the concepts in this work. Individuals who contributed 2840 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, 2841 Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, Adrian 2842 Farrel, Sri Gundavelli, Brian Haberman, Joel Halpern, Tom Herbert, 2843 Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Andy Malis, 2844 Satoru Matsushima, Tomek Mrugalski, Alexandru Petrescu, Behcet 2845 Saikaya, Joe Touch, Bernie Volz, Ryuji Wakikawa and Lloyd Wood. 2846 Members of the IESG also provided valuable input during their review 2847 process that greatly improved the document. Special thanks go to 2848 Stewart Bryant, Joel Halpern and Brian Haberman for their shepherding 2849 guidance. 2851 This work has further been encouraged and supported by Boeing 2852 colleagues including Dave Bernhardt, Cam Brodie, Balaguruna 2853 Chidambaram, Bruce Cornish, Claudiu Danilov, Wen Fang, Anthony 2854 Gregory, Jeff Holland, Ed King, Gen MacLean, Rob Muszkiewicz, Sean 2855 O'Sullivan, Kent Shuey, Brian Skeen, Mike Slane, Brendan Williams, 2856 Julie Wulff, Yueli Yang, and other members of the BR&T and BIT mobile 2857 networking teams. 2859 Earlier works on NBMA tunneling approaches are found in 2860 [RFC2529][RFC5214][RFC5569]. 2862 Many of the constructs presented in this second edition of AERO are 2863 based on the author's earlier works, including: 2865 o The Internet Routing Overlay Network (IRON) 2866 [RFC6179][I-D.templin-ironbis] 2868 o Virtual Enterprise Traversal (VET) 2869 [RFC5558][I-D.templin-intarea-vet] 2871 o The Subnetwork Encapsulation and Adaptation Layer (SEAL) 2872 [RFC5320][I-D.templin-intarea-seal] 2874 o AERO, First Edition [RFC6706] 2876 Note that these works cite numerous earlier efforts that are not also 2877 cited here due to space limitations. The authors of those earlier 2878 works are acknowledged for their insights. 2880 9. References 2882 9.1. Normative References 2884 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2885 DOI 10.17487/RFC0768, August 1980, 2886 . 2888 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2889 DOI 10.17487/RFC0791, September 1981, 2890 . 2892 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2893 RFC 792, DOI 10.17487/RFC0792, September 1981, 2894 . 2896 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2897 DOI 10.17487/RFC2003, October 1996, 2898 . 2900 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2901 Requirement Levels", BCP 14, RFC 2119, 2902 DOI 10.17487/RFC2119, March 1997, 2903 . 2905 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2906 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2907 December 1998, . 2909 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2910 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2911 December 1998, . 2913 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2914 "Definition of the Differentiated Services Field (DS 2915 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2916 DOI 10.17487/RFC2474, December 1998, 2917 . 2919 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2920 C., and M. Carney, "Dynamic Host Configuration Protocol 2921 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2922 2003, . 2924 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2925 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2926 DOI 10.17487/RFC3633, December 2003, 2927 . 2929 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2930 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2931 DOI 10.17487/RFC3971, March 2005, 2932 . 2934 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2935 for IPv6 Hosts and Routers", RFC 4213, 2936 DOI 10.17487/RFC4213, October 2005, 2937 . 2939 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2940 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2941 DOI 10.17487/RFC4861, September 2007, 2942 . 2944 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2945 Address Autoconfiguration", RFC 4862, 2946 DOI 10.17487/RFC4862, September 2007, 2947 . 2949 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2950 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2951 2011, . 2953 9.2. Informative References 2955 [I-D.herbert-gue-fragmentation] 2956 Herbert, T. and F. Templin, "Fragmentation option for 2957 Generic UDP Encapsulation", draft-herbert-gue- 2958 fragmentation-00 (work in progress), March 2015. 2960 [I-D.ietf-dhc-sedhcpv6] 2961 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 2962 DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress), 2963 June 2015. 2965 [I-D.ietf-nvo3-gue] 2966 Herbert, T., Yong, L., and O. Zia, "Generic UDP 2967 Encapsulation", draft-ietf-nvo3-gue-01 (work in progress), 2968 June 2015. 2970 [I-D.templin-intarea-seal] 2971 Templin, F., "The Subnetwork Encapsulation and Adaptation 2972 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 2973 progress), January 2014. 2975 [I-D.templin-intarea-vet] 2976 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 2977 templin-intarea-vet-40 (work in progress), May 2013. 2979 [I-D.templin-ironbis] 2980 Templin, F., "The Interior Routing Overlay Network 2981 (IRON)", draft-templin-ironbis-16 (work in progress), 2982 March 2014. 2984 [I-D.vandevelde-idr-remote-next-hop] 2985 Velde, G., Patel, K., Rao, D., Raszuk, R., and R. Bush, 2986 "BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next- 2987 hop-09 (work in progress), March 2015. 2989 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 2990 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 2991 . 2993 [RFC1035] Mockapetris, P., "Domain names - implementation and 2994 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2995 November 1987, . 2997 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2998 DOI 10.17487/RFC1191, November 1990, 2999 . 3001 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 3002 RFC 1812, DOI 10.17487/RFC1812, June 1995, 3003 . 3005 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 3006 selection, and registration of an Autonomous System (AS)", 3007 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 3008 . 3010 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3011 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 3012 1996, . 3014 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 3015 RFC 2131, DOI 10.17487/RFC2131, March 1997, 3016 . 3018 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 3019 Domains without Explicit Tunnels", RFC 2529, 3020 DOI 10.17487/RFC2529, March 1999, 3021 . 3023 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 3024 RFC 2675, DOI 10.17487/RFC2675, August 1999, 3025 . 3027 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 3028 Malis, "A Framework for IP Based Virtual Private 3029 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 3030 . 3032 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 3033 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 3034 DOI 10.17487/RFC2784, March 2000, 3035 . 3037 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 3038 RFC 2923, DOI 10.17487/RFC2923, September 2000, 3039 . 3041 [RFC2983] Black, D., "Differentiated Services and Tunnels", 3042 RFC 2983, DOI 10.17487/RFC2983, October 2000, 3043 . 3045 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3046 of Explicit Congestion Notification (ECN) to IP", 3047 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3048 . 3050 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 3051 "DNS Extensions to Support IP Version 6", RFC 3596, 3052 DOI 10.17487/RFC3596, October 2003, 3053 . 3055 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 3056 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 3057 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 3058 RFC 3819, DOI 10.17487/RFC3819, July 2004, 3059 . 3061 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 3062 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3063 DOI 10.17487/RFC4271, January 2006, 3064 . 3066 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3067 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3068 2006, . 3070 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3071 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 3072 December 2005, . 3074 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3075 Control Message Protocol (ICMPv6) for the Internet 3076 Protocol Version 6 (IPv6) Specification", RFC 4443, 3077 DOI 10.17487/RFC4443, March 2006, 3078 . 3080 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 3081 Protocol (LDAP): The Protocol", RFC 4511, 3082 DOI 10.17487/RFC4511, June 2006, 3083 . 3085 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 3086 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 3087 . 3089 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 3090 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 3091 . 3093 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3094 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 3095 . 3097 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 3098 Errors at High Data Rates", RFC 4963, 3099 DOI 10.17487/RFC4963, July 2007, 3100 . 3102 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 3103 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 3104 DOI 10.17487/RFC4994, September 2007, 3105 . 3107 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 3108 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 3109 RFC 5213, DOI 10.17487/RFC5213, August 2008, 3110 . 3112 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 3113 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 3114 DOI 10.17487/RFC5214, March 2008, 3115 . 3117 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3118 (TLS) Protocol Version 1.2", RFC 5246, 3119 DOI 10.17487/RFC5246, August 2008, 3120 . 3122 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 3123 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 3124 February 2010, . 3126 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 3127 for the Address Resolution Protocol (ARP)", RFC 5494, 3128 DOI 10.17487/RFC5494, April 2009, 3129 . 3131 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 3132 Route Optimization Requirements for Operational Use in 3133 Aeronautics and Space Exploration Mobile Networks", 3134 RFC 5522, DOI 10.17487/RFC5522, October 2009, 3135 . 3137 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 3138 RFC 5558, DOI 10.17487/RFC5558, February 2010, 3139 . 3141 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 3142 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 3143 January 2010, . 3145 [RFC5720] Templin, F., "Routing and Addressing in Networks with 3146 Global Enterprise Recursion (RANGER)", RFC 5720, 3147 DOI 10.17487/RFC5720, February 2010, 3148 . 3150 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 3151 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 3152 . 3154 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 3155 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 3156 DOI 10.17487/RFC5949, September 2010, 3157 . 3159 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 3160 "Internet Key Exchange Protocol Version 2 (IKEv2)", 3161 RFC 5996, DOI 10.17487/RFC5996, September 2010, 3162 . 3164 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3165 NAT64: Network Address and Protocol Translation from IPv6 3166 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3167 April 2011, . 3169 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 3170 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 3171 . 3173 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 3174 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 3175 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 3176 . 3178 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 3179 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 3180 DOI 10.17487/RFC6221, May 2011, 3181 . 3183 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3184 and A. Bierman, Ed., "Network Configuration Protocol 3185 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3186 . 3188 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 3189 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 3190 2011, . 3192 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 3193 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 3194 DOI 10.17487/RFC6355, August 2011, 3195 . 3197 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 3198 RFC 6422, DOI 10.17487/RFC6422, December 2011, 3199 . 3201 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 3202 for Equal Cost Multipath Routing and Link Aggregation in 3203 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 3204 . 3206 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 3207 RFC 6691, DOI 10.17487/RFC6691, July 2012, 3208 . 3210 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 3211 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 3212 . 3214 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 3215 RFC 6864, DOI 10.17487/RFC6864, February 2013, 3216 . 3218 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3219 UDP Checksums for Tunneled Packets", RFC 6935, 3220 DOI 10.17487/RFC6935, April 2013, 3221 . 3223 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3224 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3225 RFC 6936, DOI 10.17487/RFC6936, April 2013, 3226 . 3228 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 3229 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 3230 May 2013, . 3232 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 3233 with IPv6 Neighbor Discovery", RFC 6980, 3234 DOI 10.17487/RFC6980, August 2013, 3235 . 3237 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 3238 Address Selection Policy Using DHCPv6", RFC 7078, 3239 DOI 10.17487/RFC7078, January 2014, 3240 . 3242 [TUNTAP] Wikipedia, W., "http://en.wikipedia.org/wiki/TUN/TAP", 3243 October 2014. 3245 Author's Address 3247 Fred L. Templin (editor) 3248 Boeing Research & Technology 3249 P.O. Box 3707 3250 Seattle, WA 98124 3251 USA 3253 Email: fltemplin@acm.org