idnits 2.17.1 draft-templin-aerolink-35.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 (September 12, 2014) is 3512 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) == Unused Reference: 'RFC0768' is defined on line 2149, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 2188, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2201, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 2244, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 2271, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 2275, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 2279, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 2287, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 2290, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 2306, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 2309, 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-03 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- 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 (~~), 14 warnings (==), 6 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: rfc6706 (if approved) September 12, 2014 5 Intended status: Standards Track 6 Expires: March 16, 2015 8 Transmission of IP Packets over AERO Links 9 draft-templin-aerolink-35.txt 11 Abstract 13 This document specifies the operation of IP over tunnel virtual links 14 using Asymmetric Extended Route Optimization (AERO). Nodes attached 15 to AERO links can exchange packets via trusted intermediate routers 16 that provide forwarding services to reach off-link destinations and 17 redirection services for route optimization. AERO provides an IPv6 18 link-local address format known as the AERO address that supports 19 operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 20 ND to IP forwarding. Admission control and provisioning are 21 supported by the Dynamic Host Configuration Protocol for IPv6 22 (DHCPv6), and node mobility is naturally supported through dynamic 23 neighbor cache updates. Although DHCPv6 and IPv6 ND messaging is 24 used in the control plane, both IPv4 and IPv6 are supported in the 25 data plane. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 16, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 64 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 6 65 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. AERO Interface Characteristics . . . . . . . . . . . . . 9 68 3.4.1. Coordination of Multiple Underlying Interfaces . . . 11 69 3.5. AERO Interface Neighbor Cache Maintenace . . . . . . . . 11 70 3.6. AERO Interface Sending Algorithm . . . . . . . . . . . . 13 71 3.7. AERO Interface Encapsulation, Re-encapsulation and 72 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 15 73 3.8. AERO Interface Data Origin Authentication . . . . . . . . 16 74 3.9. AERO Interface MTU Considerations . . . . . . . . . . . . 17 75 3.10. AERO Interface Error Handling . . . . . . . . . . . . . . 20 76 3.11. AERO Router Discovery, Prefix Delegation and Address 77 Configuration . . . . . . . . . . . . . . . . . . . . . . 24 78 3.11.1. AERO DHCPv6 Service Model . . . . . . . . . . . . . 24 79 3.11.2. AERO Client Behavior . . . . . . . . . . . . . . . . 24 80 3.11.3. AERO Server Behavior . . . . . . . . . . . . . . . . 27 81 3.12. AERO Relay/Server Routing System . . . . . . . . . . . . 29 82 3.13. AERO Redirection . . . . . . . . . . . . . . . . . . . . 29 83 3.13.1. Reference Operational Scenario . . . . . . . . . . . 29 84 3.13.2. Concept of Operations . . . . . . . . . . . . . . . 31 85 3.13.3. Message Format . . . . . . . . . . . . . . . . . . . 31 86 3.13.4. Sending Predirects . . . . . . . . . . . . . . . . . 32 87 3.13.5. Re-encapsulating and Relaying Predirects . . . . . . 33 88 3.13.6. Processing Predirects and Sending Redirects . . . . 34 89 3.13.7. Re-encapsulating and Relaying Redirects . . . . . . 36 90 3.13.8. Processing Redirects . . . . . . . . . . . . . . . . 36 91 3.13.9. Server-Oriented Redirection . . . . . . . . . . . . 37 92 3.14. Neighbor Unreachability Detection (NUD) . . . . . . . . . 37 93 3.15. Mobility Management . . . . . . . . . . . . . . . . . . . 39 94 3.15.1. Announcing Link-Layer Address Changes . . . . . . . 39 95 3.15.2. Bringing New Links Into Service . . . . . . . . . . 40 96 3.15.3. Removing Existing Links from Service . . . . . . . . 40 97 3.15.4. Moving to a New Server . . . . . . . . . . . . . . . 41 98 3.16. Encapsulation Protocol Version Considerations . . . . . . 41 99 3.17. Multicast Considerations . . . . . . . . . . . . . . . . 42 100 3.18. Operation on AERO Links Without DHCPv6 Services . . . . . 42 101 3.19. Operation on Server-less AERO Links . . . . . . . . . . . 42 102 3.20. Extending AERO Links Through Security Gateways . . . . . 42 103 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 44 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 107 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 108 8.1. Normative References . . . . . . . . . . . . . . . . . . 46 109 8.2. Informative References . . . . . . . . . . . . . . . . . 47 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 112 1. Introduction 114 This document specifies the operation of IP over tunnel virtual links 115 using Asymmetric Extended Route Optimization (AERO). The AERO link 116 can be used for tunneling to neighboring nodes over either IPv6 or 117 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 118 equivalent links for tunneling. Nodes attached to AERO links can 119 exchange packets via trusted intermediate routers that provide 120 forwarding services to reach off-link destinations and redirection 121 services for route optimization that addresses the requirements 122 outlined in [RFC5522]. 124 AERO provides an IPv6 link-local address format known as the AERO 125 address that supports operation of the IPv6 Neighbor Discovery (ND) 126 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 127 control and provisioning are supported by the Dynamic Host 128 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and node mobility 129 is naturally supported through dynamic neighbor cache updates. 130 Although DHCPv6 and IPv6 ND message signalling is used in the control 131 plane, both IPv4 and IPv6 can be used in the data plane. The 132 remainder of this document presents the AERO specification. 134 2. Terminology 136 The terminology in the normative references applies; the following 137 terms are defined within the scope of this document: 139 AERO link 140 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 141 configured over a node's attached IPv6 and/or IPv4 networks. All 142 nodes on the AERO link appear as single-hop neighbors from the 143 perspective of the virtual overlay. 145 AERO interface 146 a node's attachment to an AERO link. 148 AERO address 149 an IPv6 link-local address constructed as specified in Section 3.2 150 and applied to a Client's AERO interface. 152 AERO node 153 a node that is connected to an AERO link and that participates in 154 IPv6 ND and DHCPv6 messaging over the link. 156 AERO Client ("Client") 157 a node that applies an AERO address to an AERO interface and 158 receives an IP prefix via a DHCPv6 Prefix Delegation (PD) exchange 159 with one or more AERO Servers. 161 AERO Server ("Server") 162 a node that configures an AERO interface to provide default 163 forwarding and DHCPv6 services for AERO Clients. The Server 164 applies the IPv6 link-local subnet router anycast address (fe80::) 165 to the AERO interface and also applies an administratively 166 assigned IPv6 link-local unicast address used for operation of 167 DHCPv6 and the IPv6 ND protocol. 169 AERO Relay ("Relay") 170 a node that configures an AERO interface to relay IP packets 171 between nodes on the same AERO link and/or forward IP packets 172 between the AERO link and the native Internetwork. The Relay 173 applies an administratively assigned IPv6 link-local unicast 174 address to the AERO interface the same as for a Server. 176 ingress tunnel endpoint (ITE) 177 an AERO interface endpoint that injects tunneled packets into an 178 AERO link. 180 egress tunnel endpoint (ETE) 181 an AERO interface endpoint that receives tunneled packets from an 182 AERO link. 184 underlying network 185 a connected IPv6 or IPv4 network routing region over which the 186 tunnel virtual overlay is configured. A typical example is an 187 enterprise network. 189 underlying interface 190 an AERO node's interface point of attachment to an underlying 191 network. 193 link-layer address 194 an IP address assigned to an AERO node's underlying interface. 195 When UDP encapsulation is used, the UDP port number is also 196 considered as part of the link-layer address. Link-layer 197 addresses are used as the encapsulation header source and 198 destination addresses. 200 network layer address 201 the source or destination address of the encapsulated IP packet. 203 end user network (EUN) 204 an internal virtual or external edge IP network that an AERO 205 Client connects to the rest of the network via the AERO interface. 207 AERO Service Prefix (ASP) 208 an IP prefix associated with the AERO link and from which AERO 209 Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 210 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 212 AERO Client Prefix (ACP) 213 a more-specific IP prefix taken from an ASP and delegated to a 214 Client. 216 Throughout the document, the simple terms "Client", "Server" and 217 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 218 respectively. Capitalization is used to distinguish these terms from 219 DHCPv6 client/server/relay. 221 Throughout the document, it is said that an address is "applied" to 222 an AERO interface since the address need not always be "assigned" to 223 the interface in the traditional sense. However, the address must at 224 least be bound to the interface in some fashion to support the 225 operation of DHCPv6 and the IPv6 ND protocol. 227 The terminology of [RFC4861] (including the names of node variables 228 and protocol constants) applies to this document. Also throughout 229 the document, the term "IP" is used to generically refer to either 230 Internet Protocol version (i.e., IPv4 or IPv6). 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in [RFC2119]. 236 3. Asymmetric Extended Route Optimization (AERO) 238 The following sections specify the operation of IP over Asymmetric 239 Extended Route Optimization (AERO) links: 241 3.1. AERO Link Reference Model 243 .-(::::::::) 244 .-(:::: IP ::::)-. 245 (:: Internetwork ::) 246 `-(::::::::::::)-' 247 `-(::::::)-' 248 | 249 +--------------+ +-------+------+ +--------------+ 250 |AERO Server S1| | AERO Relay R | |AERO Server S2| 251 | (default->R) | |(C->S1; D->S2)| | (default->R) | 252 | Nbr: A | +-------+------+ | Nbr: B | 253 +-------+------+ | +------+-------+ 254 | | | 255 X---+---+-------------------+------------------+---+---X 256 | AERO Link | 257 +-----+--------+ +--------+-----+ 258 |AERO Client A | |AERO Client B | 259 | default->S1 | | default->S2 | 260 +--------------+ +--------------+ 261 .-. .-. 262 ,-( _)-. ,-( _)-. 263 .-(_ IP )-. .-(_ IP )-. 264 (__ EUN ) (__ EUN ) 265 `-(______)-' `-(______)-' 266 | | 267 +--------+ +--------+ 268 | Host C | | Host D | 269 +--------+ +--------+ 271 Figure 1: AERO Link Reference Model 273 Figure 1 above presents the AERO link reference model. In this 274 model: 276 o Relay R act as a default router for its associated Servers S1 and 277 S2, and connects the AERO link to the rest of the IP Internetwork 279 o Servers S1 and S2 associate with Relay R and also act as default 280 routers for their associated Clients A and B. 282 o Clients A and B associate with Servers S1 and S2, respectively and 283 also act as default routers for their associated EUNs 285 o Hosts C and D attach to the EUNs served by Clients A and B, 286 respectively 288 In common operational practice, there may be many additional Relays, 289 Servers and Clients. 291 3.2. AERO Node Types 293 AERO Relays provide default forwarding services to AERO Servers. 294 Relays forward packets between Servers connected to the same AERO 295 link and also forward packets between the AERO link and the native 296 Internetwork. Relays present the AERO link to the native 297 Internetwork as a set of one or more ASPs. Each Relay advertises the 298 ASPs for the AERO link into the native IP Internetwork and serves as 299 a gateway between the AERO link and the Internetwork. AERO Relays 300 maintain an AERO interface neighbor cache entry for each AERO Server, 301 and maintain an IP forwarding table entry for each AERO Client. 303 AERO Servers provide default forwarding services to AERO Clients. 304 Each Server also peers with each Relay in a dynamic routing protocol 305 instance to advertise its list of associated Clients. Servers 306 configure a DHCPv6 server function to facilitate Prefix Delegation 307 (PD) exchanges with Clients. Each delegated prefix becomes an AERO 308 Client Prefix (ACP) taken from an ASP. Servers forward packets 309 between Clients and Relays, as well as between Clients and other 310 Clients associated with the same Server. AERO Servers maintain an 311 AERO interface neighbor cache entry for each AERO Relay. They also 312 maintain both a neighbor cache entry and an IP forwarding table entry 313 for each of their associated Clients. 315 AERO Clients act as requesting routers to receive ACPs through DHCPv6 316 PD exchanges with AERO Servers over the AERO link. (Each Client MAY 317 associate with a single Server or with multiple Servers, e.g., for 318 fault tolerance and/or load balancing.) Each IPv6 Client receives at 319 least a /64 IPv6 ACP, and may receive even shorter prefixes. 320 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 321 singleton IPv4 address), and may receive even shorter prefixes. AERO 322 Clients maintain an AERO interface neighbor cache entry for each of 323 their associated Servers as well as for each of their correspondent 324 Clients. 326 AERO Clients that act as routers sub-delegate portions of their ACPs 327 to links on EUNs. End system applications on Clients that act as 328 routers bind to EUN interfaces (i.e., and not the AERO interface). 330 AERO Clients that act as ordinary hosts assign one or more IP 331 addresses from their ACPs to the AERO interface but DO NOT assign the 332 ACP itself to the AERO interface. Instead, the Client assigns the 333 ACP to a "black hole" route so that unused portions of the prefix are 334 nullified. End system applications on Clients that act as hosts bind 335 directly to the AERO interface. 337 3.3. AERO Addresses 339 An AERO address is an IPv6 link-local address with an embedded ACP 340 and applied to a Client's AERO interface. The AERO address is formed 341 as follows: 343 fe80::[ACP] 345 For IPv6, the AERO address begins with the prefix fe80::/64 and 346 includes in its interface identifier the base prefix taken from the 347 Client's IPv6 ACP. The base prefix is determined by masking the ACP 348 with the prefix length. For example, if the AERO Client receives the 349 IPv6 ACP: 351 2001:db8:1000:2000::/56 353 it constructs its AERO address as: 355 fe80::2001:db8:1000:2000 357 For IPv4, the AERO address is formed from the lower 64 bits of an 358 IPv4-mapped IPv6 address [RFC4291] that includes the base prefix 359 taken from the Client's IPv4 ACP. For example, if the AERO Client 360 receives the IPv4 ACP: 362 192.0.2.32/28 364 it constructs its AERO address as: 366 fe80::FFFF:192.0.2.32 368 The AERO address remains stable as the Client moves between 369 topological locations, i.e., even if its link-layer addresses change. 371 NOTE: In some cases, prospective neighbors may not have a priori 372 knowledge of the Client's ACP length and may therefore send initial 373 IPv6 ND messages with an AERO destination address that matches the 374 ACP but does not correspond to the base prefix. In that case, the 375 Client MUST accept the address as equivalent to the base address, but 376 then use the base address as the source address of any IPv6 ND 377 message replies. For example, if the Client receives the IPv6 ACP 378 2001:db8:1000:2000::/56 then subsequently receives an IPv6 ND message 379 with destination address fe80::2001:db8:1000:2001, it accepts the 380 message but uses fe80::2001:db8:1000:2000 as the source address of 381 any IPv6 ND replies. 383 3.4. AERO Interface Characteristics 385 AERO interfaces use IP-in-IPv6 encapsulation [RFC2473] to exchange 386 tunneled packets with AERO neighbors attached to an underlying IPv6 387 network, and use IP-in-IPv4 encapsulation [RFC2003][RFC4213] to 388 exchange tunneled packets with AERO neighbors attached to an 389 underlying IPv4 network. AERO interfaces can also coordinate secured 390 tunnel types such as IPsec [RFC4301] or TLS [RFC5246]. When Network 391 Address Translator (NAT) traversal and/or filtering middlebox 392 traversal may be necessary, a UDP header is further inserted 393 immediately above the IP encapsulation header. 395 AERO interfaces maintain a neighbor cache, and AERO Clients and 396 Servers use an adaptation of standard unicast IPv6 ND messaging. 397 AERO interfaces use unicast Neighbor Solicitation (NS), Neighbor 398 Advertisement (NA), Router Solicitation (RS) and Router Advertisement 399 (RA) messages the same as for any IPv6 link. AERO interfaces use two 400 redirection message types -- the first known as a Predirect message 401 and the second being the standard Redirect message (see Section 3.9). 402 AERO links further use link-local-only addressing; hence, AERO nodes 403 ignore any Prefix Information Options (PIOs) they may receive in RA 404 messages. 406 AERO interface ND messages include one or more Target Link-Layer 407 Address Options (TLLAOs) formatted as shown in Figure 2: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type = 2 | Length = 3 | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Link ID | Preference | UDP Port Number (or 0) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 +-- --+ 418 | | 419 +-- IP Address --+ 420 | | 421 +-- --+ 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Figure 2: AERO Target Link-Layer Address Option (TLLAO) Format 427 In this format, Link ID is an integer value between 0 and 255 428 corresponding to an underlying interface of the target node, and 429 Preference is an integer value between 0 and 255 indicating the 430 node's preference for this underlying interface (with 255 being the 431 highest preference, 1 being the lowest, and 0 meaning "link 432 disabled"). UDP Port Number and IP Address are set to the addresses 433 used by the target node when it sends encapsulated packets over the 434 underlying interface. When no UDP encapsulation is used, UDP Port 435 Number is set to 0. When the encapsulation IP address family is 436 IPv4, IP Address is formed as an IPv4-mapped IPv6 address [RFC4291]. 438 When a Relay enables an AERO interface, it applies an 439 administratively assigned link-local address fe80::ID to the 440 interface for communicating with Servers on the link. Each fe80::ID 441 address MUST be unique among all Relays and Servers on the link, and 442 MUST NOT collide with any potential AERO addresses, e.g., the 443 addresses could be assigned as fe80::1, fe80::2, fe80::3, etc. The 444 Relay also maintains an IP forwarding table entry for each Client- 445 Server association and maintains a neighbor cache entry for each 446 Server on the link. Relays do not require the use of IPv6 ND 447 messaging for reachability determination since Relays and Servers 448 engage in a dynamic routing protocol over the AERO interface. At a 449 minimum, however, Relays respond to NS messages by returning an NA. 451 When a Server enables an AERO interface, it applies the address 452 fe80:: to the interface as a link-local Subnet Router Anycast 453 address, and also applies an administratively assigned link-local 454 address fe80::ID to support the operation of DHCPv6 and the IPv6 ND 455 protocol as well as to communicate with Relays on the link. (The 456 Server then accepts IPv6 ND solicitation messages destined to either 457 the fe80:: or fe80::ID addresses, but always uses fe80::ID as the 458 source address of the corresponding advertisements.) The Server 459 further configures a DHCPv6 server function to facilitate DHCPv6 PD 460 exchanges with AERO Clients. The Server also maintains a neighbor 461 cache entry for each Relay on the link, and manages per-Client 462 neighbor cache entries and IP forwarding table entries based on 463 DHCPv6 exchanges. When the Server receives an NS/RS message on the 464 AERO interface it returns an NA/RA message but does not update the 465 neighbor cache. Servers also engage in a dynamic routing protocol 466 with all Relays on the link. Finally, the Server provides a simple 467 conduit between Clients and Relays, or between Clients and other 468 Clients. Therefore, packets enter the Server's AERO interface from 469 the link layer and are forwarded back out the link layer without ever 470 leaving the AERO interface and therefore without ever disturbing the 471 network layer. 473 When a Client enables an AERO interface, it invokes DHCPv6 PD to 474 receive an ACP from an AERO Server. Next, it applies the 475 corresponding AERO address to the AERO interface and creates a 476 neighbor cache entry for the Server, i.e., the PD exchange bootstraps 477 the provisioning of a unique link-local address. The Client 478 maintains a neighbor cache entry for each of its Servers and each of 479 its active correspondent Clients. When the Client receives Redirect/ 480 Predirect messages on the AERO interface it updates or creates 481 neighbor cache entries, including link-layer address information. 482 Unsolicited NA messages update the cached link-layer addresses for 483 correspondent Clients (e.g., following a link-layer address change 484 due to node mobility) but do not create new neighbor cache entries. 485 NS/NA messages used for Neighbor Unreachability Detection (NUD) 486 update timers in existing neighbor cache entires but do not update 487 link-layer addresses nor create new neighbor cache entries. Finally, 488 the Client need not maintain any IP forwarding table entries for its 489 Servers or correspondent Clients. Instead, it can set a single 490 "route-to-interface" default route in the IP forwarding table 491 pointing to the AERO interface, and all forwarding decisions can be 492 made within the AERO interface based on neighbor cache entries. On 493 systems in which adding a deafult route would violate security 494 policy, the default route could instead be installed via a 495 "synthesized RA" as discussed in Secction 3.11.2. 497 3.4.1. Coordination of Multiple Underlying Interfaces 499 AERO interfaces may be configured over multiple underlying 500 interfaces. For example, common mobile handheld devices have both 501 wireless local area network ("WLAN") and cellular wireless links. 502 These links are typically used "one at a time" with low-cost WLAN 503 preferred and highly-available cellular wireless as a standby. In a 504 more complex example, aircraft frequently have many wireless data 505 link types (e.g. satellite-based, terrestrial, air-to-air 506 directional, etc.) with diverse performance and cost properties. 508 If a Client's multiple underlying interfaces are used "one at a time" 509 (i.e., all other interfaces are in standby mode while one interface 510 is active), then Redirect, Predirect and unsolicited NA messages 511 include only a single TLLAO with Link ID set to a constant value. 513 If the Client has multiple active underlying interfaces, then from 514 the perspective of IPv6 ND it would appear to have a single link- 515 local address with multiple link-layer addresses. In that case, 516 Redirect, Predirect and unsolicited NA messages MAY include multiple 517 TLLAOs -- each with a different Link ID that corresponds to a 518 specific underlying interface of the Client. 520 3.5. AERO Interface Neighbor Cache Maintenace 522 Each AERO interface maintains a conceptual neighbor cache that 523 includes an entry for each neighbor it communicates with on the AERO 524 link, the same as for any IPv6 interface [RFC4861]. AERO interface 525 neighbor cache entires are said to be one of "permanent", "static" or 526 "dynamic". 528 Permanent neighbor cache entries are created through explicit 529 administrative action; they have no timeout values and remain in 530 place until explicitly deleted. AERO Relays maintain a permanent 531 neighbor cache entry for each Server on the link, and AERO Servers 532 maintain a permanent neighbor cache entry for each Relay on the link. 534 Static neighbor cache entries are created though DHCPv6 PD exchanges 535 and remain in place for durations bounded by prefix lifetimes. AERO 536 Servers maintain a static neighbor cache entry for each of their 537 associated Clients, and AERO Clients maintain a static neighbor cache 538 for each of their associated Servers. When an AERO Server sends a 539 DHCPv6 Reply message response to a Client's DHCPv6 Solicit or Renew 540 message, it creates or updates a static neighbor cache entry based on 541 the Client's AERO address as the network-layer address, the prefix 542 lifetime as the neighbor cache entry lifetime, the Client's 543 encapsulation IP address and UDP port number as the link-layer 544 address and the prefix length as the length to apply to the AERO 545 address. When an AERO Client receives a DHCPv6 Reply message from a 546 Server, it creates or updates a static neighbor cache entry based on 547 the Reply message link-local source address as the network-layer 548 address, the prefix lifetime as the neighbor cache entry lifetime, 549 and the encapsulation IP source address and UDP source port number as 550 the link-layer address. 552 Dynamic neighbor cache entries are created based on receipt of an 553 IPv6 ND message, and are garbage-collected if not used within a short 554 timescale. AERO Clients maintain dynamic neighbor cache entries for 555 each of their active correspondent Clients with lifetimes based on 556 IPv6 ND messaging constants. When an AERO Client receives a valid 557 Predirect message it creates or updates a dynamic neighbor cache 558 entry for the Predirect target network-layer and link-layer addresses 559 plus prefix length. The node then sets an "AcceptTime" variable in 560 the neighbor cache entry and uses this value to determine whether 561 packets received from the correspondent can be accepted. When an 562 AERO Client receives a valid Redirect message it creates or updates a 563 dynamic neighbor cache entry for the Redirect target network-layer 564 and link-layer addresses plus prefix length. The Client then sets a 565 "ForwardTime" variable in the neighbor cache entry and uses this 566 value to determine whether packets can be sent directly to the 567 correspondent. The Client also maintains a "MaxRetry" variable to 568 limit the number of keepalives sent when a correspondent may have 569 gone unreachable. 571 For dynamic neighbor cache entries, when an AERO Client receives a 572 valid NS message it (re)sets AcceptTime for the neighbor to 573 ACCEPT_TIME. When an AERO Client receives a valid solicited NA 574 message, it (re)sets ForwardTime for the neighbor to FORWARD_TIME and 575 sets MaxRetry to MAX_RETRY. When an AERO Client receives a valid 576 unsolicited NA message, it updates the correspondent's link-layer 577 addresses but DOES NOT reset AcceptTime, ForwardTime or MaxRetry. 579 It is RECOMMENDED that FORWARD_TIME be set to the default constant 580 value 30 seconds to match the default REACHABLE_TIME value specified 581 for IPv6 ND [RFC4861]. 583 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 584 value 40 seconds to allow a 10 second window so that the AERO 585 redirection procedure can converge before AcceptTime decrements below 586 FORWARD_TIME. 588 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 589 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 591 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 592 administratively set, if necessary, to better match the AERO link's 593 performance characteristics; however, if different values are chosen, 594 all nodes on the link MUST consistently configure the same values. 595 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 596 sufficiently longer than FORWARD_TIME to allow the AERO redirection 597 procedure to converge. 599 3.6. AERO Interface Sending Algorithm 601 IP packets enter a node's AERO interface either from the network 602 layer (i.e., from a local application or the IP forwarding system), 603 or from the link-layer (i.e., from the AERO tunnel virtual link). 604 Packets that enter the AERO interface from the network layer are 605 encapsulated and admitted into the AERO link (i.e., they are 606 tunnelled to an AERO interface neighbor). Packets that enter the 607 AERO interface from the link layer are either re-admitted into the 608 AERO link or delivered to the network layer where they are subject to 609 either local delivery or IP forwarding. Since each AERO node has 610 only partial information about neighbors on the link, AERO interfaces 611 may forward packets with link-local destination addresses at a layer 612 below the network layer. This means that AERO nodes act as both IP 613 routers and link-layer "bridges". AERO interface sending 614 considerations for Clients, Servers and Relays are given below. 616 When an IP packet enters a Client's AERO interface from the network 617 layer, if the destination is covered by an ASP the Client searches 618 for a dynamic neighbor cache entry with a non-zero ForwardTime and an 619 AERO address that matches the packet's destination address. (The 620 destination address may be either an address covered by the 621 neighbor's ACP or the (link-local) AERO address itself.) If there is 622 a match, the Client uses a link-layer address in the entry as the 623 link-layer address for encapsulation then admits the packet into the 624 AERO link. If there is no match, the Client instead uses the link- 625 layer address of a neighboring Server as the link-layer address for 626 encapsulation. 628 When an IP packet enters a Server's AERO interface from the link 629 layer, if the destination is covered by an ASP the Server searches 630 for a static neighbor cache entry with an AERO address that matches 631 the packet's destination address. (The destination address may be 632 either an address covered by the neighbor's ACP or the AERO address 633 itself.) If there is a match, the Server uses a link-layer address 634 in the entry as the link-layer address for encapsulation and re- 635 admits the packet into the AERO link. If there is no match, the 636 Server instead uses the link-layer address in any permanent neighbor 637 cache entry as the link-layer address for encapsulation. When a 638 Server receives a packet from a Relay, the Server MUST NOT loop the 639 packet back to the same or a different Relay. 641 When an IP packet enters a Relay's AERO interface from the network 642 layer, the Relay searches its IP forwarding table for an entry that 643 is covered by an ASP and also matches the destination. If there is a 644 match, the Relay uses the link-layer address in the neighbor cache 645 entry for the next-hop Server as the link-layer address for 646 encapsulation and admits the packet into the AERO link. When an IP 647 packet enters a Relay's AERO interface from the link-layer, if the 648 destination is not a link-local address and is not covered by an ASP 649 the Relay removes the packet from the AERO interface and uses IP 650 forwarding to forward the packet to the Internetwork. If the 651 destination address is covered by an ASP, and there is a more- 652 specific IP forwarding table entry that matches the destination, the 653 Relay uses the link-layer address in the neighbor cache entry for the 654 next-hop Server as the link-layer address for encapsulation and re- 655 admits the packet into the AERO link. If there is no more-specific 656 entry, the Relay instead drops the packet and returns an ICMP 657 Destination Unreachable message (see: Section 3.10). When an Relay 658 receives a packet from a Server, the Relay MUST NOT forward the 659 packet back to the same Server. 661 Note that in the above that the link-layer address for encapsulation 662 may be through consulting either the neighbor cache or the IP 663 forwarding table. IP forwarding is therefore linked to IPv6 ND via 664 the AERO address. 666 When an AERO node re-admits a packet into the AERO link, the node 667 MUST NOT decrement the network layer TTL/Hop-count. 669 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 671 AERO interfaces encapsulate IP packets according to whether they are 672 entering the AERO interface from the network layer or if they are 673 being re-admitted into the same AERO link they arrived on. This 674 latter form of encapsulation is known as "re-encapsulation". 676 AERO interfaces encapsulate packets per the specifications in 677 [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246] (etc.) except that the 678 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 679 and "Congestion Experienced" values in the packet's IP header into 680 the corresponding fields in the encapsulation header. For packets 681 undergoing re-encapsulation, the AERO interface instead copies the 682 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 683 Experienced" values in the original encapsulation header into the 684 corresponding fields in the new encapsulation header (i.e., the 685 values are transferred between encapsulation headers and *not* copied 686 from the encapsulated packet's network-layer header). 688 When AERO UDP encapsulation is used, the AERO interface encapsulates 689 the packet per the above tunneling specifications except that it 690 inserts a UDP header between the encapsulation header and the 691 packet's IP header. The AERO interface sets the UDP source port to a 692 constant value that it will use in each successive packet it sends 693 and sets the UDP length field to the length of the IP packet plus 8 694 bytes for the UDP header itself. For packets sent via a Server, the 695 AERO interface sets the UDP destination port to 8060 (i.e., the IANA- 696 registered port number for AERO) when AERO-only encapsulation is 697 used. For packets sent to a correspondent Client, the AERO interface 698 sets the UDP destination port to the port value stored in the 699 neighbor cache entry for this correspondent. 701 The AERO interface also sets the UDP checksum field to zero (see: 702 [RFC6935][RFC6936]) for packets that do not require assurance against 703 reassembly errors. For packets that require reassembly checks (see 704 Section 3.9), the AERO interface instead (re)calculates the UDP 705 checksum and writes the resulting value in the UDP checksum field. 707 The AERO interface next sets the IP protocol number in the 708 encapsulation header to the appropriate value for the first protocol 709 layer within the encapsulation (e.g., IPv4, IPv6, UDP, IPsec, etc.). 710 When IPv6 is used as the encapsulation protocol, the interface then 711 sets the flow label value in the encapsulation header the same as 712 described in [RFC6438]. When IPv4 is used as the encapsulation 713 protocol, the AERO interface sets the DF bit as discussed in 714 Section 3.8. 716 AERO interfaces decapsulate packets destined either to the node 717 itself or to a destination reached via an interface other than the 718 AERO interface the packet was received on. When AERO UDP 719 encapsulation is used (i.e., when a UDP header with destination port 720 8060 is present) the interface first verifies the UDP checksum in the 721 UDP checksum was non-zero then examines the first octet of the 722 encapsulated packet. The packet is accepted if the most significant 723 four bits of the first octet encode the value '0110' (i.e., the 724 version number value for IPv6) or the value '0100' (i.e., the version 725 number value for IPv4). Otherwise, the packet is accepted if the 726 first octet encodes a valid IP protocol number per the IANA 727 "protocol-numbers" registry that matches a supported encapsulation 728 type. Otherwise, the packet is discarded. 730 Further decapsulation then proceeds according to the appropriate 731 tunnel type per the above specifications. 733 3.8. AERO Interface Data Origin Authentication 735 AERO nodes employ simple data origin authentication procedures for 736 encapsulated packets they receive from other nodes on the AERO link. 737 In particular: 739 o AERO Relays and Servers accept encapsulated packets with a link- 740 layer source address that matches a permanent neighbor cache 741 entry. 743 o AERO Servers accept authentic encapsulated DHCPv6 messages, and 744 create or update a static neighbor cache entry for the source 745 based on the specific message type. 747 o AERO Servers accept encapsulated packets if there is a static 748 neighbor cache entry with an AERO address that matches the 749 packet's network-layer source address and with a link-layer 750 address that matches the packet's link-layer source address. 752 o AERO Clients accept encapsulated packets if there is a static 753 neighbor cache entry with a link-layer source address that matches 754 the packet's link-layer source address. 756 o AERO Clients and Servers accept encapsulated packets if there is a 757 dynamic neighbor cache entry with an AERO address that matches the 758 packet's network-layer source address, with a link-layer address 759 that matches the packet's link-layer source address, and with a 760 non-zero AcceptTime. 762 Note that this simple data origin authentication only applies to 763 environments in which link-layer addresses cannot be spoofed. 765 Additional security mitigations may be necessary in other 766 environments. 768 3.9. AERO Interface MTU Considerations 770 The AERO interface is the node's point of attachment to the AERO 771 link. AERO links over IP networks have a maximum link MTU of 64KB 772 minus the encapsulation overhead (i.e., "64KB-ENCAPS"), since the 773 maximum packet size in the base IP specifications is 64KB 774 [RFC0791][RFC2460]. AERO links over IPv6 networks have a theoretical 775 maximum link MTU of 4GB-ENCAPS [RFC2675], however IPv6 Jumbograms are 776 considered optional for IPv6 nodes [RFC6434] and therefore out of 777 scope for this document. 779 The IP layer sees the AERO interface as an ordinary interface that 780 configures an MTU that is no larger than the link MTU, i.e., the same 781 as for any interface. Routers MAY set an AERO interface MTU up to 782 the maximum link MTU for the specific IP protocol version. Hosts 783 SHOULD set a more conservative AERO interface MTU so that upper layer 784 protocols will see an appropriate maximum packet size, for example 785 when setting an initial TCP Maximum Segment Size (MSS). In all 786 cases, routers and hosts MUST set an MTU of at least 1500 bytes. 788 IPv6 specifies a minimum link MTU of 1280 bytes [RFC2460]. This is 789 the minimum packet size an AERO interface MUST be capable of 790 forwarding without returning an ICMP Packet Too Big (PTB) message. 791 Although IPv4 specifies a smaller minimum link MTU of 68 bytes 792 [RFC0791], AERO interfaces also observe a 1280 byte minimum for IPv4. 793 Additionally, the vast majority of links in the Internet configure an 794 MTU of at least 1500 bytes. Hosts have therefore become conditioned 795 to expect that IP packets up to 1500 bytes in length will either be 796 delivered to the final destination or a suitable ICMP Packet Too Big 797 (PTB) message returned, however such PTB messages are often lost 798 [RFC2923]. Therefore, AERO interfaces MUST pass IP packets of at 799 least 1500 bytes even if the encapsulated packet must be fragmented. 801 PTB messages may be generated by the IP layer of the AERO node if the 802 packet is too large to enter the AERO interface, from within the AERO 803 interface itself if the packet is larger than 1500 bytes and also 804 larger than the MTU of the underlying interface to be used for 805 tunneling minus ENCAPS, or from a router within the tunnel after the 806 encapsulated packet has been admitted into the tunnel. The latter 807 condition would result in a Layer-2 (L2) PTB message delivered to the 808 AERO interface, while the former two conditions would result in a 809 Layer-3 (L3) PTB message delivered to the original source. 811 For AERO links over IPv4, the IP ID field is only 16 bits in length, 812 meaning that fragmentation at high data rates could result in 813 dangerous reassembly misassociations [RFC6864][RFC4963]. For that 814 reason, AERO interfaces that send fragmented IPv4-encapsulated 815 packets MUST either institute rate limiting to ensure that the IP ID 816 field will not wrap before all earlier fragments have been processed, 817 or include an integrity check to detect reassembly errors. 819 The AERO interface therefore admits packets into the tunnel (using 820 fragmentation as necessary) as follows: 822 o For IP packets that are no larger than (1280-ENCAPS) bytes, the 823 AERO interface admits the packet into the tunnel without 824 fragmentation. For IPv4 AERO links, the AERO interface sets the 825 Don't Fragment (DF) bit to 0 so that these packets will be 826 deterministically delivered even if there is a restricting link in 827 the path. The AERO interface need not perform rate limiting or 828 include integrity checks for these packets, since any IPv4 links 829 in the path that configure an MTU smaller than 1280 bytes are very 830 likely to be slow links [RFC3819]. 832 o For IP packets that are larger than (1280-ENCAPS) bytes but no 833 larger than 1500 bytes, the AERO interface encapsulates the 834 packet. (For IPv4 AERO links, the AERO interface then sets the DF 835 bit to 0 and calculates the UDP checksum for the encapsulated 836 packet as an integrity check to account for the potential for 837 reassembly misassociations. If the encapsulation does not include 838 a UDP header or other integrity check, the AERO interface instead 839 MUST institute rate limiting.) Next, the AERO interface uses IP 840 fragmentation to fragment the encapsulated packet into two 841 fragments where the first fragment is no larger than 1024 bytes 842 and the other fragment is no larger than the first fragment. The 843 AERO interface then admits both fragments into the tunnel. 845 o For IPv4 packets that are larger than 1500 bytes and with the DF 846 bit set to 0, the AERO interface fragments the unencapsulated 847 packet into a minimum number of fragments where the first fragment 848 is no larger than 1024 bytes and all other fragments are no larger 849 than the first fragment. The AERO interface then encapsulates 850 each fragment (and for IPv4 sets the DF bit to 0) and sends each 851 fragment to the neighbor. These encapsulated fragments will be 852 deterministically delivered to the final destination. (The AERO 853 interface need not perform rate limiting or include integrity 854 checks for these packets since it is not the original source of 855 the unencapsulated packet.) 857 o For all other IP packets, if the packet is larger than the AERO 858 interface MTU the AERO node drops the packet and returns an L3 PTB 859 message with MTU set to the AERO interface MTU; otherwise, the 860 node admits the packet into the AERO interface. Next, if the 861 packet length is larger than the MTU of the underlying interface 862 to be used for tunneling minus ENCAPS, the AERO interface drops 863 the packet and returns an L3 PTB message with MTU set to the 864 larger of 1500 or the underlying interface MTU minus ENCAPS. 865 Otherwise, the AERO interface encapsulates the packet and admits 866 it into the tunnel without fragmentation (and for IPv4 sets the DF 867 bit to 1) and translates any L2 PTB messages it may receive from 868 the network into corresponding L3 PTB messages to send to the 869 original source as specified in Section 3.10. Since both L2 and 870 L3 PTB messages may be either lost or contain insufficient 871 information, however, it is RECOMMENDED that sources that send 872 unfragmentable IP packets larger than 1500 bytes use Packetization 873 Layer Path MTU Discovery (PLPMTUD) [RFC4821]. 875 While sending packets according to the above specifications, the AERO 876 interface MAY also send 1500 byte probe packets to the tunnel egress 877 to determine whether the probes can traverse the tunnel without 878 fragmentation. If the probes succeed, the tunnel ingress can begin 879 sending packets that are larger than 1280-ENCAPS bytes but no larger 880 than 1500 bytes without fragmentation (and for IPv4 with DF set to 881 1). Since the path MTU within the tunnel may fluctuate due to 882 routing changes, the tunnel ingress SHOULD continually send 883 additional probes subject to rate limiting in case L2 PTB messages 884 are lost. If the path MTU within the tunnel later becomes 885 insufficient, the tunnel ingress must resume fragmentation. 887 To construct a probe, the AERO interface prepares an NS message with 888 a Nonce option plus trailing padding octets added to a length of 1500 889 bytes without including the length of the padding in the IPv6 Payload 890 Length field. The node then encapsulates the padded NS message in 891 the encapsulation headers (and for IPv4 sets DF to 1) then sends the 892 message to the neighbor. Note that the trailing padding SHOULD NOT 893 be included within the Nonce option itself but rather as padding 894 beyond the last option in the NS message; otherwise, the (large) 895 Nonce option would be echoed back in the solicited NA message and may 896 be lost at a link with a small MTU along the reverse path. 898 In light of the above fragmentation and reassembly recommendations, 899 the tunnel egress MUST be capable of reassembling encapsulated 900 packets up to 1500+ENCAPS bytes in length. It is therefore 901 RECOMMENDED that the tunnel egress be capable of reassembling at 902 least 2KB. Also, in some environments there may be operational 903 assurance that all links within the routing region spanned by the 904 tunnel configure sufficiently large MTUs so that fragmentation and 905 reassembly can be avoided. In those cases, specific tunnel 906 specifications must explain the circumstances under which the above 907 fragmentation and reassembly recommendations need not be applied. 909 Of possible concern is that some network middleboxes hold the 910 fragments of a fragmented UDP packet until all fragments have arrived 911 before forwarding the fragments to the final destination. This means 912 that the network middlebox must also be able to accommodate 913 fragmented UDP packets up to 1500+ENCAPS bytes in length which cannot 914 be controlled by the tunnel egress. However, network middleboxes 915 already must be capable of passing fragmented UDP datagrams up to the 916 maximum fragmented IP packet size as evidenced through actual 917 operational experience (see the thread "PMTUD issue discussion" in 918 the IETF v6ops archive dated September 10, 2014). Hence, there is no 919 need for AERO to stipulate a minimum reassembly size for those 920 devices. 922 3.10. AERO Interface Error Handling 924 When an AERO node admits encapsulated packets into the AERO 925 interface, it may receive L2 or an L3 error indications. 927 An L2 error indication is an ICMP error message generated by a router 928 on the path to the neighbor or by the neighbor itself. The message 929 includes an IP header with the address of the node that generated the 930 error as the source address and with the link-layer address of the 931 AERO node as the destination address. 933 The IP header is followed by an ICMP header that includes an error 934 Type, Code and Checksum. For ICMPv6 [RFC4443], the error Types 935 include "Destination Unreachable", "Packet Too Big (PTB)", "Time 936 Exceeded" and "Parameter Problem". For ICMPv4 [RFC0792], the error 937 Types include "Destination Unreachable", "Fragmentation Needed" (a 938 Destination Unreachable Code that is analogous to the ICMPv6 PTB), 939 "Time Exceeded" and "Parameter Problem". 941 The ICMP header is followed by the leading portion of the packet that 942 generated the error, also known as the "packet-in-error". For 943 ICMPv6, [RFC4443] specifies that the packet-in-error includes: "As 944 much of invoking packet as possible without the ICMPv6 packet 945 exceeding the minimum IPv6 MTU" (i.e., no more than 1280 bytes). For 946 ICMPv4, [RFC0792] specifies that the packet-in-error includes: 947 "Internet Header + 64 bits of Original Data Datagram", however 948 [RFC1812], Section 4.3.2.3 updates this specification by stating: 949 "the ICMP datagram SHOULD contain as much of the original datagram as 950 possible without the length of the ICMP datagram exceeding 576 951 bytes". 953 The L2 error message format is shown in Figure 3: 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 ~ ~ 957 | L2 IP Header of | 958 | error message | 959 ~ ~ 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | L2 ICMP Header | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 963 ~ ~ P 964 | IP and other encapsulation | a 965 | headers of original L3 packet | c 966 ~ ~ k 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 968 ~ ~ t 969 | IP header of | 970 | original L3 packet | i 971 ~ ~ n 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 ~ ~ e 974 | Upper layer headers and | r 975 | leading portion of body | r 976 | of the original L3 packet | o 977 ~ ~ r 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 980 Figure 3: AERO Interface L2 Error Message Format 982 The AERO node rules for processing these L2 error messages is as 983 follows: 985 o When an AERO node receives an L2 "Parameter Problem", it processes 986 the message the same as described as for ordinary ICMP errors in 987 the normative references [RFC0792][RFC4443]. 989 o When an AERO node receives persistent L2 Time Exceeded messages, 990 it SHOULD reduce its current rate of admitting fragmented 991 encapsulated packets into the tunnel to ensure that the IP ID 992 field will not wrap before all earlier fragments have been 993 processed. If the AERO node includes an integrity check vector, 994 however, it MAY ignore the messages and continue sending 995 fragmented encapsulated packets without rate limiting. 997 o When an AERO Client receives persistent L2 Destination Unreachable 998 messages in response to tunneled packets that it sends to one of 999 its dynamic neighbor correspondents, the Client SHOULD test the 1000 path to the correspondent using Neighbor Unreachability Detection 1001 (NUD) (see Section 3.14). If NUD fails, the Client SHOULD set 1002 ForwardTime for the corresponding dynamic neighbor cache entry to 1003 0 and allow future packets destined to the correspondent to flow 1004 through a Server. 1006 o When an AERO Client receives persistent L2 Destination Unreachable 1007 messages in response to tunneled packets that it sends to one of 1008 its static neighbor Servers, the Client SHOULD test the path to 1009 the Server using NUD. If NUD fails, the Client SHOULD delete the 1010 neighbor cache entry and attempt to associate with a new Server. 1012 o When an AERO Server receives persistent L2 Destination Unreachable 1013 messages in response to tunneled packets that it sends to one of 1014 its static neighbor Clients, the Server SHOULD test the path to 1015 the Client using NUD. If NUD fails, the Server SHOULD cancel the 1016 DHCPv6 PD lease for the Client's ACP, withdraw its route for the 1017 ACP from the AERO routing system and delete the neighbor cache 1018 entry (see Sections 3.11 and 3.12). 1020 o When an AERO Relay or Server receives an L2 Destination 1021 Unreachable message in response to a tunneled packet that it sends 1022 to one of its permanent neighbors, it discards the message since 1023 the routing system is likely in a temporary transitional state 1024 that will soon re-converge. 1026 o When an AERO node receives an L2 PTB message, it translates the 1027 message into an L3 PTB message if possible (*) and forwards the 1028 message toward the original source as described below. 1030 To translate an L2 PTB message to an L3 PTB message, the AERO node 1031 first caches the values in the Type, Code and MTU fields of the L2 1032 ICMP header. The node next discards the L2 IP and ICMP headers, and 1033 also discards the encapsulation headers of the original L3 packet. 1034 Next the node encapsulates the included segment of the original L3 1035 packet in an L3 IP and ICMP header. In the process, the node uses 1036 the cached L2 Type and Code values to set corresponding values in the 1037 Type and Code fields of the L3 ICMP header, then writes the maximum 1038 of 1500 bytes and (L2 MTU - ENCAPS) into MTU field of the L3 ICMP 1039 header. 1041 The node next writes the IP source address of the original L3 packet 1042 as the destination address of the L3 PTB message and determines the 1043 next hop to the destination. If the next hop is reached via the AERO 1044 interface, the node uses the IPv6 address "::" or the IPv4 address 1045 "0.0.0.0" as the IP source address of the L3 PTB message. Otherwise, 1046 the node uses one of its non link-local addresses as the source 1047 address of the L3 PTB message. The node finally calculates the ICMP 1048 checksum over the L3 PTB message and writes the Checksum in the 1049 corresponding field of the L3 ICMP header. The L3 PTB message 1050 therefore is formatted as follows: 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 ~ ~ 1054 | L3 IP Header of | 1055 | error message | 1056 ~ ~ 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | L3 ICMP Header | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1060 ~ ~ p 1061 | IP header of | k 1062 | original L3 packet | t 1063 ~ ~ 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1065 ~ ~ n 1066 | Upper layer headers and | 1067 | leading portion of body | e 1068 | of the original L3 packet | r 1069 ~ ~ r 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1072 Figure 4: AERO Interface L3 Error Message Format 1074 After the node has prepared the L3 PTB message, it either forwards 1075 the message via a link outside of the AERO interface without 1076 encapsulation, or encapsulates and forwards the message to the next 1077 hop via the AERO interface. 1079 When an AERO Relay receives an L3 packet for which the destination 1080 address is covered by an ASP, if there is no more-specific routing 1081 information for the destination the Relay drops the packet and 1082 returns an L3 Destination Unreachable message. The Relay first 1083 writes the IP source address of the original L3 packet as the 1084 destination address of the L3 Destination Unreachable message and 1085 determines the next hop to the destination. If the next hop is 1086 reached via the AERO interface, the Relay uses the IPv6 address "::" 1087 or the IPv4 address "0.0.0.0" as the IP source address of the L3 1088 Destination Unreachable message and forwards the message to the next 1089 hop within the AERO interface. Otherwise, the Relay uses one of its 1090 non link-local addresses as the source address of the L3 Destination 1091 Unreachable message and forwards the message via a link outside the 1092 AERO interface. 1094 When an AERO node receives any L3 error message via the AERO 1095 interface, it examines the destination address in the L3 IP header of 1096 the message. If the next hop toward the destination address of the 1097 error message is via the AERO interface, the node re-encapsulates and 1098 forwards the message to the next hop within the AERO interface. 1099 Otherwise, if the source address in the L3 IP header of the message 1100 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1101 writes one of its non link-local addresses as the source address of 1102 the L3 message and recalculates the IP and/or ICMP checksums. The 1103 node finally forwards the message via a link outside of the AERO 1104 interface. 1106 (*) Note that in some instances the packet-in-error field of an L2 1107 PTB message may not include enough information for translation to an 1108 L3 PTB message. In that case, the AERO interface simply discards the 1109 L2 PTB message. It can therefore be said that translation of L2 PTB 1110 messages to L3 PTB messages can provide a useful optimization when 1111 possible, but is not critical for sources that correctly use PLPMTUD. 1113 3.11. AERO Router Discovery, Prefix Delegation and Address 1114 Configuration 1116 3.11.1. AERO DHCPv6 Service Model 1118 Each AERO Server configures a DHCPv6 server function to facilitate PD 1119 requests from Clients. Each Server is pre-configured with an 1120 identical list of ACP-to-Client ID mappings for all Clients enrolled 1121 in the AERO system, as well as any information necessary to 1122 authenticate Clients. The configuration information is maintained by 1123 a central administrative authority for the AERO link and securely 1124 propagated to all Servers whenever a new Client is enrolled or an 1125 existing Client is withdrawn. 1127 With these identical configurations, each Server can function 1128 independently of all other Servers, including the maintenance of 1129 active leases. Therefore, no Server-to-Server DHCPv6 state 1130 synchronization is necessary, and Clients can optionally hold 1131 separate leases for the same ACP from multiple Servers. 1133 In this way, Clients can easily associate with multiple Servers, and 1134 can receive new leases from new Servers before deprecating leases 1135 held through old Servers. This enables a graceful "make-before- 1136 break" capability. 1138 3.11.2. AERO Client Behavior 1140 AERO Clients discover the link-layer addresses of AERO Servers via 1141 static configuration, or through an automated means such as DNS name 1142 resolution. In the absence of other information, the Client resolves 1143 the Fully-Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" 1144 where "linkupnetworks" is a constant text string and "[domainname]" 1145 is the connection-specific DNS suffix for the Client's underlying 1146 network connection (e.g., "example.com"). After discovering the 1147 link-layer addresses, the Client associates with one or more of the 1148 corresponding Servers. 1150 To associate with a Server, the Client acts as a requesting router to 1151 request an ACP through a DHCPv6 PD exchange[RFC3315][RFC3633] in 1152 which the Client's Solicit/Request messages use the IPv6 1153 "unspecified" address (i.e., "::") as the IPv6 source address, 1154 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 1155 and the link-layer address of the Server as the link-layer 1156 destination address. The Client also includes a Client Identifier 1157 option with a DHCP Unique Identifier (DUID) plus any necessary 1158 authentication options to identify itself to the DHCPv6 server, and 1159 includes a Client Link Layer Address Option (CLLAO) [RFC6939] with 1160 the format shown in Figure 5: 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | OPTION_CLIENT_LINKLAYER_ADDR | option-length | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | link-layer type (16 bits) | Link ID | Preference | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 Figure 5: AERO Client Link-Layer Address Option (CLLAO) Format 1172 The Client sets the CLLAO 'option-length' field to 4 and sets the 1173 'link-layer type' field to TBD1 (see: IANA Considerations), then 1174 includes appropriate Link ID and Preference values for the underlying 1175 interface over which the Solicit/Request will be issued (note that 1176 these are the same values that would be included in a TLLAO as shown 1177 in Figure 2). If the Client is pre-provisioned with an ACP 1178 associated with the AERO service, it MAY also include the ACP in the 1179 Solicit/Request message Identity Association (IA) option to indicate 1180 its preferred ACP to the DHCPv6 server. The Client then sends the 1181 encapsulated DHCPv6 request via the underlying interface. 1183 When the Client receives its ACP and the set of ASPs via a DHCPv6 1184 Reply from the AERO Server, it creates a static neighbor cache entry 1185 with the Server's link-local address (i.e., fe80::ID) as the network- 1186 layer address and the Server's encapsulation address as the link- 1187 layer address. The Client then records the lifetime for the ACP in 1188 the neighbor cache entry and marks the neighbor cache entry as 1189 "default", i.e., the Client considers the Server as a default router. 1190 If the Reply message contains a Vendor-Specific Information Option 1191 (see: Section 3.10.3) the Client also caches each ASP in the option. 1193 The Client then applies the AERO address to the AERO interface and 1194 sub-delegates the ACP to nodes and links within its attached EUNs 1195 (the AERO address thereafter remains stable as the Client moves). 1196 The Client also assigns a default IP route to the AERO interface as a 1197 route-to-interface, i.e., with no explicit next-hop. The next hop 1198 will then be determined after a packet has been submitted to the AERO 1199 interface by inspecting the neighbor cache (see above). 1201 On some platforms (e.g., on some popular cell phone operating 1202 systems), the act of assigning a default IPv6 route to the AERO 1203 interface may not be permitted from a user application. On those 1204 platforms, sub-delegation of the ACP may also not be feasible. 1205 Typically, those platforms include a TUN/TAP interface that acts as a 1206 point-to-point conduit between user applications and the AERO 1207 interface. In that case, the Client can instead generate a 1208 "synthesized RA" message. The message conforms to [RFC4861] and is 1209 prepared as follows: 1211 o the IPv6 source address is fe80:: 1213 o the IPv6 destination address is all-nodes multicast 1215 o the Router Lifetime is non-zero, which provides both a default 1216 router lifetime and an indication of the time at which additional 1217 synthesized RAs must be sent 1219 o the message does not include a Source Link Layer Address Option 1220 (SLLAO) 1222 o the message includes a Prefix Information Option (PIO) with a /64 1223 prefix taken from the ACP as the prefix for autoconfiguration 1225 The Client then sends the synthesized RA message via the TUN/TAP 1226 interface, where the operating system kernel will interpret it as 1227 though it were generated by an actual router. The operating system 1228 will then install a default route and use StateLess Address 1229 AutoConfiguration (SLAAC) to configure an IPv6 address on the TUN/TAP 1230 interface. Methods for similarly installing an IPv4 default route 1231 and IPv4 address on the TUN/TAP interface could be based on 1232 synthesized DHCPv4 messages. 1234 The Client subsequently renews its ACP delegation through each of its 1235 Servers by performing DHCPv6 Renew/Reply exchanges with its AERO 1236 address as the IPv6 source address, 1237 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address, 1238 the link-layer address of a Server as the link-layer destination 1239 address and the same Client identifier, authentication options and 1240 CLLAO option as was used in the initial PD request. Note that if the 1241 Client does not issue a DHCPv6 Renew before the Server has terminated 1242 the lease (e.g., if the Client has been out of touch with the Server 1243 for a considerable amount of time), the Server's Reply will report 1244 NoBinding and the Client must re-initiate the DHCPv6 PD procedure. 1246 Since the Client's AERO address is configured from the unique ACP 1247 delegation it receives, there is no need for Duplicate Address 1248 Detection (DAD) on AERO links. Other nodes maliciously attempting to 1249 hijack an authorized Client's AERO address will be denied access to 1250 the network by the DHCPv6 server due to an unacceptable link-layer 1251 address and/or security parameters (see: Security Considerations). 1253 AERO Clients ignore the IP address and UDP port number in any S/TLLAO 1254 options in ND messages they receive directly from another AERO 1255 Client, but examine the Link ID and Preference values to match the 1256 message with the correct link-layer address information. 1258 When a source Client forwards a packet to a prospective destination 1259 Client (i.e., one for which the packet's destination address is 1260 covered by an ASP), the source Client initiates an AERO route 1261 optimization procedure as specified in Section 3.13. 1263 3.11.3. AERO Server Behavior 1265 AERO Servers configure a DHCPv6 server function on their AERO links. 1266 AERO Servers arrange to add their encapsulation layer IP addresses 1267 (i.e., their link-layer addresses) to the DNS resource records for 1268 the FQDN "linkupnetworks.[domainname]" before entering service. 1270 When an AERO Server receives a prospective Client's DHCPv6 PD 1271 Solicit/Request message, it first authenticates the message. If 1272 authentication succeeds, the Server determines the correct ACP to 1273 delegate to the Client by matching the Client's DUID within an online 1274 directory service (e.g., LDAP). The Server then delegates the ACP 1275 and creates a static neighbor cache entry for the Client's AERO 1276 address with lifetime set to no more than the lease lifetime and the 1277 Client's link-layer address as the link-layer address for the Link ID 1278 specified in the CLLAO option. The Server then creates an IP 1279 forwarding table entry so that the AERO routing system will propagate 1280 the ACP to all Relays (see: Section 3.12). Finally, the Server sends 1281 a DHCPv6 Reply message to the Client while using fe80::ID as the IPv6 1282 source address, the Client's AERO address as the IPv6 destination 1283 address, and the Client's link-layer address as the destination link- 1284 layer address. The Server also includes a Server Unicast option with 1285 server-address set to fe80::ID so that all future Client/Server 1286 transactions will be link-local-only unicast over the AERO link. 1288 When the Server sends the DHCPv6 Reply message, it also includes a 1289 DHCPv6 Vendor-Specific Information Option with 'enterprise-number' 1290 set to "TBD2" (see: IANA Considerations). The option is formatted as 1291 shown in[RFC3315] and with the AERO enterprise-specific format shown 1292 in Figure 6: 1294 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 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | OPTION_VENDOR_OPTS | option-len | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | enterprise-number ("TBD2") | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Reserved | Prefix Length | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | | 1303 + ASP (1) + 1304 | | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Reserved | Prefix Length | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | | 1309 + ASP (2) + 1310 | | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Reserved | Prefix Length | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | | 1315 + ASP (3) + 1316 | | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 . (etc.) . 1319 . . 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 Figure 6: AERO Vendor-Specific Information Option 1324 Per Figure 6, the option includes one or more ASP. The ASP field 1325 contains the IP prefix as it would appear in the interface identifier 1326 portion of the corresponding AERO address (see: Section 3.3). For 1327 IPv6, valid values for the Prefix Length field are 0 through 64; for 1328 IPv4, valid values are 0 through 32. 1330 After the initial DHCPv6 PD exchange, the AERO Server maintains the 1331 neighbor cache entry for the Client as long as the lease lifetime 1332 remains current. If the Client issues a Renew/Reply exchange, the 1333 Server extends the lifetime. If the Client issues a Release/Reply 1334 exchange, or if the Client does not issue a Renew/Reply within the 1335 lease lifetime, the Server deletes the neighbor cache entry for the 1336 Client and withdraws the IP route from the AERO routing system. 1338 3.12. AERO Relay/Server Routing System 1340 Relays require full topology information of all Client/Server 1341 associations, while individual Servers only require partial topology 1342 information, i.e., they only need to know the ACPs associated with 1343 their current set of associated Clients. This is accomplished 1344 through the use of an internal instance of the Border Gateway 1345 Protocol (BGP) [RFC4271] coordinated between Servers and Relays. 1346 This internal BGP instance does not interact with the public Internet 1347 BGP instance; therefore, the AERO link is presented to the IP 1348 Internetwork as a small set of ASPs as opposed to the full set of 1349 individual ACPs. 1351 In a reference BGP arrangement, each AERO Server is configured as an 1352 Autonomous System Border Router (ASBR) for a stub Autonomous System 1353 (AS) (possibly using a private AS Number (ASN) [RFC1930]), and each 1354 Server further peers with each Relay but does not peer with other 1355 Servers. Similarly, Relays need not peer with each other, since they 1356 will receive all updates from all Servers and will therefore have a 1357 consistent view of the AERO link ACP delegations. 1359 Each Server maintains a working set of associated Clients, and 1360 dynamically announces new ACPs and withdraws departed ACPs in its BGP 1361 updates to Relays. Relays do not send BGP updates to Servers, 1362 however, such that the BGP route reporting is unidirectional from the 1363 Servers to the Relays. 1365 The Relays therefore discover the full topology of the AERO link in 1366 terms of the working set of ACPs associated with each Server, while 1367 the Servers only discover the ACPs of their associated Clients. 1368 Since Clients are expected to remain associated with their current 1369 set of Servers for extended timeframes, the amount of BGP control 1370 messaging between Servers and Relays should be minimal. However, BGP 1371 peers SHOULD dampen any route oscillations caused by impatient 1372 Clients that repeatedly associate and disassociate with Servers. 1374 3.13. AERO Redirection 1376 3.13.1. Reference Operational Scenario 1378 Figure 7 depicts the AERO redirection reference operational scenario, 1379 using IPv6 addressing as the example (while not shown, a 1380 corresponding example for IPv4 addressing can be easily constructed). 1381 The figure shows an AERO Relay ('R'), two AERO Servers ('S1', 'S2'), 1382 two AERO Clients ('A', 'B') and two ordinary IPv6 hosts ('C', 'D'): 1384 +--------------+ +--------------+ +--------------+ 1385 | Server S1 | | Relay R | | Server S2 | 1386 | Nbr: A | |(C->S1; D->S2)| | Nbr: B | 1387 +--------------+ +--------------+ +--------------+ 1388 fe80::2 fe80::1 fe80::3 1389 L2(S1) L2(R) L2(S2) 1390 | | | 1391 X-----+-----+------------------+-----------------+----+----X 1392 | AERO Link | 1393 L2(A) L2(B) 1394 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1395 +--------------+ +--------------+ 1396 | AERO Client A| | AERO Client B| 1397 | (default->S1)| | (default->S2)| 1398 +--------------+ +--------------+ 1399 2001:DB8:0::/48 2001:DB8:1::/48 1400 | | 1401 .-. .-. 1402 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1403 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1404 (__ EUN )--| Host C | | Host D |--(__ EUN ) 1405 `-(______)-' +---------+ +---------+ `-(______)-' 1407 Figure 7: AERO Reference Operational Scenario 1409 In Figure 7, Relay ('R') applies the address fe80::1 to its AERO 1410 interface with link-layer address L2(R), Server ('S1') applies the 1411 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1412 applies the address fe80::3 with link-layer address L2(S2). Servers 1413 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1414 published list of valid Servers for the AERO link. 1416 AERO Client ('A') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1417 exchange via AERO Server ('S1') then applies the address 1418 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1419 L2(A). Client ('A') configures a default route and neighbor cache 1420 entry via the AERO interface with next-hop address fe80::2 and link- 1421 layer address L2(S1), then sub-delegates the ACP to its attached 1422 EUNs. IPv6 host ('C') connects to the EUN, and configures the 1423 address 2001:db8:0::1. 1425 AERO Client ('B') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1426 exchange via AERO Server ('S2') then applies the address 1427 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1428 L2(B). Client ('B') configures a default route and neighbor cache 1429 entry via the AERO interface with next-hop address fe80::3 and link- 1430 layer address L2(S2), then sub-delegates the ACP to its attached 1431 EUNs. IPv6 host ('D') connects to the EUN, and configures the 1432 address 2001:db8:1::1. 1434 3.13.2. Concept of Operations 1436 Again, with reference to Figure 7, when source host ('C') sends a 1437 packet to destination host ('D'), the packet is first forwarded over 1438 the source host's attached EUN to Client ('A'). Client ('A') then 1439 forwards the packet via its AERO interface to Server ('S1') and also 1440 sends a Predirect message toward Client ('B') via Server ('S1'). 1441 Server ('S1') then re-encapsulates and forwards both the packet and 1442 the Predirect message out the same AERO interface toward Client ('B') 1443 via Relay ('R'). 1445 When Relay ('R') receives the packet and Predirect message, it 1446 consults its forwarding table to discover Server ('S2') as the next 1447 hop toward Client ('B'). Relay ('R') then forwards both the packet 1448 and the Predirect message to Server ('S2'), which then forwards them 1449 to Client ('B'). 1451 After Client ('B') receives the Predirect message, it process the 1452 message and returns a Redirect message toward Client ('A') via Server 1453 ('S2'). During the process, Client ('B') also creates or updates a 1454 dynamic neighbor cache entry for Client ('A'). 1456 When Server ('S2') receives the Redirect message, it re-encapsulates 1457 the message and forwards it on to Relay ('R'), which forwards the 1458 message on to Server ('S1') which forwards the message on to Client 1459 ('A'). After Client ('A') receives the Redirect message, it 1460 processes the message and creates or updates a dynamic neighbor cache 1461 entry for Client ('C'). 1463 Following the above Predirect/Redirect message exchange, forwarding 1464 of packets from Client ('A') to Client ('B') without involving any 1465 intermediate nodes is enabled. The mechanisms that support this 1466 exchange are specified in the following sections. 1468 3.13.3. Message Format 1470 AERO Redirect/Predirect messages use the same format as for ICMPv6 1471 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1472 include a new "Prefix Length" field taken from the low-order 8 bits 1473 of the Redirect message Reserved field. For IPv6, valid values for 1474 the Prefix Length field are 0 through 64; for IPv4, valid values are 1475 0 through 32. The Redirect/Predirect messages are formatted as shown 1476 in Figure 8: 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Type (=137) | Code (=0/1) | Checksum | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Reserved | Prefix Length | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | | 1486 + + 1487 | | 1488 + Target Address + 1489 | | 1490 + + 1491 | | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | | 1494 + + 1495 | | 1496 + Destination Address + 1497 | | 1498 + + 1499 | | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Options ... 1502 +-+-+-+-+-+-+-+-+-+-+-+- 1504 Figure 8: AERO Redirect/Predirect Message Format 1506 3.13.4. Sending Predirects 1508 When a Client forwards a packet with a source address from one of its 1509 ACPs toward a destination address covered by an ASP (i.e., toward 1510 another AERO Client connected to the same AERO link), the source 1511 Client MAY send a Predirect message forward toward the destination 1512 Client via the Server. 1514 In the reference operational scenario, when Client ('A') forwards a 1515 packet toward Client ('B'), it MAY also send a Predirect message 1516 forward toward Client ('B'), subject to rate limiting (see 1517 Section 8.2 of [RFC4861]). Client ('A') prepares the Predirect 1518 message as follows: 1520 o the link-layer source address is set to 'L2(A)' (i.e., the link- 1521 layer address of Client ('A')). 1523 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1524 link-layer address of Server ('S1')). 1526 o the network-layer source address is set to fe80::2001:db8:0:0 1527 (i.e., the AERO address of Client ('A')). 1529 o the network-layer destination address is set to fe80::2001:db8:1:0 1530 (i.e., the AERO address of Client ('B')). 1532 o the Type is set to 137. 1534 o the Code is set to 1 to indicate "Predirect". 1536 o the Prefix Length is set to the length of the prefix to be applied 1537 to the Target Address. 1539 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1540 address of Client ('A')). 1542 o the Destination Address is set to the source address of the 1543 originating packet that triggered the Predirection event. (If the 1544 originating packet is an IPv4 packet, the address is constructed 1545 in IPv4-compatible IPv6 address format). 1547 o the message includes one or more TLLAOs with Link ID and 1548 Preference set to appropriate values for Client ('A')'s underlying 1549 interfaces, and with UDP Port Number and IP Address set to 0'. 1551 o the message SHOULD include a Timestamp option and a Nonce option. 1553 o the message includes a Redirected Header Option (RHO) that 1554 contains the originating packet truncated to ensure that at least 1555 the network-layer header is included but the size of the message 1556 does not exceed 1280 bytes. 1558 Note that the act of sending Predirect messages is cited as "MAY", 1559 since Client ('A') may have advanced knowledge that the direct path 1560 to Client ('B') would be unusable or otherwise undesirable. If the 1561 direct path later becomes unusable after the initial route 1562 optimization, Client ('A') simply allows packets to again flow 1563 through Server ('S1'). 1565 3.13.5. Re-encapsulating and Relaying Predirects 1567 When Server ('S1') receives a Predirect message from Client ('A'), it 1568 first verifies that the TLLAOs in the Predirect are a proper subset 1569 of the Link IDs in Client ('A')'s neighbor cache entry. If the 1570 Client's TLLAOs are not acceptable, Server ('S1') discards the 1571 message. Otherwise, Server ('S1') validates the message according to 1572 the ICMPv6 Redirect message validation rules in Section 8.1 of 1573 [RFC4861], except that the Predirect has Code=1. Server ('S1') also 1574 verifies that Client ('A') is authorized to use the Prefix Length in 1575 the Predirect when applied to the AERO address in the network-layer 1576 source address by searching for the AERO address in the neighbor 1577 cache. If validation fails, Server ('S1') discards the Predirect; 1578 otherwise, it copies the correct UDP Port numbers and IP Addresses 1579 for Client ('A')'s links into the (previously empty) TLLAOs. 1581 Server ('S1') then examines the network-layer destination address of 1582 the Predirect to determine the next hop toward Client ('B') by 1583 searching for the AERO address in the neighbor cache. Since Client 1584 ('B') is not one of its neighbors, Server ('S1') re-encapsulates the 1585 Predirect and relays it via Relay ('R') by changing the link-layer 1586 source address of the message to 'L2(S1)' and changing the link-layer 1587 destination address to 'L2(R)'. Server ('S1') finally forwards the 1588 re-encapsulated message to Relay ('R') without decrementing the 1589 network-layer TTL/Hop Limit field. 1591 When Relay ('R') receives the Predirect message from Server ('S1') it 1592 determines that Server ('S2') is the next hop toward Client ('B') by 1593 consulting its forwarding table. Relay ('R') then re-encapsulates 1594 the Predirect while changing the link-layer source address to 'L2(R)' 1595 and changing the link-layer destination address to 'L2(S2)'. Relay 1596 ('R') then relays the Predirect via Server ('S2'). 1598 When Server ('S2') receives the Predirect message from Relay ('R') it 1599 determines that Client ('B') is a neighbor by consulting its neighbor 1600 cache. Server ('S2') then re-encapsulates the Predirect while 1601 changing the link-layer source address to 'L2(S2)' and changing the 1602 link-layer destination address to 'L2(B)'. Server ('S2') then 1603 forwards the message to Client ('B'). 1605 3.13.6. Processing Predirects and Sending Redirects 1607 When Client ('B') receives the Predirect message, it accepts the 1608 Predirect only if the message has a link-layer source address of one 1609 of its Servers (e.g., L2(S2)). Client ('B') further accepts the 1610 message only if it is willing to serve as a redirection target. 1611 Next, Client ('B') validates the message according to the ICMPv6 1612 Redirect message validation rules in Section 8.1 of [RFC4861], except 1613 that it accepts the message even though Code=1 and even though the 1614 network-layer source address is not that of it's current first-hop 1615 router. 1617 In the reference operational scenario, when Client ('B') receives a 1618 valid Predirect message, it either creates or updates a dynamic 1619 neighbor cache entry that stores the Target Address of the message as 1620 the network-layer address of Client ('A') , stores the link-layer 1621 addresses found in the TLLAOs as the link-layer addresses of Client 1622 ('A') and stores the Prefix Length as the length to be applied to the 1623 network-layer address for forwarding purposes. Client ('B') then 1624 sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1626 After processing the message, Client ('B') prepares a Redirect 1627 message response as follows: 1629 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1630 layer address of Client ('B')). 1632 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1633 link-layer address of Server ('S2')). 1635 o the network-layer source address is set to fe80::2001:db8:1:0 1636 (i.e., the AERO address of Client ('B')). 1638 o the network-layer destination address is set to fe80::2001:db8:0:0 1639 (i.e., the AERO address of Client ('A')). 1641 o the Type is set to 137. 1643 o the Code is set to 0 to indicate "Redirect". 1645 o the Prefix Length is set to the length of the prefix to be applied 1646 to the Target Address. 1648 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1649 address of Client ('B')). 1651 o the Destination Address is set to the destination address of the 1652 originating packet that triggered the Redirection event. (If the 1653 originating packet is an IPv4 packet, the address is constructed 1654 in IPv4-compatible IPv6 address format). 1656 o the message includes one or more TLLAOs with Link ID and 1657 Preference set to appropriate values for Client ('B')'s underlying 1658 interfaces, and with UDP Port Number and IP Address set to '0'. 1660 o the message SHOULD include a Timestamp option and MUST echo the 1661 Nonce option received in the Predirect (i.e., if a Nonce option is 1662 included). 1664 o the message includes as much of the RHO copied from the 1665 corresponding AERO Predirect message as possible such that at 1666 least the network-layer header is included but the size of the 1667 message does not exceed 1280 bytes. 1669 After Client ('B') prepares the Redirect message, it sends the 1670 message to Server ('S2'). 1672 3.13.7. Re-encapsulating and Relaying Redirects 1674 When Server ('S2') receives a Redirect message from Client ('B'), it 1675 first verifies that the TLLAOs in the Redirect are a proper subset of 1676 the Link IDs in Client ('B')'s neighbor cache entry. If the Client's 1677 TLLAOs are not acceptable, Server ('S2') discards the message. 1678 Otherwise, Server ('S2') validates the message according to the 1679 ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861]. 1680 Server ('S2') also verifies that Client ('B') is authorized to use 1681 the Prefix Length in the Redirect when applied to the AERO address in 1682 the network-layer source address by searching for the AERO address in 1683 the neighbor cache. If validation fails, Server ('S2') discards the 1684 Predirect; otherwise, it copies the correct UDP Port numbers and IP 1685 Addresses for Client ('B')'s links into the (previously empty) 1686 TLLAOs. 1688 Server ('S2') then examines the network-layer destination address of 1689 the Predirect to determine the next hop toward Client ('A') by 1690 searching for the AERO address in the neighbor cache. Since Client 1691 ('A') is not one of its neighbors, Server ('S2') re-encapsulates the 1692 Predirect and relays it via Relay ('R') by changing the link-layer 1693 source address of the message to 'L2(S2)' and changing the link-layer 1694 destination address to 'L2(R)'. Server ('S2') finally forwards the 1695 re-encapsulated message to Relay ('R') without decrementing the 1696 network-layer TTL/Hop Limit field. 1698 When Relay ('R') receives the Predirect message from Server ('S2') it 1699 determines that Server ('S1') is the next hop toward Client ('A') by 1700 consulting its forwarding table. Relay ('R') then re-encapsulates 1701 the Predirect while changing the link-layer source address to 'L2(R)' 1702 and changing the link-layer destination address to 'L2(S1)'. Relay 1703 ('R') then relays the Predirect via Server ('S1'). 1705 When Server ('S1') receives the Predirect message from Relay ('R') it 1706 determines that Client ('A') is a neighbor by consulting its neighbor 1707 cache. Server ('S1') then re-encapsulates the Predirect while 1708 changing the link-layer source address to 'L2(S1)' and changing the 1709 link-layer destination address to 'L2(A)'. Server ('S1') then 1710 forwards the message to Client ('A'). 1712 3.13.8. Processing Redirects 1714 When Client ('A') receives the Redirect message, it accepts the 1715 message only if it has a link-layer source address of one of its 1716 Servers (e.g., ''L2(S1)'). Next, Client ('A') validates the message 1717 according to the ICMPv6 Redirect message validation rules in 1718 Section 8.1 of [RFC4861], except that it accepts the message even 1719 though the network-layer source address is not that of it's current 1720 first-hop router. Following validation, Client ('A') then processes 1721 the message as follows. 1723 In the reference operational scenario, when Client ('A') receives the 1724 Redirect message, it either creates or updates a dynamic neighbor 1725 cache entry that stores the Target Address of the message as the 1726 network-layer address of Client ('B'), stores the link-layer 1727 addresses found in the TLLAOs as the link-layer addresses of Client 1728 ('B') and stores the Prefix Length as the length to be applied to the 1729 network-layer address for forwarding purposes. Client ('A') then 1730 sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 1732 Now, Client ('A') has a neighbor cache entry with a valid ForwardTime 1733 value, while Client ('B') has a neighbor cache entry with a valid 1734 AcceptTime value. Thereafter, Client ('A') may forward ordinary 1735 network-layer data packets directly to Client ("B") without involving 1736 any intermediate nodes, and Client ('B') can verify that the packets 1737 came from an acceptable source. (In order for Client ('B') to 1738 forward packets to Client ('A'), a corresponding Predirect/Redirect 1739 message exchange is required in the reverse direction; hence, the 1740 mechanism is asymmetric.) 1742 3.13.9. Server-Oriented Redirection 1744 In some environments, the Server nearest the target Client may need 1745 to serve as the redirection target, e.g., if direct Client-to-Client 1746 communications are not possible. In that case, the Server prepares 1747 the Redirect message the same as if it were the destination Client 1748 (see: Section 3.9.6), except that it writes its own link-layer 1749 address in the TLLAO option. The Server must then maintain a 1750 neighbor cache entry for the redirected source Client. 1752 3.14. Neighbor Unreachability Detection (NUD) 1754 AERO nodes perform Neighbor Unreachability Detection (NUD) by sending 1755 unicast NS messages to elicit solicited NA messages from neighbors 1756 the same as described in [RFC4861]. NUD is performed either 1757 reactively in response to persistent L2 errors (see Section 3.10) or 1758 proactively to refresh existing neighbor cache entries. 1760 When an AERO node sends an NS/NA message, it MUST use its link-local 1761 address as the IPv6 source address and the link-local address of the 1762 neighbor as the IPv6 destination address. When an AERO node receives 1763 an NS message or a solicited NA message, it accepts the message if it 1764 has a neighbor cache entry for the neighbor; otherwise, it ignores 1765 the message. 1767 When a source Client is redirected to a target Client it SHOULD 1768 proactively test the direct path by sending an initial NS message to 1769 elicit a solicited NA response. While testing the path, the source 1770 Client can optionally continue sending packets via the Server, 1771 maintain a small queue of packets until target reachability is 1772 confirmed, or (optimistically) allow packets to flow directly to the 1773 target. The source Client SHOULD thereafter continue to proactively 1774 test the direct path to the target Client (see Section 7.3 of 1775 [RFC4861]) periodically in order to keep dynamic neighbor cache 1776 entries alive. 1778 In particular, while the source Client is actively sending packets to 1779 the target Client it SHOULD also send NS messages separated by 1780 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 1781 If the source Client is unable to elicit a solicited NA response from 1782 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 1783 to 0 and resume sending packets via one of its Servers. Otherwise, 1784 the source Client considers the path usable and SHOULD thereafter 1785 process any link-layer errors as a hint that the direct path to the 1786 target Client has either failed or has become intermittent. 1788 When a target Client receives an NS message from a source Client, it 1789 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 1790 otherwise, it discards the NS message. If ForwardTime is non-zero, 1791 the target Client then sends a solicited NA message to the link-layer 1792 address of the source Client; otherwise, it sends the solicited NA 1793 message to the link-layer address of one of its Servers. 1795 When a source Client receives a solicited NA message from a target 1796 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 1797 entry exists; otherwise, it discards the NA message. 1799 When ForwardTime for a dynamic neighbor cache entry expires, the 1800 source Client resumes sending any subsequent packets via a Server and 1801 may (eventually) attempt to re-initiate the AERO redirection process. 1802 When AcceptTime for a dynamic neighbor cache entry expires, the 1803 target Client discards any subsequent packets received directly from 1804 the source Client. When both ForwardTime and AcceptTime for a 1805 dynamic neighbor cache entry expire, the Client deletes the neighbor 1806 cache entry. 1808 3.15. Mobility Management 1810 3.15.1. Announcing Link-Layer Address Changes 1812 When a Client needs to change its link-layer address, e.g., due to a 1813 mobility event, it performs an immediate DHCPv6 Rebind/Reply exchange 1814 via each of its Servers using the new link-layer address as the 1815 source and with a CLLAO that includes the correct Link ID and 1816 Preference values. If authentication succeeds, the Server then 1817 update its neighbor cache and sends a DHCPv6 Reply. Note that if the 1818 Client does not issue a DHCPv6 Rebind before the Server has 1819 terminated the lease (e.g., if the Client has been out of touch with 1820 the Server for a considerable amount of time), the Server's Reply 1821 will report NoBinding and the Client must re-initiate the DHCPv6 PD 1822 procedure. 1824 Next, the Client sends unsolicited NA messages to each of its 1825 correspondent Client neighbors using the same procedures as specified 1826 in Section 7.2.6 of [RFC4861], except that it sends the messages as 1827 unicast to each neighbor via a Server instead of multicast. In this 1828 process, the Client should send no more than 1829 MAX_NEIGHBOR_ADVERTISEMENT messages separated by no less than 1830 RETRANS_TIMER seconds to each neighbor. 1832 With reference to Figure 7, Client ('B') sends unicast unsolicited NA 1833 messages to Client ('A') via Server ('S2') as follows: 1835 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1836 layer address of Client ('B')). 1838 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1839 link-layer address of Server ('S2')). 1841 o the network-layer source address is set to fe80::2001:db8:1:0 1842 (i.e., the AERO address of Client ('B')). 1844 o the network-layer destination address is set to fe80::2001:db8:0:0 1845 (i.e., the AERO address of Client ('A')). 1847 o the Type is set to 136. 1849 o the Code is set to 0. 1851 o the Solicited flag is set to 0. 1853 o the Override flag is set to 1. 1855 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1856 address of Client ('B')). 1858 o the message includes one or more TLLAOs with Link ID and 1859 Preference set to appropriate values for Client ('B')'s underlying 1860 interfaces, and with UDP Port Number and IP Address set to '0'. 1862 o the message SHOULD include a Timestamp option. 1864 When Server ('S1') receives the NA message, it relays the message in 1865 the same way as described for relaying Redirect messages in 1866 Section 3.12.7. In particular, Server ('S1') copies the correct UDP 1867 port numbers and IP addresses into the TLLAOs, changes the link-layer 1868 source address to its own address, changes the link-layer destination 1869 address to the address of Relay ('R'), then forwards the NA message 1870 via the relaying chain the same as for a Redirect. 1872 When Client ('A') receives the NA message, it accepts the message 1873 only if it already has a neighbor cache entry for Client ('B') then 1874 updates the link-layer addresses for Client ('B') based on the 1875 addresses in the TLLAOs. However, Client ('A') MUST NOT update 1876 ForwardTime since Client ('B') will not have updated AcceptTime. 1878 Note that these unsolicited NA messages are unacknowledged; hence, 1879 Client ('B') has no way of knowing whether Client ('A') has received 1880 them. If the messages are somehow lost, however, Client ('A') will 1881 soon learn of the mobility event via the NUD procedures specified in 1882 Section 3.13. 1884 3.15.2. Bringing New Links Into Service 1886 When a Client needs to bring a new underlying interface into service 1887 (e.g., when it activates a new data link), it performs an immediate 1888 Rebind/Reply exchange via each of its Servers using the new link- 1889 layer address as the source address and with a CLLAO that includes 1890 the new Link ID and Preference values. If authentication succeeds, 1891 the Server then updates its neighbor cache and sends a DHCPv6 Reply. 1892 The Client MAY then send unsolicited NA messages to each of its 1893 correspondent Clients to inform them of the new link-layer address as 1894 described in Section 3.14.1. 1896 3.15.3. Removing Existing Links from Service 1898 When a Client needs to remove an existing underlying interface from 1899 service (e.g., when it de-activates an existing data link), it 1900 performs an immediate Rebind/Reply exchange via each of its Servers 1901 over any available link with a CLLAO that includes the deprecated 1902 Link ID and a Preference value of 0. If authentication succeeds, the 1903 Server then updates its neighbor cache and sends a DHCPv6 Reply. The 1904 Client SHOULD then send unsolicited NA messages to each of its 1905 correspondent Clients to inform them of the deprecated link-layer 1906 address as described in Section 3.14.1. 1908 3.15.4. Moving to a New Server 1910 When a Client associates with a new Server, it performs the Client 1911 procedures specified in Section 3.10. 1913 When a Client disassociates with an existing Server, it sends a 1914 DHCPv6 Release message to the unicast link-local network layer 1915 address of the old Server. The Client SHOULD send the message via a 1916 new Server (i.e., by setting the link-layer destination address to 1917 the address of the new Server) in case the old Server is unreachable 1918 at the link layer, e.g., if the old Server is in a different network 1919 partition. The new Server will forward the message to a Relay, which 1920 will in turn forward the message to the old Server. 1922 When the old Server receives the DHCPv6 Release, it first 1923 authenticates the message. If authentication succeeds, the old 1924 Server withdraws the IP route from the AERO routing system and 1925 deletes the neighbor cache entry for the Client. (The old Server MAY 1926 impose a small delay before deleting the neighbor cache entry so that 1927 any packets already in the system can still be delivered to the 1928 Client.) The old Server then returns a DHCPv6 Reply message via a 1929 Relay. The Client can then use the Reply message to verify that the 1930 termination signal has been processed, and can delete both the 1931 default route and the neighbor cache entry for the old Server. (Note 1932 that the Server's Reply to the Client's Release message may be lost, 1933 e.g., if the AERO routing system has not yet converged. Since the 1934 Client is responsible for reliability, however, it will retry until 1935 it gets an indication that the Release was successful.) 1937 Clients SHOULD NOT move rapidly between Servers in order to avoid 1938 causing unpredictable oscillations in the AERO routing system. Such 1939 oscillations could result in intermittent reachability for the Client 1940 itself, while causing little harm to the network due to routing 1941 protocol dampening. Examples of when a Client might wish to change 1942 to a different Server include a Server that has gone unreachable, 1943 topological movements of significant distance, etc. 1945 3.16. Encapsulation Protocol Version Considerations 1947 A source Client may connect only to an IPvX underlying network, while 1948 the target Client connects only to an IPvY underlying network. In 1949 that case, the target and source Clients have no means for reaching 1950 each other directly (since they connect to underlying networks of 1951 different IP protocol versions) and so must ignore any redirection 1952 messages and continue to send packets via the Server. 1954 3.17. Multicast Considerations 1956 When the underlying network does not support multicast, AERO nodes 1957 map IPv6 link-scoped multicast addresses (including 1958 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 1959 Server. 1961 When the underlying network supports multicast, AERO nodes use the 1962 multicast address mapping specification found in [RFC2529] for IPv4 1963 underlying networks and use a direct multicast mapping for IPv6 1964 underlying networks. (In the latter case, "direct multicast mapping" 1965 means that if the IPv6 multicast destination address of the 1966 encapsulated packet is "M", then the IPv6 multicast destination 1967 address of the encapsulating header is also "M".) 1969 3.18. Operation on AERO Links Without DHCPv6 Services 1971 When Servers on the AERO link do not provide DHCPv6 services, 1972 operation can still be accommodated through administrative 1973 configuration of ACPs on AERO Clients. In that case, administrative 1974 configurations of AERO interface neighbor cache entries on both the 1975 Server and Client are also necessary. However, this may interfere 1976 with the ability for Clients to dynamically change to new Servers, 1977 and can expose the AERO link to misconfigurations unless the 1978 administrative configurations are carefully coordinated. 1980 3.19. Operation on Server-less AERO Links 1982 In some AERO link scenarios, there may be no Servers on the link and/ 1983 or no need for Clients to use a Server as an intermediary trust 1984 anchor. In that case, each Client acts as a Server unto itself to 1985 establish neighbor cache entries by performing direct Client-to- 1986 Client IPv6 ND message exchanges, and some other form of trust basis 1987 must be applied so that each Client can verify that the prospective 1988 neighbor is authorized to use its claimed ACP. 1990 When there is no Server on the link, Clients must arrange to receive 1991 ACPs and publish them via a secure alternate prefix delegation 1992 authority through some means outside the scope of this document. 1994 3.20. Extending AERO Links Through Security Gateways 1996 When an enterprise mobile device moves from a campus LAN connection 1997 to a public Internet link, it must re-enter the enterprise via a 1998 security gateway that has both an physical interface connection to 1999 the Internet and a physical interface connection to the enterprise 2000 internetwork. This most often entails the establishment of a Virtual 2001 Private Network (VPN) link over the public Internet from the mobile 2002 device to the security gateway. During this process, the mobile 2003 device supplies the security gateway with its public Internet address 2004 as the link-layer address for the VPN. The mobile device then acts 2005 as an AERO Client to negotiate with the security gateway to obtain 2006 its ACP. 2008 In order to satisfy this need, the security gateway also operates as 2009 an AERO Server with support for AERO Client proxying. In particular, 2010 when a mobile device (i.e., the Client) connects via the security 2011 gateway (i.e., the Server), the Server provides the Client with an 2012 ACP in a DHCPv6 PD exchange the same as if it were attached to an 2013 enterprise campus access link. The Server then replaces the Client's 2014 link-layer source address with the Server's enterprise-facing link- 2015 layer address in all AERO messages the Client sends toward neighbors 2016 on the AERO link. The AERO messages are then delivered to other 2017 devices on the AERO link as if they were originated by the security 2018 gateway instead of by the AERO Client. In the reverse direction, the 2019 AERO messages sourced by devices within the enterprise network can be 2020 forwarded to the security gateway, which then replaces the link-layer 2021 destination address with the Client's link-layer address and replaces 2022 the link-layer source address with its own (Internet-facing) link- 2023 layer address. 2025 After receiving the ACP, the Client can send IP packets that use an 2026 address taken from the ACP as the network layer source address, the 2027 Client's link-layer address as the link-layer source address, and the 2028 Server's Internet-facing link-layer address as the link-layer 2029 destination address. The Server will then rewrite the link-layer 2030 source address with the Server's own enterprise-facing link-layer 2031 address and rewrite the link-layer destination address with the 2032 target AERO node's link-layer address, and the packets will enter the 2033 enterprise network as though they were sourced from a device located 2034 within the enterprise. In the reverse direction, when a packet 2035 sourced by a node within the enterprise network uses a destination 2036 address from the Client's ACP, the packet will be delivered to the 2037 security gateway which then rewrites the link-layer destination 2038 address to the Client's link-layer address and rewrites the link- 2039 layer source address to the Server's Internet-facing link-layer 2040 address. The Server then delivers the packet across the VPN to the 2041 AERO Client. In this way, the AERO virtual link is essentially 2042 extended *through* the security gateway to the point at which the VPN 2043 link and AERO link are effectively grafted together by the link-layer 2044 address rewriting performed by the security gateway. All AERO 2045 messaging services (including route optimization and mobility 2046 signaling) are therefore extended to the Client. 2048 In order to support this virtual link grafting, the security gateway 2049 (acting as an AERO Server) must keep static neighbor cache entries 2050 for all of its associated Clients located on the public Internet. 2051 The neighbor cache entry is keyed by the AERO Client's AERO address 2052 the same as if the Client were located within the enterprise 2053 internetwork. The neighbor cache is then managed in all ways as 2054 though the Client were an ordinary AERO Client. This includes the 2055 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 2056 Unreachability Detection. 2058 Note that the main difference between a security gateway acting as an 2059 AERO Server and an enterprise-internal AERO Server is that the 2060 security gateway has at least one enterprise-internal physical 2061 interface and at least one public Internet physical interface. 2062 Conversely, the enterprise-internal AERO Server has only enterprise- 2063 internal physical interfaces. For this reason security gateway 2064 proxying is needed to ensure that the public Internet link-layer 2065 addressing space is kept separate from the enterprise-internal link- 2066 layer addressing space. This is afforded through a natural extension 2067 of the security association caching already performed for each VPN 2068 client by the security gateway. 2070 4. Implementation Status 2072 An application-layer implementation is in progress. 2074 5. IANA Considerations 2076 IANA is instructed to assign a new 2-octet Hardware Type number 2077 "TBD1" for AERO in the "arp-parameters" registry per Section 2 of 2078 [RFC5494]. The number is assigned from the 2-octet Unassigned range 2079 with Hardware Type "AERO" and with this document as the reference. 2081 IANA is instructed to assign a 4-octet Enterprise Number "TBD2" for 2082 AERO in the "enterprise-numbers" registry per [RFC3315]. 2084 6. Security Considerations 2086 AERO link security considerations are the same as for standard IPv6 2087 Neighbor Discovery [RFC4861] except that AERO improves on some 2088 aspects. In particular, AERO uses a trust basis between Clients and 2089 Servers, where the Clients only engage in the AERO mechanism when it 2090 is facilitated by a trust anchor. AERO nodes SHOULD also use DHCPv6 2091 securing services (e.g., DHCPv6 authentication, 2092 [I-D.ietf-dhc-sedhcpv6], etc.) for Client authentication and network 2093 admission control. 2095 AERO Redirect, Predirect and unsolicited NA messages SHOULD include a 2096 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2097 can use to verify the message time of origin. AERO Predirect, NS and 2098 RS messages SHOULD include a Nonce option (see Section 5.3 of 2099 [RFC3971]) that recipients echo back in corresponding responses. 2101 AERO links must be protected against link-layer address spoofing 2102 attacks in which an attacker on the link pretends to be a trusted 2103 neighbor. Links that provide link-layer securing mechanisms (e.g., 2104 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2105 enterprise network wired LANs) provide a first line of defense that 2106 is often sufficient. In other instances, additional securing 2107 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 2108 [RFC4301] or TLS [RFC5246] may be necessary. 2110 AERO Clients MUST ensure that their connectivity is not used by 2111 unauthorized nodes on their EUNs to gain access to a protected 2112 network, i.e., AERO Clients that act as routers MUST NOT provide 2113 routing services for unauthorized nodes. (This concern is no 2114 different than for ordinary hosts that receive an IP address 2115 delegation but then "share" the address with unauthorized nodes via a 2116 NAT function.) 2118 On some AERO links, establishment and maintenance of a direct path 2119 between neighbors requires secured coordination such as through the 2120 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 2121 security association. 2123 7. Acknowledgements 2125 Discussions both on IETF lists and in private exchanges helped shape 2126 some of the concepts in this work. Individuals who contributed 2127 insights include Mikael Abrahamsson, Mark Andrews, Fred Baker, 2128 Stewart Bryant, Brian Carpenter, Wojciech Dec, Ralph Droms, Brian 2129 Haberman, Joel Halpern, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted 2130 Lemon, Joe Touch and Bernie Volz. Members of the IESG also provided 2131 valuable input during their review process that greatly improved the 2132 document. Special thanks go to Stewart Bryant, Joel Halpern and 2133 Brian Haberman for their shepherding guidance. 2135 This work has further been encouraged and supported by Boeing 2136 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 2137 Balaguruna Chidambaram, Claudiu Danilov, Wen Fang, Anthony Gregory, 2138 Jeff Holland, Ed King, Gen MacLean, Kent Shuey, Brian Skeen, Mike 2139 Slane, Julie Wulff, Yueli Yang, and other members of the BR&T and BIT 2140 mobile networking teams. 2142 Earlier works on NBMA tunneling approaches are found in 2143 [RFC2529][RFC5214][RFC5569]. 2145 8. References 2147 8.1. Normative References 2149 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2150 August 1980. 2152 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2153 1981. 2155 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2156 RFC 792, September 1981. 2158 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2159 October 1996. 2161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2162 Requirement Levels", BCP 14, RFC 2119, March 1997. 2164 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2165 (IPv6) Specification", RFC 2460, December 1998. 2167 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2168 IPv6 Specification", RFC 2473, December 1998. 2170 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2171 and M. Carney, "Dynamic Host Configuration Protocol for 2172 IPv6 (DHCPv6)", RFC 3315, July 2003. 2174 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2175 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2176 December 2003. 2178 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2179 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2181 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2182 for IPv6 Hosts and Routers", RFC 4213, October 2005. 2184 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2185 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2186 September 2007. 2188 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2189 Address Autoconfiguration", RFC 4862, September 2007. 2191 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2192 Requirements", RFC 6434, December 2011. 2194 8.2. Informative References 2196 [I-D.ietf-dhc-sedhcpv6] 2197 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 2198 DHCPv6 with Public Key", draft-ietf-dhc-sedhcpv6-03 (work 2199 in progress), June 2014. 2201 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 2202 RFC 879, November 1983. 2204 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 2205 1812, June 1995. 2207 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2208 selection, and registration of an Autonomous System (AS)", 2209 BCP 6, RFC 1930, March 1996. 2211 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2212 Domains without Explicit Tunnels", RFC 2529, March 1999. 2214 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2215 RFC 2675, August 1999. 2217 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2218 2923, September 2000. 2220 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2221 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2222 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2223 RFC 3819, July 2004. 2225 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 2226 Protocol 4 (BGP-4)", RFC 4271, January 2006. 2228 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2229 Architecture", RFC 4291, February 2006. 2231 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2232 Internet Protocol", RFC 4301, December 2005. 2234 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 2235 Message Protocol (ICMPv6) for the Internet Protocol 2236 Version 6 (IPv6) Specification", RFC 4443, March 2006. 2238 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2239 Discovery", RFC 4821, March 2007. 2241 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2242 Errors at High Data Rates", RFC 4963, July 2007. 2244 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 2245 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 2246 September 2007. 2248 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2249 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2250 March 2008. 2252 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2253 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2255 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 2256 for the Address Resolution Protocol (ARP)", RFC 5494, 2257 April 2009. 2259 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2260 Route Optimization Requirements for Operational Use in 2261 Aeronautics and Space Exploration Mobile Networks", RFC 2262 5522, October 2009. 2264 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2265 Infrastructures (6rd)", RFC 5569, January 2010. 2267 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2268 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 2269 5996, September 2010. 2271 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2272 NAT64: Network Address and Protocol Translation from IPv6 2273 Clients to IPv4 Servers", RFC 6146, April 2011. 2275 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2276 Troan, "Basic Requirements for IPv6 Customer Edge 2277 Routers", RFC 6204, April 2011. 2279 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2280 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2281 2011. 2283 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2284 for Equal Cost Multipath Routing and Link Aggregation in 2285 Tunnels", RFC 6438, November 2011. 2287 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2288 RFC 6691, July 2012. 2290 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 2291 (AERO)", RFC 6706, August 2012. 2293 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2294 RFC 6864, February 2013. 2296 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2297 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 2299 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2300 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2301 RFC 6936, April 2013. 2303 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2304 Address Option in DHCPv6", RFC 6939, May 2013. 2306 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2307 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 2309 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2310 Address Selection Policy Using DHCPv6", RFC 7078, January 2311 2014. 2313 Author's Address 2315 Fred L. Templin (editor) 2316 Boeing Research & Technology 2317 P.O. Box 3707 2318 Seattle, WA 98124 2319 USA 2321 Email: fltemplin@acm.org