idnits 2.17.1 draft-templin-aerolink-21.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 (May 27, 2014) is 3593 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 1309, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 1353, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 1439, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 11 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) May 27, 2014 5 Intended status: Standards Track 6 Expires: November 28, 2014 8 Transmission of IPv6 Packets over AERO Links 9 draft-templin-aerolink-21.txt 11 Abstract 13 This document specifies the operation of IPv6 over tunnel virtual 14 Non-Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 15 Route Optimization (AERO). Nodes attached to AERO links can exchange 16 packets via trusted intermediate routers on the link that provide 17 forwarding services to reach off-link destinations and/or redirection 18 services to inform the node of an on-link neighbor that is closer to 19 the final destination. Operation of the IPv6 Neighbor Discovery (ND) 20 protocol over AERO links is based on an IPv6 link local address 21 format known as the AERO address. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 28, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 60 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. AERO Interface Characteristics . . . . . . . . . . . . . 6 63 3.3.1. Coordination of Multiple Underlying Interfaces . . . 9 64 3.4. AERO Interface Neighbor Cache Maintenace . . . . . . . . 9 65 3.5. AERO Interface Data Origin Authentication . . . . . . . . 11 66 3.6. AERO Interface MTU Considerations . . . . . . . . . . . . 11 67 3.7. AERO Interface Encapsulation, Re-encapsulation and 68 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 13 69 3.8. AERO Router Discovery, Prefix Delegation and Address 70 Configuration . . . . . . . . . . . . . . . . . . . . . . 14 71 3.8.1. AERO Client Behavior . . . . . . . . . . . . . . . . 14 72 3.8.2. AERO Server Behavior . . . . . . . . . . . . . . . . 15 73 3.9. AERO Redirection . . . . . . . . . . . . . . . . . . . . 16 74 3.9.1. Reference Operational Scenario . . . . . . . . . . . 16 75 3.9.2. Classical Redirection Approaches . . . . . . . . . . 18 76 3.9.3. Concept of Operations . . . . . . . . . . . . . . . . 19 77 3.9.4. Message Format . . . . . . . . . . . . . . . . . . . 19 78 3.9.5. Sending Predirects . . . . . . . . . . . . . . . . . 20 79 3.9.6. Processing Predirects and Sending Redirects . . . . . 21 80 3.9.7. Re-encapsulating and Relaying Redirects . . . . . . . 22 81 3.9.8. Processing Redirects . . . . . . . . . . . . . . . . 23 82 3.10. Neighbor Reachability Maintenance . . . . . . . . . . . . 24 83 3.11. Mobility and Link-Layer Address Change Considerations . . 25 84 3.12. Underlying Protocol Version Considerations . . . . . . . 26 85 3.13. Multicast Considerations . . . . . . . . . . . . . . . . 26 86 3.14. Operation on AERO Links Without DHCPv6 Services . . . . . 26 87 3.15. Operation on Server-less AERO Links . . . . . . . . . . . 26 88 3.16. Other Considerations . . . . . . . . . . . . . . . . . . 27 89 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 95 8.2. Informative References . . . . . . . . . . . . . . . . . 29 96 Appendix A. AERO Server and Relay Interworking . . . . . . . . . 31 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 99 1. Introduction 101 This document specifies the operation of IPv6 over tunnel virtual 102 Non-Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 103 Route Optimization (AERO). Nodes attached to AERO links can exchange 104 packets via trusted intermediate routers on the link that provide 105 forwarding services to reach off-link destinations and/or redirection 106 services to inform the node of an on-link neighbor that is closer to 107 the final destination. This redirection provides a route 108 optimization capability that addresses the requirements outlined in 109 [RFC5522]. 111 Nodes on AERO links use an IPv6 link-local address format known as 112 the AERO Address. This address type has properties that avoid 113 duplication and statelessly link IPv6 Neighbor Discovery (ND) to IPv6 114 routing. The AERO link can be used for tunneling to neighboring 115 nodes on either IPv6 or IPv4 networks, i.e., AERO views the IPv6 and 116 IPv4 networks as equivalent links for tunneling. The remainder of 117 this document presents the AERO specification. 119 2. Terminology 121 The terminology in the normative references applies; the following 122 terms are defined within the scope of this document: 124 AERO link 125 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 126 configured over a node's attached IPv6 and/or IPv4 networks. All 127 nodes on the AERO link appear as single-hop neighbors from the 128 perspective of IPv6. 130 AERO interface 131 a node's attachment to an AERO link. 133 AERO address 134 an IPv6 link-local address assigned to an AERO interface and 135 constructed as specified in Section 3.6. 137 AERO node 138 a node that is connected to an AERO link and that participates in 139 IPv6 Neighbor Discovery over the link. 141 AERO Client ("client") 142 a node that configures either a host interface or a router 143 interface on an AERO link. 145 AERO Server ("server") 146 a node that configures a router interface on an AERO link over 147 which it can provide default forwarding and redirection services 148 for other AERO nodes. 150 AERO Relay ("relay") 151 a node that relays IPv6 packets between Servers on the same AERO 152 link, and/or that forwards IPv6 packets between the AERO link and 153 the IPv6 Internet. An AERO Relay may or may not also be 154 configured as an AERO Server. 156 ingress tunnel endpoint (ITE) 157 an AERO interface endpoint that injects tunneled packets into an 158 AERO link. 160 egress tunnel endpoint (ETE) 161 an AERO interface endpoint that receives tunneled packets from an 162 AERO link. 164 underlying network 165 a connected IPv6 or IPv4 network routing region over which AERO 166 nodes tunnel IPv6 packets. 168 underlying interface 169 an AERO node's interface point of attachment to an underlying 170 network. 172 underlying address 173 an IP address assigned to an AERO node's underlying interface. 174 When UDP encapsulation is used, the UDP port number is also 175 considered as part of the underlying address. Underlying 176 addresses are used as the source and destination addresses of the 177 AERO encapsulation header. 179 link-layer address 180 the same as defined for "underlying address" above, and formed 181 from the concatenation of the UDP port number and underlying 182 address as specified in Section 3.3. 184 network layer address 185 an IPv6 address used as the source or destination address of the 186 inner IPv6 packet header. 188 end user network (EUN) 189 an IPv6 network attached to a downstream interface of an AERO 190 Client (where the AERO interface is seen as the upstream 191 interface). 193 Throughout the document, the simple terms "Client", "Server" and 194 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 195 respectively. Capitalization is used to distinguish these terms from 196 DHCPv6 client/server/relay. This is an important distinction, since 197 an AERO Server may be a DHCPv6 relay, and an AERO Relay may be a 198 DHCPv6 server. 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 3. Asymmetric Extended Route Optimization (AERO) 206 The following sections specify the operation of IPv6 over Asymmetric 207 Extended Route Optimization (AERO) links: 209 3.1. AERO Node Types 211 AERO Relays relay packets between nodes connected to the same AERO 212 link and also forward packets between the AERO link and the native 213 IPv6 network. The relaying process entails re-encapsulation of IPv6 214 packets that were received from a first AERO node and are to be 215 forwarded without modification to a second AERO node. 217 AERO Servers configure their AERO interfaces as router interfaces, 218 and provide default routing services to AERO Clients. AERO Servers 219 configure a DHCPv6 relay or server function and facilitate DHCPv6 220 Prefix Delegation (PD) exchanges. An AERO Server may also act as an 221 AERO Relay. 223 AERO Clients act as requesting routers to receive IPv6 prefixes 224 through a DHCPv6 PD exchange via an AERO Server over the AERO link. 225 (Clients typically associate with a single Server at a time; Clients 226 MAY associate with multiple Servers, but associating with many 227 Servers may result in excessive control message overhead.) Each AERO 228 Client receives at least a /64 prefix delegation, and may receive 229 even shorter prefixes. 231 AERO Clients that act as routers configure their AERO interfaces as 232 router interfaces and sub-delegate portions of their received prefix 233 delegations to links on EUNs. End system applications on AERO 234 Clients that act as routers bind to EUN interfaces (i.e., and not the 235 AERO interface). 237 AERO Clients that act as ordinary hosts configure their AERO 238 interfaces as host interfaces and assign one or more IPv6 addresses 239 taken from their received prefix delegations to the AERO interface 240 but DO NOT assign the delegated prefix itself to the AERO interface. 242 Instead, the host assigns the delegated prefix to a "black hole" 243 route so that unused portions of the prefix are nullified. End 244 system applications on AERO Clients that act as hosts bind directly 245 to the AERO interface. 247 3.2. AERO Addresses 249 An AERO address is an IPv6 link-local address assigned to an AERO 250 interface and with an IPv6 prefix embedded within the interface 251 identifier. The AERO address is formatted as: 253 fe80::[IPv6 prefix] 255 Each AERO Client configures an AERO address based on the prefix it 256 has received from the AERO link prefix delegation authority (e.g., 257 the DHCPv6 server). The address begins with the prefix fe80::/64 and 258 includes in its interface identifier the base /64 prefix taken from 259 the Client's delegated IPv6 prefix. The base prefix is determined by 260 masking the delegated prefix with the prefix length. For example, if 261 an AERO Client has received the prefix delegation: 263 2001:db8:1000:2000::/56 265 it would construct its AERO address as: 267 fe80::2001:db8:1000:2000 269 The AERO address remains stable as the Client moves between 270 topological locations, i.e., even if its underlying address changes. 272 Each AERO Server configures the AERO address 'fe80::0'; this 273 corresponds to the IPv6 "default" prefix (i.e., ::/0) and provides a 274 handle for Clients to insert into a neighbor cache entry. 276 3.3. AERO Interface Characteristics 278 AERO interfaces use IPv6-in-IPv6 encapsulation [RFC2473] to exchange 279 tunneled packets with AERO neighbors attached to an underlying IPv6 280 network, and use IPv6-in-IPv4 encapsulation [RFC4213] to exchange 281 tunneled packets with AERO neighbors attached to an underlying IPv4 282 network. AERO interfaces can also operate over secured tunnel types 283 such as IPsec [RFC4301] or TLS [RFC5246] in environments where strong 284 authentication and confidentiality are required. When NAT traversal 285 and/or filtering middlebox traversal may be necessary, a UDP header 286 is further inserted immediately above the outer IP encapsulation 287 header. 289 Servers assign the link-local address fe80::0 to their AERO 290 interfaces. Servers and Relays also use (non-AERO) administratively- 291 assigned link-local addresses to support the operation of the inter- 292 Server/Relay routing system (see: [IRON]). 294 Clients initially use a temporary IPv6 link-local address in the 295 DHCPv6 PD exchanges used to receive an IPv6 prefix and derive an AERO 296 address. If the Client is pre-provisioned with an IPv6 prefix 297 associated with the AERO service, it SHOULD use the AERO address 298 derived from the prefix as the temporary address. Otherwise, the 299 Client SHOULD use "fe80::1" as the temporary address since this 300 address will not conflict with any valid AERO addresses and will thus 301 not be used in any AERO neighbor discovery messaging. After the 302 Client receives a prefix delegation, it assigns the corresponding 303 AERO address to the AERO interface. DHCPv6 is therefore used to 304 bootstrap the assignment of unique link-local addresses on the AERO 305 link. 307 AERO interfaces maintain a neighbor cache and use an augmentation of 308 standard unicast IPv6 ND messaging. AERO interfaces use Redirect, 309 Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router 310 Solicitation (RS) and Router Advertisement (RA) messages the same as 311 for any IPv6 link. AERO links further use link-local-only 312 addressing; hence, Clients ignore any Prefix Information Options 313 (PIOs) they may receive in RA messages. 315 AERO Redirect messages include TLLAOs the same as for any IPv6 link. 316 The TLLAO includes the link-layer address for the target node, which 317 is formed from the concatenation of a 1-octet Link ID value followed 318 by a 1-octet Preference value followed by the 2-octet UDP port number 319 used by the target when it sends UDP-encapsulated packets over the 320 AERO interface (or 0 when the target does not use UDP encapsulation) 321 followed by a 16-octet IP address. The TLLAO format is shown in 322 Figure 1: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type = 2 | Length = 3 | Reserved | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Link ID | Preference | UDP Port Number (or 0) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 +-- --+ 333 | | 334 +-- IP Address --+ 335 | | 336 +-- --+ 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Figure 1: AERO TLLAO Format for IPv6 342 In this format, Link ID is an integer value between 0 and 255 343 corresponding to the underlying interface by the target node, and 344 Preference is an integer value between 0 and 255 indicating the 345 target node's preference for this underlying interface (with 0 being 346 highest preference and 255 being lowest). UDP Port Number and IP 347 Address are the addresses that appear in the outer encapsulating 348 headers of packets sent over the target node's underlying interface. 349 (Note that when the encapsulation IP address family is IPv4 the IP 350 address is formed as an IPv4-compatible IPv6 address (see: 351 [RFC4291]). Note also that multiple TLLAO options may appear in an 352 ND message, e.g., if the target node wishes to publish multiple 353 underlying interfaces.) 355 AERO NS/NA/RS/RA messages include Source/Target Link Layer Address 356 Options (S/TLLAOs) formatted as shown in Figure 1 with Link ID and 357 Preference fields set to values corresponding to the underlying 358 interface that will convey (encapsulated) messages but with UDP Port 359 Number and IP Address values set to 0 (since the source may have no 360 way of knowing whether there is a NAT on the path and hence may be 361 unable to convey the correct values). Instead, AERO nodes ignore the 362 address information in these S/TLLAOs and determine the link-layer 363 addresses of neighbors by examining the link-layer source address of 364 any NS/NA/RS/RA messages they receive. Therefore, Redirect messages 365 alone convey non-zero address information in TLLAOs. 367 Finally, AERO interface NS/NA/RS/RA messages only update existing 368 neighbor cache entires and do not create new neighbor cache entries, 369 whereas Redirect messages can both update and create neighbor cache 370 entries. 372 3.3.1. Coordination of Multiple Underlying Interfaces 374 AERO interfaces may be configured over multiple underlying 375 interfaces. From the perspective of IPv6 Neighbor Discovery, the 376 AERO interface therefore appears as a single logical interface with 377 multiple link-layer addresses the same as described for "Inbound Load 378 Balancing" in Section 3 of [RFC4861]. The load balancing paradigm 379 applies to AERO Servers that are connected to stable backhaul 380 networks, but may not necessarily be appropriate for AERO Clients 381 that connect to multiple diverse media types. 383 For example, common handheld devices of the modern era have both 384 wireless local area network (aka "WiFi") and cellular wireless links. 385 These links are typically used "one at a time" with low-cost WiFi 386 preferred and highly-available cellular wireless as a cold standby. 387 In a more complex example, aircraft frequently have many wireless 388 data link types (e.g. satellite-based, terrestrial, directional 389 point-to-point, etc.) with diverse performance and cost properties. 391 If a Client's multiple underlying interfaces are used "one at a time" 392 (i.e., all other interfaces are quiescent when one interface is 393 active), then the S/TLLAOs in ND messages SHOULD use the same Link ID 394 and Preference values regardless of the underlying interface. If 395 multiple underlying interfaces may be used simultaneously, the Client 396 instead MAY use a different Link ID and Preference value for each 397 interface. In that case, the Client would need to send separate RS 398 messages to each of its Servers for each underlying interface it 399 wishes to activate so that the Server can convey correct addressing 400 information in the TLLAOs of Redirect messages. 402 3.4. AERO Interface Neighbor Cache Maintenace 404 Each AERO node maintains a per-AERO interface conceptual neighbor 405 cache that includes an entry for each neighbor it communicates with 406 on the AERO link, the same as for any IPv6 interface (see [RFC4861]). 407 Neighbor cache entries are created and maintained as follows: 409 When an AERO Server relays a DHCPv6 Reply message to an AERO Client, 410 it creates or updates a neighbor cache entry for the Client based on 411 the information in the IA_PD option as the Client's network layer 412 address and the Client's outer IP address and UDP port number as the 413 link-layer address. 415 When an AERO Client receives a DHCPv6 Reply message from an AERO 416 Server, it creates or updates a neighbor cache entry for the Server 417 based on fe80::0 as the network layer address and the Server's outer 418 IP address and UDP port number as the link-layer address . 420 When an AERO Client receives a valid Predirect message (See 421 Section 3.10.5) it creates or updates a neighbor cache entry for the 422 Predirect target network-layer and link-layer addresses, and also 423 creates an IPv6 forwarding table entry for the Predirected (source) 424 prefix. The node then sets an "ACCEPT_TIME" timer in the neighbor 425 cache entry and uses this timer to validate any messages received 426 from the Predirected neighbor. 428 When an AERO Client receives a valid Redirect message (see 429 Section 3.10.7) it creates or updates a neighbor cache entry for the 430 Redirect target network-layer and link-layer addresses, and also 431 creates an IPv6 forwarding table entry for the redirected 432 (destination) prefix. The node then sets a "FORWARD_TIME" timer in 433 the neighbor cache entry and uses this timer to determine whether 434 packets can be sent directly to the redirected neighbor. The node 435 also maintains a constant value MAX_RETRY to limit the number of 436 keepalives sent when a neighbor has gone unreachable. 438 When an AERO Client receives a valid NS message it (re)sets the 439 ACCEPT_TIME timer for this neighbor. 441 When an AERO Client receives a valid NA message, it (re)sets the 442 FORWARD_TIME timer for this neighbor. 444 It is RECOMMENDED that FORWARD_TIME be set to the default constant 445 value 30 seconds to match the default REACHABLE_TIME value specified 446 for IPv6 neighbor discovery [RFC4861]. 448 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 449 value 40 seconds to allow a 10 second window so that the AERO 450 redirection procedure can converge before the ACCEPT_TIME timer 451 decrements below FORWARD_TIME. 453 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 454 for IPv6 neighbor discovery address resolution in Section 7.3.3 of 455 [RFC4861]. 457 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 458 administratively set, if necessary, to better match the AERO link's 459 performance characteristics; however, if different values are chosen, 460 all nodes on the link MUST consistently configure the same values. 461 ACCEPT_TIME SHOULD further be set to a value that is sufficiently 462 longer than FORWARD_TIME to allow the AERO redirection procedure to 463 converge. 465 3.5. AERO Interface Data Origin Authentication 467 AERO nodes use a simple data origin authentication for encapsulated 468 packets they receive from other nodes. In particular, AERO Clients 469 accept encapsulated packets with a link-layer source address 470 belonging to one of their current AERO Servers and all AERO nodes 471 accept encapsulated packets with a link-layer source address that is 472 correct for the network-layer source address. 474 The AERO node considers the link-layer source address correct for the 475 network-layer source address if there is an IPv6 forwarding table 476 entry that matches the network-layer source address as well as a 477 neighbor cache entry corresponding to the next hop that includes the 478 link-layer address and the ACCEPT_TIME timer is non-zero. An 479 exception is that neighbor discovery messages may include a different 480 link-layer address than the one currently in the neighbor cache, and 481 the new link-layer address updates the neighbor cache entry. 483 3.6. AERO Interface MTU Considerations 485 The AERO link Maximum Transmission Unit (MTU) is 64KB minus the 486 encapsulation overhead for IPv4 [RFC0791] and 4GB minus the 487 encapsulation overhead for IPv6 [RFC2675]. This is the most that 488 IPv4 and IPv6 (respectively) can convey within the constraints of 489 protocol constants, but actual sizes available for tunneling will 490 frequently be much smaller. 492 The base tunneling specifications for IPv4 and IPv6 typically set a 493 static MTU on the tunnel interface to 1500 bytes minus the 494 encapsulation overhead or smaller still if the tunnel is likely to 495 incur additional encapsulations on the path. This can result in path 496 MTU related black holes when packets that are too large to be 497 accommodated over the AERO link are dropped, but the resulting ICMP 498 Packet Too Big (PTB) messages are lost on the return path. As a 499 result, AERO nodes use the following MTU mitigations to accommodate 500 larger packets. 502 AERO nodes set their AERO interface MTU to the larger of the 503 underlying interface MTU minus the encapsulation overhead, and 1500 504 bytes. (If there are multiple underlying interfaces, the node sets 505 the AERO interface MTU according to the largest underlying interface 506 MTU, or 64KB /4G minus the encapsulation overhead if the largest MTU 507 cannot be determined.) AERO nodes optionally cache other per- 508 neighbor MTU values in the underlying IP path MTU discovery cache 509 initialized to the underlying interface MTU. 511 AERO nodes admit packets that are no larger than 1280 bytes minus the 512 encapsulation overhead (*) as well as packets that are larger than 513 1500 bytes into the tunnel without fragmentation, i.e., as long as 514 they are no larger than the AERO interface MTU before encapsulation 515 and also no larger than the cached per-neighbor MTU following 516 encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit 517 to 0 for packets no larger than 1280 bytes minus the encapsulation 518 overhead (*) and sets the DF bit to 1 for packets larger than 1500 519 bytes. If a large packet is lost in the path, the node may 520 optionally cache the MTU reported in the resulting PTB message or may 521 ignore the message, e.g., if there is a possibility that the message 522 is spurious. 524 For packets destined to an AERO node that are larger than 1280 bytes 525 minus the encapsulation overhead (*) but no larger than 1500 bytes, 526 the node uses outer IP fragmentation to fragment the packet into two 527 pieces (where the first fragment contains 1024 bytes of the 528 fragmented inner packet) then admits the fragments into the tunnel. 529 If the outer protocol is IPv4, the node admits the packet into the 530 tunnel with DF set to 0 and subject to rate limiting to avoid 531 reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the 532 node also sends a 1500 byte probe message (**) to the neighbor, 533 subject to rate limiting. To construct a probe, the node prepares an 534 ICMPv6 Neighbor Solicitation (NS) message with trailing padding 535 octets added to a length of 1500 bytes but does not include the 536 length of the padding in the IPv6 Payload Length field. The node 537 then encapsulates the NS in the outer encapsulation headers (while 538 including the length of the padding in the outer length fields), sets 539 DF to 1 (for IPv4) and sends the padded NS message to the neighbor. 540 If the neighbor returns an NA message, the node may then send whole 541 packets within this size range and (for IPv4) relax the rate limiting 542 requirement. 544 AERO nodes MUST be capable of reassembling packets up to 1500 bytes 545 plus the encapsulation overhead length. It is therefore RECOMMENDED 546 that AERO nodes be capable of reassembling at least 2KB. 548 (*) Note that if it is known without probing that the minimum Path 549 MTU to an AERO node is MINMTU bytes (where 1280 < MINMTU < 1500) then 550 MINMTU can be used instead of 1280 in the fragmentation threshold 551 considerations listed above. 553 (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used 554 for MTU probing purposes, since smaller probes may be fragmented if 555 there is a nested tunnel somewhere on the path to the neighbor. 556 Probe sizes larger than 1500 bytes MAY be used, but may be 557 unnecessary since original sources are expected to implement 558 [RFC4821] when sending large packets. 560 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 562 AERO interfaces encapsulate IPv6 packets according to whether they 563 are entering the AERO interface for the first time or if they are 564 being forwarded out the same AERO interface that they arrived on. 565 This latter form of encapsulation is known as "re-encapsulation". 567 AERO interfaces encapsulate packets per the specifications in 568 [RFC2473][RFC4213][RFC4301][RFC5246] except that the interface copies 569 the "Hop Limit", "Traffic Class" and "Congestion Experienced" values 570 in the inner IPv6 header into the corresponding fields in the outer 571 IP header. For packets undergoing re-encapsulation, the AERO 572 interface instead copies the "TTL/Hop Limit", "Type of Service/ 573 Traffic Class" and "Congestion Experienced" values in the original 574 outer IP header into the corresponding fields in the new outer IP 575 header (i.e., the values are transferred between outer headers and 576 *not* copied from the inner network-layer header). 578 When AERO UDP encapsulation is used, the AERO interface encapsulates 579 the packet per the specifications in [RFC2473][RFC4213] except that 580 it inserts a UDP header between the outer IP header and inner IPv6 581 header. The AERO interface sets the UDP source port to a constant 582 value that it will use in each successive packet it sends, sets the 583 UDP checksum field to zero (see: [RFC6935][RFC6936]) and sets the UDP 584 length field to the length of the inner packet plus 8 bytes for the 585 UDP header itself. For packets sent via a Server, the AERO interface 586 sets the UDP destination port to 8060 (i.e., the IANA-registered port 587 number for AERO) when AERO-only encapsulation is used. For packets 588 sent to a neighboring Client, the AERO interface sets the UDP 589 destination port to the port value stored in the neighbor cache entry 590 for this neighbor. 592 The AERO interface next sets the outer IP protocol number to the 593 appropriate value for the first protocol layer within the 594 encapsulation (e.g., IPv6, UDP, IPsec, etc.). When IPv6 is used as 595 the outer IP protocol, the interface then sets the flow label value 596 in the outer IPv6 header the same as described in [RFC6438]. When 597 IPv4 is used as the outer IP protocol, the AERO interface sets the DF 598 bit as discussed in Section 3.6. 600 AERO interfaces decapsulate packets destined either to the node 601 itself or to a destination reached via an interface other than the 602 receiving AERO interface. When AERO UDP encapsulation is used (i.e., 603 when a UDP header with destination port 8060 is present) the 604 interface examines the first octet of the encapsulated packet. If 605 the most significant four bits of the first octet encode the value 606 '0110' (i.e., the version number value for IPv6), the packet is 607 accepted and the encapsulating UDP header is discarded; otherwise, 608 the packet is discarded. 610 Further decapsulation then proceeds according to the appropriate 611 tunnel type [RFC2473][RFC4213][RFC4301][RFC5246]. 613 3.8. AERO Router Discovery, Prefix Delegation and Address Configuration 615 3.8.1. AERO Client Behavior 617 AERO Clients observe the IPv6 node requirements defined in [RFC6434]. 618 AERO Clients first discover the link-layer addresses of AERO Servers 619 via static configuration, or through an automated means such as DNS 620 name resolution. In the absence of other information, the Client 621 resolves the Fully-Qualified Domain Name (FQDN) 622 "linkupnetworks.domainname", where "domainname" is the DNS domain 623 appropriate for the Client's attached underlying network. The Client 624 then creates a neighbor cache entry with fe80::0 as the link-local 625 address and the discovered address of one or more Servers as the 626 link-layer addresses. The neighbor cache entry is created with both 627 ACCEPT_TIME and FORWARD_TIME set to infinity, since the Client will 628 remain with its current Server(s) unless it explicitly switches to 629 different Server(s). 631 Next, the Client acts as a requesting router to request an IPv6 632 prefix through DHCPv6 PD [RFC3633] via each AERO Server it wishes to 633 associate with using a temporary link-local address (see: 634 Section 3.3) as the IPv6 source address and fe80::0 as the IPv6 635 destination address. The Client includes a DHCPv6 Unique Identifier 636 (DUID) in the Client Identifier option of its DHCPv6 messages 637 [RFC3315][RFC6355] and includes any additional authenticating 638 information necessary to authenticate itself to the DHCPv6 server. 639 If the Client is pre-provisioned with an IPv6 prefix associated with 640 the AERO service, it MAY also include the prefix in an IA_PD option 641 in its DHCPv6 Request command to indicate its preferred prefix to the 642 DHCPv6 server. 644 After the Client receives its prefix delegation, it assigns the link- 645 local AERO address taken from the prefix to the AERO interface (see: 646 Section 3.3) and sub-delegates the prefix to nodes and links within 647 its attached EUNs (the AERO link-local address thereafter remains 648 stable as the Client moves). The Client further renews its prefix 649 delegation via standard DHCPv6 procedures by sending DHCPv6 Renew 650 messages with its AERO address as the IPv6 source address, fe80::0 as 651 the IPv6 destination address and the same DUID value in the Client 652 Identifier option. 654 The Client then sends an RS message to each of its associated Servers 655 to receive an RA message with a default router lifetime and any other 656 link-specific parameters. When the Client receives an RA message, it 657 configures a default route according to the default router lifetime 658 but ignores any Prefix Information Options (PIOs) included in the RA 659 message since the AERO link is link-local-only. The Client further 660 ignores any RS messages it might receive, since only Servers may 661 process RS messages. 663 The Client then sends periodic RS messages to each Server (subject to 664 rate limiting) to obtain new RA messages for Neighbor Unreachability 665 Detection (NUD), to refresh any network state, and to update the 666 default router lifetime and any other link-specific parameters. The 667 Client can also forward IPv6 packets destined to networks beyond its 668 local EUNs via a Server as an IPv6 default router. The Server may in 669 turn return a redirection message informing the Client of a neighbor 670 on the AERO link that is topologically closer to the final 671 destination as specified in Section 3.9. 673 Note that, since the Client's AERO address is configured from the 674 unique DHCPv6 prefix delegation it receives, there is no need for 675 Duplicate Address Detection (DAD) on AERO links. Other nodes 676 maliciously attempting to hijack an authorized Client's AERO address 677 will be denied due to an unacceptable link-layer address and/or 678 security parameters (see: Security Considerations). 680 3.8.2. AERO Server Behavior 682 AERO Servers observe the IPv6 router requirements defined in 683 [RFC6434] and further configure a DHCPv6 relay function on their AERO 684 links. When the AERO Server relays a Client's DHCPv6 PD messages to 685 the DHCPv6 server, it wraps each message in a "Relay-forward" message 686 per [RFC3315] and includes a DHCPv6 Interface Identifier option that 687 encodes a value that identifies the AERO link to the DHCPv6 server. 689 The Server then includes the Client's link-layer address in a DHCPv6 690 Client Link Layer Address Option (CLLAO) [RFC6939] with the link- 691 layer address format shown in Figure 1. The Server sets the CLLAO 692 'option-length' field to 22 (2 plus the length of the link-layer 693 address) and sets the 'link-layer type' field to TBD (see: IANA 694 Considerations). The Server finally includes a DHCPv6 Echo Request 695 Option (ERO) [RFC4994] that encodes the option code for the CLLAO in 696 a 'requested-option-code-n' field. The CLLAO information will 697 therefore subsequently be echoed back in the DHCPv6 Server's "Relay- 698 reply" message. 700 When the DHCPv6 server issues the IPv6 prefix delegation in a "Relay- 701 reply" message via the AERO Server (acting as a DHCPv6 relay), the 702 AERO Server obtains the Client's link-layer address from the echoed 703 CLLAO option and obtains the Client's delegated prefix from the 704 included IA_PD option. The Server then creates a neighbor cache 705 entry for the Client's AERO address (see: Section 3.3) with the 706 Client's link-layer address as the link-layer address for the 707 neighbor cache entry. The neighbor cache entry is created with both 708 ACCEPT_TIME and FORWARD_TIME set to infinity, since the Client will 709 remain with this Server unless it explicitly disassociates with the 710 Server. 712 The Server also configures an IPv6 forwarding table entry that lists 713 the Client's AERO address as the next hop toward the delegated IPv6 714 prefix with a lifetime derived from the DHCPv6 lease lifetime. The 715 Server finally injects the Client's prefix as an IPv6 route into the 716 inter-Server/Relay routing system (see: [IRON]) then relays the 717 DHCPv6 message to the Client while using fe80::0 as the IPv6 source 718 address, the link-local address found in the "peer address" field of 719 the Relay-reply message as the IPv6 destination address, and the 720 Client's link-layer address as the destination link-layer address. 722 Servers respond to RS/NS messages from Clients on their AERO 723 interfaces by returning an RA/NA message. When the Server receives 724 an RS/NS message, it updates the neighbor cache entry using the 725 network-layer source address as the neighbor's network-layer address 726 and using the link-layer source address of the RS/NS message as the 727 neighbor's link-layer address. The Server SHOULD NOT include PIOs in 728 any RA messages it sends to Clients, since the Client will ignore any 729 such options. 731 Servers ignore any RA messages they may receive from a Client. 732 Servers MAY examine RA messages they may receive from other Servers 733 for consistency verification purposes. 735 When the Server forwards a packet via the same AERO interface on 736 which it arrived, it initiates an AERO route optimization procedure 737 as specified in Section 3.9. 739 3.9. AERO Redirection 741 3.9.1. Reference Operational Scenario 743 Figure 2 depicts the AERO redirection reference operational scenario. 744 The figure shows an AERO Server('A'), two AERO Clients ('B', 'D') and 745 three ordinary IPv6 hosts ('C', 'E', 'F'): 747 .-(::::::::) 748 .-(::: IPv6 :::)-. +-------------+ 749 (:::: Internet ::::)--| Host F | 750 `-(::::::::::::)-' +-------------+ 751 `-(::::::)-' 2001:db8:2::1 752 | 753 +--------------+ 754 | AERO Server A| 755 | (C->B; E->D) | 756 +--------------+ 757 fe80::0 758 L2(A) 759 | 760 X-----+-----------+-----------+--------X 761 | AERO Link | 762 L2(B) L2(D) 763 fe80::2001:db8:0:0 fe80::2001:db8:1:0 .-. 764 +--------------+ +--------------+ ,-( _)-. 765 | AERO Client B| | AERO Client D| .-(_ IPv6 )-. 766 | (default->A) | | (default->A) |--(__ EUN ) 767 +--------------+ +--------------+ `-(______)-' 768 2001:DB8:0::/48 2001:DB8:1::/48 | 769 | 2001:db8:1::1 770 .-. +-------------+ 771 ,-( _)-. 2001:db8:0::1 | Host E | 772 .-(_ IPv6 )-. +-------------+ +-------------+ 773 (__ EUN )--| Host C | 774 `-(______)-' +-------------+ 776 Figure 2: AERO Reference Operational Scenario 778 In Figure 2, AERO Server ('A') connects to the AERO link and connects 779 to the IPv6 Internet, either directly or via an AERO Relay (not 780 shown). Server ('A') assigns the address fe80::0 to its AERO 781 interface with link-layer address L2(A). Server ('A') next arranges 782 to add L2(A) to a published list of valid Servers for the AERO link. 784 AERO Client ('B') receives the IPv6 prefix 2001:db8:0::/48 in a 785 DHCPv6 PD exchange via AERO Server ('A') then assigns the address 786 fe80::2001:db8:0:0 to its AERO interface with link-layer address 787 L2(B). Client ('B') configures a default route via the AERO 788 interface with next-hop address fe80::0 and link-layer address L2(A), 789 then sub-delegates the prefix 2001:db8:0::/48 to its attached EUNs. 790 IPv6 host ('C') connects to the EUN, and configures the address 791 2001:db8:0::1. 793 AERO Client ('D') receives the IPv6 prefix 2001:db8:1::/48 in a 794 DHCPv6 PD exchange via AERO Server ('A') then assigns the address 795 fe80::2001:db8:1:0 to its AERO interface with link-layer address 796 L2(D). Client ('D') configures a default route via the AERO 797 interface with next-hop address fe80::0 and link-layer address L2(A), 798 then sub-delegates the prefix 2001:db8:1::/48 to its attached EUNs. 799 IPv6 host ('E') connects to the EUN, and configures the address 800 2001:db8:1::1. 802 Finally, IPv6 host ('F') connects to an IPv6 network outside of the 803 AERO link domain. Host ('F') configures its IPv6 interface in a 804 manner specific to its attached IPv6 link, and assigns the address 805 2001:db8:2::1 to its IPv6 link interface. 807 3.9.2. Classical Redirection Approaches 809 With reference to Figure 2, when the IPv6 source host ('C') sends a 810 packet to an IPv6 destination host ('E'), the packet is first 811 forwarded via the EUN to AERO Client ('B'). Client ('B') then 812 forwards the packet over its AERO interface to AERO Server ('A'), 813 which then re-encapsulates and forwards the packet to AERO Client 814 ('D'), where the packet is finally forwarded to the IPv6 destination 815 host ('E'). When Server ('A') re-encapsulates and forwards the 816 packet back out on its advertising AERO interface, it must arrange to 817 redirect Client ('B') toward Client ('D') as a better next-hop node 818 on the AERO link that is closer to the final destination. However, 819 this redirection process applied to AERO interfaces must be more 820 carefully orchestrated than on ordinary links since the parties may 821 be separated by potentially many underlying network routing hops. 823 Consider a first alternative in which Server ('A') informs Client 824 ('B') only and does not inform Client ('D') (i.e., "classical 825 redirection"). In that case, Client ('D') has no way of knowing that 826 Client ('B') is authorized to forward packets from the claimed source 827 address, and it may simply elect to drop the packets. Also, Client 828 ('B') has no way of knowing whether Client ('D') is performing some 829 form of source address filtering that would reject packets arriving 830 from a node other than a trusted default router, nor whether Client 831 ('D') is even reachable via a direct path that does not involve 832 Server ('A'). 834 Consider a second alternative in which Server ('A') informs both 835 Client ('B') and Client ('D') separately, via independent redirection 836 control messages (i.e., "augmented redirection"). In that case, if 837 Client ('B') receives the redirection control message but Client 838 ('D') does not, subsequent packets sent by Client ('B') could be 839 dropped due to filtering since Client ('D') would not have a route to 840 verify the claimed source address. Also, if Client ('D') receives 841 the redirection control message but Client ('B') does not, subsequent 842 packets sent in the reverse direction by Client ('D') would be lost. 844 Since both of these alternatives have shortcomings, a new redirection 845 technique (i.e., "AERO redirection") is needed. 847 3.9.3. Concept of Operations 849 Again, with reference to Figure 2, when source host ('C') sends a 850 packet to destination host ('E'), the packet is first forwarded over 851 the source host's attached EUN to Client ('B'), which then forwards 852 the packet via its AERO interface to Server ('A'). 854 Server ('A') then re-encapsulates and forwards the packet out the 855 same AERO interface toward Client ('D') and also sends an AERO 856 "Predirect" message forward to Client ('D') as specified in 857 Section 3.9.5. The Predirect message includes Client ('B')'s 858 network- and link-layer addresses as well as information that Client 859 ('D') can use to determine the IPv6 prefix used by Client ('B') . 860 After Client ('D') receives the Predirect message, it process the 861 message and returns an AERO Redirect message destined for Client 862 ('B') via Server ('A') as specified in Section 3.9.6. During the 863 process, Client ('D') also creates or updates a neighbor cache entry 864 for Client ('B') in the "ACCEPT" state, and creates an IPv6 865 forwarding table entry for Client ('B')'s IPv6 prefix. 867 When Server ('A') receives the Redirect message, it re-encapsulates 868 the message and forwards it on to Client ('B') as specified in 869 Section 3.9.7. The message includes Client ('D')'s network- and 870 link-layer addresses as well as information that Client ('B') can use 871 to determine the IPv6 prefix used by Client ('D'). After Client 872 ('B') receives the Redirect message, it processes the message as 873 specified in Section 3.9.8. During the process, Client ('B') also 874 creates or updates a neighbor cache entry for Client ('D') in the 875 "FORWARD" state, and creates an IPv6 forwarding table entry for 876 Client ('D')'s IPv6 prefix. 878 Following the above Predirect/Redirect message exchange, forwarding 879 of packets from Client ('B') to Client ('D') without involving Server 880 ('A) as an intermediary is enabled. The mechanisms that support this 881 exchange are specified in the following sections. 883 3.9.4. Message Format 885 AERO Redirect/Predirect messages use the same format as for ICMPv6 886 Redirect messages depicted in Section 4.5 of [RFC4861], but also 887 include a new "Prefix Length" field taken from the low-order 8 bits 888 of the Redirect message Reserved field (valid values for the Prefix 889 Length field are 0 through 64). The Redirect/Predirect messages are 890 formatted as shown in Figure 3: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Type (=137) | Code (=0/1) | Checksum | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Reserved | Prefix Length | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | | 900 + + 901 | | 902 + Target Address + 903 | | 904 + + 905 | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | | 908 + + 909 | | 910 + Destination Address + 911 | | 912 + + 913 | | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Options ... 916 +-+-+-+-+-+-+-+-+-+-+-+- 918 Figure 3: AERO Redirect/Predirect Message Format 920 3.9.5. Sending Predirects 922 When a Server forwards a packet out the same AERO interface that it 923 arrived on, the Server sends a Predirect message forward toward the 924 AERO Client nearest the destination instead of sending a Redirect 925 message back to Client nearest the source. 927 In the reference operational scenario, when Server ('A') forwards a 928 packet sent by Client ('B') toward Client ('D'), it also sends a 929 Predirect message forward toward Client ('D'), subject to rate 930 limiting (see Section 8.2 of [RFC4861]). Server ('A') prepares the 931 Predirect message as follows: 933 o the link-layer source address is set to 'L2(A)' (i.e., the 934 underlying address of Server ('A')). 936 o the link-layer destination address is set to 'L2(D)' (i.e., the 937 underlying address of Client ('D')). 939 o the network-layer source address is set to fe80::0 (i.e., the 940 link-local address of Server ('A')). 942 o the network-layer destination address is set to fe80::2001:db8:1:0 943 (i.e., the AERO address of Client ('D')). 945 o the Type is set to 137. 947 o the Code is set to 1 to indicate "Predirect". 949 o the Prefix Length is set to the length of the prefix to be applied 950 to Target address. 952 o the Target Address is set to fe80::2001:db8:0::0 (i.e., the AERO 953 address of Client ('B')). 955 o the Destination Address is set to the IPv6 source address of the 956 packet that triggered the Predirection event. 958 o the message includes one or more TLLAOs set to 'L2(B)' and any 959 other underlying address(es) of Client ('B'). 961 o the message includes a Redirected Header Option (RHO) that 962 contains the originating packet truncated to ensure that at least 963 the network-layer header is included but the size of the message 964 does not exceed 1280 bytes. 966 Server ('A') then sends the message forward to Client ('D'). 968 3.9.6. Processing Predirects and Sending Redirects 970 When Client ('D') receives a Predirect message, it accepts the 971 message only if it the message has a link-layer source address of the 972 Server, i.e. 'L2(A)'. Client ('D') further accepts the message only 973 if it is willing to serve as a redirection target. Next, Client 974 ('D') validates the message according to the ICMPv6 Redirect message 975 validation rules in Section 8.1 of [RFC4861]. 977 In the reference operational scenario, when the Client ('D') receives 978 a valid Predirect message, it either creates or updates a neighbor 979 cache entry that stores the Target Address of the message as the 980 network-layer address of Client ('B') and stores the link-layer 981 address(es) found in the TLLAO(s) as the link-layer address(es) of 982 Client ('B'). Client ('D') then sets the neighbor cache entry in the 983 ACCEPT state with timeout value ACCEPT-TIME. Next, Client ('D') 984 applies the Prefix Length to the Interface Identifier portion of the 985 Target Address and records the resulting IPv6 prefix in its IPv6 986 forwarding table. 988 After processing the message, Client ('D') prepares a Redirect 989 message response as follows: 991 o the link-layer source address is set to 'L2(D)' (i.e., the link- 992 layer address of Client ('D')). 994 o the link-layer destination address is set to 'L2(A)' (i.e., the 995 link-layer address of Server ('A')). 997 o the network-layer source address is set to 'L3(D)' (i.e., the AERO 998 address of Client ('D')). 1000 o the network-layer destination address is set to 'L3(B)' (i.e., the 1001 AERO address of Client ('B')). 1003 o the Type is set to 137. 1005 o the Code is set to 0 to indicate "Redirect". 1007 o the Prefix Length is set to the length of the prefix to be applied 1008 to the Target and Destination address. 1010 o the Target Address is set to fe80::2001:db8:1::1 (i.e., the AERO 1011 address of Client ('D')). 1013 o the Destination Address is set to the IPv6 destination address of 1014 the packet that triggered the Redirection event. 1016 o the message includes one or more TLLAOs with UDP port number and 1017 IP address set to '0' and with Link ID and Preference values set 1018 to the appropriate values for the underlying interfaces Client 1019 ('D') wishes to enable for accepting encapsulated packets from 1020 Client ('B'). 1022 o the message includes as much of the RHO copied from the 1023 corresponding AERO Predirect message as possible such that at 1024 least the network-layer header is included but the size of the 1025 message does not exceed 1280 bytes. 1027 After Client ('D') prepares the Redirect message, it sends the 1028 message to Server ('A'). 1030 3.9.7. Re-encapsulating and Relaying Redirects 1032 When Server ('A') receives a Redirect message from Client ('D'), it 1033 accepts the message only if it has a neighbor cache entry that 1034 associates the message's link-layer source address with the network- 1035 layer source address. Next, Server ('A') validates the message 1036 according to the ICMPv6 Redirect message validation rules in 1037 Section 8.1 of [RFC4861] and also verifies that Client ('D') is 1038 authorized to use the Prefix Length in the Redirect message when 1039 applied to the AERO address in the network-layer source of the 1040 Redirect message. If validation fails, Server ('A') discards the 1041 message; otherwise, it copies the correct UDP port numbers and IP 1042 addresses into the TLLAOs supplied by Client ('D') according to the 1043 Link ID in each TLLAO. 1045 Server ('A') then re-encapsulates the Redirect and relays it on to 1046 Client ('B') by changing the link-layer source address of the message 1047 to 'L2(A)', changing the network-layer source address of the message 1048 to fe80::0, and changing the link-layer destination address to 1049 'L2(B)' . Server ('A') finally forwards the re-encapsulated message 1050 to the ingress node ('B') without decrementing the network-layer IPv6 1051 header Hop Limit field. 1053 While not shown in Figure 2, AERO Relays relay Redirect and Predirect 1054 messages in exactly this same fashion described above. See Figure 4 1055 in Appendix A for an extension of the reference operational scenario 1056 that includes Relays. 1058 3.9.8. Processing Redirects 1060 When Client ('B') receives the Redirect message, it accepts the 1061 message only if it has a link-layer source address of the Server, 1062 i.e. 'L2(A)'. Next, Client ('B') validates the message according to 1063 the ICMPv6 Redirect message validation rules in Section 8.1 of 1064 [RFC4861]. Following validation, Client ('B') then processes the 1065 message as follows. 1067 In the reference operational scenario, when Client ('B') receives the 1068 Redirect message, it either creates or updates a neighbor cache entry 1069 that stores the Target Address of the message as the network-layer 1070 address of Client ('D') and stores the link-layer address(es) found 1071 in the TLLAO(s) as the link-layer address(es) of Client ('D'). 1072 Client ('D') then sets the neighbor cache entry in the FORWARD state 1073 with timeout value FORWARD_TIME. Next, Client ('B') applies the 1074 Prefix Length to the Interface Identifier portion of the Target 1075 Address and records the resulting IPv6 prefix in its IPv6 forwarding 1076 table. 1078 Now, Client ('B') has an IPv6 forwarding table entry for 1079 Client('D')'s prefix and a neighbor cache entry with a valid 1080 FORWARD_TIME, while Client ('D') has an IPv6 forwarding table entry 1081 for Client ('B')'s prefix with a valid ACCEPT_TIME. Thereafter, 1082 Client ('B') may forward ordinary network-layer data packets directly 1083 to Client ("D") without involving Server ('A') and Client ('D') can 1084 verify that the packets came from an acceptable source. (In order 1085 for Client ('D') to forward packets to Client ('B') a corresponding 1086 Predirect/Redirect message exchange is required in the reverse 1087 direction.) 1089 3.10. Neighbor Reachability Maintenance 1091 Each AERO node uses its delegated prefix to create an AERO address 1092 (see: Section 3.3). It can then send unicast NS messages to elicit 1093 NA messages from neighbors the same as described for Neighbor 1094 Unreachability Detection (NUD) in [RFC4861] except that the UDP port 1095 and IP address fields of any included S/TLLAOs encode the value 0. 1096 When an AERO node sends an NS/NA message, it MUST use its AERO 1097 address as the IPv6 source address and the AERO address of the 1098 neighbor as the IPv6 destination address. When an AERO node receives 1099 an NS/NA message, it accepts the message if it has a neighbor cache 1100 entry for the neighbor; otherwise, it ignores the message. 1102 When a source Client is redirected to a target Client it SHOULD test 1103 the direct path to the target by sending an initial NS message to 1104 elicit a solicited NA response. While testing the path, the source 1105 Client SHOULD continue sending packets via the Server until target 1106 Client reachability has been confirmed. The source Client SHOULD 1107 thereafter continue to test the direct path to the target Client (see 1108 Section 7.3 of [RFC4861]) in order to keep neighbor cache entries 1109 alive. In particular, the source Client sends NS messages to the 1110 target Client subject to rate limiting in order to receive solicited 1111 NA messages. If at any time the direct path over all underlying 1112 interfaces appears to be failing, the source Client can resume 1113 sending packets via the Server which may or may not result in a new 1114 redirection event. 1116 When a target Client receives an NS message from a source Client, it 1117 resets the ACCEPT_TIME timer if a neighbor cache entry exists; 1118 otherwise, it discards the NS message. 1120 When a source Client receives a solicited NA message from a target 1121 Client, it resets the FORWARD_TIME timer if a neighbor cache entry 1122 exists; otherwise, it discards the NA message. 1124 When the FORWARD_TIME timer on a neighbor cache entry expires, the 1125 source Client resumes sending any subsequent packets via the Server 1126 and may (eventually) receive a new Redirect message. When the 1127 ACCEPT_TIME timer on a neighbor cache entry expires, the target 1128 Client discards any subsequent packets received directly from the 1129 source Client. When both the FORWARD_TIME and ACCEPT_TIME timers on 1130 a neighbor cache entry expire, the Client deletes both the neighbor 1131 cache entry and the corresponding IPv6 forwarding table entry. 1133 If the source Client is unable to elicit an NA response from the 1134 target Client after MAX_RETRY attempts, it SHOULD consider the direct 1135 path unusable for forwarding purpose. 1137 After reachability of the target Client has been verified, the source 1138 Client SHOULD thereafter process any link-layer errors as a hint that 1139 the direct path to the target Client has either failed or has become 1140 intermittent. 1142 3.11. Mobility and Link-Layer Address Change Considerations 1144 When a Client needs to change one of its link-layer addresses (e.g., 1145 due to a mobility event), it sends an immediate NS message to each of 1146 its active neighbors (including the Server) using the new link-layer 1147 address as the outer source address and with the correct Link ID and 1148 Preference values in the SLLAO. The Client processes any NA messages 1149 returned as an indication that the neighbor has received the update. 1151 When a Client needs to associate with a new Server, it issues a new 1152 DHCPv6 Request message via the new Server as the DHCPv6 relay. The 1153 new Server then relays the message to the DHCPv6 server and processes 1154 the resulting exchange the same as described in Section 3.9.2. After 1155 the Client receives the resulting DHCPv6 Reply message, it sends an 1156 RS message to the new Server to receive a new RA message and update 1157 its neighbor cache entry for fe80::0. 1159 When a Client disassociates with an existing Server, it sends a 1160 "terminating RS" message to the old Server. The terminating RS 1161 message is prepared exactly the same as for an ordinary RS message, 1162 except that the Code field contains the value '1'. When the old 1163 Server receives the terminating RS message, it withdraws the IPv6 1164 route from the routing system and deletes the neighbor cache entry 1165 and IPv6 forwarding table entry for the Client. The old Server then 1166 returns an RA message with default router lifetime set to 0 which the 1167 Client can use to verify that the termination signal has been 1168 processed. The client then deletes both the default route and the 1169 neighbor cache entry for the old Server. (Note that the Client and 1170 the old Server can impose a small delay before deleting the neighbor 1171 cache and IPv6 forwarding table entries so that any packets already 1172 in the system can still be delivered to the Client.) 1174 An alternative to sending a "terminating RS" message would be for the 1175 Client to somehow perform a DHCPv6 exchange with the DHCPv6 relay 1176 function on the old AERO Server but without involving the DHCPv6 1177 server. This would be insecure because the Client only has a DHCPv6 1178 security association with the DHCPv6 server and not the DHCPv6 relay. 1179 Conversely, the Client and Server already require an authentic 1180 exchange of IPv6 Neighbor Discovery messages. 1182 3.12. Underlying Protocol Version Considerations 1184 A source Client may connect only to an IPvX underlying network, while 1185 the target Client connects only to an IPvY underlying network. In 1186 that case, the target and source Clients have no means for reaching 1187 each other directly (since they connect to underlying networks of 1188 different IP protocol versions) and so must ignore any redirection 1189 messages and continue to send packets via the Server. 1191 3.13. Multicast Considerations 1193 When the underlying network does not support multicast, AERO nodes 1194 map IPv6 link-scoped multicast addresses (including 1195 "All_DHCP_Relay_Agents_and_Servers") to the underlying IP address of 1196 a Server. 1198 When the underlying network supports multicast, AERO nodes use the 1199 multicast address mapping specification found in [RFC2529] for IPv4 1200 underlying networks and use a direct multicast mapping for IPv6 1201 underlying networks. (In the latter case, "direct multicast mapping" 1202 means that if the IPv6 multicast destination address of the inner 1203 packet is "M", then the IPv6 multicast destination address of the 1204 encapsulating header is also "M".) 1206 3.14. Operation on AERO Links Without DHCPv6 Services 1208 When the AERO link does not provide DHCPv6 services, operation can 1209 still be accommodated through administrative configuration of 1210 prefixes on AERO Clients. In that case, administrative 1211 configurations of IPv6 routes and AERO interface neighbor cache 1212 entries on both the Server and Client are also necessary. However, 1213 this may preclude the ability for Clients to dynamically change to 1214 new Servers, and can expose the AERO link to misconfigurations unless 1215 the administrative configurations are carefully coordinated. 1217 3.15. Operation on Server-less AERO Links 1219 In some AERO link scenarios, there may be no Servers on the link and/ 1220 or no need for Clients to use a Server as an intermediary trust 1221 anchor. In that case, each Client can then act as its own Server to 1222 establish neighbor cache entries and IPv6 forwarding table entries by 1223 performing direct Client-to-Client Predirect/Redirect exchanges, and 1224 some other form of trust basis must be applied so that each Client 1225 can verify that the prospective neighbor is authorized to use its 1226 claimed prefix. 1228 When there is no Server on the link, Clients must arrange to receive 1229 prefix delegations and publish the delegations via a secure alternate 1230 prefix delegation authority through some means outside the scope of 1231 this document. 1233 3.16. Other Considerations 1235 IPv6 hosts serviced by an AERO Client can reach IPv4-only services 1236 via a NAT64 gateway [RFC6146] within the IPv6 network. 1238 AERO nodes can use the Default Address Selection Policy with DHCPv6 1239 option [RFC7078] the same as on any IPv6 link. 1241 All other (non-multicast) functions that operate over ordinary IPv6 1242 links operate in the same fashion over AERO links. 1244 4. Implementation Status 1246 An application-layer implementation is in progress. 1248 5. IANA Considerations 1250 The IANA is instructed to assign a new 2-octet Hardware Type number 1251 for AERO in the "arp-parameters" registry per Section 2 of [RFC5494]. 1252 The number is assigned from the 2-octet Unassigned range with 1253 Hardware Type "AERO" and with this document as the reference. 1255 6. Security Considerations 1257 AERO link security considerations are the same as for standard IPv6 1258 Neighbor Discovery [RFC4861] except that AERO improves on some 1259 aspects. In particular, AERO is dependent on a trust basis between 1260 Clients and Servers, where the Clients only engage in the AERO 1261 mechanism when it is facilitated by a trust anchor. 1263 AERO links must be protected against link-layer address spoofing 1264 attacks in which an attacker on the link pretends to be a trusted 1265 neighbor. Links that provide link-layer securing mechanisms (e.g., 1266 WiFi networks) and links that provide physical security (e.g., 1267 enterprise network wired LANs) provide a first line of defense that 1268 is often sufficient. In other instances, securing mechanisms such as 1269 Secure Neighbor Discovery (SeND) [RFC3971], IPsec [RFC4301] or TLS 1270 [RFC5246] may be necessary. 1272 AERO Clients MUST ensure that their connectivity is not used by 1273 unauthorized nodes on EUNs to gain access to a protected network, 1274 i.e., AERO Clients that act as IPv6 routers MUST NOT provide routing 1275 services for unauthorized nodes. (This concern is no different than 1276 for ordinary hosts that receive an IP address delegation but then 1277 "share" the address with unauthorized nodes via an IPv6/IPv6 NAT 1278 function.) 1280 On some AERO links, establishment and maintenance of a direct path 1281 between neighbors requires secured coordination such as through the 1282 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 1283 security association. 1285 7. Acknowledgements 1287 Discussions both on IETF lists and in private exchanges helped shape 1288 some of the concepts in this work. Individuals who contributed 1289 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1290 Brian Carpenter, Wojciech Dec, Brian Haberman, Joel Halpern, Sascha 1291 Hlusiak, Lee Howard, Joe Touch and Bernie Volz. Members of the IESG 1292 also provided valuable input during their review process that greatly 1293 improved the document. Special thanks go to Stewart Bryant, Joel 1294 Halpern and Brian Haberman for their shepherding guidance. 1296 This work has further been encouraged and supported by Boeing 1297 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 1298 Balaguruna Chidambaram, Wen Fang, Anthony Gregory, Jeff Holland, Ed 1299 King, Gen MacLean, Kent Shuey, Mike Slane, Julie Wulff, Yueli Yang, 1300 and other members of the BR&T and BIT mobile networking teams. 1302 Earlier works on NBMA tunneling approaches are found in 1303 [RFC2529][RFC5214][RFC5569]. 1305 8. References 1307 8.1. Normative References 1309 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1310 August 1980. 1312 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1313 1981. 1315 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1316 RFC 792, September 1981. 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, March 1997. 1321 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1322 (IPv6) Specification", RFC 2460, December 1998. 1324 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1325 IPv6 Specification", RFC 2473, December 1998. 1327 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1328 and M. Carney, "Dynamic Host Configuration Protocol for 1329 IPv6 (DHCPv6)", RFC 3315, July 2003. 1331 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1332 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1333 December 2003. 1335 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1336 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1338 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1339 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1340 September 2007. 1342 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1343 Address Autoconfiguration", RFC 4862, September 2007. 1345 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1346 Requirements", RFC 6434, December 2011. 1348 8.2. Informative References 1350 [IRON] Templin, F., "The Internet Routing Overlay Network 1351 (IRON)", Work in Progress, June 2012. 1353 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1354 RFC 879, November 1983. 1356 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1357 Domains without Explicit Tunnels", RFC 2529, March 1999. 1359 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1360 RFC 2675, August 1999. 1362 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1363 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1365 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1366 Architecture", RFC 4291, February 2006. 1368 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1369 Internet Protocol", RFC 4301, December 2005. 1371 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1372 Discovery", RFC 4821, March 2007. 1374 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1375 Errors at High Data Rates", RFC 4963, July 2007. 1377 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 1378 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 1379 September 2007. 1381 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1382 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1383 March 2008. 1385 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1386 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1388 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 1389 for the Address Resolution Protocol (ARP)", RFC 5494, 1390 April 2009. 1392 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1393 Route Optimization Requirements for Operational Use in 1394 Aeronautics and Space Exploration Mobile Networks", RFC 1395 5522, October 2009. 1397 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1398 Infrastructures (6rd)", RFC 5569, January 2010. 1400 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1401 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1402 5996, September 2010. 1404 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1405 NAT64: Network Address and Protocol Translation from IPv6 1406 Clients to IPv4 Servers", RFC 6146, April 2011. 1408 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1409 Troan, "Basic Requirements for IPv6 Customer Edge 1410 Routers", RFC 6204, April 2011. 1412 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 1413 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 1414 2011. 1416 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1417 for Equal Cost Multipath Routing and Link Aggregation in 1418 Tunnels", RFC 6438, November 2011. 1420 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1421 RFC 6691, July 2012. 1423 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1424 (AERO)", RFC 6706, August 2012. 1426 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1427 RFC 6864, February 2013. 1429 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1430 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1432 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1433 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1434 RFC 6936, April 2013. 1436 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 1437 Address Option in DHCPv6", RFC 6939, May 2013. 1439 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1440 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1442 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 1443 Address Selection Policy Using DHCPv6", RFC 7078, January 1444 2014. 1446 Appendix A. AERO Server and Relay Interworking 1448 Figure 2 depicts a reference AERO operational scenario with a single 1449 Server on the AERO link. In order to support scaling to larger 1450 numbers of nodes, the AERO link can deploy multiple Servers and 1451 Relays, e.g., as shown in Figure 4. 1453 .-(::::::::) 1454 .-(::: IPv6 :::)-. 1455 (:: Internetwork ::) 1456 `-(::::::::::::)-' 1457 `-(::::::)-' 1458 | 1459 +--------------+ +------+-------+ +--------------+ 1460 |AERO Server C | | AERO Relay D | |AERO Server E | 1461 | (default->D) | | (A->C; G->E) | | (default->D) | 1462 | (A->B) | +-------+------+ | (G->F) | 1463 +-------+------+ | +------+-------+ 1464 | | | 1465 X---+---+-------------------+------------------+---+---X 1466 | AERO Link | 1467 +-----+--------+ +--------+-----+ 1468 |AERO Client B | |AERO Client F | 1469 | (default->C) | | (default->E) | 1470 +--------------+ +--------------+ 1471 .-. .-. 1472 ,-( _)-. ,-( _)-. 1473 .-(_ IPv6 )-. .-(_ IPv6 )-. 1474 (__ EUN ) (__ EUN ) 1475 `-(______)-' `-(______)-' 1476 | | 1477 +--------+ +--------+ 1478 | Host A | | Host G | 1479 +--------+ +--------+ 1481 Figure 4: AERO Server/Relay Interworking 1483 In this example, Client ('B') associates with Server ('C'), while 1484 Client ('F') associates with Server ('E'). Furthermore, Servers 1485 ('C') and ('E') do not associate with each other directly, but rather 1486 have an association with Relay ('D') (i.e., a router that has full 1487 topology information concerning its associated Servers and their 1488 Clients). Relay ('D') connects to the AERO link, and also connects 1489 to the native IPv6 Internetwork. 1491 When host ('A') sends a packet toward destination host ('G'), IPv6 1492 forwarding directs the packet through the EUN to Client ('B'), which 1493 forwards the packet to Server ('C') in absence of more-specific 1494 forwarding information. Server ('C') forwards the packet, and it 1495 also generates an AERO Predirect message that is then forwarded 1496 through Relay ('D') to Server ('E'). When Server ('E') receives the 1497 message, it forwards the message to Client ('F'). 1499 After processing the AERO Predirect message, Client ('F') sends an 1500 AERO Redirect message to Server ('E'). Server ('E'), in turn, 1501 forwards the message through Relay ('D') to Server ('C'). When 1502 Server ('C') receives the message, it forwards the message to Client 1503 ('B') informing it that host 'G's EUN can be reached via Client 1504 ('F'), thus completing the AERO redirection. 1506 The network layer routing information shared between Servers and 1507 Relays must be carefully coordinated in a manner outside the scope of 1508 this document. In particular, Relays require full topology 1509 information, while individual Servers only require partial topology 1510 information (i.e., they only need to know the EUN prefixes associated 1511 with their current set of Clients). See [IRON] for an architectural 1512 discussion of routing coordination between Relays and Servers. 1514 Author's Address 1516 Fred L. Templin (editor) 1517 Boeing Research & Technology 1518 P.O. Box 3707 1519 Seattle, WA 98124 1520 USA 1522 Email: fltemplin@acm.org