idnits 2.17.1 draft-templin-aerolink-33.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 09, 2014) is 3517 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 2088, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 2127, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 2140, but no explicit reference was found in the text == Unused Reference: 'RFC4994' is defined on line 2183, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 2210, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 2214, but no explicit reference was found in the text == Unused Reference: 'RFC6355' is defined on line 2218, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 2226, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 2229, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 2245, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 2248, 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 09, 2014 5 Intended status: Standards Track 6 Expires: March 13, 2015 8 Transmission of IP Packets over AERO Links 9 draft-templin-aerolink-33.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 13, 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 . . . . . . . . 39 97 3.15.4. Moving to a New Server . . . . . . . . . . . . . . . 40 98 3.15.5. Extending AERO Links Through Security Gateways . . . 40 99 3.16. Encapsulation Protocol Version Considerations . . . . . . 42 100 3.17. Multicast Considerations . . . . . . . . . . . . . . . . 42 101 3.18. Operation on AERO Links Without DHCPv6 Services . . . . . 43 102 3.19. Operation on Server-less AERO Links . . . . . . . . . . . 43 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 of 913 arbitrary length (i.e., up to 64KB); hence, there is no need for AERO 914 to stipulate a minimum reassembly size for those devices. 916 3.10. AERO Interface Error Handling 918 When an AERO node admits an encapsulated packet into the AERO 919 interface, it may receive an L2 or an L3 error indication. The AERO 920 node must then take appropriate actions to either deal with the error 921 locally or relay a corresponding error message toward the source of 922 the original packet. 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 an L2 Time Exceeded message, it SHOULD 987 reduce its current rate of admitting fragmented encapsulated 988 packets into the tunnel to ensure that the IP ID field will not 989 wrap before all earlier fragments have been processed. If the 990 AERO node includes an integrity check vector, however, it MAY 991 ignore the Time Exceeded message and continue sending fragmented 992 encapsulated packets without rate limiting. 994 o When an AERO Client receives an L2 Destination Unreachable message 995 in response to a tunneled packet that it sends directly to one of 996 its dynamic neighbor correspondents, the Client SHOULD set 997 ForwardTime for the corresponding dynamic neighbor cache entry to 998 0 and allow future packets destined to the correspondent to flow 999 through a Server. 1001 o When an AERO Client receives an L2 Destination Unreachable message 1002 in response to a tunneled packet that it sends directly to one of 1003 its static neighbor Servers, the Client SHOULD attempt to 1004 associate with a new Server. 1006 o When an AERO Relay or Server receives an L2 Destination 1007 Unreachable message in response to a tunneled packet that it sends 1008 to any neighbor, it discards the message since the routing system 1009 is likely in a temporary transitional state that will soon re- 1010 converge. 1012 o When an AERO node receives an L2 PTB message, it translates the 1013 message into an L3 PTB message if possible (*) and forwards the 1014 message toward the original source as described below. 1016 To translate an L2 PTB message to an L3 PTB message, the AERO node 1017 first caches the values in the Type, Code and MTU fields of the L2 1018 ICMP header. The node next discards the L2 IP and ICMP headers, and 1019 also discards the encapsulation headers of the original L3 packet. 1020 Next the node encapsulates the included segment of the original L3 1021 packet in an L3 IP and ICMP header. In the process, the node uses 1022 the cached L2 Type and Code values to set corresponding values in the 1023 Type and Code fields of the L3 ICMP header, then writes the maximum 1024 of 1500 bytes and (L2 MTU - ENCAPS) in the L3 ICMP header. 1026 The node next writes the IP source address of the original L3 packet 1027 as the destination address of the L3 PTB message and determines the 1028 next hop to the destination. If the next hop is reached via the AERO 1029 interface, the node uses the IPv6 address "::" or the IPv4 address 1030 "0.0.0.0" as the IP source address of the L3 PTB message. Otherwise, 1031 the node uses one of its non link-local addresses as the source 1032 address of the L3 PTB message. The node finally calculates the ICMP 1033 checksum over the L3 PTB message and writes the Checksum in the 1034 corresponding field of the L3 ICMP header. The L3 PTB message 1035 therefore is formatted as follows: 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 ~ ~ 1039 | L3 IP Header of | 1040 | error message | 1041 ~ ~ 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | L3 ICMP Header | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1045 ~ ~ p 1046 | IP header of | k 1047 | original L3 packet | t 1048 ~ ~ 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 1050 ~ ~ n 1051 | Upper layer headers and | 1052 | leading portion of body | e 1053 | of the original L3 packet | r 1054 ~ ~ r 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 1057 Figure 4: AERO Interface L3 Error Message Format 1059 After the node has prepared the L3 PTB message, it either forwards 1060 the message via a link outside of the AERO interface without 1061 encapsulation, or re-encapsulates and forwards the message to the 1062 next hop within the AERO interface. 1064 When an AERO Relay receives an L3 packet for which the destination 1065 address is covered by an ASP, if there is no more-specific routing 1066 information for the destination the Relay drops the packet and 1067 returns an L3 Destination Unreachable message. The Relay first 1068 writes the IP source address of the original L3 packet as the 1069 destination address of the L3 Destination Unreachable message and 1070 determines the next hop to the destination. If the next hop is 1071 reached via the AERO interface, the Relay uses the IPv6 address "::" 1072 or the IPv4 address "0.0.0.0" as the IP source address of the L3 1073 Destination Unreachable message and forwards the message to the next 1074 hop within the AERO interface. Otherwise, the Relay uses one of its 1075 non link-local addresses as the source address of the L3 Destination 1076 Unreachable message and forwards the message via a link outside the 1077 AERO interface. 1079 When an AERO node receives any L3 error message via the AERO 1080 interface, it examines the destination address in the L3 IP header of 1081 the message. If the next hop toward the destination address of the 1082 error message is via the AERO interface, the node re-encapsulates and 1083 forwards the message to the next hop within the AERO interface. 1084 Otherwise, if the source address in the L3 IP header of the message 1085 is the IPv6 address "::" or the IPv4 address "0.0.0.0", the node 1086 writes one of its non link-local addresses as the source address of 1087 the L3 message and recalculates the IP and/or ICMP checksums. The 1088 node finally forwards the message via a link outside of the AERO 1089 interface. 1091 (*) Note that in some instances the packet-in-error field of an L2 1092 PTB message may not include enough information for translation to an 1093 L3 PTB message. In that case, the AERO interface simply discards the 1094 L2 PTB message. It can therefore be said that translation of L2 PTB 1095 messages to L3 PTB messages can provide a useful optimization when 1096 possible, but is not critical for sources that correctly use PLPMTUD. 1098 3.11. AERO Router Discovery, Prefix Delegation and Address 1099 Configuration 1101 3.11.1. AERO DHCPv6 Service Model 1103 Each AERO Server configures a DHCPv6 server function to facilitate PD 1104 requests from Clients. Each Server is pre-configured with an 1105 identical list of ACP-to-Client ID mappings for all Clients enrolled 1106 in the AERO system, as well as any information necessary to 1107 authenticate Clients. The configuration information is maintained by 1108 a central administrative authority for the AERO link and securely 1109 propagated to all Servers whenever a new Client is enrolled or an 1110 existing Client is withdrawn. 1112 With these identical configurations, each Server can function 1113 independently of all other Servers, including the maintenance of 1114 active leases. Therefore, no Server-to-Server DHCPv6 state 1115 synchronization is necessary, and Clients can optionally hold 1116 separate leases for the same ACP from multiple Servers. 1118 In this way, Clients can easily associate with multiple Servers, and 1119 can receive new leases from new Servers before deprecating leases 1120 held through old Servers. This enables a graceful "make-before- 1121 break" capability. 1123 3.11.2. AERO Client Behavior 1125 AERO Clients discover the link-layer addresses of AERO Servers via 1126 static configuration, or through an automated means such as DNS name 1127 resolution. In the absence of other information, the Client resolves 1128 the Fully-Qualified Domain Name (FQDN) "linkupnetworks.[domainname]" 1129 where "linkupnetworks" is a constant text string and "[domainname]" 1130 is the connection-specific DNS suffix for the Client's underlying 1131 network connection (e.g., "example.com"). After discovering the 1132 link-layer addresses, the Client associates with one or more of the 1133 corresponding Servers. 1135 To associate with a Server, the Client acts as a requesting router to 1136 request an ACP through a DHCPv6 PD two-message 1137 exchange[RFC3315][RFC3633] in which the Solicit message uses the IPv6 1138 "unspecified" address (i.e., "::") as the IPv6 source address, 1139 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address 1140 and the link-layer address of the Server as the link-layer 1141 destination address. The Client includes a Rapid Commit option as 1142 well as a Client Identifier option with a DHCP Unique Identifier 1143 (DUID), plus any necessary authentication options to identify itself 1144 to the DHCPv6 server. The Client also includes a Client Link Layer 1145 Address Option (CLLAO) [RFC6939] with the format shown in Figure 5 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | OPTION_CLIENT_LINKLAYER_ADDR | option-length | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | link-layer type (16 bits) | Link ID | Preference | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 Figure 5: AERO Client Link-Layer Address Option (CLLAO) Format 1157 The Client sets the CLLAO 'option-length' field to 4 and sets the 1158 'link-layer type' field to TBD1 (see: IANA Considerations), then 1159 includes appropriate Link ID and Preference values for the underlying 1160 interface over which the Solicit will be issued (note that these are 1161 the same values that would be included in a TLLAO as shown in 1162 Figure 2). If the Client is pre-provisioned with an ACP associated 1163 with the AERO service, it MAY also include the ACP in the Solicit 1164 message Identity Association (IA) option to indicate its preferred 1165 ACP to the DHCPv6 server. The Client then sends the encapsulated 1166 DHCPv6 request via the underlying interface. 1168 When the Client receives its ACP and the set of ASPs via a DHCPv6 1169 Reply from the AERO Server, it creates a static neighbor cache entry 1170 with the Server's link-local address (i.e., fe80::ID) as the network- 1171 layer address and the Server's encapsulation address as the link- 1172 layer address. The Client then records the lifetime for the ACP in 1173 the neighbor cache entry and marks the neighbor cache entry as 1174 "default", i.e., the Client considers the Server as a default router. 1175 If the Reply message contains a Vendor-Specific Information Option 1176 (see: Section 3.10.3) the Client also caches each ASP in the option. 1178 The Client then applies the AERO address to the AERO interface and 1179 sub-delegates the ACP to nodes and links within its attached EUNs 1180 (the AERO address thereafter remains stable as the Client moves). 1181 The Client also assigns a default IP route to the AERO interface as a 1182 route-to-interface, i.e., with no explicit next-hop. The next hop 1183 will then be determined after a packet has been submitted to the AERO 1184 interface by inspecting the neighbor cache (see above). 1186 The Client subsequently renews its ACP delegation through each of its 1187 Servers by performing DHCPv6 Renew/Reply exchanges with its AERO 1188 address as the IPv6 source address, 1189 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address, 1190 the link-layer address of a Server as the link-layer destination 1191 address and the same Client identifier, authentication options and 1192 CLLAO option as was used in the initial PD request. 1194 Since the Client's AERO address is configured from the unique ACP 1195 delegation it receives, there is no need for Duplicate Address 1196 Detection (DAD) on AERO links. Other nodes maliciously attempting to 1197 hijack an authorized Client's AERO address will be denied access to 1198 the network by the DHCPv6 server due to an unacceptable link-layer 1199 address and/or security parameters (see: Security Considerations). 1201 AERO Clients ignore the IP address and UDP port number in any S/TLLAO 1202 options in ND messages they receive directly from another AERO 1203 Client, but examine the Link ID and Preference values to match the 1204 message with the correct link-layer address information. 1206 When a source Client forwards a packet to a prospective destination 1207 Client (i.e., one for which the packet's destination address is 1208 covered by an ASP), the source Client initiates an AERO route 1209 optimization procedure as specified in Section 3.13. 1211 3.11.3. AERO Server Behavior 1213 AERO Servers configure a DHCPv6 server function on their AERO links. 1214 AERO Servers arrange to add their encapsulation layer IP addresses 1215 (i.e., their link-layer addresses) to the DNS resource records for 1216 the FQDN "linkupnetworks.[domainname]" before entering service. 1218 When an AERO Server receives a prospective Client's DHCPv6 PD Solicit 1219 message, it first authenticates the message. If authentication 1220 succeeds, the Server determines the correct ACP to delegate to the 1221 Client by matching the Client's DUID within an online directory 1222 service (e.g., LDAP). The Server then delegates the ACP and creates 1223 a static neighbor cache entry for the Client's AERO address with 1224 lifetime set to no more than the lease lifetime and the Client's 1225 link-layer address as the link-layer address for the Link ID 1226 specified in the CLLAO option. The Server then creates an IP 1227 forwarding table entry so that the AERO routing system will propagate 1228 the ACP to all Relays (see: Section 3.12). Finally, the Server sends 1229 a DHCPv6 Reply message to the Client while using fe80::ID as the IPv6 1230 source address, the Client's AERO address as the IPv6 destination 1231 address, and the Client's link-layer address as the destination link- 1232 layer address. The Server also includes a Server Unicast option with 1233 server-address set to fe80::ID so that all future Client/Server 1234 transactions will be link-local-only unicast over the AERO link. 1236 When the Server sends the DHCPv6 Reply message, it also includes a 1237 DHCPv6 Vendor-Specific Information Option with 'enterprise-number' 1238 set to "TBD2" (see: IANA Considerations). The option is formatted as 1239 shown in[RFC3315] and with the AERO enterprise-specific format shown 1240 in Figure 6: 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | OPTION_VENDOR_OPTS | option-len | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | enterprise-number ("TBD2") | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Reserved | Prefix Length | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | | 1251 + ASP (1) + 1252 | | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Reserved | Prefix Length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | | 1257 + ASP (2) + 1258 | | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Reserved | Prefix Length | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | | 1263 + ASP (3) + 1264 | | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 . (etc.) . 1267 . . 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 Figure 6: AERO Vendor-Specific Information Option 1272 Per Figure 6, the option includes one or more ASP. The ASP field 1273 contains the IP prefix as it would appear in the interface identifier 1274 portion of the corresponding AERO address (see: Section 3.3). For 1275 IPv6, valid values for the Prefix Length field are 0 through 64; for 1276 IPv4, valid values are 0 through 32. 1278 After the initial Solicit/Reply exchange, the AERO Server maintains 1279 the neighbor cache entry for the Client as long as the lease lifetime 1280 remains current. If the Client issues a Renew/Reply exchange, the 1281 Server extends the lifetime. If the Client issues a Release/Reply 1282 exchange, or if the Client does not issue a Renew/Reply within the 1283 lease lifetime, the Server deletes the neighbor cache entry for the 1284 Client and withdraws the IP route from the AERO routing system. 1286 3.12. AERO Relay/Server Routing System 1288 Relays require full topology information of all Client/Server 1289 associations, while individual Servers only require partial topology 1290 information, i.e., they only need to know the ACPs associated with 1291 their current set of associated Clients. This is accomplished 1292 through the use of an internal instance of the Border Gateway 1293 Protocol (BGP) [RFC4271] coordinated between Servers and Relays. 1294 This internal BGP instance does not interact with the public Internet 1295 BGP instance; therefore, the AERO link is presented to the IP 1296 Internetwork as a small set of ASPs as opposed to the full set of 1297 individual ACPs. 1299 In a reference BGP arrangement, each AERO Server is configured as an 1300 Autonomous System Border Router (ASBR) for a stub Autonomous System 1301 (AS) (possibly using a private AS Number (ASN) [RFC1930]), and each 1302 Server further peers with each Relay but does not peer with other 1303 Servers. Similarly, Relays need not peer with each other, since they 1304 will receive all updates from all Servers and will therefore have a 1305 consistent view of the AERO link ACP delegations. 1307 Each Server maintains a working set of associated Clients, and 1308 dynamically announces new ACPs and withdraws departed ACPs in its BGP 1309 updates to Relays. Relays do not send BGP updates to Servers, 1310 however, such that the BGP route reporting is unidirectional from the 1311 Servers to the Relays. 1313 The Relays therefore discover the full topology of the AERO link in 1314 terms of the working set of ACPs associated with each Server, while 1315 the Servers only discover the ACPs of their associated Clients. 1316 Since Clients are expected to remain associated with their current 1317 set of Servers for extended timeframes, the amount of BGP control 1318 messaging between Servers and Relays should be minimal. However, BGP 1319 peers SHOULD dampen any route oscillations caused by impatient 1320 Clients that repeatedly associate and disassociate with Servers. 1322 3.13. AERO Redirection 1324 3.13.1. Reference Operational Scenario 1326 Figure 7 depicts the AERO redirection reference operational scenario, 1327 using IPv6 addressing as the example (while not shown, a 1328 corresponding example for IPv4 addressing can be easily constructed). 1329 The figure shows an AERO Relay ('R'), two AERO Servers ('S1', 'S2'), 1330 two AERO Clients ('A', 'B') and two ordinary IPv6 hosts ('C', 'D'): 1332 +--------------+ +--------------+ +--------------+ 1333 | Server S1 | | Relay R | | Server S2 | 1334 | Nbr: A | |(C->S1; D->S2)| | Nbr: B | 1335 +--------------+ +--------------+ +--------------+ 1336 fe80::2 fe80::1 fe80::3 1337 L2(S1) L2(R) L2(S2) 1338 | | | 1339 X-----+-----+------------------+-----------------+----+----X 1340 | AERO Link | 1341 L2(A) L2(B) 1342 fe80::2001:db8:0:0 fe80::2001:db8:1:0 1343 +--------------+ +--------------+ 1344 | AERO Client A| | AERO Client B| 1345 | (default->S1)| | (default->S2)| 1346 +--------------+ +--------------+ 1347 2001:DB8:0::/48 2001:DB8:1::/48 1348 | | 1349 .-. .-. 1350 ,-( _)-. 2001:db8:0::1 2001:db8:1::1 ,-( _)-. 1351 .-(_ IP )-. +---------+ +---------+ .-(_ IP )-. 1352 (__ EUN )--| Host C | | Host D |--(__ EUN ) 1353 `-(______)-' +---------+ +---------+ `-(______)-' 1355 Figure 7: AERO Reference Operational Scenario 1357 In Figure 7, Relay ('R') applies the address fe80::1 to its AERO 1358 interface with link-layer address L2(R), Server ('S1') applies the 1359 address fe80::2 with link-layer address L2(S1),and Server ('S2') 1360 applies the address fe80::3 with link-layer address L2(S2). Servers 1361 ('S1') and ('S2') next arrange to add their link-layer addresses to a 1362 published list of valid Servers for the AERO link. 1364 AERO Client ('A') receives the ACP 2001:db8:0::/48 in a DHCPv6 PD 1365 exchange via AERO Server ('S1') then applies the address 1366 fe80::2001:db8:0:0 to its AERO interface with link-layer address 1367 L2(A). Client ('A') configures a default route and neighbor cache 1368 entry via the AERO interface with next-hop address fe80::2 and link- 1369 layer address L2(S1), then sub-delegates the ACP to its attached 1370 EUNs. IPv6 host ('C') connects to the EUN, and configures the 1371 address 2001:db8:0::1. 1373 AERO Client ('B') receives the ACP 2001:db8:1::/48 in a DHCPv6 PD 1374 exchange via AERO Server ('S2') then applies the address 1375 fe80::2001:db8:1:0 to its AERO interface with link-layer address 1376 L2(B). Client ('B') configures a default route and neighbor cache 1377 entry via the AERO interface with next-hop address fe80::3 and link- 1378 layer address L2(S2), then sub-delegates the ACP to its attached 1379 EUNs. IPv6 host ('D') connects to the EUN, and configures the 1380 address 2001:db8:1::1. 1382 3.13.2. Concept of Operations 1384 Again, with reference to Figure 7, when source host ('C') sends a 1385 packet to destination host ('D'), the packet is first forwarded over 1386 the source host's attached EUN to Client ('A'). Client ('A') then 1387 forwards the packet via its AERO interface to Server ('S1') and also 1388 sends a Predirect message toward Client ('B') via Server ('S1'). 1389 Server ('S1') then re-encapsulates and forwards both the packet and 1390 the Predirect message out the same AERO interface toward Client ('B') 1391 via Relay ('R'). 1393 When Relay ('R') receives the packet and Predirect message, it 1394 consults its forwarding table to discover Server ('S2') as the next 1395 hop toward Client ('B'). Relay ('R') then forwards both the packet 1396 and the Predirect message to Server ('S2'), which then forwards them 1397 to Client ('B'). 1399 After Client ('B') receives the Predirect message, it process the 1400 message and returns a Redirect message toward Client ('A') via Server 1401 ('S2'). During the process, Client ('B') also creates or updates a 1402 dynamic neighbor cache entry for Client ('A'). 1404 When Server ('S2') receives the Redirect message, it re-encapsulates 1405 the message and forwards it on to Relay ('R'), which forwards the 1406 message on to Server ('S1') which forwards the message on to Client 1407 ('A'). After Client ('A') receives the Redirect message, it 1408 processes the message and creates or updates a dynamic neighbor cache 1409 entry for Client ('C'). 1411 Following the above Predirect/Redirect message exchange, forwarding 1412 of packets from Client ('A') to Client ('B') without involving any 1413 intermediate nodes is enabled. The mechanisms that support this 1414 exchange are specified in the following sections. 1416 3.13.3. Message Format 1418 AERO Redirect/Predirect messages use the same format as for ICMPv6 1419 Redirect messages depicted in Section 4.5 of [RFC4861], but also 1420 include a new "Prefix Length" field taken from the low-order 8 bits 1421 of the Redirect message Reserved field. For IPv6, valid values for 1422 the Prefix Length field are 0 through 64; for IPv4, valid values are 1423 0 through 32. The Redirect/Predirect messages are formatted as shown 1424 in Figure 8: 1426 0 1 2 3 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Type (=137) | Code (=0/1) | Checksum | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Reserved | Prefix Length | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | | 1434 + + 1435 | | 1436 + Target Address + 1437 | | 1438 + + 1439 | | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | | 1442 + + 1443 | | 1444 + Destination Address + 1445 | | 1446 + + 1447 | | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Options ... 1450 +-+-+-+-+-+-+-+-+-+-+-+- 1452 Figure 8: AERO Redirect/Predirect Message Format 1454 3.13.4. Sending Predirects 1456 When a Client forwards a packet with a source address from one of its 1457 ACPs toward a destination address covered by an ASP (i.e., toward 1458 another AERO Client connected to the same AERO link), the source 1459 Client MAY send a Predirect message forward toward the destination 1460 Client via the Server. 1462 In the reference operational scenario, when Client ('A') forwards a 1463 packet toward Client ('B'), it MAY also send a Predirect message 1464 forward toward Client ('B'), subject to rate limiting (see 1465 Section 8.2 of [RFC4861]). Client ('A') prepares the Predirect 1466 message as follows: 1468 o the link-layer source address is set to 'L2(A)' (i.e., the link- 1469 layer address of Client ('A')). 1471 o the link-layer destination address is set to 'L2(S1)' (i.e., the 1472 link-layer address of Server ('S1')). 1474 o the network-layer source address is set to fe80::2001:db8:0:0 1475 (i.e., the AERO address of Client ('A')). 1477 o the network-layer destination address is set to fe80::2001:db8:1:0 1478 (i.e., the AERO address of Client ('B')). 1480 o the Type is set to 137. 1482 o the Code is set to 1 to indicate "Predirect". 1484 o the Prefix Length is set to the length of the prefix to be applied 1485 to the Target Address. 1487 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 1488 address of Client ('A')). 1490 o the Destination Address is set to the source address of the 1491 originating packet that triggered the Predirection event. (If the 1492 originating packet is an IPv4 packet, the address is constructed 1493 in IPv4-compatible IPv6 address format). 1495 o the message includes one or more TLLAOs with Link ID and 1496 Preference set to appropriate values for Client ('A')'s underlying 1497 interfaces, and with UDP Port Number and IP Address set to 0'. 1499 o the message SHOULD include a Timestamp option and a Nonce option. 1501 o the message includes a Redirected Header Option (RHO) that 1502 contains the originating packet truncated to ensure that at least 1503 the network-layer header is included but the size of the message 1504 does not exceed 1280 bytes. 1506 Note that the act of sending Predirect messages is cited as "MAY", 1507 since Client ('A') may have advanced knowledge that the direct path 1508 to Client ('B') would be unusable or otherwise undesirable. If the 1509 direct path later becomes unusable after the initial route 1510 optimization, Client ('A') simply allows packets to again flow 1511 through Server ('S1'). 1513 3.13.5. Re-encapsulating and Relaying Predirects 1515 When Server ('S1') receives a Predirect message from Client ('A'), it 1516 first verifies that the TLLAOs in the Predirect are a proper subset 1517 of the Link IDs in Client ('A')'s neighbor cache entry. If the 1518 Client's TLLAOs are not acceptable, Server ('S1') discards the 1519 message. Otherwise, Server ('S1') validates the message according to 1520 the ICMPv6 Redirect message validation rules in Section 8.1 of 1521 [RFC4861], except that the Predirect has Code=1. Server ('S1') also 1522 verifies that Client ('A') is authorized to use the Prefix Length in 1523 the Predirect when applied to the AERO address in the network-layer 1524 source address by searching for the AERO address in the neighbor 1525 cache. If validation fails, Server ('S1') discards the Predirect; 1526 otherwise, it copies the correct UDP Port numbers and IP Addresses 1527 for Client ('A')'s links into the (previously empty) TLLAOs. 1529 Server ('S1') then examines the network-layer destination address of 1530 the Predirect to determine the next hop toward Client ('B') by 1531 searching for the AERO address in the neighbor cache. Since Client 1532 ('B') is not one of its neighbors, Server ('S1') re-encapsulates the 1533 Predirect and relays it via Relay ('R') by changing the link-layer 1534 source address of the message to 'L2(S1)' and changing the link-layer 1535 destination address to 'L2(R)'. Server ('S1') finally forwards the 1536 re-encapsulated message to Relay ('R') without decrementing the 1537 network-layer TTL/Hop Limit field. 1539 When Relay ('R') receives the Predirect message from Server ('S1') it 1540 determines that Server ('S2') is the next hop toward Client ('B') by 1541 consulting its forwarding table. Relay ('R') then re-encapsulates 1542 the Predirect while changing the link-layer source address to 'L2(R)' 1543 and changing the link-layer destination address to 'L2(S2)'. Relay 1544 ('R') then relays the Predirect via Server ('S2'). 1546 When Server ('S2') receives the Predirect message from Relay ('R') it 1547 determines that Client ('B') is a neighbor by consulting its neighbor 1548 cache. Server ('S2') then re-encapsulates the Predirect while 1549 changing the link-layer source address to 'L2(S2)' and changing the 1550 link-layer destination address to 'L2(B)'. Server ('S2') then 1551 forwards the message to Client ('B'). 1553 3.13.6. Processing Predirects and Sending Redirects 1555 When Client ('B') receives the Predirect message, it accepts the 1556 Predirect only if the message has a link-layer source address of one 1557 of its Servers (e.g., L2(S2)). Client ('B') further accepts the 1558 message only if it is willing to serve as a redirection target. 1559 Next, Client ('B') validates the message according to the ICMPv6 1560 Redirect message validation rules in Section 8.1 of [RFC4861], except 1561 that it accepts the message even though Code=1 and even though the 1562 network-layer source address is not that of it's current first-hop 1563 router. 1565 In the reference operational scenario, when Client ('B') receives a 1566 valid Predirect message, it either creates or updates a dynamic 1567 neighbor cache entry that stores the Target Address of the message as 1568 the network-layer address of Client ('A') , stores the link-layer 1569 addresses found in the TLLAOs as the link-layer addresses of Client 1570 ('A') and stores the Prefix Length as the length to be applied to the 1571 network-layer address for forwarding purposes. Client ('B') then 1572 sets AcceptTime for the neighbor cache entry to ACCEPT_TIME. 1574 After processing the message, Client ('B') prepares a Redirect 1575 message response as follows: 1577 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1578 layer address of Client ('B')). 1580 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1581 link-layer address of Server ('S2')). 1583 o the network-layer source address is set to fe80::2001:db8:1:0 1584 (i.e., the AERO address of Client ('B')). 1586 o the network-layer destination address is set to fe80::2001:db8:0:0 1587 (i.e., the AERO address of Client ('A')). 1589 o the Type is set to 137. 1591 o the Code is set to 0 to indicate "Redirect". 1593 o the Prefix Length is set to the length of the prefix to be applied 1594 to the Target Address. 1596 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1597 address of Client ('B')). 1599 o the Destination Address is set to the destination address of the 1600 originating packet that triggered the Redirection event. (If the 1601 originating packet is an IPv4 packet, the address is constructed 1602 in IPv4-compatible IPv6 address format). 1604 o the message includes one or more TLLAOs with Link ID and 1605 Preference set to appropriate values for Client ('B')'s underlying 1606 interfaces, and with UDP Port Number and IP Address set to '0'. 1608 o the message SHOULD include a Timestamp option and MUST echo the 1609 Nonce option received in the Predirect (i.e., if a Nonce option is 1610 included). 1612 o the message includes as much of the RHO copied from the 1613 corresponding AERO Predirect message as possible such that at 1614 least the network-layer header is included but the size of the 1615 message does not exceed 1280 bytes. 1617 After Client ('B') prepares the Redirect message, it sends the 1618 message to Server ('S2'). 1620 3.13.7. Re-encapsulating and Relaying Redirects 1622 When Server ('S2') receives a Redirect message from Client ('B'), it 1623 first verifies that the TLLAOs in the Redirect are a proper subset of 1624 the Link IDs in Client ('B')'s neighbor cache entry. If the Client's 1625 TLLAOs are not acceptable, Server ('S2') discards the message. 1626 Otherwise, Server ('S2') validates the message according to the 1627 ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861]. 1628 Server ('S2') also verifies that Client ('B') is authorized to use 1629 the Prefix Length in the Redirect when applied to the AERO address in 1630 the network-layer source address by searching for the AERO address in 1631 the neighbor cache. If validation fails, Server ('S2') discards the 1632 Predirect; otherwise, it copies the correct UDP Port numbers and IP 1633 Addresses for Client ('B')'s links into the (previously empty) 1634 TLLAOs. 1636 Server ('S2') then examines the network-layer destination address of 1637 the Predirect to determine the next hop toward Client ('A') by 1638 searching for the AERO address in the neighbor cache. Since Client 1639 ('A') is not one of its neighbors, Server ('S2') re-encapsulates the 1640 Predirect and relays it via Relay ('R') by changing the link-layer 1641 source address of the message to 'L2(S2)' and changing the link-layer 1642 destination address to 'L2(R)'. Server ('S2') finally forwards the 1643 re-encapsulated message to Relay ('R') without decrementing the 1644 network-layer TTL/Hop Limit field. 1646 When Relay ('R') receives the Predirect message from Server ('S2') it 1647 determines that Server ('S1') is the next hop toward Client ('A') by 1648 consulting its forwarding table. Relay ('R') then re-encapsulates 1649 the Predirect while changing the link-layer source address to 'L2(R)' 1650 and changing the link-layer destination address to 'L2(S1)'. Relay 1651 ('R') then relays the Predirect via Server ('S1'). 1653 When Server ('S1') receives the Predirect message from Relay ('R') it 1654 determines that Client ('A') is a neighbor by consulting its neighbor 1655 cache. Server ('S1') then re-encapsulates the Predirect while 1656 changing the link-layer source address to 'L2(S1)' and changing the 1657 link-layer destination address to 'L2(A)'. Server ('S1') then 1658 forwards the message to Client ('A'). 1660 3.13.8. Processing Redirects 1662 When Client ('A') receives the Redirect message, it accepts the 1663 message only if it has a link-layer source address of one of its 1664 Servers (e.g., ''L2(S1)'). Next, Client ('A') validates the message 1665 according to the ICMPv6 Redirect message validation rules in 1666 Section 8.1 of [RFC4861], except that it accepts the message even 1667 though the network-layer source address is not that of it's current 1668 first-hop router. Following validation, Client ('A') then processes 1669 the message as follows. 1671 In the reference operational scenario, when Client ('A') receives the 1672 Redirect message, it either creates or updates a dynamic neighbor 1673 cache entry that stores the Target Address of the message as the 1674 network-layer address of Client ('B'), stores the link-layer 1675 addresses found in the TLLAOs as the link-layer addresses of Client 1676 ('B') and stores the Prefix Length as the length to be applied to the 1677 network-layer address for forwarding purposes. Client ('A') then 1678 sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 1680 Now, Client ('A') has a neighbor cache entry with a valid ForwardTime 1681 value, while Client ('B') has a neighbor cache entry with a valid 1682 AcceptTime value. Thereafter, Client ('A') may forward ordinary 1683 network-layer data packets directly to Client ("B") without involving 1684 any intermediate nodes, and Client ('B') can verify that the packets 1685 came from an acceptable source. (In order for Client ('B') to 1686 forward packets to Client ('A'), a corresponding Predirect/Redirect 1687 message exchange is required in the reverse direction; hence, the 1688 mechanism is asymmetric.) 1690 3.13.9. Server-Oriented Redirection 1692 In some environments, the Server nearest the target Client may need 1693 to serve as the redirection target, e.g., if direct Client-to-Client 1694 communications are not possible. In that case, the Server prepares 1695 the Redirect message the same as if it were the destination Client 1696 (see: Section 3.9.6), except that it writes its own link-layer 1697 address in the TLLAO option. The Server must then maintain a 1698 neighbor cache entry for the redirected source Client. 1700 3.14. Neighbor Unreachability Detection (NUD) 1702 AERO nodes perform NUD by sending unicast NS messages to elicit 1703 solicited NA messages from neighbors the same as described in 1704 [RFC4861]. When an AERO node sends an NS/NA message, it MUST use its 1705 link-local address as the IPv6 source address and the link-local 1706 address of the neighbor as the IPv6 destination address. When an 1707 AERO node receives an NS message or a solicited NA message, it 1708 accepts the message if it has a neighbor cache entry for the 1709 neighbor; otherwise, it ignores the message. 1711 When a source Client is redirected to a target Client it SHOULD test 1712 the direct path by sending an initial NS message to elicit a 1713 solicited NA response. While testing the path, the source Client can 1714 optionally continue sending packets via the Server, maintain a small 1715 queue of packets until target reachability is confirmed, or 1716 (optimistically) allow packets to flow directly to the target. The 1717 source Client SHOULD thereafter continue to test the direct path to 1718 the target Client (see Section 7.3 of [RFC4861]) periodically in 1719 order to keep dynamic neighbor cache entries alive. 1721 In particular, while the source Client is actively sending packets to 1722 the target Client it SHOULD also send NS messages separated by 1723 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 1724 If the source Client is unable to elicit a solicited NA response from 1725 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 1726 to 0 and resume sending packets via one of its Servers. Otherwise, 1727 the source Client considers the path usable and SHOULD thereafter 1728 process any link-layer errors as a hint that the direct path to the 1729 target Client has either failed or has become intermittent. 1731 When a target Client receives an NS message from a source Client, it 1732 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 1733 otherwise, it discards the NS message. If ForwardTime is non-zero, 1734 the target Client then sends a solicited NA message to the link-layer 1735 address of the source Client; otherwise, it sends the solicited NA 1736 message to the link-layer address of one of its Servers. 1738 When a source Client receives a solicited NA message from a target 1739 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 1740 entry exists; otherwise, it discards the NA message. 1742 When ForwardTime for a dynamic neighbor cache entry expires, the 1743 source Client resumes sending any subsequent packets via a Server and 1744 may (eventually) attempt to re-initiate the AERO redirection process. 1745 When AcceptTime for a dynamic neighbor cache entry expires, the 1746 target Client discards any subsequent packets received directly from 1747 the source Client. When both ForwardTime and AcceptTime for a 1748 dynamic neighbor cache entry expire, the Client deletes the neighbor 1749 cache entry. 1751 3.15. Mobility Management 1753 3.15.1. Announcing Link-Layer Address Changes 1755 When a Client needs to change its link-layer address, e.g., due to a 1756 mobility event, it performs an immediate DHCPv6 Rebind/Reply exchange 1757 via each of its Servers using the new link-layer address as the 1758 source and with a CLLAO that includes the correct Link ID and 1759 Preference values. If authentication succeeds, the Server then 1760 update its neighbor cache and sends a DHCPv6 Reply. 1762 Next, the Client sends unsolicited NA messages to each of its 1763 correspondent Client neighbors using the same procedures as specified 1764 in Section 7.2.6 of [RFC4861], except that it sends the messages as 1765 unicast to each neighbor via a Server instead of multicast. In this 1766 process, the Client should send no more than 1767 MAX_NEIGHBOR_ADVERTISEMENT messages separated by no less than 1768 RETRANS_TIMER seconds to each neighbor. 1770 With reference to Figure 7, Client ('B') sends unicast unsolicited NA 1771 messages to Client ('A') via Server ('S2') as follows: 1773 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1774 layer address of Client ('B')). 1776 o the link-layer destination address is set to 'L2(S2)' (i.e., the 1777 link-layer address of Server ('S2')). 1779 o the network-layer source address is set to fe80::2001:db8:1:0 1780 (i.e., the AERO address of Client ('B')). 1782 o the network-layer destination address is set to fe80::2001:db8:0:0 1783 (i.e., the AERO address of Client ('A')). 1785 o the Type is set to 136. 1787 o the Code is set to 0. 1789 o the Solicited flag is set to 0. 1791 o the Override flag is set to 1. 1793 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1794 address of Client ('B')). 1796 o the message includes one or more TLLAOs with Link ID and 1797 Preference set to appropriate values for Client ('B')'s underlying 1798 interfaces, and with UDP Port Number and IP Address set to '0'. 1800 o the message SHOULD include a Timestamp option. 1802 When Server ('S1') receives the NA message, it relays the message in 1803 the same way as described for relaying Redirect messages in 1804 Section 3.12.7. In particular, Server ('S1') copies the correct UDP 1805 port numbers and IP addresses into the TLLAOs, changes the link-layer 1806 source address to its own address, changes the link-layer destination 1807 address to the address of Relay ('R'), then forwards the NA message 1808 via the relaying chain the same as for a Redirect. 1810 When Client ('A') receives the NA message, it accepts the message 1811 only if it already has a neighbor cache entry for Client ('B') then 1812 updates the link-layer addresses for Client ('B') based on the 1813 addresses in the TLLAOs. However, Client ('A') MUST NOT update 1814 ForwardTime since Client ('B') will not have updated AcceptTime. 1816 Note that these unsolicited NA messages are unacknowledged; hence, 1817 Client ('B') has no way of knowing whether Client ('A') has received 1818 them. If the messages are somehow lost, however, Client ('A') will 1819 soon learn of the mobility event via the NUD procedures specified in 1820 Section 3.13. 1822 3.15.2. Bringing New Links Into Service 1824 When a Client needs to bring a new underlying interface into service 1825 (e.g., when it activates a new data link), it performs an immediate 1826 Rebind/Reply exchange via each of its Servers using the new link- 1827 layer address as the source address and with a CLLAO that includes 1828 the new Link ID and Preference values. If authentication succeeds, 1829 the Server then updates its neighbor cache and sends a DHCPv6 Reply. 1830 The Client MAY then send unsolicited NA messages to each of its 1831 correspondent Clients to inform them of the new link-layer address as 1832 described in Section 3.14.1. 1834 3.15.3. Removing Existing Links from Service 1836 When a Client needs to remove an existing underlying interface from 1837 service (e.g., when it de-activates an existing data link), it 1838 performs an immediate Rebind/Reply exchange via each of its Servers 1839 over any available link with a CLLAO that includes the deprecated 1840 Link ID and a Preference value of 0. If authentication succeeds, the 1841 Server then updates its neighbor cache and sends a DHCPv6 Reply. The 1842 Client SHOULD then send unsolicited NA messages to each of its 1843 correspondent Clients to inform them of the deprecated link-layer 1844 address as described in Section 3.14.1. 1846 3.15.4. Moving to a New Server 1848 When a Client associates with a new Server, it performs the Client 1849 procedures specified in Section 3.10. 1851 When a Client disassociates with an existing Server, it sends a 1852 DHCPv6 Release message to the unicast link-local network layer 1853 address of the old Server. The Client SHOULD send the message via a 1854 new Server (i.e., by setting the link-layer destination address to 1855 the address of the new Server) in case the old Server is unreachable 1856 at the link layer, e.g., if the old Server is in a different network 1857 partition. The new Server will forward the message to a Relay, which 1858 will in turn forward the message to the old Server. 1860 When the old Server receives the DHCPv6 Release, it first 1861 authenticates the message. If authentication succeeds, the old 1862 Server withdraws the IP route from the AERO routing system and 1863 deletes the neighbor cache entry for the Client. (The old Server MAY 1864 impose a small delay before deleting the neighbor cache entry so that 1865 any packets already in the system can still be delivered to the 1866 Client.) The old Server then returns a DHCPv6 Reply message via a 1867 Relay. The Client can then use the Reply message to verify that the 1868 termination signal has been processed, and can delete both the 1869 default route and the neighbor cache entry for the old Server. (Note 1870 that the Server's Reply to the Client's Release message may be lost, 1871 e.g., if the AERO routing system has not yet converged. Since the 1872 Client is responsible for reliability, however, it will retry until 1873 it gets an indication that the Release was successful.) 1875 Clients SHOULD NOT move rapidly between Servers in order to avoid 1876 causing unpredictable oscillations in the AERO routing system. Such 1877 oscillations could result in intermittent reachability for the Client 1878 itself, while causing little harm to the network due to routing 1879 protocol dampening. Examples of when a Client might wish to change 1880 to a different Server include a Server that has gone unreachable, 1881 topological movements of significant distance, etc. 1883 3.15.5. Extending AERO Links Through Security Gateways 1885 When an enterprise mobile device moves from a campus LAN connection 1886 to a public Internet link, it must re-enter the enterprise via a 1887 security gateway that has both an physical interface connection to 1888 the Internet and a physical interface connection to the enterprise 1889 internetwork. This most often entails the establishment of a Virtual 1890 Private Network (VPN) link over the public Internet from the mobile 1891 device to the security gateway. During this process, the mobile 1892 device supplies the security gateway with its public Internet address 1893 as the link-layer address for the VPN. The mobile device then acts 1894 as an AERO Client to negotiate with the security gateway to obtain 1895 its ACP. 1897 In order to satisfy this need, the security gateway also operates as 1898 an AERO Server with support for AERO Client proxying. In particular, 1899 when a mobile device (i.e., the Client) connects via the security 1900 gateway (i.e., the Server), the Server provides the Client with an 1901 ACP in a DHCPv6 PD exchange the same as if it were attached to an 1902 enterprise campus access link. The Server then replaces the Client's 1903 link-layer source address with the Server's enterprise-facing link- 1904 layer address in all AERO messages the Client sends toward neighbors 1905 on the AERO link. The AERO messages are then delivered to other 1906 devices on the AERO link as if they were originated by the security 1907 gateway instead of by the AERO Client. In the reverse direction, the 1908 AERO messages sourced by devices within the enterprise network can be 1909 forwarded to the security gateway, which then replaces the link-layer 1910 destination address with the Client's link-layer address and replaces 1911 the link-layer source address with its own (Internet-facing) link- 1912 layer address. 1914 After receiving the ACP, the Client can send IP packets that use an 1915 address taken from the ACP as the network layer source address, the 1916 Client's link-layer address as the link-layer source address, and the 1917 Server's Internet-facing link-layer address as the link-layer 1918 destination address. The Server will then rewrite the link-layer 1919 source address with the Server's own enterprise-facing link-layer 1920 address and rewrite the link-layer destination address with the 1921 target AERO node's link-layer address, and the packets will enter the 1922 enterprise network as though they were sourced from a device located 1923 within the enterprise. In the reverse direction, when a packet 1924 sourced by a node within the enterprise network uses a destination 1925 address from the Client's ACP, the packet will be delivered to the 1926 security gateway which then rewrites the link-layer destination 1927 address to the Client's link-layer address and rewrites the link- 1928 layer source address to the Server's Internet-facing link-layer 1929 address. The Server then delivers the packet across the VPN to the 1930 AERO Client. In this way, the AERO virtual link is essentially 1931 extended *through* the security gateway to the point at which the VPN 1932 link and AERO link are effectively grafted together by the link-layer 1933 address rewriting performed by the security gateway. All AERO 1934 messaging services (including route optimization and mobility 1935 signaling) are therefore extended to the Client. 1937 In order to support this virtual link grafting, the security gateway 1938 (acting as an AERO Server) must keep static neighbor cache entries 1939 for all of its associated Clients located on the public Internet. 1940 The neighbor cache entry is keyed by the AERO Client's AERO address 1941 the same as if the Client were located within the enterprise 1942 internetwork. The neighbor cache is then managed in all ways as 1943 though the Client were an ordinary AERO Client. This includes the 1944 AERO IPv6 ND messaging signaling for Route Optimization and Neighbor 1945 Unreachability Detection. 1947 Note that the main difference between a security gateway acting as an 1948 AERO Server and an enterprise-internal AERO Server is that the 1949 security gateway has at least one enterprise-internal physical 1950 interface and at least one public Internet physical interface. 1951 Conversely, the enterprise-internal AERO Server has only enterprise- 1952 internal physical interfaces. For this reason security gateway 1953 proxying is needed to ensure that the public Internet link-layer 1954 addressing space is kept separate from the enterprise-internal link- 1955 layer addressing space. This is afforded through a natural extension 1956 of the security association caching already performed for each VPN 1957 client by the security gateway. 1959 3.16. Encapsulation Protocol Version Considerations 1961 A source Client may connect only to an IPvX underlying network, while 1962 the target Client connects only to an IPvY underlying network. In 1963 that case, the target and source Clients have no means for reaching 1964 each other directly (since they connect to underlying networks of 1965 different IP protocol versions) and so must ignore any redirection 1966 messages and continue to send packets via the Server. 1968 3.17. Multicast Considerations 1970 When the underlying network does not support multicast, AERO nodes 1971 map IPv6 link-scoped multicast addresses (including 1972 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 1973 Server. 1975 When the underlying network supports multicast, AERO nodes use the 1976 multicast address mapping specification found in [RFC2529] for IPv4 1977 underlying networks and use a direct multicast mapping for IPv6 1978 underlying networks. (In the latter case, "direct multicast mapping" 1979 means that if the IPv6 multicast destination address of the 1980 encapsulated packet is "M", then the IPv6 multicast destination 1981 address of the encapsulating header is also "M".) 1983 3.18. Operation on AERO Links Without DHCPv6 Services 1985 When Servers on the AERO link do not provide DHCPv6 services, 1986 operation can still be accommodated through administrative 1987 configuration of ACPs on AERO Clients. In that case, administrative 1988 configurations of AERO interface neighbor cache entries on both the 1989 Server and Client are also necessary. However, this may interfere 1990 with the ability for Clients to dynamically change to new Servers, 1991 and can expose the AERO link to misconfigurations unless the 1992 administrative configurations are carefully coordinated. 1994 3.19. Operation on Server-less AERO Links 1996 In some AERO link scenarios, there may be no Servers on the link and/ 1997 or no need for Clients to use a Server as an intermediary trust 1998 anchor. In that case, each Client acts as a Server unto itself to 1999 establish neighbor cache entries by performing direct Client-to- 2000 Client IPv6 ND message exchanges, and some other form of trust basis 2001 must be applied so that each Client can verify that the prospective 2002 neighbor is authorized to use its claimed ACP. 2004 When there is no Server on the link, Clients must arrange to receive 2005 ACPs and publish them via a secure alternate prefix delegation 2006 authority through some means outside the scope of this document. 2008 4. Implementation Status 2010 An application-layer implementation is in progress. 2012 5. IANA Considerations 2014 IANA is instructed to assign a new 2-octet Hardware Type number 2015 "TBD1" for AERO in the "arp-parameters" registry per Section 2 of 2016 [RFC5494]. The number is assigned from the 2-octet Unassigned range 2017 with Hardware Type "AERO" and with this document as the reference. 2019 IANA is instructed to assign a 4-octet Enterprise Number "TBD2" for 2020 AERO in the "enterprise-numbers" registry per [RFC3315]. 2022 6. Security Considerations 2024 AERO link security considerations are the same as for standard IPv6 2025 Neighbor Discovery [RFC4861] except that AERO improves on some 2026 aspects. In particular, AERO uses a trust basis between Clients and 2027 Servers, where the Clients only engage in the AERO mechanism when it 2028 is facilitated by a trust anchor. AERO nodes SHOULD also use DHCPv6 2029 securing services (e.g., DHCPv6 authentication, 2031 [I-D.ietf-dhc-sedhcpv6], etc.) for Client authentication and network 2032 admission control. 2034 AERO Redirect, Predirect and unsolicited NA messages SHOULD include a 2035 Timestamp option (see Section 5.3 of [RFC3971]) that other AERO nodes 2036 can use to verify the message time of origin. AERO Predirect, NS and 2037 RS messages SHOULD include a Nonce option (see Section 5.3 of 2038 [RFC3971]) that recipients echo back in corresponding responses. 2040 AERO links must be protected against link-layer address spoofing 2041 attacks in which an attacker on the link pretends to be a trusted 2042 neighbor. Links that provide link-layer securing mechanisms (e.g., 2043 IEEE 802.1X WLANs) and links that provide physical security (e.g., 2044 enterprise network wired LANs) provide a first line of defense that 2045 is often sufficient. In other instances, additional securing 2046 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 2047 [RFC4301] or TLS [RFC5246] may be necessary. 2049 AERO Clients MUST ensure that their connectivity is not used by 2050 unauthorized nodes on their EUNs to gain access to a protected 2051 network, i.e., AERO Clients that act as routers MUST NOT provide 2052 routing services for unauthorized nodes. (This concern is no 2053 different than for ordinary hosts that receive an IP address 2054 delegation but then "share" the address with unauthorized nodes via a 2055 NAT function.) 2057 On some AERO links, establishment and maintenance of a direct path 2058 between neighbors requires secured coordination such as through the 2059 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 2060 security association. 2062 7. Acknowledgements 2064 Discussions both on IETF lists and in private exchanges helped shape 2065 some of the concepts in this work. Individuals who contributed 2066 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 2067 Brian Carpenter, Wojciech Dec, Ralph Droms, Brian Haberman, Joel 2068 Halpern, Sascha Hlusiak, Lee Howard, Andre Kostur, Ted Lemon, Joe 2069 Touch and Bernie Volz. Members of the IESG also provided valuable 2070 input during their review process that greatly improved the document. 2071 Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman 2072 for their shepherding guidance. 2074 This work has further been encouraged and supported by Boeing 2075 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 2076 Balaguruna Chidambaram, Claudiu Danilov, Wen Fang, Anthony Gregory, 2077 Jeff Holland, Ed King, Gen MacLean, Kent Shuey, Brian Skeen, Mike 2078 Slane, Julie Wulff, Yueli Yang, and other members of the BR&T and BIT 2079 mobile networking teams. 2081 Earlier works on NBMA tunneling approaches are found in 2082 [RFC2529][RFC5214][RFC5569]. 2084 8. References 2086 8.1. Normative References 2088 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2089 August 1980. 2091 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2092 1981. 2094 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2095 RFC 792, September 1981. 2097 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2098 October 1996. 2100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2101 Requirement Levels", BCP 14, RFC 2119, March 1997. 2103 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2104 (IPv6) Specification", RFC 2460, December 1998. 2106 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2107 IPv6 Specification", RFC 2473, December 1998. 2109 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2110 and M. Carney, "Dynamic Host Configuration Protocol for 2111 IPv6 (DHCPv6)", RFC 3315, July 2003. 2113 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 2114 Host Configuration Protocol (DHCP) version 6", RFC 3633, 2115 December 2003. 2117 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2118 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2120 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2121 for IPv6 Hosts and Routers", RFC 4213, October 2005. 2123 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2124 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2125 September 2007. 2127 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2128 Address Autoconfiguration", RFC 4862, September 2007. 2130 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2131 Requirements", RFC 6434, December 2011. 2133 8.2. Informative References 2135 [I-D.ietf-dhc-sedhcpv6] 2136 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 2137 DHCPv6 with Public Key", draft-ietf-dhc-sedhcpv6-03 (work 2138 in progress), June 2014. 2140 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 2141 RFC 879, November 1983. 2143 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 2144 1812, June 1995. 2146 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 2147 selection, and registration of an Autonomous System (AS)", 2148 BCP 6, RFC 1930, March 1996. 2150 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2151 Domains without Explicit Tunnels", RFC 2529, March 1999. 2153 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2154 RFC 2675, August 1999. 2156 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2157 2923, September 2000. 2159 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2160 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2161 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2162 RFC 3819, July 2004. 2164 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 2165 Protocol 4 (BGP-4)", RFC 4271, January 2006. 2167 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2168 Architecture", RFC 4291, February 2006. 2170 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2171 Internet Protocol", RFC 4301, December 2005. 2173 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 2174 Message Protocol (ICMPv6) for the Internet Protocol 2175 Version 6 (IPv6) Specification", RFC 4443, March 2006. 2177 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2178 Discovery", RFC 4821, March 2007. 2180 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2181 Errors at High Data Rates", RFC 4963, July 2007. 2183 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 2184 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 2185 September 2007. 2187 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2188 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2189 March 2008. 2191 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2192 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2194 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 2195 for the Address Resolution Protocol (ARP)", RFC 5494, 2196 April 2009. 2198 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 2199 Route Optimization Requirements for Operational Use in 2200 Aeronautics and Space Exploration Mobile Networks", RFC 2201 5522, October 2009. 2203 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2204 Infrastructures (6rd)", RFC 5569, January 2010. 2206 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2207 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 2208 5996, September 2010. 2210 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2211 NAT64: Network Address and Protocol Translation from IPv6 2212 Clients to IPv4 Servers", RFC 6146, April 2011. 2214 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2215 Troan, "Basic Requirements for IPv6 Customer Edge 2216 Routers", RFC 6204, April 2011. 2218 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 2219 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2220 2011. 2222 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2223 for Equal Cost Multipath Routing and Link Aggregation in 2224 Tunnels", RFC 6438, November 2011. 2226 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2227 RFC 6691, July 2012. 2229 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 2230 (AERO)", RFC 6706, August 2012. 2232 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 2233 RFC 6864, February 2013. 2235 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2236 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 2238 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2239 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2240 RFC 6936, April 2013. 2242 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2243 Address Option in DHCPv6", RFC 6939, May 2013. 2245 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2246 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 2248 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2249 Address Selection Policy Using DHCPv6", RFC 7078, January 2250 2014. 2252 Author's Address 2254 Fred L. Templin (editor) 2255 Boeing Research & Technology 2256 P.O. Box 3707 2257 Seattle, WA 98124 2258 USA 2260 Email: fltemplin@acm.org