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