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