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