idnits 2.17.1 draft-templin-aerolink-32.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 (August 26, 2014) is 3524 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 1744, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1750, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1759, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1783, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 1796, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 1851, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 1855, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 1859, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1867, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 1870, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 1886, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 1889, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-03 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 17 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) August 26, 2014 5 Intended status: Standards Track 6 Expires: February 27, 2015 8 Transmission of IP Packets over AERO Links 9 draft-templin-aerolink-32.txt 11 Abstract 13 This document specifies the operation of IP over tunnel virtual links 14 using Asymmetric Extended Route Optimization (AERO). Nodes attached 15 to AERO links can exchange packets via trusted intermediate routers 16 that provide forwarding services to reach off-link destinations and 17 redirection services for route optimization. AERO provides an IPv6 18 link-local address format known as the AERO address that supports 19 operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 20 ND to IP forwarding. Admission control and provisioning are 21 supported by the Dynamic Host Configuration Protocol for IPv6 22 (DHCPv6), and node mobility is naturally supported through dynamic 23 neighbor cache updates. Although DHCPv6 and IPv6 ND messaging is 24 used in the control plane, both IPv4 and IPv6 are supported in the 25 data plane. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 27, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 64 3.1. AERO Link Reference Model . . . . . . . . . . . . . . . . 6 65 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. AERO Interface Characteristics . . . . . . . . . . . . . 9 68 3.4.1. Coordination of Multiple Underlying Interfaces . . . 11 69 3.5. AERO Interface Neighbor Cache Maintenace . . . . . . . . 11 70 3.6. AERO Interface Sending Algorithm . . . . . . . . . . . . 13 71 3.7. AERO Interface Encapsulation, Re-encapsulation and 72 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 14 73 3.8. AERO Interface Data Origin Authentication . . . . . . . . 16 74 3.9. AERO Interface MTU Considerations . . . . . . . . . . . . 16 75 3.10. AERO Router Discovery, Prefix Delegation and Address 76 Configuration . . . . . . . . . . . . . . . . . . . . . . 18 77 3.10.1. AERO DHCPv6 Service Model . . . . . . . . . . . . . 18 78 3.10.2. AERO Client Behavior . . . . . . . . . . . . . . . . 19 79 3.10.3. AERO Server Behavior . . . . . . . . . . . . . . . . 20 80 3.11. AERO Relay/Server Routing System . . . . . . . . . . . . 23 81 3.12. AERO Redirection . . . . . . . . . . . . . . . . . . . . 23 82 3.12.1. Reference Operational Scenario . . . . . . . . . . . 23 83 3.12.2. Concept of Operations . . . . . . . . . . . . . . . 25 84 3.12.3. Message Format . . . . . . . . . . . . . . . . . . . 25 85 3.12.4. Sending Predirects . . . . . . . . . . . . . . . . . 26 86 3.12.5. Re-encapsulating and Relaying Predirects . . . . . . 27 87 3.12.6. Processing Predirects and Sending Redirects . . . . 28 88 3.12.7. Re-encapsulating and Relaying Redirects . . . . . . 30 89 3.12.8. Processing Redirects . . . . . . . . . . . . . . . . 30 90 3.12.9. Server-Oriented Redirection . . . . . . . . . . . . 31 91 3.13. Neighbor Unreachability Detection (NUD) . . . . . . . . . 31 92 3.14. Mobility Management . . . . . . . . . . . . . . . . . . . 32 93 3.14.1. Announcing Link-Layer Address Changes . . . . . . . 32 94 3.14.2. Bringing New Links Into Service . . . . . . . . . . 34 95 3.14.3. Removing Existing Links from Service . . . . . . . . 34 96 3.14.4. Moving to a New Server . . . . . . . . . . . . . . . 34 98 3.15. Encapsulation Protocol Version Considerations . . . . . . 35 99 3.16. Multicast Considerations . . . . . . . . . . . . . . . . 35 100 3.17. Operation on AERO Links Without DHCPv6 Services . . . . . 36 101 3.18. Operation on Server-less AERO Links . . . . . . . . . . . 36 102 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 36 103 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 105 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 108 8.2. Informative References . . . . . . . . . . . . . . . . . 39 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 111 1. Introduction 113 This document specifies the operation of IP over tunnel virtual links 114 using Asymmetric Extended Route Optimization (AERO). The AERO link 115 can be used for tunneling to neighboring nodes over either IPv6 or 116 IPv4 networks, i.e., AERO views the IPv6 and IPv4 networks as 117 equivalent links for tunneling. Nodes attached to AERO links can 118 exchange packets via trusted intermediate routers that provide 119 forwarding services to reach off-link destinations and redirection 120 services for route optimization that addresses the requirements 121 outlined in [RFC5522]. 123 AERO provides an IPv6 link-local address format known as the AERO 124 address that supports operation of the IPv6 Neighbor Discovery (ND) 125 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 126 control and provisioning are supported by the Dynamic Host 127 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and node mobility 128 is naturally supported through dynamic neighbor cache updates. 129 Although DHCPv6 and IPv6 ND message signalling is used in the control 130 plane, either of IPv4 and IPv6 can be used in the data plane. The 131 remainder of this document presents the AERO specification. 133 2. Terminology 135 The terminology in the normative references applies; the following 136 terms are defined within the scope of this document: 138 AERO link 139 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 140 configured over a node's attached IPv6 and/or IPv4 networks. All 141 nodes on the AERO link appear as single-hop neighbors from the 142 perspective of the virtual overlay. 144 AERO interface 145 a node's attachment to an AERO link. 147 AERO address 148 an IPv6 link-local address constructed as specified in Section 3.2 149 and applied to a Client's AERO interface. 151 AERO node 152 a node that is connected to an AERO link and that participates in 153 IPv6 ND over the link. 155 AERO Client ("Client") 156 a node that applies an AERO address to an AERO interface and 157 receives an IP prefix delegation. 159 AERO Server ("Server") 160 a node that configures an AERO interface to provide default 161 forwarding and DHCPv6 services for AERO Clients. The Server 162 applies the IPv6 link-local subnet router anycast address (fe80::) 163 to the AERO interface and also applies an administratively 164 assigned IPv6 link-local unicast address used for operation of the 165 IPv6 ND protocol. 167 AERO Relay ("Relay") 168 a node that configures an AERO interface to relay IP packets 169 between nodes on the same AERO link and/or forward IP packets 170 between the AERO link and the native Internetwork. The Relay 171 applies an administratively assigned IPv6 link-local unicast 172 address to the AERO interface the same as for a Server. 174 ingress tunnel endpoint (ITE) 175 an AERO interface endpoint that injects tunneled packets into an 176 AERO link. 178 egress tunnel endpoint (ETE) 179 an AERO interface endpoint that receives tunneled packets from an 180 AERO link. 182 underlying network 183 a connected IPv6 or IPv4 network routing region over which the 184 tunnel virtual overlay is configured. A typical example is an 185 enterprise network. 187 underlying interface 188 an AERO node's interface point of attachment to an underlying 189 network. 191 link-layer address 192 an IP address assigned to an AERO node's underlying interface. 193 When UDP encapsulation is used, the UDP port number is also 194 considered as part of the link-layer address. Link-layer 195 addresses are used as the encapsulation header source and 196 destination addresses. 198 network layer address 199 the source or destination address of the encapsulated IP packet. 201 end user network (EUN) 202 an internal virtual or external edge IP network that an AERO 203 Client connects to the rest of the network via the AERO interface. 205 AERO Service Prefix (ASP) 206 an IP prefix associated with the AERO link and from which AERO 207 Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 208 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 210 AERO Client Prefix (ACP) 211 a more-specific IP prefix taken from an ASP and delegated to a 212 Client. 214 Throughout the document, the simple terms "Client", "Server" and 215 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 216 respectively. Capitalization is used to distinguish these terms from 217 DHCPv6 client/server/relay. 219 Throughout the document, it is said that an address is "applied" to 220 an AERO interface since the address need not always be "assigned" to 221 the interface in the traditional sense. However, the address must at 222 least be bound to the interface in some fashion to support the 223 operation of DHCPv6 and the IPv6 ND protocol. 225 The terminology of [RFC4861] (including the names of node variables 226 and protocol constants) applies to this document. Also throughout 227 the document, the term "IP" is used to generically refer to either 228 Internet Protocol version (i.e., IPv4 or IPv6). 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119]. 234 3. Asymmetric Extended Route Optimization (AERO) 236 The following sections specify the operation of IP over Asymmetric 237 Extended Route Optimization (AERO) links: 239 3.1. AERO Link Reference Model 241 .-(::::::::) 242 .-(:::: IP ::::)-. 243 (:: Internetwork ::) 244 `-(::::::::::::)-' 245 `-(::::::)-' 246 | 247 +--------------+ +-------+------+ +--------------+ 248 |AERO Server S1| | AERO Relay R | |AERO Server S2| 249 | (default->R) | |(C->S1; D->S2)| | (default->R) | 250 | Nbr: A | +-------+------+ | Nbr: B | 251 +-------+------+ | +------+-------+ 252 | | | 253 X---+---+-------------------+------------------+---+---X 254 | AERO Link | 255 +-----+--------+ +--------+-----+ 256 |AERO Client A | |AERO Client B | 257 | default->S1 | | default->S2 | 258 +--------------+ +--------------+ 259 .-. .-. 260 ,-( _)-. ,-( _)-. 261 .-(_ IP )-. .-(_ IP )-. 262 (__ EUN ) (__ EUN ) 263 `-(______)-' `-(______)-' 264 | | 265 +--------+ +--------+ 266 | Host C | | Host D | 267 +--------+ +--------+ 269 Figure 1: AERO Link Reference Model 271 Figure 1 above presents the AERO link reference model. In this 272 model: 274 o Relay R act as a default router for its associated Servers S1 and 275 S2, and connects the AERO link to the rest of the IP Internetwork 277 o Servers S1 and S2 associate with Relay R and also act as default 278 routers for their associated Clients A and B. 280 o Clients A and B associate with Servers S1 and S2, respectively and 281 also act as default routers for their associated EUNs 283 o Hosts C and D attach to the EUNs served by Clients A and B, 284 respectively 286 In operational practice, there may be many additional Relays, Servers 287 and Clients. 289 3.2. AERO Node Types 291 AERO Relays provide default forwarding services to AERO Servers. 292 Relays forward packets between Servers connected to the same AERO 293 link and also forward packets between the AERO link and the native 294 Internetwork. Relays present the AERO link to the native 295 Internetwork as a set of one or more ASPs. Each Relay advertises the 296 ASPs for the AERO link into the native IP Internetwork and serves as 297 a gateway between the AERO link and the Internetwork. AERO Relays 298 maintain an AERO interface neighbor cache entry for each AERO Server, 299 and maintain an IP forwarding table entry for each AERO Client. 301 AERO Servers provide default forwarding services to AERO Clients. 302 Each Server also peers with each Relay in a dynamic routing protocol 303 session to advertise its list of associated Clients. Servers 304 configure a DHCPv6 server function to facilitate Prefix Delegation 305 (PD) exchanges with Clients. Each delegated prefix becomes an AERO 306 Client Prefix (ACP) taken from an ASP. Servers forward packets 307 between Clients and Relays, as well as between Clients and other 308 Clients associated with the same Server. AERO Servers maintain an 309 AERO interface neighbor cache entry for each AERO Relay. They also 310 maintain both a neighbor cache entry and an IP forwarding table entry 311 for each of their associated Clients. 313 AERO Clients act as requesting routers to receive ACPs through DHCPv6 314 PD exchanges with AERO Servers over the AERO link. (Each Client MAY 315 associate with a single Server or with multiple Servers, e.g., for 316 fault tolerance and/or load balancing.) Each IPv6 Client receives at 317 least a /64 IPv6 ACP, and may receive even shorter prefixes. 318 Similarly, each IPv4 Client receives at least a /32 IPv4 ACP (i.e., a 319 singleton IPv4 address), and may receive even shorter prefixes. AERO 320 Clients maintain an AERO interface neighbor cache entry for each of 321 their associated Servers as well as for each of their correspondent 322 Clients. 324 AERO Clients that act as routers sub-delegate portions of their ACPs 325 to links on EUNs. End system applications on Clients that act as 326 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 Clients that act as hosts bind 333 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 from the lower 64 bits of an 356 IPv4-mapped IPv6 address [RFC4291] that includes the base prefix 357 taken from the Client's IPv4 ACP. For example, if the AERO Client 358 receives the IPv4 ACP: 360 192.0.2.32/28 362 it constructs its AERO address as: 364 fe80::FFFF:192.0.2.32 366 The AERO address remains stable as the Client moves between 367 topological locations, i.e., even if its link-layer addresses change. 369 NOTE: In some cases, prospective neighbors may not have a priori 370 knowledge of the Client's ACP length and may therefore send initial 371 IPv6 ND messages with an AERO destination address that matches the 372 ACP but does not correspond to the base prefix. In that case, the 373 Client MUST accept the address as equivalent to the base address, but 374 then use the base address as the source address of any IPv6 ND 375 message replies. For example, if the Client receives the IPv6 ACP 376 2001:db8:1000:2000::/56 then subsequently receives an IPv6 ND message 377 with destination address fe80::2001:db8:1000:2001, it accepts the 378 message but uses fe80::2001:db8:1000:2000 as the source address of 379 any IPv6 ND replies. 381 3.4. AERO Interface Characteristics 383 AERO interfaces use IP-in-IPv6 encapsulation [RFC2473] to exchange 384 tunneled packets with AERO neighbors attached to an underlying IPv6 385 network, and use IP-in-IPv4 encapsulation [RFC2003][RFC4213] to 386 exchange tunneled packets with AERO neighbors attached to an 387 underlying IPv4 network. AERO interfaces can also coordinate secured 388 tunnel types such as IPsec [RFC4301] or TLS [RFC5246]. When Network 389 Address Translator (NAT) traversal and/or filtering middlebox 390 traversal may be necessary, a UDP header is further inserted 391 immediately above the IP encapsulation header. 393 AERO interfaces maintain a neighbor cache, and AERO Clients and 394 Servers use an adaptation of standard unicast IPv6 ND messaging. 395 AERO interfaces use unicast Neighbor Solicitation (NS), Neighbor 396 Advertisement (NA), Router Solicitation (RS) and Router Advertisement 397 (RA) messages the same as for any IPv6 link. AERO interfaces use two 398 redirection message types -- the first known as a Predirect message 399 and the second being the standard Redirect message (see Section 3.9). 400 AERO links further use link-local-only addressing; hence, AERO nodes 401 ignore any Prefix Information Options (PIOs) they may receive in RA 402 messages. 404 AERO interface ND messages include one or more Target Link-Layer 405 Address Options (TLLAOs) formatted as shown 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 255 being the 429 highest preference, 1 being the lowest and 0 meaning "link 430 disabled"). UDP Port Number and IP Address are set to the addresses 431 used by the target node when it sends encapsulated packets over the 432 underlying interface. When no UDP encapsulation is used, UDP Port 433 Number is set to 0. When the encapsulation IP address family is 434 IPv4, IP Address is formed as an 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 DHCPv6 and the IPv6 ND 453 protocol as well as to communicate with Relays on the link. The 454 Server configures a DHCPv6 server function to facilitate DHCPv6 PD 455 exchanges with AERO Clients. The Server also maintains a neighbor 456 cache entry for each Relay on the link, and manages per-Client 457 neighbor cache entries and IP forwarding table entries based on 458 DHCPv6 exchanges. When the Server receives an NS/RS message on the 459 AERO interface it returns an NA/RA message but does not update the 460 neighbor cache. 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 DHCPv6 PD to 469 receive an ACP from an AERO Server. Next, it applies the 470 corresponding AERO address to the AERO interface and creates a 471 neighbor cache entry for the Server, i.e., the PD exchange bootstraps 472 the provisioning of a unique link-local address. The Client 473 maintains a neighbor cache entry for each of its Servers and each of 474 its active peer Clients. When the Client receives Redirect/Predirect 475 messages on the AERO interface it updates or creates neighbor cache 476 entries, including link-layer address information. Unsolicited NA 477 messages update the cached link-layer addresses for the neighbor 478 Client (e.g., following a link-layer address change due to node 479 mobility) but do not create new neighbor cache entries. NS/NA 480 messages used for Neighbor Unreachability Detection (NUD) update 481 timers in existing neighbor cache entires but do not update link- 482 layer addresses nor create new neighbor cache entries. Finally, the 483 Client need not maintain any IP forwarding table entries for 484 neighboring Clients. Instead, it can set a single "route-to- 485 interface" default route in the IP forwarding table pointing to the 486 AERO interface, and all forwarding decisions can be made within the 487 AERO interface based on neighbor cache entries. 489 3.4.1. Coordination of Multiple Underlying Interfaces 491 AERO interfaces may be configured over multiple underlying 492 interfaces. For example, common mobile handheld devices have both 493 wireless local area network ("WLAN") and cellular wireless links. 494 These links are typically used "one at a time" with low-cost WLAN 495 preferred and highly-available cellular wireless as a standby. In a 496 more complex example, aircraft frequently have many wireless data 497 link types (e.g. satellite-based, terrestrial, air-to-air 498 directional, etc.) with diverse performance and cost properties. 500 If a Client's multiple underlying interfaces are used "one at a time" 501 (i.e., all other interfaces are in standby mode while one interface 502 is active), then Redirect, Predirect and unsolicited NA messages 503 include only a single TLLAO with Link ID set to a constant value. 505 If the Client has multiple active underlying interfaces, then from 506 the perspective of IPv6 ND it would appear to have a single link- 507 local address with multiple link-layer addresses. In that case, 508 Redirect, Predirect and unsolicited NA messages MAY include multiple 509 TLLAOs -- each with a different Link ID that corresponds to a 510 specific underlying interface of the Client. 512 3.5. AERO Interface Neighbor Cache Maintenace 514 Each AERO interface maintains a conceptual neighbor cache that 515 includes an entry for each neighbor it communicates with on the AERO 516 link, the same as for any IPv6 interface [RFC4861]. AERO interface 517 neighbor cache entires are said to be one of "permanent", "static" or 518 "dynamic". 520 Permanent neighbor cache entries are created through explicit 521 administrative action; they have no timeout values and remain in 522 place until explicitly deleted. AERO Relays maintain a permanent 523 neighbor cache entry for each Server on the link, and AERO Servers 524 maintain a permanent neighbor cache entry for each Relay on the link. 526 Static neighbor cache entries are created though DHCPv6 PD exchanges 527 and remain in place for durations bounded by prefix lifetimes. AERO 528 Servers maintain a static neighbor cache entry for each of their 529 associated Clients, and AERO Clients maintain a static neighbor cache 530 for each of their associated Servers. When an AERO Server sends a 531 DHCPv6 Reply message response to a Client's DHCPv6 Solicit or Renew 532 message, it creates or updates a static neighbor cache entry based on 533 the Client's AERO address as the network-layer address, the prefix 534 lifetime as the neighbor cache entry lifetime, the Client's 535 encapsulation IP address and UDP port number as the link-layer 536 address and the prefix length as the length to apply to the AERO 537 address. When an AERO Client receives a DHCPv6 Reply message from a 538 Server, it creates or updates a static neighbor cache entry based on 539 the Reply message link-local source address as the network-layer 540 address, the prefix lifetime as the neighbor cache entry lifetime, 541 and the encapsulation IP source address and UDP source port number as 542 the link-layer address. 544 Dynamic neighbor cache entries are created based on receipt of an 545 IPv6 ND message, and are garbage-collected if not used within a short 546 timescale. AERO Clients maintain dynamic neighbor cache entries for 547 each of their active correspondent Clients with lifetimes based on 548 IPv6 ND messaging constants. When an AERO Client receives a valid 549 Predirect message it creates or updates a dynamic neighbor cache 550 entry for the Predirect target network-layer and link-layer addresses 551 plus prefix length. The node then sets an "AcceptTime" variable for 552 the neighbor and uses this value to determine whether packets 553 received from the predirected neighbor can be accepted. When an AERO 554 Client receives a valid Redirect message it creates or updates a 555 dynamic neighbor cache entry for the Redirect target network-layer 556 and link-layer addresses plus prefix length. The Client then sets a 557 "ForwardTime" variable for the neighbor and uses this value to 558 determine whether packets can be sent directly to the redirected 559 neighbor. The Client also maintains a "MaxRetry" variable to limit 560 the number of keepalives sent when a neighbor may have gone 561 unreachable. 563 For dynamic neighbor cache entries, when an AERO Client receives a 564 valid NS message it (re)sets AcceptTime for the neighbor to 565 ACCEPT_TIME. When an AERO Client receives a valid solicited NA 566 message, it (re)sets ForwardTime for the neighbor to FORWARD_TIME and 567 sets MaxRetry to MAX_RETRY. When an AERO Client receives a valid 568 unsolicited NA message, it updates the neighbor's link-layer 569 addresses but DOES NOT reset AcceptTime, ForwardTime or MaxRetry. 571 It is RECOMMENDED that FORWARD_TIME be set to the default constant 572 value 30 seconds to match the default REACHABLE_TIME value specified 573 for IPv6 ND [RFC4861]. 575 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 576 value 40 seconds to allow a 10 second window so that the AERO 577 redirection procedure can converge before AcceptTime decrements below 578 FORWARD_TIME. 580 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 581 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 583 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 584 administratively set, if necessary, to better match the AERO link's 585 performance characteristics; however, if different values are chosen, 586 all nodes on the link MUST consistently configure the same values. 587 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 588 sufficiently longer than FORWARD_TIME to allow the AERO redirection 589 procedure to converge. 591 3.6. AERO Interface Sending Algorithm 593 IP packets enter a node's AERO interface either from the network 594 layer (i.e., from a local application or the IP forwarding system), 595 or from the link-layer (i.e., from the AERO tunnel virtual link). 596 Packets that enter the AERO interface from the network layer are 597 encapsulated and admitted into the AERO link (i.e., they are 598 tunnelled to an AERO interface neighbor). Packets that enter the 599 AERO interface from the link layer are either re-admitted into the 600 AERO link or delivered to the network layer where they are subject to 601 either local delivery or IP forwarding. Since each AERO node has 602 only partial information about neighbors on the link, AERO interfaces 603 may forward packets with link-local destination addresses at a layer 604 below the network layer. This means that AERO nodes act as both IP 605 routers and link-layer "bridges". AERO interface sending 606 considerations for Clients, Servers and Relays are given below. 608 When an IP packet enters a Client's AERO interface from the network 609 layer, if the destination is covered by an ASP the Client searches 610 for a dynamic neighbor cache entry with a non-zero ForwardTime and an 611 AERO address that matches the packet's destination address. (The 612 destination address may be either an address covered by the 613 neighbor's ACP or the (link-local) AERO address itself.) If there is 614 a match, the Client uses a link-layer address in the entry as the 615 link-layer address for encapsulation then admits the packet into the 616 AERO link. If there is no match, the Client instead uses the link- 617 layer address of a neighboring Server as the link-layer address for 618 encapsulation. 620 When an IP packet enters a Server's AERO interface from the link 621 layer, if the destination is covered by an ASP the Server searches 622 for a static neighbor cache entry with an AERO address that matches 623 the packet's destination address. (The destination address may be 624 either an address covered by the neighbor's ACP or the AERO address 625 itself.) If there is a match, the Server uses a link-layer address 626 in the entry as the link-layer address for encapsulation and re- 627 admits the packet into the AERO link. If there is no match, the 628 Server instead uses the link-layer address in any permanent neighbor 629 cache entry as the link-layer address for encapsulation. When a 630 Server receives a packet from a Relay, the Server MUST NOT loop the 631 packet back to the same or a different Relay. 633 When an IP packet enters a Relay's AERO interface from the network 634 layer, the Relay searches its IP forwarding table for an entry that 635 is covered by an ASP and also matches the destination. If there is a 636 match, the Relay uses the link-layer address in the neighbor cache 637 entry for the next-hop Server as the link-layer address for 638 encapsulation and admits the packet into the AERO link. When an IP 639 packet enters a Relay's AERO interface from the link-layer, if the 640 destination is not a link-local address and is not covered by an ASP 641 the Relay removes the packet from the AERO interface and uses IP 642 forwarding to forward the packet to the Internetwork. If the 643 destination address is covered by an ASP, and there is a more- 644 specific IP forwarding table entry that matches the destination, the 645 Relay uses the link-layer address in the neighbor cache entry for the 646 next-hop Server as the link-layer address for encapsulation and re- 647 admits the packet into the AERO link. If there is no more-specific 648 entry, the Relay instead drops the packet. When an Relay receives a 649 packet from a Server, the Relay MUST NOT forward the packet back to 650 the same Server. 652 Note that in the above that the link-layer address for encapsulation 653 may be through consulting either the neighbor cache or the IP 654 forwarding table. IP forwarding is therefore linked to IPv6 ND via 655 the AERO address. 657 When an AERO node re-admits a packet into the AERO link, the node 658 MUST NOT decrement the network layer TTL/Hop-count. 660 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 662 AERO interfaces encapsulate IP packets according to whether they are 663 entering the AERO interface from the network layer or if they are 664 being re-admitted into the same AERO link they arrived on. This 665 latter form of encapsulation is known as "re-encapsulation". 667 AERO interfaces encapsulate packets per the specifications in 668 [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246] (etc.) except that the 669 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 670 and "Congestion Experienced" values in the packet's IP header into 671 the corresponding fields in the encapsulation header. For packets 672 undergoing re-encapsulation, the AERO interface instead copies the 673 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 674 Experienced" values in the original encapsulation header into the 675 corresponding fields in the new encapsulation header (i.e., the 676 values are transferred between encapsulation headers and *not* copied 677 from the encapsulated packet's network-layer header). 679 When AERO UDP encapsulation is used, the AERO interface encapsulates 680 the packet per the above tunneling specifications except that it 681 inserts a UDP header between the encapsulation header and the 682 packet's IP header. The AERO interface sets the UDP source port to a 683 constant value that it will use in each successive packet it sends, 684 sets the UDP checksum field to zero (see: [RFC6935][RFC6936]) and 685 sets the UDP length field to the length of the IP packet plus 8 bytes 686 for the UDP header itself. For packets sent via a Server, the AERO 687 interface sets the UDP destination port to 8060 (i.e., the IANA- 688 registered port number for AERO) when AERO-only encapsulation is 689 used. For packets sent to a neighboring Client, the AERO interface 690 sets the UDP destination port to the port value stored in the 691 neighbor cache entry for this neighbor. 693 The AERO interface next sets the IP protocol number in the 694 encapsulation header to the appropriate value for the first protocol 695 layer within the encapsulation (e.g., IPv4, IPv6, UDP, IPsec, etc.). 696 When IPv6 is used as the encapsulation protocol, the interface then 697 sets the flow label value in the encapsulation header the same as 698 described in [RFC6438]. When IPv4 is used as the encapsulation 699 protocol, the AERO interface sets the DF bit as discussed in 700 Section 3.8. 702 AERO interfaces decapsulate packets destined either to the node 703 itself or to a destination reached via an interface other than the 704 AERO interface the packet was received on. When AERO UDP 705 encapsulation is used (i.e., when a UDP header with destination port 706 8060 is present) the interface examines the first octet of the 707 encapsulated packet. The packet is accepted if the most significant 708 four bits of the first octet encode the value '0110' (i.e., the 709 version number value for IPv6) or the value '0100' (i.e., the version 710 number value for IPv4). Otherwise, the packet is accepted if the 711 first octet encodes a valid IP protocol number per the IANA 712 "protocol-numbers" registry that matches a supported encapsulation 713 type. Otherwise, the packet is discarded. 715 Further decapsulation then proceeds according to the appropriate 716 tunnel type per the above specifications. 718 3.8. AERO Interface Data Origin Authentication 720 AERO nodes employ simple data origin authentication procedures for 721 encapsulated packets they receive from other nodes on the AERO link. 722 In particular, AERO Clients accept encapsulated packets with a link- 723 layer source address belonging to one of their current AERO Servers, 724 and AERO Servers accept encapsulated packets with a link-layer source 725 address belonging to one of their current Clients. 727 AERO Clients and Servers also accept encapsulated packets if there is 728 a dynamic neighbor cache entry with an AERO address that matches the 729 packet's network-layer source address prefix, with a link-layer 730 address that matches the packet's link-layer source address, and 731 AcceptTime is non-zero. 733 An AERO Server also accepts packets with a link-layer source address 734 that matches one of its associated Relays, and an AERO Relay accepts 735 packets with a source address that matches one of its associated 736 Servers. 738 Finally, AERO Servers accept DHCPv6 messages even if the link-layer 739 source address does not belong to one of their current Clients. The 740 DHCPv6 server will authenticate the message and (assuming 741 authentication succeeds) create or update a static neighbor cache 742 entry for the source Client. 744 Note that this simple data origin authentication only applies to 745 environments in which link-layer addresses cannot be spoofed. 746 Additional security mitigations may be necessary in other 747 environments. 749 3.9. AERO Interface MTU Considerations 751 The AERO link Maximum Transmission Unit (MTU) is 64KB minus the 752 encapsulation overhead for IPv4 as the link-layer [RFC0791] and 4GB 753 minus the encapsulation overhead for IPv6 as the link layer 754 [RFC2675]. This is the most that IPv4 and IPv6 (respectively) can 755 convey within the constraints of protocol constants, but actual sizes 756 available for tunneling will frequently be much smaller. 758 The base tunneling specifications for IPv4 and IPv6 typically set a 759 static MTU on the tunnel interface to 1500 bytes minus the 760 encapsulation overhead or smaller still if the tunnel is likely to 761 incur additional encapsulations on the path. This can result in path 762 MTU related black holes when packets that are too large to be 763 accommodated over the AERO link are dropped, but the resulting ICMP 764 Packet Too Big (PTB) messages are lost on the return path. As a 765 result, AERO nodes use the following MTU mitigations to accommodate 766 larger packets. 768 AERO nodes set their AERO interface MTU to the larger of the 769 underlying interface MTU minus the encapsulation overhead, and 1500 770 bytes. (If there are multiple underlying interfaces, the node sets 771 the AERO interface MTU according to the largest underlying interface 772 MTU, or 64KB /4G minus the encapsulation overhead if the largest MTU 773 cannot be determined.) AERO nodes optionally cache other per- 774 neighbor MTU values in the underlying IP path MTU discovery cache 775 initialized to the underlying interface MTU. 777 AERO nodes admit packets that are no larger than 1280 bytes minus the 778 encapsulation overhead (*) as well as packets that are larger than 779 1500 bytes into the tunnel without fragmentation, i.e., as long as 780 they are no larger than the AERO interface MTU before encapsulation 781 and also no larger than the cached per-neighbor MTU following 782 encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit 783 to 0 for packets no larger than 1280 bytes minus the encapsulation 784 overhead (*) and sets the DF bit to 1 for packets larger than 1500 785 bytes. If a large packet is lost in the path, the node may 786 optionally cache the MTU reported in the resulting PTB message or may 787 ignore the message, e.g., if there is a possibility that the message 788 is spurious. 790 For packets destined to an AERO node that are larger than 1280 bytes 791 minus the encapsulation overhead (*) but no larger than 1500 bytes, 792 the node uses IP fragmentation to fragment the encapsulated packet 793 into two pieces (where the first fragment contains 1024 bytes of the 794 original IP packet) then admits the fragments into the tunnel. If 795 the link-layer protocol is IPv4, the node admits each fragment into 796 the tunnel with DF set to 0 and subject to rate limiting to avoid 797 reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the 798 node also sends a 1500 byte probe message (**) to the neighbor, 799 subject to rate limiting. 801 To construct a probe, the node prepares an NS message with a Nonce 802 option plus trailing padding octets added to a length of 1500 bytes 803 without including the length of the padding in the IPv6 Payload 804 Length field. The node then encapsulates the NS in the encapsulation 805 headers (while including the length of the padding in the 806 encapsulation header length fields), sets DF to 1 (for IPv4) and 807 sends the padded NS message to the neighbor. If the neighbor returns 808 an NA message with a correct Nonce value, the node may then send 809 whole packets within this size range and (for IPv4) relax the rate 810 limiting requirement. (Note that the trailing padding SHOULD NOT be 811 included within the Nonce option itself but rather as padding beyond 812 the last option in the NS message; otherwise, the (large) Nonce 813 option would be echoed back in the solicited NA message and may be 814 lost at a link with a small MTU along the reverse path.) 816 AERO nodes MUST be capable of reassembling packets up to 1500 bytes 817 plus the encapsulation overhead length. It is therefore RECOMMENDED 818 that AERO nodes be capable of reassembling at least 2KB. 820 (*) Note that if it is known without probing that the minimum Path 821 MTU to an AERO node is MINMTU bytes (where 1280 < MINMTU < 1500) then 822 MINMTU can be used instead of 1280 in the fragmentation threshold 823 considerations listed above. 825 (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used 826 for MTU probing purposes, since smaller probes may be fragmented if 827 there is a nested tunnel somewhere on the path to the neighbor. 828 Probe sizes larger than 1500 bytes MAY be used, but may be 829 unnecessary since original sources are expected to implement 830 [RFC4821] when sending large packets. 832 3.10. AERO Router Discovery, Prefix Delegation and Address 833 Configuration 835 3.10.1. AERO DHCPv6 Service Model 837 Each AERO Server configures a DHCPv6 server function to facilitate PD 838 requests from Clients. Each Server is pre-configured with an 839 identical list of ACP-to-Client ID mappings for all Clients enrolled 840 in the AERO system, as well as any information necessary to 841 authenticate Clients. The configuration information is maintained by 842 a central administrative authority for the AERO link and securely 843 propagated to all Servers whenever a new Client is enrolled or an 844 existing Client is withdrawn. 846 With these identical configurations, each Server can function 847 independently of all other Servers, including the maintenance of 848 active leases. Therefore, no Server-to-Server DHCPv6 state 849 synchronization is necessary, and Clients can optionally hold 850 separate leases for the same ACP from multiple Servers. 852 In this way, Clients can easily associate with multiple Servers, and 853 can receive new leases from new Servers before deprecating leases 854 held through old Servers. This enables a graceful "make-before- 855 break" capability. 857 3.10.2. AERO Client Behavior 859 AERO Clients discover the link-layer addresses of AERO Servers via 860 static configuration, or through an automated means such as DNS name 861 resolution. In the absence of other information, the Client resolves 862 the Fully-Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" 863 where "linkupnetworks" is a constant text string and "[domainname]" 864 is the connection-specific DNS suffix for the Client's underlying 865 network connection (e.g., "example.com"). After discovering the 866 link-layer addresses, the Client associates with one or more of the 867 corresponding Servers. 869 To associate with a Server, the Client acts as a requesting router to 870 request an ACP through a DHCPv6 PD two-message 871 exchange[RFC3315][RFC3633] in which the Solicit message uses the IPv6 872 "unspecified" address (i.e., "::") as the IPv6 source address, 873 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 874 and the link-layer address of the Server as the link-layer 875 destination address. The Client includes a Rapid Commit option as 876 well as a Client Identifier option with a DHCP Unique Identifier 877 (DUID), plus any necessary authentication options to identify itself 878 to the DHCPv6 server. The Client also includes a Client Link Layer 879 Address Option (CLLAO) [RFC6939] with the format shown in Figure 3 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | OPTION_CLIENT_LINKLAYER_ADDR | option-length | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | link-layer type (16 bits) | Link ID | Preference | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Figure 3: AERO Client Link-Layer Address Option (CLLAO) Format 891 The Client sets the CLLAO 'option-length' field to 4 and sets the 892 'link-layer type' field to TBD1 (see: IANA Considerations), then 893 includes appropriate Link ID and Preference values for the underlying 894 interface over which the Solicit will be issued (note that these are 895 the same values that would be included in a TLLAO as shown in 896 Figure 2). If the Client is pre-provisioned with an ACP associated 897 with the AERO service, it MAY also include the ACP in the Solicit 898 message Identity Association (IA) option to indicate its preferred 899 ACP to the DHCPv6 server. The Client then sends the encapsulated 900 DHCPv6 request via the underlying interface. 902 When the Client receives its ACP and the set of ASPs via a DHCPv6 903 Reply from the AERO Server, it creates a static neighbor cache entry 904 with the Server's link-local address (i.e., fe80::ID) as the network- 905 layer address and the Server's encapsulation address as the link- 906 layer address. The Client then records the lifetime for the ACP in 907 the neighbor cache entry and marks the neighbor cache entry as 908 "default", i.e., the Client considers the Server as a default router. 909 If the Reply message contains a Vendor-Specific Information Option 910 (see: Section 3.10.3) the Client also caches each ASP in the option. 912 The Client then applies the AERO address to the AERO interface and 913 sub-delegates the ACP to nodes and links within its attached EUNs 914 (the AERO address thereafter remains stable as the Client moves). 915 The Client also assigns a default IP route to the AERO interface as a 916 route-to-interface, i.e., with no explicit next-hop. The next hop 917 will then be determined after a packet has been submitted to the AERO 918 interface by inspecting the neighbor cache (see above). 920 The Client subsequently renews its ACP delegation through each of its 921 Servers by performing DHCPv6 Renew/Reply exchanges with its AERO 922 address as the IPv6 source address, 923 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address, 924 the link-layer address of a Server as the link-layer destination 925 address and the same Client identifier, authentication options and 926 CLLAO option as was used in the initial PD request. 928 Since the Client's AERO address is configured from the unique ACP 929 delegation it receives, there is no need for Duplicate Address 930 Detection (DAD) on AERO links. Other nodes maliciously attempting to 931 hijack an authorized Client's AERO address will be denied access to 932 the network by the DHCPv6 server due to an unacceptable link-layer 933 address and/or security parameters (see: Security Considerations). 935 AERO Clients ignore the IP address and UDP port number in any S/TLLAO 936 options in ND messages they receive directly from another AERO 937 Client, but examine the Link ID and Preference values to match the 938 message with the correct link-layer address information. 940 When a source Client forwards a packet to a prospective destination 941 Client (i.e., one for which the packet's destination address is 942 covered by an ASP), the source Client initiates an AERO route 943 optimization procedure as specified in Section 3.12. 945 3.10.3. AERO Server Behavior 947 AERO Servers configure a DHCPv6 server function on their AERO links. 948 AERO Servers arrange to add their encapsulation layer IP addresses 949 (i.e., their link-layer addresses) to the DNS resource records for 950 the FQDN "linkupnetworks.[domainname]" before entering service. 952 When an AERO Server receives a prospective Client's DHCPv6 PD Solicit 953 message, it first authenticates the message. If authentication 954 succeeds, the Server determines the correct ACP to delegate to the 955 Client by matching the Client's DUID within an online directory 956 service (e.g., LDAP). The Server then delegates the ACP and creates 957 a static neighbor cache entry for the Client's AERO address with 958 lifetime set to no more than the lease lifetime and the Client's 959 link-layer address as the link-layer address for the Link ID 960 specified in the CLLAO option. The Server then creates an IP 961 forwarding table entry so that the inter-Server/Relay routing system 962 will propagate the ACP to all Relays (see: Section 3.11). Finally, 963 the Server sends a DHCPv6 Reply message to the Client while using 964 fe80::ID as the IPv6 source address, the Client's AERO address as the 965 IPv6 destination address, and the Client's link-layer address as the 966 destination link-layer address. The Server also includes a Server 967 Unicast option with server-address set to fe80::ID so that all future 968 Client/Server transactions will be link-local-only unicast over the 969 AERO link. 971 When the Server sends the DHCPv6 Reply message, it also includes a 972 DHCPv6 Vendor-Specific Information Option with 'enterprise-number' 973 set to "TBD2" (see: IANA Considerations). The option is formatted as 974 shown in[RFC3315] and with the AERO enterprise-specific format shown 975 in Figure 4: 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | OPTION_VENDOR_OPTS | option-len | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | enterprise-number ("TBD2") | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Reserved | Prefix Length | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | | 986 + ASP (1) + 987 | | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Reserved | Prefix Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | | 992 + ASP (2) + 993 | | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Reserved | Prefix Length | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | | 998 + ASP (3) + 999 | | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 . (etc.) . 1002 . . 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Figure 4: AERO Vendor-Specific Information Option 1007 Per Figure 4, the option includes one or more ASP. The ASP field 1008 contains the IP prefix as it would appear in the interface identifier 1009 portion of the corresponding AERO address (see: Section 3.3). For 1010 IPv6, valid values for the Prefix Length field are 0 through 64; for 1011 IPv4, valid values are 0 through 32. 1013 After the initial Solicit/Reply exchange, the AERO Server maintains 1014 the neighbor cache entry for the Client as long as the lease lifetime 1015 remains current. If the Client issues a Renew/Reply exchange, the 1016 Server extends the lifetime. If the Client issues a Release/Reply 1017 exchange, or if the Client does not issue a Renew/Reply within the 1018 lease lifetime, the Server deletes the neighbor cache entry for the 1019 Client and withdraws the IP route from the routing system. 1021 3.11. AERO Relay/Server Routing System 1023 Relays require full topology information of all Client/Server 1024 associations, while individual Servers only require partial topology 1025 information, i.e., they only need to know the ACPs associated with 1026 their current set of associated Clients. This is accomplished 1027 through the use of an internal instance of the Border Gateway 1028 Protocol (BGP) [RFC4271] coordinated between Servers and Relays. 1029 This internal BGP instance does not interact with the public Internet 1030 BGP instance; therefore, the AERO link is presented to the IP 1031 Internetwork as a small set of ASPs as opposed to the full set of 1032 individual ACPs. 1034 In a reference BGP arrangement, each AERO Server is configured as an 1035 Autonomous System Border Router (ASBR) for a stub Autonomous System 1036 (AS) (possibly using a private AS Number (ASN) [RFC1930]), and each 1037 Server further peers with each Relay but does not peer with other 1038 Servers. Similarly, Relays need not peer with each other, since they 1039 will receive all updates from all Servers and will therefore have a 1040 consistent view of the AERO link ACP delegations. 1042 Each Server maintains a working set of associated Clients, and 1043 dynamically announces new ACPs and withdraws departed ACPs in its BGP 1044 updates to Relays. Relays do not send BGP updates to Servers, 1045 however, such that the BGP route reporting is unidirectional from the 1046 Servers to the Relays. 1048 The Relays therefore discover the full topology of the AERO link in 1049 terms of the working set of ACPs associated with each Server, while 1050 the Servers only discover the ACPs of their associated Clients. 1051 Since Clients are expected to remain associated with their current 1052 set of Servers for extended timeframes, the amount of BGP control 1053 messaging between Servers and Relays should be minimal. However, BGP 1054 peers SHOULD dampen any route oscillations caused by impatient 1055 Clients that repeatedly associate and disassociate with Servers. 1057 3.12. AERO Redirection 1059 3.12.1. Reference Operational Scenario 1061 Figure 5 depicts the AERO redirection reference operational scenario, 1062 using IPv6 addressing as the example (while not shown, a 1063 corresponding example for IPv4 addressing can be easily constructed). 1064 The figure shows an AERO Relay ('R'), two AERO Servers ('S1', 'S2'), 1065 two AERO Clients ('A', 'B') and two ordinary IPv6 hosts ('C', 'D'): 1067 +--------------+ +--------------+ +--------------+ 1068 | Server S1 | | Relay R | | Server S2 | 1069 | Nbr: A | |(C->S1; D->S2)| | Nbr: B | 1070 +--------------+ +--------------+ +--------------+ 1071 fe80::2 fe80::1 fe80::3 1072 L2(S1) L2(R) L2(S2) 1073 | | | 1074 X-----+-----+------------------+-----------------+----+----X 1075 | AERO Link | 1076 L2(A) L2(B) 1077 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1078 +--------------+ +--------------+ 1079 | AERO Client A| | AERO Client B| 1080 | (default->S1)| | (default->S2)| 1081 +--------------+ +--------------+ 1082 2001:DB8:0::/48 2001:DB8:1::/48 1083 | | 1084 .-. .-. 1085 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1086 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1087 (__ EUN )--| Host C | | Host D |--(__ EUN ) 1088 `-(______)-' +---------+ +---------+ `-(______)-' 1090 Figure 5: AERO Reference Operational Scenario 1092 In Figure 5, Relay ('R') applies the address fe80::1 to its AERO 1093 interface with link-layer address L2(R), Server ('S1') applies the 1094 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1095 applies the address fe80::3 with link-layer address L2(S2). Servers 1096 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1097 published list of valid Servers for the AERO link. 1099 AERO Client ('A') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1100 exchange via AERO Server ('S1') then applies the address 1101 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1102 L2(A). Client ('A') configures a default route and neighbor cache 1103 entry via the AERO interface with next-hop address fe80::2 and link- 1104 layer address L2(S1), then sub-delegates the ACP to its attached 1105 EUNs. IPv6 host ('C') connects to the EUN, and configures the 1106 address 2001:db8:0::1. 1108 AERO Client ('B') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1109 exchange via AERO Server ('S2') then applies the address 1110 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1111 L2(B). Client ('B') configures a default route and neighbor cache 1112 entry via the AERO interface with next-hop address fe80::3 and link- 1113 layer address L2(S2), then sub-delegates the ACP to its attached 1114 EUNs. IPv6 host ('D') connects to the EUN, and configures the 1115 address 2001:db8:1::1. 1117 3.12.2. Concept of Operations 1119 Again, with reference to Figure 5, when source host ('C') sends a 1120 packet to destination host ('D'), the packet is first forwarded over 1121 the source host's attached EUN to Client ('A'). Client ('A') then 1122 forwards the packet via its AERO interface to Server ('S1') and also 1123 sends a Predirect message toward Client ('B') via Server ('S1'). 1124 Server ('S1') then re-encapsulates and forwards both the packet and 1125 the Predirect message out the same AERO interface toward Client ('B') 1126 via Relay ('R'). 1128 When Relay ('R') receives the packet and Predirect message, it 1129 consults its forwarding table to discover Server ('S2') as the next 1130 hop toward Client ('B'). Relay ('R') then forwards both the packet 1131 and the Predirect message to Server ('S2'), which then forwards them 1132 to Client ('B'). 1134 After Client ('B') receives the Predirect message, it process the 1135 message and returns a Redirect message toward Client ('A') via Server 1136 ('S2'). During the process, Client ('B') also creates or updates a 1137 dynamic neighbor cache entry for Client ('A'). 1139 When Server ('S2') receives the Redirect message, it re-encapsulates 1140 the message and forwards it on to Relay ('R'), which forwards the 1141 message on to Server ('S1') which forwards the message on to Client 1142 ('A'). After Client ('A') receives the Redirect message, it 1143 processes the message and creates or updates a dynamic neighbor cache 1144 entry for Client ('C'). 1146 Following the above Predirect/Redirect message exchange, forwarding 1147 of packets from Client ('A') to Client ('B') without involving any 1148 intermediate nodes is enabled. The mechanisms that support this 1149 exchange are specified in the following sections. 1151 3.12.3. Message Format 1153 AERO Redirect/Predirect messages use the same format as for ICMPv6 1154 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1155 include a new "Prefix Length" field taken from the low-order 8 bits 1156 of the Redirect message Reserved field. For IPv6, valid values for 1157 the Prefix Length field are 0 through 64; for IPv4, valid values are 1158 0 through 32. The Redirect/Predirect messages are formatted as shown 1159 in Figure 6: 1161 0 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Type (=137) | Code (=0/1) | Checksum | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Reserved | Prefix Length | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | | 1169 + + 1170 | | 1171 + Target Address + 1172 | | 1173 + + 1174 | | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | | 1177 + + 1178 | | 1179 + Destination Address + 1180 | | 1181 + + 1182 | | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Options ... 1185 +-+-+-+-+-+-+-+-+-+-+-+- 1187 Figure 6: AERO Redirect/Predirect Message Format 1189 3.12.4. Sending Predirects 1191 When a Client forwards a packet with a source address from one of its 1192 ACPs toward a destination address covered by an ASP (i.e., toward 1193 another AERO Client connected to the same AERO link), the source 1194 Client MAY send a Predirect message forward toward the destination 1195 Client via the Server. 1197 In the reference operational scenario, when Client ('A') forwards a 1198 packet toward Client ('B'), it MAY also send a Predirect message 1199 forward toward Client ('B'), subject to rate limiting (see 1200 Section 8.2 of [RFC4861]). Client ('A') prepares the Predirect 1201 message as follows: 1203 o the link-layer source address is set to 'L2(A)' (i.e., the link- 1204 layer address of Client ('A')). 1206 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1207 link-layer address of Server ('S1')). 1209 o the network-layer source address is set to fe80::2001:db8:0:0 1210 (i.e., the AERO address of Client ('A')). 1212 o the network-layer destination address is set to fe80::2001:db8:1:0 1213 (i.e., the AERO address of Client ('B')). 1215 o the Type is set to 137. 1217 o the Code is set to 1 to indicate "Predirect". 1219 o the Prefix Length is set to the length of the prefix to be applied 1220 to the Target Address. 1222 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1223 address of Client ('A')). 1225 o the Destination Address is set to the source address of the 1226 originating packet that triggered the Predirection event. (If the 1227 originating packet is an IPv4 packet, the address is constructed 1228 in IPv4-compatible IPv6 address format). 1230 o the message includes one or more TLLAOs with Link ID and 1231 Preference set to appropriate values for Client ('A')'s underlying 1232 interfaces, and with UDP Port Number and IP Address set to 0'. 1234 o the message SHOULD include a Timestamp option and a Nonce option. 1236 o the message includes a Redirected Header Option (RHO) that 1237 contains the originating packet truncated to ensure that at least 1238 the network-layer header is included but the size of the message 1239 does not exceed 1280 bytes. 1241 Note that the act of sending Predirect messages is cited as "MAY", 1242 since Client ('A') may have advanced knowledge that the direct path 1243 to Client ('B') would be unusable or otherwise undesirable. If the 1244 direct path later becomes unusable after the initial route 1245 optimization, Client ('A') simply allows packets to again flow 1246 through Server ('S1'). 1248 3.12.5. Re-encapsulating and Relaying Predirects 1250 When Server ('S1') receives a Predirect message from Client ('A'), it 1251 first verifies that the TLLAOs in the Predirect are a proper subset 1252 of the Link IDs in Client ('A')'s neighbor cache entry. If the 1253 Client's TLLAOs are not acceptable, Server ('S1') discards the 1254 message. Otherwise, Server ('S1') validates the message according to 1255 the ICMPv6 Redirect message validation rules in Section 8.1 of 1256 [RFC4861], except that the Predirect has Code=1. Server ('S1') also 1257 verifies that Client ('A') is authorized to use the Prefix Length in 1258 the Predirect when applied to the AERO address in the network-layer 1259 source address by searching for the AERO address in the neighbor 1260 cache. If validation fails, Server ('S1') discards the Predirect; 1261 otherwise, it copies the correct UDP Port numbers and IP Addresses 1262 for Client ('A')'s links into the (previously empty) TLLAOs. 1264 Server ('S1') then examines the network-layer destination address of 1265 the Predirect to determine the next hop toward Client ('B') by 1266 searching for the AERO address in the neighbor cache. Since Client 1267 ('B') is not one of its neighbors, Server ('S1') re-encapsulates the 1268 Predirect and relays it via Relay ('R') by changing the link-layer 1269 source address of the message to 'L2(S1)' and changing the link-layer 1270 destination address to 'L2(R)'. Server ('S1') finally forwards the 1271 re-encapsulated message to Relay ('R') without decrementing the 1272 network-layer TTL/Hop Limit field. 1274 When Relay ('R') receives the Predirect message from Server ('S1') it 1275 determines that Server ('S2') is the next hop toward Client ('B') by 1276 consulting its forwarding table. Relay ('R') then re-encapsulates 1277 the Predirect while changing the link-layer source address to 'L2(R)' 1278 and changing the link-layer destination address to 'L2(S2)'. Relay 1279 ('R') then relays the Predirect via Server ('S2'). 1281 When Server ('S2') receives the Predirect message from Relay ('R') it 1282 determines that Client ('B') is a neighbor by consulting its neighbor 1283 cache. Server ('S2') then re-encapsulates the Predirect while 1284 changing the link-layer source address to 'L2(S2)' and changing the 1285 link-layer destination address to 'L2(B)'. Server ('S2') then 1286 forwards the message to Client ('B'). 1288 3.12.6. Processing Predirects and Sending Redirects 1290 When Client ('B') receives the Predirect message, it accepts the 1291 Predirect only if the message has a link-layer source address of one 1292 of its Servers (e.g., L2(S2)). Client ('B') further accepts the 1293 message only if it is willing to serve as a redirection target. 1294 Next, Client ('B') validates the message according to the ICMPv6 1295 Redirect message validation rules in Section 8.1 of [RFC4861], except 1296 that it accepts the message even though Code=1 and even though the 1297 network-layer source address is not that of it's current first-hop 1298 router. 1300 In the reference operational scenario, when Client ('B') receives a 1301 valid Predirect message, it either creates or updates a dynamic 1302 neighbor cache entry that stores the Target Address of the message as 1303 the network-layer address of Client ('A') , stores the link-layer 1304 addresses found in the TLLAOs as the link-layer addresses of Client 1305 ('A') and stores the Prefix Length as the length to be applied to the 1306 network-layer address for forwarding purposes. Client ('B') then 1307 sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1309 After processing the message, Client ('B') prepares a Redirect 1310 message response as follows: 1312 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1313 layer address of Client ('B')). 1315 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1316 link-layer address of Server ('S2')). 1318 o the network-layer source address is set to fe80::2001:db8:1:0 1319 (i.e., the AERO address of Client ('B')). 1321 o the network-layer destination address is set to fe80::2001:db8:0:0 1322 (i.e., the AERO address of Client ('A')). 1324 o the Type is set to 137. 1326 o the Code is set to 0 to indicate "Redirect". 1328 o the Prefix Length is set to the length of the prefix to be applied 1329 to the Target Address. 1331 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1332 address of Client ('B')). 1334 o the Destination Address is set to the destination address of the 1335 originating packet that triggered the Redirection event. (If the 1336 originating packet is an IPv4 packet, the address is constructed 1337 in IPv4-compatible IPv6 address format). 1339 o the message includes one or more TLLAOs with Link ID and 1340 Preference set to appropriate values for Client ('B')'s underlying 1341 interfaces, and with UDP Port Number and IP Address set to '0'. 1343 o the message SHOULD include a Timestamp option and MUST echo the 1344 Nonce option received in the Predirect (i.e., if a Nonce option is 1345 included). 1347 o the message includes as much of the RHO copied from the 1348 corresponding AERO Predirect message as possible such that at 1349 least the network-layer header is included but the size of the 1350 message does not exceed 1280 bytes. 1352 After Client ('B') prepares the Redirect message, it sends the 1353 message to Server ('S2'). 1355 3.12.7. Re-encapsulating and Relaying Redirects 1357 When Server ('S2') receives a Redirect message from Client ('B'), it 1358 first verifies that the TLLAOs in the Redirect are a proper subset of 1359 the Link IDs in Client ('B')'s neighbor cache entry. If the Client's 1360 TLLAOs are not acceptable, Server ('S2') discards the message. 1361 Otherwise, Server ('S2') validates the message according to the 1362 ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861]. 1363 Server ('S2') also verifies that Client ('B') is authorized to use 1364 the Prefix Length in the Redirect when applied to the AERO address in 1365 the network-layer source address by searching for the AERO address in 1366 the neighbor cache. If validation fails, Server ('S2') discards the 1367 Predirect; otherwise, it copies the correct UDP Port numbers and IP 1368 Addresses for Client ('B')'s links into the (previously empty) 1369 TLLAOs. 1371 Server ('S2') then examines the network-layer destination address of 1372 the Predirect to determine the next hop toward Client ('A') by 1373 searching for the AERO address in the neighbor cache. Since Client 1374 ('A') is not one of its neighbors, Server ('S2') re-encapsulates the 1375 Predirect and relays it via Relay ('R') by changing the link-layer 1376 source address of the message to 'L2(S2)' and changing the link-layer 1377 destination address to 'L2(R)'. Server ('S2') finally forwards the 1378 re-encapsulated message to Relay ('R') without decrementing the 1379 network-layer TTL/Hop Limit field. 1381 When Relay ('R') receives the Predirect message from Server ('S2') it 1382 determines that Server ('S1') is the next hop toward Client ('A') by 1383 consulting its forwarding table. Relay ('R') then re-encapsulates 1384 the Predirect while changing the link-layer source address to 'L2(R)' 1385 and changing the link-layer destination address to 'L2(S1)'. Relay 1386 ('R') then relays the Predirect via Server ('S1'). 1388 When Server ('S1') receives the Predirect message from Relay ('R') it 1389 determines that Client ('A') is a neighbor by consulting its neighbor 1390 cache. Server ('S1') then re-encapsulates the Predirect while 1391 changing the link-layer source address to 'L2(S1)' and changing the 1392 link-layer destination address to 'L2(A)'. Server ('S1') then 1393 forwards the message to Client ('A'). 1395 3.12.8. Processing Redirects 1397 When Client ('A') receives the Redirect message, it accepts the 1398 message only if it has a link-layer source address of one of its 1399 Servers (e.g., ''L2(S1)'). Next, Client ('A') validates the message 1400 according to the ICMPv6 Redirect message validation rules in 1401 Section 8.1 of [RFC4861], except that it accepts the message even 1402 though the network-layer source address is not that of it's current 1403 first-hop router. Following validation, Client ('A') then processes 1404 the message as follows. 1406 In the reference operational scenario, when Client ('A') receives the 1407 Redirect message, it either creates or updates a dynamic neighbor 1408 cache entry that stores the Target Address of the message as the 1409 network-layer address of Client ('B'), stores the link-layer 1410 addresses found in the TLLAOs as the link-layer addresses of Client 1411 ('B') and stores the Prefix Length as the length to be applied to the 1412 network-layer address for forwarding purposes. Client ('A') then 1413 sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 1415 Now, Client ('A') has a neighbor cache entry with a valid ForwardTime 1416 value, while Client ('B') has a neighbor cache entry with a valid 1417 AcceptTime value. Thereafter, Client ('A') may forward ordinary 1418 network-layer data packets directly to Client ("B") without involving 1419 any intermediate nodes, and Client ('B') can verify that the packets 1420 came from an acceptable source. (In order for Client ('B') to 1421 forward packets to Client ('A'), a corresponding Predirect/Redirect 1422 message exchange is required in the reverse direction; hence, the 1423 mechanism is asymmetric.) 1425 3.12.9. Server-Oriented Redirection 1427 In some environments, the Server nearest the target Client may need 1428 to serve as the redirection target, e.g., if direct Client-to-Client 1429 communications are not possible. In that case, the Server prepares 1430 the Redirect message the same as if it were the destination Client 1431 (see: Section 3.9.6), except that it writes its own link-layer 1432 address in the TLLAO option. The Server must then maintain a 1433 neighbor cache entry for the redirected source Client. 1435 3.13. Neighbor Unreachability Detection (NUD) 1437 AERO nodes perform NUD by sending unicast NS messages to elicit 1438 solicited NA messages from neighbors the same as described in 1439 [RFC4861]. When an AERO node sends an NS/NA message, it MUST use its 1440 link-local address as the IPv6 source address and the link-local 1441 address of the neighbor as the IPv6 destination address. When an 1442 AERO node receives an NS message or a solicited NA message, it 1443 accepts the message if it has a neighbor cache entry for the 1444 neighbor; otherwise, it ignores the message. 1446 When a source Client is redirected to a target Client it SHOULD test 1447 the direct path by sending an initial NS message to elicit a 1448 solicited NA response. While testing the path, the source Client can 1449 optionally continue sending packets via the Server, maintain a small 1450 queue of packets until target reachability is confirmed, or 1451 (optimistically) allow packets to flow directly to the target. The 1452 source Client SHOULD thereafter continue to test the direct path to 1453 the target Client (see Section 7.3 of [RFC4861]) periodically in 1454 order to keep dynamic neighbor cache entries alive. 1456 In particular, while the source Client is actively sending packets to 1457 the target Client it SHOULD also send NS messages separated by 1458 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 1459 If the source Client is unable to elicit a solicited NA response from 1460 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 1461 to 0 and resume sending packets via one of its Servers. Otherwise, 1462 the source Client considers the path usable and SHOULD thereafter 1463 process any link-layer errors as a hint that the direct path to the 1464 target Client has either failed or has become intermittent. 1466 When a target Client receives an NS message from a source Client, it 1467 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 1468 otherwise, it discards the NS message. If ForwardTime is non-zero, 1469 the target Client then sends a solicited NA message to the link-layer 1470 address of the source Client; otherwise, it sends the solicited NA 1471 message to the link-layer address of one of its Servers. 1473 When a source Client receives a solicited NA message from a target 1474 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 1475 entry exists; otherwise, it discards the NA message. 1477 When ForwardTime for a dynamic neighbor cache entry expires, the 1478 source Client resumes sending any subsequent packets via a Server and 1479 may (eventually) attempt to re-initiate the AERO redirection process. 1480 When AcceptTime for a dynamic neighbor cache entry expires, the 1481 target Client discards any subsequent packets received directly from 1482 the source Client. When both ForwardTime and AcceptTime for a 1483 dynamic neighbor cache entry expire, the Client deletes the neighbor 1484 cache entry. 1486 3.14. Mobility Management 1488 3.14.1. Announcing Link-Layer Address Changes 1490 When a Client needs to change its link-layer address, e.g., due to a 1491 mobility event, it performs an immediate DHCPv6 Rebind/Reply exchange 1492 via each of its Servers using the new link-layer address as the 1493 source and with a CLLAO that includes the correct Link ID and 1494 Preference values. If authentication succeeds, the Server then 1495 update its neighbor cache and sends a DHCPv6 Reply. 1497 Next, the Client sends unsolicited NA messages to each of its 1498 correspondent Client neighbors using the same procedures as specified 1499 in Section 7.2.6 of [RFC4861], except that it sends the messages as 1500 unicast to each neighbor via a Server instead of multicast. In this 1501 process, the Client should send no more than 1502 MAX_NEIGHBOR_ADVERTISEMENT messages separated by no less than 1503 RETRANS_TIMER seconds to each neighbor. 1505 With reference to Figure 5, Client ('B') sends unicast unsolicited NA 1506 messages to Client ('A') via Server ('S2') as follows: 1508 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1509 layer address of Client ('B')). 1511 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1512 link-layer address of Server ('S2')). 1514 o the network-layer source address is set to fe80::2001:db8:1:0 1515 (i.e., the AERO address of Client ('B')). 1517 o the network-layer destination address is set to fe80::2001:db8:0:0 1518 (i.e., the AERO address of Client ('A')). 1520 o the Type is set to 136. 1522 o the Code is set to 0. 1524 o the Solicited flag is set to 0. 1526 o the Override flag is set to 1. 1528 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1529 address of Client ('B')). 1531 o the message includes one or more TLLAOs with Link ID and 1532 Preference set to appropriate values for Client ('B')'s underlying 1533 interfaces, and with UDP Port Number and IP Address set to '0'. 1535 o the message SHOULD include a Timestamp option. 1537 When Server ('S1') receives the NA message, it relays the message in 1538 the same way as described for relaying Redirect messages in 1539 Section 3.12.7. In particular, Server ('S1') copies the correct UDP 1540 port numbers and IP addresses into the TLLAOs, changes the link-layer 1541 source address to its own address, changes the link-layer destination 1542 address to the address of Relay ('R'), then forwards the NA message 1543 via the relaying chain the same as for a Redirect. 1545 When Client ('A') receives the NA message, it accepts the message 1546 only if it already has a neighbor cache entry for Client ('B') then 1547 updates the link-layer addresses for Client ('B') based on the 1548 addresses in the TLLAOs. However, Client ('A') MUST NOT update 1549 ForwardTime since Client ('B') will not have updated AcceptTime. 1551 Note that these unsolicited NA messages are unacknowledged; hence, 1552 Client ('B') has no way of knowing whether Client ('A') has received 1553 them. If the messages are somehow lost, however, Client ('A') will 1554 soon learn of the mobility event via the NUD procedures specified in 1555 Section 3.13. 1557 3.14.2. Bringing New Links Into Service 1559 When a Client needs to bring a new underlying interface into service 1560 (e.g., when it activates a new data link), it performs an immediate 1561 Rebind/Reply exchange via each of its Servers using the new link- 1562 layer address as the source address and with a CLLAO that includes 1563 the new Link ID and Preference values. If authentication succeeds, 1564 the Server then updates its neighbor cache and sends a DHCPv6 Reply. 1565 The Client MAY then send unsolicited NA messages to each of its 1566 correspondent Clients to inform them of the new link-layer address as 1567 described in Section 3.14.1. 1569 3.14.3. Removing Existing Links from Service 1571 When a Client needs to remove an existing underlying interface from 1572 service (e.g., when it de-activates an existing data link), it 1573 performs an immediate Rebind/Reply exchange via each of its Servers 1574 over any available link with a CLLAO that includes the deprecated 1575 Link ID and a Preference value of 0. If authentication succeeds, the 1576 Server then updates its neighbor cache and sends a DHCPv6 Reply. The 1577 Client SHOULD then send unsolicited NA messages to each of its 1578 correspondent Clients to inform them of the deprecated link-layer 1579 address as described in Section 3.14.1. 1581 3.14.4. Moving to a New Server 1583 When a Client associates with a new Server, it performs the Client 1584 procedures specified in Section 3.10. 1586 When a Client disassociates with an existing Server, it sends a 1587 DHCPv6 Release message to the unicast network layer address of the 1588 old Server. The Client SHOULD send the message via a new Server 1589 (i.e., by setting the link-layer destination address to the address 1590 of the new Server) in case the old Server is unreachable at the link 1591 layer, e.g., if the old Server is in a different network partition. 1593 The new Server will forward the message to a Relay, which will in 1594 turn forward the message to the old Server. 1596 When the old Server receives the DHCPv6 Release, it first 1597 authenticates the message. If authentication succeeds, the old 1598 Server withdraws the IP route from the routing system and deletes the 1599 neighbor cache entry for the Client. (The old Server MAY impose a 1600 small delay before deleting the neighbor cache entry so that any 1601 packets already in the system can still be delivered to the Client.) 1602 The old Server then returns a DHCPv6 Reply message via a Relay. The 1603 Client can then use the Reply message to verify that the termination 1604 signal has been processed, and can delete both the default route and 1605 the neighbor cache entry for the old Server. 1607 Clients SHOULD NOT move rapidly between Servers in order to avoid 1608 causing unpredictable oscillations in the Server/Relay routing 1609 system. Such oscillations could result in intermittent reachability 1610 for the Client itself, while causing little harm to the network due 1611 to routing protocol dampening. Examples of when a Client might wish 1612 to change to a different Server include a Server that has gone 1613 unreachable, topological movements of significant distance, etc. 1615 3.15. Encapsulation Protocol Version Considerations 1617 A source Client may connect only to an IPvX underlying network, while 1618 the target Client connects only to an IPvY underlying network. In 1619 that case, the target and source Clients have no means for reaching 1620 each other directly (since they connect to underlying networks of 1621 different IP protocol versions) and so must ignore any redirection 1622 messages and continue to send packets via the Server. 1624 3.16. Multicast Considerations 1626 When the underlying network does not support multicast, AERO nodes 1627 map IPv6 link-scoped multicast addresses (including 1628 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 1629 Server. 1631 When the underlying network supports multicast, AERO nodes use the 1632 multicast address mapping specification found in [RFC2529] for IPv4 1633 underlying networks and use a direct multicast mapping for IPv6 1634 underlying networks. (In the latter case, "direct multicast mapping" 1635 means that if the IPv6 multicast destination address of the 1636 encapsulated packet is "M", then the IPv6 multicast destination 1637 address of the encapsulating header is also "M".) 1639 3.17. Operation on AERO Links Without DHCPv6 Services 1641 When Servers on the AERO link do not provide DHCPv6 services, 1642 operation can still be accommodated through administrative 1643 configuration of ACPs on AERO Clients. In that case, administrative 1644 configurations of AERO interface neighbor cache entries on both the 1645 Server and Client are also necessary. However, this may interfere 1646 with the ability for Clients to dynamically change to new Servers, 1647 and can expose the AERO link to misconfigurations unless the 1648 administrative configurations are carefully coordinated. 1650 3.18. Operation on Server-less AERO Links 1652 In some AERO link scenarios, there may be no Servers on the link and/ 1653 or no need for Clients to use a Server as an intermediary trust 1654 anchor. In that case, each Client acts as a Server unto itself to 1655 establish neighbor cache entries by performing direct Client-to- 1656 Client IPv6 ND message exchanges, and some other form of trust basis 1657 must be applied so that each Client can verify that the prospective 1658 neighbor is authorized to use its claimed ACP. 1660 When there is no Server on the link, Clients must arrange to receive 1661 ACPs and publish them via a secure alternate prefix delegation 1662 authority through some means outside the scope of this document. 1664 4. Implementation Status 1666 An application-layer implementation is in progress. 1668 5. IANA Considerations 1670 IANA is instructed to assign a new 2-octet Hardware Type number 1671 "TBD1" for AERO in the "arp-parameters" registry per Section 2 of 1672 [RFC5494]. The number is assigned from the 2-octet Unassigned range 1673 with Hardware Type "AERO" and with this document as the reference. 1675 IANA is instructed to assign a 4-octet Enterprise Number "TBD2" for 1676 AERO in the "enterprise-numbers" registry per [RFC3315]. 1678 6. Security Considerations 1680 AERO link security considerations are the same as for standard IPv6 1681 Neighbor Discovery [RFC4861] except that AERO improves on some 1682 aspects. In particular, AERO uses a trust basis between Clients and 1683 Servers, where the Clients only engage in the AERO mechanism when it 1684 is facilitated by a trust anchor. AERO nodes SHOULD also use DHCPv6 1685 securing services (e.g., DHCPv6 authentication, 1687 [I-D.ietf-dhc-sedhcpv6], etc.) for Client authentication and network 1688 admission control. 1690 AERO Redirect, Predirect and unsolicited NA messages SHOULD include a 1691 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 1692 can use to verify the message time of origin. AERO Predirect, NS and 1693 RS messages SHOULD include a Nonce option (see Section 5.3 of 1694 [RFC3971]) that recipients echo back in corresponding responses. 1696 AERO links must be protected against link-layer address spoofing 1697 attacks in which an attacker on the link pretends to be a trusted 1698 neighbor. Links that provide link-layer securing mechanisms (e.g., 1699 IEEE 802.1X WLANs) and links that provide physical security (e.g., 1700 enterprise network wired LANs) provide a first line of defense that 1701 is often sufficient. In other instances, additional securing 1702 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 1703 [RFC4301] or TLS [RFC5246] may be necessary. 1705 AERO Clients MUST ensure that their connectivity is not used by 1706 unauthorized nodes on their EUNs to gain access to a protected 1707 network, i.e., AERO Clients that act as routers MUST NOT provide 1708 routing services for unauthorized nodes. (This concern is no 1709 different than for ordinary hosts that receive an IP address 1710 delegation but then "share" the address with unauthorized nodes via a 1711 NAT function.) 1713 On some AERO links, establishment and maintenance of a direct path 1714 between neighbors requires secured coordination such as through the 1715 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 1716 security association. 1718 7. Acknowledgements 1720 Discussions both on IETF lists and in private exchanges helped shape 1721 some of the concepts in this work. Individuals who contributed 1722 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1723 Brian Carpenter, Wojciech Dec, Ralph Droms, Brian Haberman, Joel 1724 Halpern, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Joe 1725 Touch and Bernie Volz. Members of the IESG also provided valuable 1726 input during their review process that greatly improved the document. 1727 Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman 1728 for their shepherding guidance. 1730 This work has further been encouraged and supported by Boeing 1731 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 1732 Balaguruna Chidambaram, Claudiu Danilov, Wen Fang, Anthony Gregory, 1733 Jeff Holland, Ed King, Gen MacLean, Kent Shuey, Brian Skeen, Mike 1734 Slane, Julie Wulff, Yueli Yang, and other members of the BR&T and BIT 1735 mobile networking teams. 1737 Earlier works on NBMA tunneling approaches are found in 1738 [RFC2529][RFC5214][RFC5569]. 1740 8. References 1742 8.1. Normative References 1744 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1745 August 1980. 1747 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1748 1981. 1750 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1751 RFC 792, September 1981. 1753 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1754 October 1996. 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, March 1997. 1759 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1760 (IPv6) Specification", RFC 2460, December 1998. 1762 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1763 IPv6 Specification", RFC 2473, December 1998. 1765 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1766 and M. Carney, "Dynamic Host Configuration Protocol for 1767 IPv6 (DHCPv6)", RFC 3315, July 2003. 1769 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1770 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1771 December 2003. 1773 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1774 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1776 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1777 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1779 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1780 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1781 September 2007. 1783 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1784 Address Autoconfiguration", RFC 4862, September 2007. 1786 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1787 Requirements", RFC 6434, December 2011. 1789 8.2. Informative References 1791 [I-D.ietf-dhc-sedhcpv6] 1792 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 1793 DHCPv6 with Public Key", draft-ietf-dhc-sedhcpv6-03 (work 1794 in progress), June 2014. 1796 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1797 RFC 879, November 1983. 1799 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1800 selection, and registration of an Autonomous System (AS)", 1801 BCP 6, RFC 1930, March 1996. 1803 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1804 Domains without Explicit Tunnels", RFC 2529, March 1999. 1806 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1807 RFC 2675, August 1999. 1809 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1810 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1812 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1813 Architecture", RFC 4291, February 2006. 1815 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1816 Internet Protocol", RFC 4301, December 2005. 1818 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1819 Discovery", RFC 4821, March 2007. 1821 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1822 Errors at High Data Rates", RFC 4963, July 2007. 1824 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 1825 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 1826 September 2007. 1828 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1829 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1830 March 2008. 1832 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1833 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1835 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 1836 for the Address Resolution Protocol (ARP)", RFC 5494, 1837 April 2009. 1839 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1840 Route Optimization Requirements for Operational Use in 1841 Aeronautics and Space Exploration Mobile Networks", RFC 1842 5522, October 2009. 1844 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1845 Infrastructures (6rd)", RFC 5569, January 2010. 1847 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1848 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1849 5996, September 2010. 1851 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1852 NAT64: Network Address and Protocol Translation from IPv6 1853 Clients to IPv4 Servers", RFC 6146, April 2011. 1855 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1856 Troan, "Basic Requirements for IPv6 Customer Edge 1857 Routers", RFC 6204, April 2011. 1859 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 1860 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 1861 2011. 1863 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1864 for Equal Cost Multipath Routing and Link Aggregation in 1865 Tunnels", RFC 6438, November 2011. 1867 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1868 RFC 6691, July 2012. 1870 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1871 (AERO)", RFC 6706, August 2012. 1873 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1874 RFC 6864, February 2013. 1876 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1877 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1879 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1880 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1881 RFC 6936, April 2013. 1883 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 1884 Address Option in DHCPv6", RFC 6939, May 2013. 1886 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1887 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1889 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 1890 Address Selection Policy Using DHCPv6", RFC 7078, January 1891 2014. 1893 Author's Address 1895 Fred L. Templin (editor) 1896 Boeing Research & Technology 1897 P.O. Box 3707 1898 Seattle, WA 98124 1899 USA 1901 Email: fltemplin@acm.org