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