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