idnits 2.17.1 draft-templin-aerolink-30.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 (July 21, 2014) is 3566 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 1684, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1690, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1699, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1723, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 1726, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 1731, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 1790, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1802, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 1805, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 1821, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 1824, 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) -- 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) July 21, 2014 5 Intended status: Standards Track 6 Expires: January 22, 2015 8 Transmission of IP Packets over AERO Links 9 draft-templin-aerolink-30.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 IPv6 ND messaging is used in the 24 control plane, both IPv4 and IPv6 are supported in the data plane. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 22, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 63 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 5 64 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 7 65 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 8 66 3.4. AERO Interface Characteristics . . . . . . . . . . . . . 9 67 3.4.1. Coordination of Multiple Underlying Interfaces . . . 11 68 3.5. AERO Interface Neighbor Cache Maintenace . . . . . . . . 12 69 3.6. AERO Interface Sending Algorithm . . . . . . . . . . . . 13 70 3.7. AERO Interface Encapsulation, Re-encapsulation and 71 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 15 72 3.8. AERO Interface Data Origin Authentication . . . . . . . . 16 73 3.9. AERO Interface MTU Considerations . . . . . . . . . . . . 16 74 3.10. AERO Router Discovery, Prefix Delegation and Address 75 Configuration . . . . . . . . . . . . . . . . . . . . . . 18 76 3.10.1. AERO Client Behavior . . . . . . . . . . . . . . . . 18 77 3.10.2. AERO Server Behavior . . . . . . . . . . . . . . . . 20 78 3.10.3. DHCPv6 Server Behavior . . . . . . . . . . . . . . . 21 79 3.11. AERO Relay/Server Routing System . . . . . . . . . . . . 22 80 3.12. AERO Redirection . . . . . . . . . . . . . . . . . . . . 23 81 3.12.1. Reference Operational Scenario . . . . . . . . . . . 23 82 3.12.2. Concept of Operations . . . . . . . . . . . . . . . 25 83 3.12.3. Message Format . . . . . . . . . . . . . . . . . . . 25 84 3.12.4. Sending Predirects . . . . . . . . . . . . . . . . . 26 85 3.12.5. Re-encapsulating and Relaying Predirects . . . . . . 27 86 3.12.6. Processing Predirects and Sending Redirects . . . . 28 87 3.12.7. Re-encapsulating and Relaying Redirects . . . . . . 30 88 3.12.8. Processing Redirects . . . . . . . . . . . . . . . . 30 89 3.12.9. Server-Oriented Redirection . . . . . . . . . . . . 31 90 3.13. Neighbor Unreachability Detection (NUD) . . . . . . . . . 31 91 3.14. Mobility Management . . . . . . . . . . . . . . . . . . . 32 92 3.14.1. Announcing Link-Layer Address Changes . . . . . . . 32 93 3.14.2. Moving to a New Server . . . . . . . . . . . . . . . 34 94 3.15. Encapsulation Protocol Version Considerations . . . . . . 34 95 3.16. Multicast Considerations . . . . . . . . . . . . . . . . 35 96 3.17. Operation on AERO Links Without DHCPv6 Services . . . . . 35 97 3.18. Operation on Server-less AERO Links . . . . . . . . . . . 35 98 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 35 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 104 8.2. Informative References . . . . . . . . . . . . . . . . . 38 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 107 1. Introduction 109 This document specifies the operation of IP over tunnel virtual links 110 using Asymmetric Extended Route Optimization (AERO). The AERO link 111 can be used for tunneling to neighboring nodes over either IPv6 or 112 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 113 equivalent links for tunneling. Nodes attached to AERO links can 114 exchange packets via trusted intermediate routers that provide 115 forwarding services to reach off-link destinations and redirection 116 services for route optimization that addresses the requirements 117 outlined in [RFC5522]. 119 AERO provides an IPv6 link-local address format known as the AERO 120 address that supports operation of the IPv6 Neighbor Discovery (ND) 121 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 122 control and provisioning are supported by the Dynamic Host 123 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and node mobility 124 is naturally supported through dynamic neighbor cache updates. 125 Although IPv6 ND message signalling is used in the control plane, 126 either of IPv4 and IPv6 can be used in the data plane. The remainder 127 of this document presents the AERO specification. 129 2. Terminology 131 The terminology in the normative references applies; the following 132 terms are defined within the scope of this document: 134 AERO link 135 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 136 configured over a node's attached IPv6 and/or IPv4 networks. All 137 nodes on the AERO link appear as single-hop neighbors from the 138 perspective of the virtual overlay. 140 AERO interface 141 a node's attachment to an AERO link. 143 AERO address 144 an IPv6 link-local address constructed as specified in Section 3.2 145 and applied to a Client's AERO interface. 147 AERO node 148 a node that is connected to an AERO link and that participates in 149 IPv6 ND over the link. 151 AERO Client ("Client") 152 a node that applies an AERO address to an AERO interface and 153 receives an IP prefix delegation. 155 AERO Server ("Server") 156 a node that configures an AERO interface to provide default 157 forwarding services for AERO Clients. The Server applies the IPv6 158 link-local subnet router anycast address (fe80::) to the AERO 159 interface and also applies an administratively assigned IPv6 link- 160 local unicast address used for operation of the IPv6 ND protocol. 162 AERO Relay ("Relay") 163 a node that configures an AERO interface to relay IP packets 164 between nodes on the same AERO link and/or forward IP packets 165 between the AERO link and the native Internetwork. The Relay 166 applies an administratively assigned IPv6 link-local unicast 167 address to the AERO interface the same as for a Server. 169 ingress tunnel endpoint (ITE) 170 an AERO interface endpoint that injects tunneled packets into an 171 AERO link. 173 egress tunnel endpoint (ETE) 174 an AERO interface endpoint that receives tunneled packets from an 175 AERO link. 177 underlying network 178 a connected IPv6 or IPv4 network routing region over which the 179 tunnel virtual overlay is configured. 181 underlying interface 182 an AERO node's interface point of attachment to an underlying 183 network. 185 link-layer address 186 an IP address assigned to an AERO node's underlying interface. 187 When UDP encapsulation is used, the UDP port number is also 188 considered as part of the link-layer address. Link-layer 189 addresses are used as the encapsulation header source and 190 destination addresses. 192 network layer address 193 the source or destination address of the encapsulated IP packet. 195 end user network (EUN) 196 an internal virtual or external edge IP network that an AERO 197 Client connects to the rest of the network via the AERO interface. 199 AERO Service Prefix (ASP) 200 an IP prefix associated with the AERO link and from which AERO 201 Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 202 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 204 AERO Client Prefix (ACP) 205 a more-specific IP prefix taken from an ASP and delegated to a 206 Client. 208 Throughout the document, the simple terms "Client", "Server" and 209 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 210 respectively. Capitalization is used to distinguish these terms from 211 DHCPv6 client/server/relay. This is an important distinction to 212 avoid ambiguity, e.g., an AERO Server also acts as a DHCPv6 relay, an 213 AERO Relay may also act as a DHCPv6 server, etc. 215 Throughout the document, it is said that an address is "applied" to 216 an AERO interface since the address need not always be "assigned" to 217 the interface in the traditional sense. However, the address must at 218 least be bound to the interface in some fashion for operation of the 219 IPv6 ND protocol. 221 The terminology of [RFC4861] (including the names of node variables 222 and protocol constants) applies to this document. Also throughout 223 the document, the term "IP" is used to generically refer to either 224 Internet Protocol version (i.e., IPv4 or IPv6). 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 3. Asymmetric Extended Route Optimization (AERO) 232 The following sections specify the operation of IP over Asymmetric 233 Extended Route Optimization (AERO) links: 235 3.1. AERO Link Reference Model 236 .-(::::::::) 237 .-(:::: IP ::::)-. +-----------+ 238 (:: Internetwork ::) | DHCPv6 | 239 `-(::::::::::::)-' | Server X | 240 `-(::::::)-' +-----------+ 241 | 242 +--------------+ +------+-------+ +--------------+ 243 |AERO Server S1| | AERO Relay R | |AERO Server S2| 244 | (default->R) | |(C->S1; D->S2)| | (default->R) | 245 | Nbr: A | +-------+------+ | Nbr: B | 246 +-------+------+ | +------+-------+ 247 | | | 248 X---+---+-------------------+------------------+---+---X 249 | AERO Link | 250 +-----+--------+ +--------+-----+ 251 |AERO Client A | |AERO Client B | 252 | default->S1 | | default->S2 | 253 +--------------+ +--------------+ 254 .-. .-. 255 ,-( _)-. ,-( _)-. 256 .-(_ IP )-. .-(_ IP )-. 257 (__ EUN ) (__ EUN ) 258 `-(______)-' `-(______)-' 259 | | 260 +--------+ +--------+ 261 | Host C | | Host D | 262 +--------+ +--------+ 264 Figure 1: AERO Link Reference Model 266 Figure 1 above presents the AERO link reference model. In this 267 model: 269 o DHCPv6 Server X is the prefix delegation authority for the 270 delegation of ACPs taken from the AERO link's ASPs 272 o Relay R associates with Servers S1 and S2, and connects the link 273 to the rest of the IP Internetwork 275 o Servers S1 and S2 associate with Relay R and also act as default 276 routers for their associated Clients A and B 278 o Clients A and B associate with Servers S1 and S2, respectively and 279 also act as default routers for their associated EUNs 281 o Hosts C and D attach to the EUNs served by Clients A and B, 282 respectively 284 In this model, there may be many additional Relays, Servers and 285 Clients. Each Sever peers with each Relay in a dynamic routing 286 protocol session to advertise its list of associated Clients. Each 287 Relay advertises the ASPs for the AERO link into the native IP 288 Internetwork and serves as a gateway between the AERO link and the 289 Internetwork. Clients may associate with only a single Server or 290 with multiple Server, e.g., for fault tolerance and/or load 291 balancing. 293 3.2. AERO Node Types 295 The DHCPv6 server is authoritative for the management of the AERO 296 link's AERO Service Prefixes (ASPs). The DHCPv6 server is therefore 297 critical infrastructure for the AERO link, but need not otherwise 298 participate as an AERO node. AERO Servers communicate with the 299 DHCPv6 server either via the AERO link itself or via a different IPv6 300 link. 302 AERO Relays relay packets between nodes connected to the same AERO 303 link and also forward packets between the AERO link and the native 304 Internetwork. The relaying process entails re-encapsulation of IP 305 packets that were received from a first AERO node and are to be 306 forwarded without modification to a second AERO node. AERO Relays 307 present the AERO link to the native Internetwork as a set of one or 308 more ASPs. 310 AERO Servers provide default routing services to AERO Clients. AERO 311 Servers configure a DHCPv6 relay function and facilitate Prefix 312 Delegation (PD) exchanges between AERO Clients and the DHCPv6 server. 313 Each delegated prefix becomes an AERO Client Prefix (ACP) taken from 314 an ASP. 316 AERO Clients act as requesting routers to receive ACPs through DHCPv6 317 PD exchanges via AERO Servers over the AERO link. (Each Client MAY 318 associate with a single Server or with multiple Servers.) Each IPv6 319 AERO Client receives at least a /64 IPv6 ACP, and may receive even 320 shorter prefixes. Similarly, each IPv4 AERO Client receives at least 321 a /32 IPv4 ACP (i.e., a singleton IPv4 address), and may receive even 322 shorter prefixes. 324 AERO Clients that act as routers sub-delegate portions of their ACPs 325 to links on EUNs. End system applications on AERO Clients that act 326 as routers bind to EUN interfaces (i.e., and not the AERO interface). 328 AERO Clients that act as ordinary hosts assign one or more IP 329 addresses from their ACPs to the AERO interface but DO NOT assign the 330 ACP itself to the AERO interface. Instead, the Client assigns the 331 ACP to a "black hole" route so that unused portions of the prefix are 332 nullified. End system applications on AERO Clients that act as hosts 333 bind directly to the AERO interface. 335 3.3. AERO Addresses 337 An AERO address is an IPv6 link-local address with an embedded ACP 338 and applied to a Client's AERO interface. The AERO address is formed 339 as follows: 341 fe80::[ACP] 343 For IPv6, the AERO address begins with the prefix fe80::/64 and 344 includes in its interface identifier the base prefix taken from the 345 Client's IPv6 ACP. The base prefix is determined by masking the ACP 346 with the prefix length. For example, if the AERO Client receives the 347 IPv6 ACP: 349 2001:db8:1000:2000::/56 351 it constructs its AERO address as: 353 fe80::2001:db8:1000:2000 355 For IPv4, the AERO address is formed as an IPv4-mapped IPv6 address 356 [RFC4291] that includes the base prefix taken from the Client's IPv4 357 ACP. For example, if the AERO Client receives the IPv4 ACP: 359 192.0.2.32/28 361 it constructs its AERO address as: 363 fe80::FFFF:192.0.2.32 365 The AERO address remains stable as the Client moves between 366 topological locations, i.e., even if its link-layer addresses change. 368 NOTE: In some cases, prospective neighbors may not have a priori 369 knowledge of the Client's ACP length and may therefore send initial 370 IPv6 ND messages with an AERO destination address that matches the 371 ACP but does not correspond to the base prefix. In that case, the 372 Client MUST accept the address as equivalent to the base address, but 373 then use the base address as the source address of any IPv6 ND 374 message replies. For example, if the Client receives the IPv6 ACP 375 2001:db8:1000:2000::/56 then subsequently receives an IPv6 ND message 376 with destination address fe80::2001:db8:1000:2001, it accepts the 377 message but uses fe80::2001:db8:1000:2000 as the source address of 378 any IPv6 ND replies. 380 3.4. AERO Interface Characteristics 382 AERO interfaces use IP-in-IPv6 encapsulation [RFC2473] to exchange 383 tunneled packets with AERO neighbors attached to an underlying IPv6 384 network, and use IP-in-IPv4 encapsulation [RFC2003][RFC4213] to 385 exchange tunneled packets with AERO neighbors attached to an 386 underlying IPv4 network. AERO interfaces can also coordinate secured 387 tunnel types such as IPsec [RFC4301] or TLS [RFC5246]. When Network 388 Address Translator (NAT) traversal and/or filtering middlebox 389 traversal may be necessary, a UDP header is further inserted 390 immediately above the IP encapsulation header. 392 AERO interfaces maintain a neighbor cache, and AERO Clients and 393 Servers use an adaptation of standard unicast IPv6 ND messaging. 394 AERO interfaces use unicast Neighbor Solicitation (NS), Neighbor 395 Advertisement (NA), Router Solicitation (RS) and Router Advertisement 396 (RA) messages the same as for any IPv6 link. AERO interfaces use two 397 redirection message types -- the first known as a Predirect message 398 and the second being the standard Redirect message (see Section 3.9). 399 AERO links further use link-local-only addressing; hence, AERO nodes 400 ignore any Prefix Information Options (PIOs) they may receive in RA 401 messages. 403 AERO interface Redirect, Predirect and unsolicited NA messages 404 include Target Link-Layer Address Options (TLLAOs) formatted as shown 405 in Figure 2: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type = 2 | Length = 3 | Reserved | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Link ID | Preference | UDP Port Number (or 0) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 +-- --+ 416 | | 417 +-- IP Address --+ 418 | | 419 +-- --+ 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 2: AERO Target Link-Layer Address Option (TLLAO) Format 425 In this format, Link ID is an integer value between 0 and 255 426 corresponding to an underlying interface of the target node, and 427 Preference is an integer value between 0 and 255 indicating the 428 node's preference for this underlying interface, with 0 being highest 429 preference and 255 being lowest. UDP Port Number and IP Address are 430 set to the addresses used by the target node when it sends 431 encapsulated packets over the underlying interface. When no UDP 432 encapsulation is used, UDP Port Number is set to 0. When the 433 encapsulation IP address family is IPv4, IP Address is formed as an 434 IPv4-mapped IPv6 address [RFC4291]. 436 When a Relay enables an AERO interface, it applies an 437 administratively assigned link-local address fe80::ID to the 438 interface for communicating with Servers on the link. Each fe80::ID 439 address MUST be unique among all Relays and Servers on the link, and 440 MUST NOT collide with any potential AERO addresses, e.g., the 441 addresses could be assigned as fe80::1, fe80::2, fe80::3, etc. The 442 Relay also maintains an IP forwarding table entry for each Client- 443 Server association and maintains a neighbor cache entry for each 444 Server on the link. Relays do not require the use of IPv6 ND 445 messaging for reachability determination since Relays and Servers 446 engage in a dynamic routing protocol over the AERO interface. At a 447 minimum, however, Relays respond to NS messages by returning an NA. 449 When a Server enables an AERO interface, it applies the address 450 fe80:: to the interface as a link-local Subnet Router Anycast 451 address, and also applies an administratively assigned link-local 452 address fe80::ID to support the operation of the IPv6 ND protocol and 453 to communicate with Relays on the link. The Server maintains a 454 neighbor cache entry for each Relay on the link, and also creates 455 per-Client neighbor cache entries whenever it discovers a new Client. 456 At a minimum, when the Server receives an NS/RS messages on the AERO 457 interface it returns an NA/RA message. When the Server receives an 458 NS/NA, it also update timers in existing neighbor cache entries but 459 does not create new neighbor cache entries nor update cached link- 460 layer addresses. Servers also engage in a dynamic routing protocol 461 with all Relays on the link. Finally, the Server provides a simple 462 conduit between Clients and Relays, or between Clients and other 463 Clients. Therefore, packets enter the Server's AERO interface from 464 the link layer and are forwarded back out the link layer without ever 465 leaving the AERO interface and therefore without ever disturbing the 466 network layer. 468 When a Client enables an AERO interface, it invokes prefix delegation 469 to receive an ACP. Next, it applies the corresponding AERO address 470 to the AERO interface, i.e., the prefix delegation bootstraps the 471 provisioning of a unique link-local address. The Client maintains a 472 neighbor cache entry for each of its Servers and each of its active 473 peer Clients. When the Client receives Redirect/Predirect messages 474 on the AERO interface it updates or creates neighbor cache entries, 475 including link-layer address information. Unsolicited NA messages 476 update the cached link-layer address for the neighbor Client (e.g., 477 following a link-layer address change due to node mobility) but do 478 not create new neighbor cache entries. RA messages as well as NS/NA 479 messages used for Neighbor Unreachability Detection (NUD) update 480 timers in existing neighbor cache entires but do not update link- 481 layer addresses nor create new neighbor cache entries. Redirect, 482 Predirect and unsolicited NA messages SHOULD include a Timestamp 483 option (see Section 5.3 of [RFC3971]) that other AERO nodes can use 484 to verify the message time of origin. Predirect, NS and RS messages 485 SHOULD include a Nonce option (see Section 5.3 of [RFC3971]) that 486 recipients echo back in corresponding responses. Finally, the Client 487 need not maintain any IP forwarding table entries for neighboring 488 Clients. Instead, it can set a single "route-to-interface" default 489 route in the IP forwarding table pointing to the AERO interface, and 490 all forwarding decisions can be made within the AERO interface based 491 on neighbor cache entries. 493 3.4.1. Coordination of Multiple Underlying Interfaces 495 AERO interfaces may be configured over multiple underlying 496 interfaces. For example, common mobile handheld devices have both 497 wireless local area network ("WLAN") and cellular wireless links. 498 These links are typically used "one at a time" with low-cost WLAN 499 preferred and highly-available cellular wireless as a standby. In a 500 more complex example, aircraft frequently have many wireless data 501 link types (e.g. satellite-based, terrestrial, air-to-air 502 directional, etc.) with diverse performance and cost properties. 504 If a Client's multiple underlying interfaces are used "one at a time" 505 (i.e., all other interfaces are in standby mode while one interface 506 is active), then Redirect, Predirect and unsolicited NA messages 507 include only a single TLLAO with Link ID set to a constant value 508 (e.g., 0). 510 If the Client has multiple active underlying interfaces, then from 511 the perspective of IPv6 ND it would appear to have a single link- 512 local address with multiple link-layer addresses. In that case, 513 Redirect, Predirect and unsolicited NA messages MAY include multiple 514 TLLAOs -- each with a different Link ID that corresponds to a 515 specific underlying interface of the Client. Further details on 516 coordination of multiple active underlying interfaces are outside the 517 scope of this specification. 519 3.5. AERO Interface Neighbor Cache Maintenace 521 Each AERO interface maintains a conceptual neighbor cache that 522 includes an entry for each neighbor it communicates with on the AERO 523 link, the same as for any IPv6 interface [RFC4861]. Neighbor cache 524 entries are created and maintained as follows: 526 AERO Relays maintain a permanent neighbor cache entry for each Server 527 on the link, and AERO Servers maintain a permanent neighbor cache 528 entry for each Relay on the link. AERO Clients maintain a neighbor 529 cache entry for each of their associated Servers, and AERO Servers 530 maintain a neighbor cache for each of their associated Clients with a 531 lifetime based on the DHCPv6 lease lifetime. AERO Clients maintain 532 neighbor cache entries for each of their active correspondent Clients 533 with lifetimes based on IPv6 ND messaging constants. 535 When an AERO Server relays a DHCPv6 Reply message to an AERO Client, 536 it creates or updates a neighbor cache entry for the Client based on 537 the AERO address corresponding to the Client's ACP as the network- 538 layer address and with the Client's encapsulation IP address and UDP 539 port number as the link-layer address. The Server also records the 540 ACP's lease lifetime and prefix length in the neighbor cache entry. 542 When an AERO Client receives a DHCPv6 Reply message from an AERO 543 Server, it creates or updates a neighbor cache entry for the Server 544 based on the Reply message link-local source address as the network- 545 layer address, the lease lifetime as the neighbor cache entry 546 lifetime, and the encapsulation IP source address and UDP source port 547 number as the link-layer address. 549 When an AERO Client receives a valid Predirect message it creates or 550 updates a neighbor cache entry for the Predirect target network-layer 551 and link-layer addresses plus prefix length. The node then sets an 552 "AcceptTime" variable for the neighbor and uses this value to 553 determine whether packets received from the predirected neighbor can 554 be accepted. 556 When an AERO Client receives a valid Redirect message it creates or 557 updates a neighbor cache entry for the Redirect target network-layer 558 and link-layer addresses plus prefix length. The node then sets a 559 "ForwardTime" variable for the neighbor and uses this value to 560 determine whether packets can be sent directly to the redirected 561 neighbor. The node also maintains a "Retry" variable to limit the 562 number of keepalives sent when a neighbor may have gone unreachable. 564 When an AERO Client receives a valid NS message corresponding to a 565 neighbor cache entry for another Client, it (re)sets AcceptTime for 566 the neighbor to ACCEPT_TIME. 568 When an AERO Client receives a valid solicited NA message 569 corresponding to a neighbor cache entry for another Client, it 570 (re)sets ForwardTime for the neighbor to FORWARD_TIME and sets Retry 571 to MAX_RETRY. (When an AERO Client receives a valid unsolicited NA 572 message, it updates the neighbor's link-layer address but DOES NOT 573 reset ForwardTime or Retries.) 575 It is RECOMMENDED that FORWARD_TIME be set to the default constant 576 value 30 seconds to match the default REACHABLE_TIME value specified 577 for IPv6 ND [RFC4861]. 579 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 580 value 40 seconds to allow a 10 second window so that the AERO 581 redirection procedure can converge before AcceptTime decrements below 582 FORWARD_TIME. 584 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 585 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 587 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 588 administratively set, if necessary, to better match the AERO link's 589 performance characteristics; however, if different values are chosen, 590 all nodes on the link MUST consistently configure the same values. 591 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 592 sufficiently longer than FORWARD_TIME to allow the AERO redirection 593 procedure to converge. 595 For AERO Client<->Server neighbor cache entries, AcceptTime and 596 ForwardTime are set based on the DHCPv6 lease lifetime and may be 597 modified based on the Router Lifetime advertised in the Server's RA 598 messages. 600 3.6. AERO Interface Sending Algorithm 602 When an IP packet enters a Client's AERO interface from the network 603 layer, the Client searches its neighbor cache for an entry with an 604 AERO address that matches the packet's destination address. If there 605 is a match, the Client uses the link-layer address in the neighbor 606 cache entry as the link-layer address for encapsulation then admits 607 the packet into the tunnel. If there is no match, the Client instead 608 uses the link-layer address of a neighboring Server as the link-layer 609 address for encapsulation. (Note that the Client caches the ASPs for 610 the AERO link and can thus search the neighbor cache only for 611 destination addresses that are covered by an ASP.) 613 When an IP packet enters a Server's AERO interface from the link 614 layer, the Server searches for a neighbor cache match the same as for 615 a Client. If there is a match, the Server uses the link-layer 616 address in the neighbor cache entry as the link-layer address for re- 617 encapsulation. If there is no match, the Server instead uses the 618 link-layer address of a neighboring Relay as the link-layer address 619 for encapsulation. Servers also relay Predirect, Redirect and 620 unsolicited Neighbor Advertisement messages received from a Client 621 and with an AERO destination address. If the AERO destination 622 address is the address of a neighbor, the Server changes the link- 623 layer source address to its own address, changes the link-layer 624 destination address to the address of the neighbor and forwards the 625 message to the neighbor. If the AERO destination address is not a 626 neighbor, the Server instead forwards the message to a Relay. When 627 an AERO Relay forwards either a data packet or an IPv6 ND message to 628 an AERO Server, the Server MUST NOT forward the packet back to the 629 same or a different Relay. 631 When an IP packet enters a Relay's AERO interface from the network 632 layer, the Relay searches its IP forwarding table for an entry that 633 is covered by an ASP and also matches the destination. If there is a 634 match, the Relay uses the link-layer address in the neighbor cache 635 entry for the next-hop Server as the link-layer address for 636 encapsulation. When an IP packet enters a Relay's AERO interface 637 from the link-layer, if the destination is not covered by an ASP the 638 Relay forwards the packet to another IP link as indicated by the IP 639 forwarding table. If the destination is covered by an ASP, and there 640 is a more-specific forwarding table entry that matches the 641 destination, the Relay uses the link-layer address in the neighbor 642 cache entry for the next-hop Server as the link-layer address for 643 encapsulation. If there is no more-specific entry, the Relay instead 644 drops the packet. Relays also relay Predirect, Redirect and 645 unsolicited Neighbor Advertisement messages by searching for an IP 646 forwarding table entry that matches the message's AERO destination 647 address. If there is a match, the Relay proxies the packet in the 648 same manner as described for Servers above; otherwise, the Relay 649 drops the packet. When an AERO Server forwards either a data packet 650 or an IPv6 ND message to an AERO Relay, the Relay MUST NOT forward 651 the packet back to the same Server. 653 Note that in the above this tunnel exit determination is often based 654 on consulting the neighbor cache instead of the IP forwarding table. 655 IP forwarding is therefore linked to IPv6 ND via the AERO address. 657 When an AERO node forwards a packet back out the same AERO interface 658 the packet arrived on, the node MUST NOT decrement the network layer 659 TTL/Hop-count. 661 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 663 AERO interfaces encapsulate IP packets according to whether they are 664 entering the AERO interface from the network layer or if they are 665 being forwarded out the same AERO interface that they arrived on. 666 This latter form of encapsulation is known as "re-encapsulation". 668 AERO interfaces encapsulate packets per the specifications in 669 [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246] (etc.) except that the 670 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 671 and "Congestion Experienced" values in the packet's IP header into 672 the corresponding fields in the encapsulation header. For packets 673 undergoing re-encapsulation, the AERO interface instead copies the 674 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 675 Experienced" values in the original encapsulation header into the 676 corresponding fields in the new encapsulation header (i.e., the 677 values are transferred between encapsulation headers and *not* copied 678 from the encapsulated packet's network-layer header). 680 When AERO UDP encapsulation is used, the AERO interface encapsulates 681 the packet per the specifications in [RFC2003][RFC2473][RFC4213] 682 except that it inserts a UDP header between the encapsulation header 683 and the packet's IP header. The AERO interface sets the UDP source 684 port to a constant value that it will use in each successive packet 685 it sends, sets the UDP checksum field to zero (see: 686 [RFC6935][RFC6936]) and sets the UDP length field to the length of 687 the IP packet plus 8 bytes for the UDP header itself. For packets 688 sent via a Server, the AERO interface sets the UDP destination port 689 to 8060 (i.e., the IANA-registered port number for AERO) when AERO- 690 only encapsulation is used. For packets sent to a neighboring 691 Client, the AERO interface sets the UDP destination port to the port 692 value stored in the neighbor cache entry for this neighbor. 694 The AERO interface next sets the IP protocol number in the 695 encapsulation header to the appropriate value for the first protocol 696 layer within the encapsulation (e.g., IPv4, IPv6, UDP, IPsec, etc.). 697 When IPv6 is used as the encapsulation protocol, the interface then 698 sets the flow label value in the encapsulation header the same as 699 described in [RFC6438]. When IPv4 is used as the encapsulation 700 protocol, the AERO interface sets the DF bit as discussed in 701 Section 3.7. 703 AERO interfaces decapsulate packets destined either to the node 704 itself or to a destination reached via an interface other than the 705 AERO interface the packet was received on. When AERO UDP 706 encapsulation is used (i.e., when a UDP header with destination port 707 8060 is present) the interface examines the first octet of the 708 encapsulated packet. If the most significant four bits of the first 709 octet encode the value '0110' (i.e., the version number value for 710 IPv6) or the value '0100' (i.e., the version number value for IPv4), 711 the packet is accepted and the encapsulating UDP header is discarded; 712 otherwise, the packet is discarded. 714 Further decapsulation then proceeds according to the appropriate 715 tunnel type [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246] (etc.). 717 3.8. AERO Interface Data Origin Authentication 719 AERO nodes employ simple data origin authentication procedures for 720 encapsulated packets they receive from other nodes. In particular, 721 AERO Clients accept encapsulated packets with a link-layer source 722 address belonging to one of their current AERO Servers, and AERO 723 Clients and Servers accept encapsulated packets with a link-layer 724 source address that is correct for the network-layer source address. 726 The AERO node considers the link-layer source address correct for the 727 network-layer source address if there is an AERO interface neighbor 728 cache entry with an AERO address that matches the packet's network- 729 layer source address prefix, with a link-layer address that matches 730 the packet's link-layer source address, and AcceptTime is non-zero. 732 An AERO Server also accepts packets with a link-layer source address 733 that matches one of its associated Relays, and an AERO Relay accepts 734 packets with a source address that matches one of its associated 735 Servers. 737 Note that this simple data origin authentication only applies to 738 environments in which link-layer addresses cannot be spoofed. 739 Additional security mitigations may be necessary in other 740 environments. 742 3.9. AERO Interface MTU Considerations 744 The AERO link Maximum Transmission Unit (MTU) is 64KB minus the 745 encapsulation overhead for IPv4 as the link-layer [RFC0791] and 4GB 746 minus the encapsulation overhead for IPv6 as the link layer 747 [RFC2675]. This is the most that IPv4 and IPv6 (respectively) can 748 convey within the constraints of protocol constants, but actual sizes 749 available for tunneling will frequently be much smaller. 751 The base tunneling specifications for IPv4 and IPv6 typically set a 752 static MTU on the tunnel interface to 1500 bytes minus the 753 encapsulation overhead or smaller still if the tunnel is likely to 754 incur additional encapsulations on the path. This can result in path 755 MTU related black holes when packets that are too large to be 756 accommodated over the AERO link are dropped, but the resulting ICMP 757 Packet Too Big (PTB) messages are lost on the return path. As a 758 result, AERO nodes use the following MTU mitigations to accommodate 759 larger packets. 761 AERO nodes set their AERO interface MTU to the larger of the 762 underlying interface MTU minus the encapsulation overhead, and 1500 763 bytes. (If there are multiple underlying interfaces, the node sets 764 the AERO interface MTU according to the largest underlying interface 765 MTU, or 64KB /4G minus the encapsulation overhead if the largest MTU 766 cannot be determined.) AERO nodes optionally cache other per- 767 neighbor MTU values in the underlying IP path MTU discovery cache 768 initialized to the underlying interface MTU. 770 AERO nodes admit packets that are no larger than 1280 bytes minus the 771 encapsulation overhead (*) as well as packets that are larger than 772 1500 bytes into the tunnel without fragmentation, i.e., as long as 773 they are no larger than the AERO interface MTU before encapsulation 774 and also no larger than the cached per-neighbor MTU following 775 encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit 776 to 0 for packets no larger than 1280 bytes minus the encapsulation 777 overhead (*) and sets the DF bit to 1 for packets larger than 1500 778 bytes. If a large packet is lost in the path, the node may 779 optionally cache the MTU reported in the resulting PTB message or may 780 ignore the message, e.g., if there is a possibility that the message 781 is spurious. 783 For packets destined to an AERO node that are larger than 1280 bytes 784 minus the encapsulation overhead (*) but no larger than 1500 bytes, 785 the node uses IP fragmentation to fragment the encapsulated packet 786 into two pieces (where the first fragment contains 1024 bytes of the 787 original IP packet) then admits the fragments into the tunnel. If 788 the link-layer protocol is IPv4, the node admits each fragment into 789 the tunnel with DF set to 0 and subject to rate limiting to avoid 790 reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the 791 node also sends a 1500 byte probe message (**) to the neighbor, 792 subject to rate limiting. 794 To construct a probe, the node prepares an NS message with a Nonce 795 option plus trailing padding octets added to a length of 1500 bytes 796 without including the length of the padding in the IPv6 Payload 797 Length field. The node then encapsulates the NS in the encapsulation 798 headers (while including the length of the padding in the 799 encapsulation header length fields), sets DF to 1 (for IPv4) and 800 sends the padded NS message to the neighbor. If the neighbor returns 801 an NA message with a correct Nonce value, the node may then send 802 whole packets within this size range and (for IPv4) relax the rate 803 limiting requirement. (Note that the trailing padding SHOULD NOT be 804 included within the Nonce option itself but rather as padding beyond 805 the last option in the NS message; otherwise, the (large) Nonce 806 option would be echoed back in the solicited NA message and may be 807 lost at a link with a small MTU along the reverse path.) 809 AERO nodes MUST be capable of reassembling packets up to 1500 bytes 810 plus the encapsulation overhead length. It is therefore RECOMMENDED 811 that AERO nodes be capable of reassembling at least 2KB. 813 (*) Note that if it is known without probing that the minimum Path 814 MTU to an AERO node is MINMTU bytes (where 1280 < MINMTU < 1500) then 815 MINMTU can be used instead of 1280 in the fragmentation threshold 816 considerations listed above. 818 (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used 819 for MTU probing purposes, since smaller probes may be fragmented if 820 there is a nested tunnel somewhere on the path to the neighbor. 821 Probe sizes larger than 1500 bytes MAY be used, but may be 822 unnecessary since original sources are expected to implement 823 [RFC4821] when sending large packets. 825 3.10. AERO Router Discovery, Prefix Delegation and Address 826 Configuration 828 3.10.1. AERO Client Behavior 830 AERO Clients discover the link-layer addresses of AERO Servers via 831 static configuration, or through an automated means such as DNS name 832 resolution. In the absence of other information, the Client resolves 833 the Fully-Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" 834 where "[domainname]" is the connection-specific DNS suffix for the 835 Client's underlying network connection. After discovering the link- 836 layer addresses, the Client associates with one or more of the 837 corresponding Servers. 839 To associate with a Server, the Client acts as a requesting router to 840 request an ACP through DHCPv6 PD [RFC3315][RFC3633][RFC6355] using 841 'fe80::ffff:ffff:ffff:ffff' as the IPv6 source address, 842 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 843 and the link-layer address of the Server as the link-layer 844 destination address. The Client includes a DHCPv6 Unique Identifier 845 (DUID) in the Client Identifier option of its DHCPv6 messages (as 846 well as a DHCPv6 authentication option if necessary) to identify 847 itself to the DHCPv6 server. The Client also includes a DHCPv6 848 Client Link Layer Address Option (CLLAO) [RFC6939] with the link- 849 layer address format shown in Figure 2 with Link ID followed by 850 Preference followed by the values 0 for both the UDP Port Number and 851 IP Address.The Client sets the CLLAO 'option-length' field to 22 (2 852 plus the length of the link-layer address) and sets the 'link-layer 853 type' field to TBD1 (see: IANA Considerations). If the Client is 854 pre-provisioned with an ACP associated with the AERO service, it MAY 855 also include the ACP in its DHCPv6 PD Request to indicate its 856 preferred ACP to the DHCPv6 server. The Client then sends the 857 encapsulated DHCPv6 request via an underlying interface. 859 When the Client receives its ACP and the set of ASPs via a Reply from 860 the DHCPv6 server, i.e., via an AERO Server acting as a DHCPv6 relay, 861 it creates a neighbor cache entry with the Server's link-local 862 address (i.e., fe80::ID) as the network-layer address and the 863 Server's encapsulation address as the link-layer address. 865 The Client then applies the AERO address to the AERO interface and 866 sub-delegates the ACP to nodes and links within its attached EUNs 867 (the AERO address thereafter remains stable as the Client moves). 868 The Client also assigns a default IP route to the AERO interface as a 869 route-to-interface, i.e., with no explicit next-hop. 871 The Client subsequently renews its ACP delegation by performing 872 DHCPv6 Renew/Reply exchanges with its AERO address as the IPv6 source 873 address, 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination 874 address, the link-layer address of a Server as the link-layer 875 destination address and the same DUID and authentication information. 876 If the Client wishes to associate with multiple Servers, it can 877 perform DHCPv6 Renew/Reply exchanges via each of the Servers. 879 The Client then sends an RS message to each of its associated Servers 880 to receive an RA message with a Router Lifetime and any other link- 881 specific parameters. The Client uses the Router Lifetime to set the 882 lifetime for the neighbor cache entry for this Server. The Client 883 further ignores any RS messages it might receive, since only Servers 884 may process RS messages. 886 The Client then sends periodic RS messages to obtain new RA messages, 887 and further initiates a new DHCPv6 Renew/Reply exchange before the 888 Router Lifetime expires. The Client can also forward IP packets 889 destined to networks beyond its local EUNs via a Server as a default 890 router. 892 Since the Client's AERO address is configured from the unique ACP 893 delegation it receives, there is no need for Duplicate Address 894 Detection (DAD) on AERO links. Other nodes maliciously attempting to 895 hijack an authorized Client's AERO address will be denied access to 896 the network by the DHCPv6 server due to an unacceptable link-layer 897 address and/or security parameters (see: Security Considerations). 899 AERO Clients ignore the IP address and UDP port number in any S/TLLAO 900 options in ND messages they receive directly from another AERO 901 Client, but examine the Link ID and Preference values to match the 902 message with the correct link-layer address information. 904 When a source Client forwards a packet to a prospective destination 905 Client (i.e., one for which the packet's destination address is 906 covered by an ASP), the source Client initiates an AERO route 907 optimization procedure as specified in Section 3.12. 909 3.10.2. AERO Server Behavior 911 AERO Servers configure a DHCPv6 relay function on their AERO links. 912 AERO Servers arrange to add their encapsulation layer IP addresses 913 (i.e., their link-layer addresses) to the DNS resource records for 914 the FQDN "linkupnetworks.[domainname]" before entering service. 915 Here, "linkupnetworks" is a constant text string, and "[domainname]" 916 is the connection-specific DNS suffix for this underlying network 917 connection. 919 When an AERO Server relays a prospective Client's DHCPv6 PD messages 920 to the DHCPv6 server, it wraps each message in a "Relay-forward" 921 message per [RFC3315] and includes a DHCPv6 Interface Identifier 922 option that encodes a value that identifies the AERO link to the 923 DHCPv6 server. Without creating internal state, the Server then 924 modifies the Client's link-layer address in the CLLAO [RFC6939] by 925 writing the client's UDP Port number and IP adddress in the 926 corresponding fields of the option. The Server finally includes a 927 DHCPv6 Echo Request Option (ERO) [RFC4994] that encodes the option 928 code for the CLLAO in a 'requested-option-code-n' field, then relays 929 the message to the DHCPv6 server. The CLLAO information will 930 therefore subsequently be echoed back in the DHCPv6 server's "Relay- 931 reply" message. 933 When the DHCPv6 server issues the ASPs and ACP prefix delegation in a 934 "Relay-reply" message via the AERO Server (acting as a DHCPv6 relay), 935 the Server obtains the Client's link-layer address from the echoed 936 CLLAO option and also obtains the Client's delegated ACP and lease 937 lifetime from the message. The Server then creates a neighbor cache 938 entry for the Client's AERO address with the Client's link-layer 939 address as the link-layer address and with lifetime set to no more 940 than the lease lifetime. The Server finally injects the ACP as an IP 941 route into the inter-Server/Relay routing system (see: Section 3.11) 942 then relays the DHCPv6 message to the Client while using fe80::ID as 943 the IPv6 source address, the link-local address found in the "peer 944 address" field of the Relay-reply message as the IPv6 destination 945 address, and the Client's link-layer address as the destination link- 946 layer address. 948 Servers respond to NS/RS messages from Clients on their AERO 949 interfaces by returning an NA/RA message. When the Server returns an 950 RA message, it sets Router Lifetime to the neighbor cache entry 951 lifetime but does not include any Prefix Information Options (PIOs) 952 since the AERO link is link-local-only. The server decrements the 953 neighbor cache entry lifetime according to the system clock. 955 Servers ignore any RA messages they may receive from a Client, but 956 they MAY examine RA messages received from other Servers for 957 consistency verification purposes. 959 3.10.3. DHCPv6 Server Behavior 961 The DHCPv6 server observes both the base DHCPv6 specification 962 [RFC3315] and the DHCPv6 PD specification [RFC3633]. The DHCPv6 963 server further MUST honor the DHCPv6 Echo Request Option (ERO) and 964 Client Link-Layer Address Option (CLLAO) as discussed in 965 Section 3.10.1. 967 The DHCPv6 server also includes a DHCPv6 Vendor-Specific Information 968 Option with 'enterprise-number' set to "TBD2" (see: IANA 969 Considerations). The option is formatted as shown in[RFC3315] and 970 with the AERO enterprise-specific format shown in Figure 3: 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | OPTION_VENDOR_OPTS | option-len | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | enterprise-number ("TBD2") | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Reserved | Prefix Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 + ASP (1) + 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Reserved | Prefix Length | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | | 987 + ASP (2) + 988 | | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Reserved | Prefix Length | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | | 993 + ASP (3) + 994 | | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 . (etc.) . 997 . . 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Figure 3: AERO Vendor-Specific Information Option 1002 Per Figure 3, the option includes one or more ASP. The Prefix Length 1003 field must contain a value between 0 - 64 and the ASP field contains 1004 the leading 64 bits of the ASP. When the Client receives an AERO 1005 Vendor-Specific Information Option it accepts the option and caches 1006 each ASP that observes the format specified above. If the Client 1007 cannot parse the ASPs, it ignores the option. 1009 3.11. AERO Relay/Server Routing System 1011 Relays require full topology information of all Client/Server 1012 associations, while individual Servers only require partial topology 1013 information, i.e., they only need to know the ACPs associated with 1014 their current set of associated Clients. This is accomplished 1015 through the use of an internal instance of the Border Gateway 1016 Protocol (BGP) [RFC4271] coordinated between Servers and Relays. 1017 This internal BGP instance does not interact with the public Internet 1018 BGP instance; therefore, the AERO link is presented to the IP 1019 Internetwork as a small set of ASPs as opposed to the full set of 1020 individual ACPs. 1022 In a reference BGP arrangement, each AERO Server is configured as an 1023 Autonomous System Border Router (ASBR) for a stub Autonomous System 1024 (AS) (possibly using a private AS Number (ASN) [RFC1930]), and each 1025 Server further peers with each Relay but does not peer with other 1026 Servers. Similarly, Relays need not peer with each other, since they 1027 will receive all updates from all Servers and will therefore have a 1028 consistent view of the AERO link ACP delegations. 1030 Each Server maintains a working set of associated Clients, and 1031 dynamically announces new ACPs and withdraws departed ACPs in its BGP 1032 updates to Relays. Relays do not send BGP updates to Servers, 1033 however, such that the BGP route reporting is unidirectional from the 1034 Servers to the Relays. 1036 The Relays therefore discover the full topology of the AERO link in 1037 terms of the working set of ACPs associated with each Server, while 1038 the Servers only discover the ACPs of their associated Clients. 1039 Since Clients are expected to remain associated with their current 1040 set of Servers for extended timeframes, the amount of BGP control 1041 messaging between Servers and Relays should be minimal. However, BGP 1042 peers SHOULD dampen any route oscillations caused by impatient 1043 Clients that repeatedly associate and disassociate with Servers. 1045 3.12. AERO Redirection 1047 3.12.1. Reference Operational Scenario 1049 Figure 4 depicts the AERO redirection reference operational scenario, 1050 using IPv6 addressing as the example (while not shown, a 1051 corresponding example for IPv4 addressing can be easily constructed). 1052 The figure shows an AERO Relay ('R'), two AERO Servers ('S1', 'S2'), 1053 two AERO Clients ('A', 'B') and two ordinary IPv6 hosts ('C', 'D'): 1055 +--------------+ +--------------+ +--------------+ 1056 | Server S1 | | Relay R | | Server S2 | 1057 | Nbr: A | |(C->S1; D->S2)| | Nbr: B | 1058 +--------------+ +--------------+ +--------------+ 1059 fe80::2 fe80::1 fe80::3 1060 L2(S1) L2(R) L2(S2) 1061 | | | 1062 X-----+-----+------------------+-----------------+----+----X 1063 | AERO Link | 1064 L2(A) L2(B) 1065 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1066 +--------------+ +--------------+ 1067 | AERO Client A| | AERO Client B| 1068 | (default->S1)| | (default->S2)| 1069 +--------------+ +--------------+ 1070 2001:DB8:0::/48 2001:DB8:1::/48 1071 | | 1072 .-. .-. 1073 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1074 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1075 (__ EUN )--| Host C | | Host D |--(__ EUN ) 1076 `-(______)-' +---------+ +---------+ `-(______)-' 1078 Figure 4: AERO Reference Operational Scenario 1080 In Figure 4, Relay ('R') applies the address fe80::1 to its AERO 1081 interface with link-layer address L2(R), Server ('S1') applies the 1082 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1083 applies the address fe80::3 with link-layer address L2(S2). Servers 1084 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1085 published list of valid Servers for the AERO link. 1087 AERO Client ('A') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1088 exchange via AERO Server ('S1') then assigns the address 1089 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1090 L2(A). Client ('A') configures a default route and neighbor cache 1091 entry via the AERO interface with next-hop address fe80::2 and link- 1092 layer address L2(S1), then sub-delegates the ACP to its attached 1093 EUNs. IPv6 host ('C') connects to the EUN, and configures the 1094 address 2001:db8:0::1. 1096 AERO Client ('B') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1097 exchange via AERO Server ('S2') then assigns the address 1098 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1099 L2(B). Client ('B') configures a default route and neighbor cache 1100 entry via the AERO interface with next-hop address fe80::3 and link- 1101 layer address L2(S2), then sub-delegates the ACP to its attached 1102 EUNs. IPv6 host ('D') connects to the EUN, and configures the 1103 address 2001:db8:1::1. 1105 3.12.2. Concept of Operations 1107 Again, with reference to Figure 4, when source host ('C') sends a 1108 packet to destination host ('D'), the packet is first forwarded over 1109 the source host's attached EUN to Client ('A'). Client ('A') then 1110 forwards the packet via its AERO interface to Server ('S1') and also 1111 sends a Predirect message toward Client ('B') via Server ('S1'). 1112 Server ('S1') then re-encapsulates and forwards both the packet and 1113 the Predirect message out the same AERO interface toward Client ('B') 1114 via Relay ('R'). 1116 When Relay ('R') receives the packet and Predirect message, it 1117 consults its forwarding table to discover Server ('S2') as the next 1118 hop toward Client ('B'). Relay ('R') then forwards both messages to 1119 Server ('S2'), which then forwards them to Client ('B'). 1121 After Client ('B') receives the Predirect message, it process the 1122 message and returns a Redirect message toward Client ('A') via Server 1123 ('S2'). During the process, Client ('B') also creates or updates a 1124 neighbor cache entry for Client ('A'). 1126 When Server ('S2') receives the Redirect message, it re-encapsulates 1127 the message and forwards it on to Relay ('R'), which forwards the 1128 message on to Server ('S1') which forwards the message on to Client 1129 ('A'). After Client ('A') receives the Redirect message, it 1130 processes the message and creates or updates a neighbor cache entry 1131 for Client ('C'). 1133 Following the above Predirect/Redirect message exchange, forwarding 1134 of packets from Client ('A') to Client ('B') without involving any 1135 intermediate nodes is enabled. The mechanisms that support this 1136 exchange are specified in the following sections. 1138 3.12.3. Message Format 1140 AERO Redirect/Predirect messages use the same format as for ICMPv6 1141 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1142 include a new "Prefix Length" field taken from the low-order 8 bits 1143 of the Redirect message Reserved field. (For IPv6, valid values for 1144 the Prefix Length field are 0 through 64; for IPv4, valid values are 1145 0 through 32.) The Redirect/Predirect messages are formatted as 1146 shown in Figure 5: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Type (=137) | Code (=0/1) | Checksum | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Reserved | Prefix Length | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | | 1156 + + 1157 | | 1158 + Target Address + 1159 | | 1160 + + 1161 | | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | | 1164 + + 1165 | | 1166 + Destination Address + 1167 | | 1168 + + 1169 | | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Options ... 1172 +-+-+-+-+-+-+-+-+-+-+-+- 1174 Figure 5: AERO Redirect/Predirect Message Format 1176 3.12.4. Sending Predirects 1178 When a Client forwards a packet with a source address from one of its 1179 ACPs toward a destination address covered by an ASP (i.e., toward 1180 another AERO Client connected to the same AERO link), the source 1181 Client MAY send a Predirect message forward toward the destination 1182 Client via the Server. 1184 In the reference operational scenario, when Client ('A') forwards a 1185 packet toward Client ('B'), it MAY also send a Predirect message 1186 forward toward Client ('B'), subject to rate limiting (see 1187 Section 8.2 of [RFC4861]). Client ('A') prepares the Predirect 1188 message as follows: 1190 o the link-layer source address is set to 'L2(A)' (i.e., the link- 1191 layer address of Client ('A')). 1193 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1194 link-layer address of Server ('S1')). 1196 o the network-layer source address is set to fe80::2001:db8:0:0 1197 (i.e., the AERO address of Client ('A')). 1199 o the network-layer destination address is set to fe80::2001:db8:1:0 1200 (i.e., the AERO address of Client ('B')). 1202 o the Type is set to 137. 1204 o the Code is set to 1 to indicate "Predirect". 1206 o the Prefix Length is set to the length of the prefix to be applied 1207 to the Target Address. 1209 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1210 address of Client ('A')). 1212 o the Destination Address is set to the source address of the 1213 originating packet that triggered the Predirection event. (If the 1214 originating packet is an IPv4 packet, the address is constructed 1215 in IPv4-compatible IPv6 address format). 1217 o the message includes a TLLAO with Link ID and Preference set to 1218 appropriate values for Client ('A')'s underlying interface, and 1219 with UDP Port Number and IP Address set to 0'. 1221 o the message SHOULD include a Timestamp option. 1223 o the message includes a Redirected Header Option (RHO) that 1224 contains the originating packet truncated to ensure that at least 1225 the network-layer header is included but the size of the message 1226 does not exceed 1280 bytes. 1228 Note that the act of sending Predirect messages is cited as "MAY", 1229 since Client ('A') may have advanced knowledge that the direct path 1230 to Client ('B') would be unusable. If the direct path later becomes 1231 unusable after the initial route optimization, Client ('A') simply 1232 allows packets to again flow through Server ('S1'). 1234 3.12.5. Re-encapsulating and Relaying Predirects 1236 When Server ('S1') receives a Predirect message from Client ('A'), it 1237 first verifies that the requested redirection is authorized. If the 1238 redirection is not permitted, Server ('S1') discards the message. 1239 Otherwise, Server ('S1') validates the message according to the 1240 ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861], 1241 except that the Predirect has Code=1. Server ('S1') also verifies 1242 that Client ('A') is authorized to use the Prefix Length in the 1243 Predirect when applied to the AERO address in the network-layer 1244 source address by searching for the AERO address in the neighbor 1245 cache. If validation fails, Server ('S1') discards the Predirect; 1246 otherwise, it copies the correct UDP Port number and IP Address for 1247 Client ('A') into the (previously empty) TLLAO. 1249 Server ('S1') then examines the network-layer destination address of 1250 the Predirect to determine the next hop toward Client ('B') by 1251 searching for the AERO address in the neighbor cache. Since Client 1252 ('B') is not one of its neighbors, Server ('S1') re-encapsulates the 1253 Predirect and relays it via Relay ('R') by changing the link-layer 1254 source address of the message to 'L2(S1)' and changing the link-layer 1255 destination address to 'L2(R)'. Server ('S1') finally forwards the 1256 re-encapsulated message to Relay ('R') without decrementing the 1257 network-layer TTL/Hop Limit field. 1259 When Relay ('R') receives the Predirect message from Server ('S1') it 1260 determines that Server ('S2') is the next hop toward Client ('B') by 1261 consulting its forwarding table. Relay ('R') then re-encapsulates 1262 the Predirect while changing the link-layer source address to 'L2(R)' 1263 and changing the link-layer destination address to 'L2(S2)'. Relay 1264 ('R') then relays the Predirect via Server ('S2'). 1266 When Server ('S2') receives the Predirect message from Relay ('R') it 1267 determines that Client ('B') is a neighbor by consulting its neighbor 1268 cache. Server ('S2') then re-encapsulates the Predirect while 1269 changing the link-layer source address to 'L2(S2)' and changing the 1270 link-layer destination address to 'L2(B)'. Server ('S2') then 1271 forwards the message to Client ('B'). 1273 3.12.6. Processing Predirects and Sending Redirects 1275 When Client ('B') receives the Predirect message, it accepts the 1276 Predirect only if the message has a link-layer source address of one 1277 of its Servers (e.g., L2(S2)). Client ('B') further accepts the 1278 message only if it is willing to serve as a redirection target. 1279 Next, Client ('B') validates the message according to the ICMPv6 1280 Redirect message validation rules in Section 8.1 of [RFC4861], except 1281 that it accepts the message even though Code=1 and even though the 1282 network-layer source address is not that of it's current first-hop 1283 router. 1285 In the reference operational scenario, when Client ('B') receives a 1286 valid Predirect message, it either creates or updates a neighbor 1287 cache entry that stores the Target Address of the message as the 1288 network-layer address of Client ('A') , stores the link-layer address 1289 found in the TLLAO as the link-layer address(es) of Client ('A') and 1290 stores the Prefix Length as the length to be applied to the network- 1291 layer address for forwarding purposes. Client ('B') then sets 1292 AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1294 After processing the message, Client ('B') prepares a Redirect 1295 message response as follows: 1297 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1298 layer address of Client ('B')). 1300 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1301 link-layer address of Server ('S2')). 1303 o the network-layer source address is set to fe80::2001:db8:1:0 1304 (i.e., the AERO address of Client ('B')). 1306 o the network-layer destination address is set to fe80::2001:db8:0:0 1307 (i.e., the AERO address of Client ('A')). 1309 o the Type is set to 137. 1311 o the Code is set to 0 to indicate "Redirect". 1313 o the Prefix Length is set to the length of the prefix to be applied 1314 to the Target Address. 1316 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1317 address of Client ('B')). 1319 o the Destination Address is set to the destination address of the 1320 originating packet that triggered the Redirection event. (If the 1321 originating packet is an IPv4 packet, the address is constructed 1322 in IPv4-compatible IPv6 address format). 1324 o the message includes a TLLAO with Link ID and Preference set to 1325 appropriate values for Client ('B')'s underlying interface, and 1326 with UDP Port Number and IP Address set to '0'. 1328 o the message SHOULD include a Timestamp option. 1330 o the message includes as much of the RHO copied from the 1331 corresponding AERO Predirect message as possible such that at 1332 least the network-layer header is included but the size of the 1333 message does not exceed 1280 bytes. 1335 After Client ('B') prepares the Redirect message, it sends the 1336 message to Server ('S2'). 1338 3.12.7. Re-encapsulating and Relaying Redirects 1340 When Server ('S2') receives a Redirect message from Client ('B'), it 1341 first verifies that the requested redirection is authorized. If the 1342 redirection is not permitted, Server ('S2') discards the message. 1343 Otherwise, Server ('S2') validates the message according to the 1344 ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861]. 1345 Server ('S2') also verifies that Client ('B') is authorized to use 1346 the Prefix Length in the Redirect when applied to the AERO address in 1347 the network-layer source address by searching for the AERO address in 1348 the neighbor cache. If validation fails, Server ('S2') discards the 1349 Predirect; otherwise, it copies the correct UDP Port number and IP 1350 Address for Client ('B') into the (previously empty) TLLAO. 1352 Server ('S2') then examines the network-layer destination address of 1353 the Predirect to determine the next hop toward Client ('A') by 1354 searching for the AERO address in the neighbor cache. Since Client 1355 ('A') is not one of its neighbors, Server ('S2') re-encapsulates the 1356 Predirect and relays it via Relay ('R') by changing the link-layer 1357 source address of the message to 'L2(S2)' and changing the link-layer 1358 destination address to 'L2(R)'. Server ('S2') finally forwards the 1359 re-encapsulated message to Relay ('R') without decrementing the 1360 network-layer TTL/Hop Limit field. 1362 When Relay ('R') receives the Predirect message from Server ('S2') it 1363 determines that Server ('S1') is the next hop toward Client ('A') by 1364 consulting its forwarding table. Relay ('R') then re-encapsulates 1365 the Predirect while changing the link-layer source address to 'L2(R)' 1366 and changing the link-layer destination address to 'L2(S1)'. Relay 1367 ('R') then relays the Predirect via Server ('S1'). 1369 When Server ('S1') receives the Predirect message from Relay ('R') it 1370 determines that Client ('A') is a neighbor by consulting its neighbor 1371 cache. Server ('S1') then re-encapsulates the Predirect while 1372 changing the link-layer source address to 'L2(S1)' and changing the 1373 link-layer destination address to 'L2(A)'. Server ('S1') then 1374 forwards the message to Client ('A'). 1376 3.12.8. Processing Redirects 1378 When Client ('A') receives the Redirect message, it accepts the 1379 message only if it has a link-layer source address of one of its 1380 Servers (e.g., ''L2(S1)'). Next, Client ('A') validates the message 1381 according to the ICMPv6 Redirect message validation rules in 1382 Section 8.1 of [RFC4861], except that it accepts the message even 1383 though the network-layer source address is not that of it's current 1384 first-hop router. Following validation, Client ('A') then processes 1385 the message as follows. 1387 In the reference operational scenario, when Client ('A') receives the 1388 Redirect message, it either creates or updates a neighbor cache entry 1389 that stores the Target Address of the message as the network-layer 1390 address of Client ('B'), stores the link-layer address found in the 1391 TLLAO as the link-layer address of Client ('B') and stores the Prefix 1392 Length as the length to be applied to the network-layer address for 1393 forwarding purposes. Client ('A') then sets ForwardTime for the 1394 neighbor cache entry to FORWARD_TIME. 1396 Now, Client ('A') has a neighbor cache entry with a valid ForwardTime 1397 value, while Client ('B') has a neighbor cache entry with a valid 1398 AcceptTime value. Thereafter, Client ('A') may forward ordinary 1399 network-layer data packets directly to Client ("B") without involving 1400 any intermediate nodes, and Client ('B') can verify that the packets 1401 came from an acceptable source. (In order for Client ('B') to 1402 forward packets to Client ('A'), a corresponding Predirect/Redirect 1403 message exchange is required in the reverse direction; hence, the 1404 mechanism is asymmetric.) 1406 3.12.9. Server-Oriented Redirection 1408 In some environments, the Server nearest the destination Client may 1409 need to serve as the redirection target, e.g., if direct Client-to- 1410 Client communications are not possible. In that case, the Server 1411 prepares the Redirect message the same as if it were the destination 1412 Client (see: Section 3.9.6), except that it writes its own link-layer 1413 address in the TLLAO option. The Server must then maintain a 1414 neighbor cache entry for the redirected source Client. 1416 3.13. Neighbor Unreachability Detection (NUD) 1418 AERO nodes perform NUD by sending unicast NS messages to elicit 1419 solicited NA messages from neighbors the same as described in 1420 [RFC4861]. When an AERO node sends an NS/NA message, it MUST use its 1421 AERO address as the IPv6 source address and the link-local address of 1422 the neighbor as the IPv6 destination address. When an AERO node 1423 receives an NS message or a solicited NA message, it accepts the 1424 message if it has a neighbor cache entry for the neighbor; otherwise, 1425 it ignores the message. 1427 When a source Client is redirected to a target Client it SHOULD test 1428 the direct path by sending an initial NS message to elicit a 1429 solicited NA response. While testing the path, the source Client can 1430 optionally continue sending packets via the Server, maintain a small 1431 queue of packets until target reachability is confirmed, or 1432 (optimistically) allow packets to flow directly to the target. The 1433 source Client SHOULD thereafter continue to test the direct path to 1434 the target Client (see Section 7.3 of [RFC4861]) periodically in 1435 order to keep neighbor cache entries alive. 1437 In particular, while the source Client is actively sending packets to 1438 the target Client it SHOULD also send NS messages separated by 1439 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 1440 If the source Client is unable to elicit a solicited NA response from 1441 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 1442 to 0 and resume sending packets via the Server which may or may not 1443 result in a new redirection event. Otherwise, the source Client 1444 considers the path usable and SHOULD thereafter process any link- 1445 layer errors as a hint that the direct path to the target Client has 1446 either failed or has become intermittent. 1448 When a target Client receives an NS message from a source Client, it 1449 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 1450 otherwise, it discards the NS message. 1452 When a source Client receives a solicited NA message from a target 1453 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 1454 entry exists; otherwise, it discards the NA message. 1456 When ForwardTime for a neighbor cache entry expires, the source 1457 Client resumes sending any subsequent packets via the Server and may 1458 (eventually) attempt to re-initiate the AERO redirection process. 1459 When AcceptTime for a neighbor cache entry expires, the target Client 1460 discards any subsequent packets received directly from the source 1461 Client. When both ForwardTime and AcceptTime for a neighbor cache 1462 entry expire, the Client deletes the neighbor cache entry. 1464 3.14. Mobility Management 1466 3.14.1. Announcing Link-Layer Address Changes 1468 When a Client needs to change its link-layer address, e.g., due to a 1469 mobility event, it performs an immediate DHCPv6 Renew/Reply via each 1470 of its Servers using the new link-layer address as the source. The 1471 DHCPv6 Server will re-authenticate the Client and (assuming 1472 authentication succeeds) the DHCPv6 Renew/Reply exchange will update 1473 each Server's neighbor cache. 1475 Next, the Client sends unsolicited NA messages to each of its active 1476 neighbors using the same procedures as specified in Section 7.2.6 of 1477 [RFC4861], except that it sends the messages as unicast to each 1478 neighbor via a Server instead of multicast. In this process, the 1479 Client should send no more than MAX_NEIGHBOR_ADVERTISEMENT messages 1480 separated by no less than RETRANS_TIMER seconds to each neighbor. 1482 With reference to Figure 4, Client ('B') sends unicast unsolicited NA 1483 messages to Client ('A') via Server ('S2') as follows: 1485 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1486 layer address of Client ('B')). 1488 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1489 link-layer address of Server ('S2')). 1491 o the network-layer source address is set to fe80::2001:db8:1:0 1492 (i.e., the AERO address of Client ('B')). 1494 o the network-layer destination address is set to fe80::2001:db8:0:0 1495 (i.e., the AERO address of Client ('A')). 1497 o the Type is set to 136. 1499 o the Code is set to 0. 1501 o the Solicited flag is set to 0. 1503 o the Override flag is set to 1. 1505 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1506 address of Client ('B')). 1508 o the message includes a TLLAO with Link ID and Preference set to 1509 appropriate values for Client ('B')'s underlying interface, and 1510 with UDP Port Number and IP Address set to '0'. 1512 o the message SHOULD include a Timestamp option. 1514 When Server ('S1') receives the NA message, it relays the message in 1515 the same way as described for relaying Redirect messages in 1516 Section 3.12.7. In particular, Server ('S1') copies the correct UDP 1517 port number and IP address into the TLLAO, changes the link-layer 1518 source address to its own address, changes the link-layer destination 1519 address to the address of Relay ('R'), then forwards the NA message 1520 via the relaying chain the same as for a Redirect. 1522 When Client ('A') receives the NA message, it accepts the message 1523 only if it already has a neighbor cache entry for Client ('B') then 1524 updates the link-layer address for Client ('B') based on the address 1525 in the TLLAO. However, Client ('A') MUST NOT update ForwardTime 1526 since Client ('B') will not have updated AcceptTime. 1528 Note that these unsolicited NA messages are unacknowledged; hence, 1529 Client ('B') has no way of knowing whether Client ('A') has received 1530 them. If the messages are somehow lost, however, Client ('A') will 1531 soon learn of the mobility event via the NUD procedures specified in 1532 Section 3.13. 1534 3.14.2. Moving to a New Server 1536 When a Client associates with a new Server, it issues a new DHCPv6 1537 Renew message via the new Server as the DHCPv6 relay. The new Server 1538 then relays the message to the DHCPv6 server and processes the 1539 resulting exchange. After the Client receives the resulting DHCPv6 1540 Reply message, it sends an RS message to the new Server to receive a 1541 new RA message. 1543 When a Client disassociates with an existing Server, it sends a 1544 "terminating RS" message to the old Server. The terminating RS 1545 message is prepared exactly the same as for an ordinary RS message, 1546 except that the Code field contains the value '1'. When the old 1547 Server receives the terminating RS message, it withdraws the IP route 1548 from the routing system and deletes the neighbor cache entry for the 1549 Client. The old Server then returns an RA message with default 1550 router lifetime set to 0 which the Client can use to verify that the 1551 termination signal has been processed. The client then deletes both 1552 the default route and the neighbor cache entry for the old Server. 1553 The old Server SHOULD impose a small delay before deleting the 1554 neighbor cache entry so that any packets already in the system can 1555 still be delivered to the Client. 1557 Clients SHOULD NOT move rapidly between Servers in order to avoid 1558 causing unpredictable oscillations in the Server/Relay routing 1559 system. Such oscillations could result in intermittent reachability 1560 for the Client itself, while causing little harm to the network due 1561 to routing protocol dampening. Examples of when a Client may change 1562 to a different Server include a Server that has gone unreachable, 1563 topological movements of significant distance, etc. 1565 3.15. Encapsulation Protocol Version Considerations 1567 A source Client may connect only to an IPvX underlying network, while 1568 the target Client connects only to an IPvY underlying network. In 1569 that case, the target and source Clients have no means for reaching 1570 each other directly (since they connect to underlying networks of 1571 different IP protocol versions) and so must ignore any redirection 1572 messages and continue to send packets via the Server. 1574 3.16. Multicast Considerations 1576 When the underlying network does not support multicast, AERO nodes 1577 map IPv6 link-scoped multicast addresses (including 1578 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 1579 Server. 1581 When the underlying network supports multicast, AERO nodes use the 1582 multicast address mapping specification found in [RFC2529] for IPv4 1583 underlying networks and use a direct multicast mapping for IPv6 1584 underlying networks. (In the latter case, "direct multicast mapping" 1585 means that if the IPv6 multicast destination address of the 1586 encapsulated packet is "M", then the IPv6 multicast destination 1587 address of the encapsulating header is also "M".) 1589 3.17. Operation on AERO Links Without DHCPv6 Services 1591 When the AERO link does not provide DHCPv6 services, operation can 1592 still be accommodated through administrative configuration of ACPs on 1593 AERO Clients. In that case, administrative configurations of AERO 1594 interface neighbor cache entries on both the Server and Client are 1595 also necessary. However, this may interfere with the ability for 1596 Clients to dynamically change to new Servers, and can expose the AERO 1597 link to misconfigurations unless the administrative configurations 1598 are carefully coordinated. 1600 3.18. Operation on Server-less AERO Links 1602 In some AERO link scenarios, there may be no Servers on the link and/ 1603 or no need for Clients to use a Server as an intermediary trust 1604 anchor. In that case, each Client acts as a Server unto itself to 1605 establish neighbor cache entries by performing direct Client-to- 1606 Client Predirect/Redirect exchanges, and some other form of trust 1607 basis must be applied so that each Client can verify that the 1608 prospective neighbor is authorized to use its claimed ACP. 1610 When there is no Server on the link, Clients must arrange to receive 1611 ACPs and publish them via a secure alternate prefix delegation 1612 authority through some means outside the scope of this document. 1614 4. Implementation Status 1616 An application-layer implementation is in progress. 1618 5. IANA Considerations 1620 The IANA is instructed to assign a new 2-octet Hardware Type number 1621 "TBD1" for AERO in the "arp-parameters" registry per Section 2 of 1622 [RFC5494]. The number is assigned from the 2-octet Unassigned range 1623 with Hardware Type "AERO" and with this document as the reference. 1625 The IANA is further instructed to assign a 4-octet Enterprise Number 1626 "TBD2" for AERO in the "enterprise-numbers" registry per [RFC3315]. 1628 6. Security Considerations 1630 AERO link security considerations are the same as for standard IPv6 1631 Neighbor Discovery [RFC4861] except that AERO improves on some 1632 aspects. In particular, AERO uses a trust basis between Clients and 1633 Servers, where the Clients only engage in the AERO mechanism when it 1634 is facilitated by a trust anchor. AERO also uses DHCPv6 1635 authentication for Client authentication and network admission 1636 control. 1638 AERO links must be protected against link-layer address spoofing 1639 attacks in which an attacker on the link pretends to be a trusted 1640 neighbor. Links that provide link-layer securing mechanisms (e.g., 1641 IEEE 802.1X WLANs) and links that provide physical security (e.g., 1642 enterprise network wired LANs) provide a first line of defense that 1643 is often sufficient. In other instances, additional securing 1644 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 1645 [RFC4301] or TLS [RFC5246] may be necessary. 1647 AERO Clients MUST ensure that their connectivity is not used by 1648 unauthorized nodes on EUNs to gain access to a protected network, 1649 i.e., AERO Clients that act as routers MUST NOT provide routing 1650 services for unauthorized nodes. (This concern is no different than 1651 for ordinary hosts that receive an IP address delegation but then 1652 "share" the address with unauthorized nodes via a NAT function.) 1654 On some AERO links, establishment and maintenance of a direct path 1655 between neighbors requires secured coordination such as through the 1656 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 1657 security association. 1659 7. Acknowledgements 1661 Discussions both on IETF lists and in private exchanges helped shape 1662 some of the concepts in this work. Individuals who contributed 1663 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1664 Brian Carpenter, Wojciech Dec, Brian Haberman, Joel Halpern, Sascha 1665 Hlusiak, Lee Howard, Joe Touch and Bernie Volz. Members of the IESG 1666 also provided valuable input during their review process that greatly 1667 improved the document. Special thanks go to Stewart Bryant, Joel 1668 Halpern and Brian Haberman for their shepherding guidance. 1670 This work has further been encouraged and supported by Boeing 1671 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 1672 Balaguruna Chidambaram, Wen Fang, Anthony Gregory, Jeff Holland, Ed 1673 King, Gen MacLean, Kent Shuey, Brian Skeen, Mike Slane, Julie Wulff, 1674 Yueli Yang, and other members of the BR&T and BIT mobile networking 1675 teams. 1677 Earlier works on NBMA tunneling approaches are found in 1678 [RFC2529][RFC5214][RFC5569]. 1680 8. References 1682 8.1. Normative References 1684 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1685 August 1980. 1687 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1688 1981. 1690 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1691 RFC 792, September 1981. 1693 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1694 October 1996. 1696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1697 Requirement Levels", BCP 14, RFC 2119, March 1997. 1699 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1700 (IPv6) Specification", RFC 2460, December 1998. 1702 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1703 IPv6 Specification", RFC 2473, December 1998. 1705 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1706 and M. Carney, "Dynamic Host Configuration Protocol for 1707 IPv6 (DHCPv6)", RFC 3315, July 2003. 1709 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1710 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1711 December 2003. 1713 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1714 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1716 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1717 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1719 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1720 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1721 September 2007. 1723 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1724 Address Autoconfiguration", RFC 4862, September 2007. 1726 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1727 Requirements", RFC 6434, December 2011. 1729 8.2. Informative References 1731 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1732 RFC 879, November 1983. 1734 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1735 selection, and registration of an Autonomous System (AS)", 1736 BCP 6, RFC 1930, March 1996. 1738 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1739 Domains without Explicit Tunnels", RFC 2529, March 1999. 1741 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1742 RFC 2675, August 1999. 1744 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1745 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1747 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1748 Architecture", RFC 4291, February 2006. 1750 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1751 Internet Protocol", RFC 4301, December 2005. 1753 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1754 Discovery", RFC 4821, March 2007. 1756 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1757 Errors at High Data Rates", RFC 4963, July 2007. 1759 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 1760 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 1761 September 2007. 1763 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1764 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1765 March 2008. 1767 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1768 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1770 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 1771 for the Address Resolution Protocol (ARP)", RFC 5494, 1772 April 2009. 1774 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1775 Route Optimization Requirements for Operational Use in 1776 Aeronautics and Space Exploration Mobile Networks", RFC 1777 5522, October 2009. 1779 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1780 Infrastructures (6rd)", RFC 5569, January 2010. 1782 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1783 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1784 5996, September 2010. 1786 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1787 NAT64: Network Address and Protocol Translation from IPv6 1788 Clients to IPv4 Servers", RFC 6146, April 2011. 1790 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1791 Troan, "Basic Requirements for IPv6 Customer Edge 1792 Routers", RFC 6204, April 2011. 1794 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 1795 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 1796 2011. 1798 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1799 for Equal Cost Multipath Routing and Link Aggregation in 1800 Tunnels", RFC 6438, November 2011. 1802 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1803 RFC 6691, July 2012. 1805 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1806 (AERO)", RFC 6706, August 2012. 1808 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1809 RFC 6864, February 2013. 1811 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1812 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1814 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1815 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1816 RFC 6936, April 2013. 1818 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 1819 Address Option in DHCPv6", RFC 6939, May 2013. 1821 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1822 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1824 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 1825 Address Selection Policy Using DHCPv6", RFC 7078, January 1826 2014. 1828 Author's Address 1830 Fred L. Templin (editor) 1831 Boeing Research & Technology 1832 P.O. Box 3707 1833 Seattle, WA 98124 1834 USA 1836 Email: fltemplin@acm.org