idnits 2.17.1 draft-templin-aerolink-29.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 (June 30, 2014) is 3581 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 1454, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1469, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1493, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 1501, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 1556, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 1560, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1572, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 1575, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 1591, but no explicit reference was found in the text == Unused Reference: 'RFC7078' is defined on line 1594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc6706 (if approved) June 30, 2014 5 Intended status: Standards Track 6 Expires: January 1, 2015 8 Transmission of IP Packets over AERO Links 9 draft-templin-aerolink-29.txt 11 Abstract 13 This document specifies the operation of IP over tunnel virtual Non- 14 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 that provide forwarding 17 services to reach off-link destinations and redirection services for 18 route optimization. AERO provides an IPv6 link-local address format 19 known as the AERO address that supports operation of the IPv6 20 Neighbor Discovery (ND) protocol and links IPv6 ND to IP forwarding. 21 Admission control and provisioning are supported by the Dynamic Host 22 Configuration Protocol for IPv6 (DHCPv6), and node mobility is 23 naturally supported through dynamic neighbor cache updates. Although 24 IPv6 ND messaging is used in the control plane, both IPv4 and IPv6 25 are supported in the 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 January 1, 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 Node Types . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. AERO Addresses . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. AERO Interface Characteristics . . . . . . . . . . . . . 7 67 3.3.1. Coordination of Multiple Underlying Interfaces . . . 9 68 3.4. AERO Interface Neighbor Cache Maintenace . . . . . . . . 10 69 3.5. AERO Interface Data Origin Authentication . . . . . . . . 11 70 3.6. AERO Interface MTU Considerations . . . . . . . . . . . . 11 71 3.7. AERO Interface Encapsulation, Re-encapsulation and 72 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 13 73 3.8. AERO Router Discovery, Prefix Delegation and Address 74 Configuration . . . . . . . . . . . . . . . . . . . . . . 14 75 3.8.1. AERO Server Behavior . . . . . . . . . . . . . . . . 14 76 3.8.2. AERO Client Behavior . . . . . . . . . . . . . . . . 16 77 3.9. AERO Redirection . . . . . . . . . . . . . . . . . . . . 17 78 3.9.1. Reference Operational Scenario . . . . . . . . . . . 17 79 3.9.2. Concept of Operations . . . . . . . . . . . . . . . . 19 80 3.9.3. Message Format . . . . . . . . . . . . . . . . . . . 20 81 3.9.4. Sending Predirects . . . . . . . . . . . . . . . . . 20 82 3.9.5. Re-encapsulating and Relaying Predirects . . . . . . 22 83 3.9.6. Processing Predirects and Sending Redirects . . . . . 22 84 3.9.7. Re-encapsulating and Relaying Redirects . . . . . . . 24 85 3.9.8. Processing Redirects . . . . . . . . . . . . . . . . 24 86 3.9.9. AERO Relay Operation . . . . . . . . . . . . . . . . 25 87 3.9.10. Server-Oriented Redirection . . . . . . . . . . . . . 25 88 3.10. Neighbor Unreachability Detection (NUD) . . . . . . . . . 26 89 3.11. Mobility Management . . . . . . . . . . . . . . . . . . . 27 90 3.11.1. Announcing Link-Layer Address Changes . . . . . . . 27 91 3.11.2. Moving to a New Server . . . . . . . . . . . . . . . 28 92 3.12. Encapsulation Protocol Version Considerations . . . . . . 29 93 3.13. Multicast Considerations . . . . . . . . . . . . . . . . 29 94 3.14. Operation on AERO Links Without DHCPv6 Services . . . . . 29 95 3.15. Operation on Server-less AERO Links . . . . . . . . . . . 30 96 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 31 102 8.2. Informative References . . . . . . . . . . . . . . . . . 32 103 Appendix A. AERO Server and Relay Interworking . . . . . . . . . 34 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 106 1. Introduction 108 This document specifies the operation of IP over tunnel virtual Non- 109 Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 110 Route Optimization (AERO). The AERO link can be used for tunneling 111 to neighboring nodes on either IPv6 or IPv4 networks, i.e., AERO 112 views the IPv6 and IPv4 networks as equivalent links for tunneling. 113 Nodes attached to AERO links can exchange packets via trusted 114 intermediate routers that provide forwarding services to reach off- 115 link destinations and redirection services for route optimization 116 that addresses the requirements outlined in [RFC5522]. 118 AERO provides an IPv6 link-local address format known as the AERO 119 address that supports operation of the IPv6 Neighbor Discovery (ND) 120 [RFC4861] protocol and links IPv6 ND to IP forwarding. Admission 121 control and provisioning are supported by the Dynamic Host 122 Configuration Protocol for IPv6 (DHCPv6) [RFC3315], and node mobility 123 is naturally supported through dynamic neighbor cache updates. 124 Although IPv6 ND message signalling is used in the control plane, 125 both IPv4 and IPv6 are supported in the data plane. The remainder of 126 this document presents the AERO specification. 128 2. Terminology 130 The terminology in the normative references applies; the following 131 terms are defined within the scope of this document: 133 AERO link 134 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 135 configured over a node's attached IPv6 and/or IPv4 networks. All 136 nodes on the AERO link appear as single-hop neighbors from the 137 perspective of the virtual overlay IP layer. 139 AERO interface 140 a node's attachment to an AERO link. 142 AERO address 143 an IPv6 link-local address constructed as specified in Section 3.2 144 and assigned to a Client's AERO interface. 146 AERO node 147 a node that is connected to an AERO link and that participates in 148 IPv6 ND over the link. 150 AERO Client ("Client") 151 a node that assigns an AERO address on an AERO interface and 152 receives a Client Prefix delegation. 154 AERO Server ("Server") 155 a node that assigns the IPv6 link-local subnet router anycast 156 address (fe80::) and an administratively provisioned IPv6 link- 157 local unicast address on an AERO interface over which it can 158 provide default forwarding services for AERO Clients. 160 AERO Relay ("Relay") 161 a node that relays IP packets between Servers on the same AERO 162 link, and/or that forwards IP packets between the AERO link and 163 the native Internetwork. An AERO Relay may or may not also be 164 configured as an AERO Server. 166 ingress tunnel endpoint (ITE) 167 an AERO interface endpoint that injects tunneled packets into an 168 AERO link. 170 egress tunnel endpoint (ETE) 171 an AERO interface endpoint that receives tunneled packets from an 172 AERO link. 174 underlying network 175 a connected IPv6 or IPv4 network routing region over whichthe 176 tunnel virtual overrlay is configured. 178 underlying interface 179 an AERO node's interface point of attachment to an underlying 180 network. 182 link-layer address 183 an IP address assigned to an AERO node's underlying interface. 184 When UDP encapsulation is used, the UDP port number is also 185 considered as part of the link-layer address. Link-layer 186 addresses are used as the encapsulation header source and 187 destination addresses. 189 network layer address 190 the source or destination address of the encapsulated IP packet. 192 end user network (EUN) 193 an internal virtual or external edge IP network that an AERO 194 Client connects to the AERO interface. 196 AERO Service Prefix (ASP) 197 an IP prefix associated with the AERO link and from which Client 198 Prefixes (CPs) are derived (for example, the IPv6 CP 199 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). 201 Client Prefix (CP) 202 an IP prefix taken from an ASP and delegated to a Client. 204 Throughout the document, the simple terms "Client", "Server" and 205 "Relay" refer to "AERO Client", "AERO Server" and "AERO Relay", 206 respectively. Capitalization is used to distinguish these terms from 207 DHCPv6 client/server/relay. This is an important distinction, since 208 an AERO Server may be a DHCPv6 relay, and an AERO Relay may be a 209 DHCPv6 server. 211 The terminology of [RFC4861] (including the names of node variables 212 and protocol constants) applies to this document. Also throughout 213 the document, the term "IP" is used to generically refer to either 214 Internet Protocol version (i.e., IPv4 or IPv6). 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 3. Asymmetric Extended Route Optimization (AERO) 222 The following sections specify the operation of IP over Asymmetric 223 Extended Route Optimization (AERO) links: 225 3.1. AERO Node Types 227 AERO Relays relay packets between nodes connected to the same AERO 228 link and also forward packets between the AERO link and the native 229 Internetwork. The relaying process entails re-encapsulation of IP 230 packets that were received from a first AERO node and are to be 231 forwarded without modification to a second AERO node. AERO Relays 232 present the AERO link to the native Internetwork as a set of one or 233 more AERO Service Prefixes (ASPs). 235 AERO Servers provide default routing services to AERO Clients. AERO 236 Servers configure a DHCPv6 relay or server function and facilitate 237 DHCPv6 Prefix Delegation (PD) exchanges for AERO Clients. Each 238 delegated prefix becomes a Client Prefix (CP) taken from an ASP. An 239 AERO Server may also act as an AERO Relay. 241 AERO Clients act as requesting routers to receive CPs through a 242 DHCPv6 PD exchange via AERO Servers over the AERO link. (Each Client 243 MAY associate with multiple Servers, but associating with many 244 Servers may result in excessive control message overhead.) Each IPv6 245 AERO Client receives at least a /64 IPv6 CP, and may receive even 246 shorter prefixes. Similarly, each IPv4 AERO Client receives at least 247 a /32 IPv4 CP (i.e., a singleton IPv4 address), and may receive even 248 shorter prefixes. 250 AERO Clients that act as routers sub-delegate portions of their CPs 251 to links on EUNs. End system applications on AERO Clients that act 252 as routers bind to EUN interfaces (i.e., and not the AERO interface). 254 AERO Clients that act as ordinary hosts assign one or more IP 255 addresses from their CPs to the AERO interface but DO NOT assign the 256 CP itself to the AERO interface. Instead, the Client assigns the CP 257 to a "black hole" route so that unused portions of the prefix are 258 nullified. End system applications on AERO Clients that act as hosts 259 bind directly to the AERO interface. 261 3.2. AERO Addresses 263 An AERO address is an IPv6 link-local address with an embedded CP and 264 assigned to a Client's AERO interface. The AERO address is formed as 265 follows: 267 fe80::[Client Prefix (CP)] 269 For IPv6, the AERO address begins with the prefix fe80::/64 and 270 includes in its interface identifier the base prefix taken from the 271 Client's IPv6 CP. The base prefix is determined by masking the CP 272 with the prefix length. For example, if the AERO Client receives the 273 IPv6 CP: 275 2001:db8:1000:2000::/56 277 it constructs its AERO address as: 279 fe80::2001:db8:1000:2000 281 For IPv4, the AERO address begins with the prefix fe80::/96 and 282 includes in its interface identifier the base prefix taken from the 283 Client's IPv4 CP. For example, if the AERO Client receives the IPv4 284 CP: 286 192.0.2.32/28 288 it constructs its AERO address as: 290 fe80::192.0.2.32 292 The AERO address remains stable as the Client moves between 293 topological locations, i.e., even if its link-layer addresses change. 295 NOTE: In some cases, prospective neighbors may not have a priori 296 knowledge of the Client's CP length and may therefore send initial 297 IPv6 ND messages with an AERO destination address that matches the CP 298 but does not correspond to the base prefix. In that case, the Client 299 MUST accept the address as equivalent to the base address, but then 300 use the base address as the source address of any IPv6 ND message 301 replies. For example, if the Client receives the IPv6 CP 302 2001:db8:1000:2000::/56 then subsequently receives an IPv6 ND message 303 with destination address fe80::2001:db8:1000:2001, it accepts the 304 message but uses fe80::2001:db8:1000:2000 as the source address of 305 any IPv6 ND replies. 307 3.3. AERO Interface Characteristics 309 AERO interfaces use IP-in-IPv6 encapsulation [RFC2473] to exchange 310 tunneled packets with AERO neighbors attached to an underlying IPv6 311 network, and use IP-in-IPv4 encapsulation [RFC2003][RFC4213] to 312 exchange tunneled packets with AERO neighbors attached to an 313 underlying IPv4 network. AERO interfaces can also operate over 314 secured tunnel types such as IPsec [RFC4301] or TLS [RFC5246]. When 315 Network Address Translator (NAT) traversal and/or filtering middlebox 316 traversal may be necessary, a UDP header is further inserted 317 immediately above the IP encapsulation header. 319 Servers and Relays maintain a set of ASPs from which CPs are 320 delegated to Clients. Relays present the ASPs to the native 321 Internetwork as a set of aggregated prefixes in the routing system. 322 The ASPs are never deaggregated within the native Internetwork 323 routing system; hence, no Client mobility events within the AERO link 324 are exposed outside of the AERO link. 326 Servers assign the address fe80:: to their AERO interfaces as a link- 327 local Subnet Router Anycast address. Servers and Relays also assign 328 a link-local address fe80::ID to support the operation of the IPv6 ND 329 protocol and the inter-Server/Relay routing system (see: Appendix A). 330 Each fe80::ID address MUST be unique among all Servers and Relays on 331 the AERO link, and MUST NOT collide with any potential AERO addresses 332 (e.g., the addresses for Servers and Relays on the link could be 333 assigned as fe80::1, fe80::2, fe80::3, etc.). Servers accept IPV6 ND 334 messages with either fe80::ID or fe80:: as the IPv6 destination 335 address, but MUST use the fe80::ID address as the IPv6 source address 336 of any IPv6 ND messages they generate. 338 When a Client does not know the fe80::ID address of a Server, it can 339 use fe80:: as a temporary destination address in IPv6 ND messages. 340 When a Client enables an AERO interface, it invokes DHCPv6 PD using 341 the temporary IPv6 link-local source address 342 fe80::ffff:ffff:ffff:ffff to receive one or more CP delegations. 343 After the Client receives a CP, it assigns the corresponding AERO 344 address to the AERO interface and deprecates the temporary address, 345 i.e., the Client invokes DHCPv6 to bootstrap the provisioning of a 346 unique link-local address before invoking IPv6 ND. 348 AERO interfaces maintain a neighbor cache and use an adaptation of 349 standard unicast IPv6 ND messaging. AERO interfaces use unicast 350 Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router 351 Solicitation (RS) and Router Advertisement (RA) messages the same as 352 for any IPv6 link. AERO interfaces use two redirection message types 353 -- the first known as a Predirect message and the second being the 354 standard Redirect message (see Section 3.9). AERO links further use 355 link-local-only addressing; hence, Clients ignore any Prefix 356 Information Options (PIOs) they may receive in RA messages with the 357 'A' and/or 'L' bits set. 359 AERO interface Redirect, Predirect and unsolicited NA messages 360 include Target Link-Layer Address Options (TLLAOs) formatted as shown 361 in Figure 1: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type = 2 | Length = 3 | Reserved | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Link ID | Preference | UDP Port Number (or 0) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 +-- --+ 372 | | 373 +-- IP Address --+ 374 | | 375 +-- --+ 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 1: AERO Target Link-Layer Address Option (TLLAO) Format 381 In this format, Link ID is an integer value between 0 and 255 382 corresponding to an underlying interface of the target node, and 383 Preference is an integer value between 0 and 255 indicating the 384 node's preference for this underlying interface, with 0 being highest 385 preference and 255 being lowest. UDP Port Number and IP Address are 386 set to the addresses used by the target node when it sends 387 encapsulated packets over the underlying interface. When no UDP 388 encapsulation is used, UDP Port Number is set to 0. When the 389 encapsulation IP address family is IPv4, IP Address is formed as an 390 IPv4-compatible IPv6 address [RFC4291], i.e., 96 bits of leading 0's 391 followed by a 32-bit IPv4 address 393 AERO interface Redirect/Predirect messages can both update and create 394 neighbor cache entries, including link-layer address information. 395 AERO interface unsolicited NA messages update a neighbor's cached 396 link-layer address for the sender, e.g., following a link-layer 397 address change due to node mobility. AERO interface RS/RA messages 398 as well as NS/NA messages used for Neighbor Unreachability Detection 399 (NUD) update timers in existing neighbor cache entires but do not 400 update link-layer addresses nor create new neighbor cache entries. 402 AERO interface Redirect, Predirect and unsolicited NA messages SHOULD 403 include a Timestamp option (see Section 5.3 of [RFC3971]) that other 404 AERO nodes can use to verify the message time of origin. AERO 405 interface NS/RS messages SHOULD include a Nonce option (see 406 Section 5.3 of [RFC3971]) that recipients echo back in corresponding 407 NA/RA responses. 409 3.3.1. Coordination of Multiple Underlying Interfaces 411 AERO interfaces may be configured over multiple underlying 412 interfaces. For example, common mobile handheld devices have both 413 wireless local area network ("WLAN") and cellular wireless links. 414 These links are typically used "one at a time" with low-cost WLAN 415 preferred and highly-available cellular wireless as a standby. In a 416 more complex example, aircraft frequently have many wireless data 417 link types (e.g. satellite-based, terrestrial, air-to-air 418 directional, etc.) with diverse performance and cost properties. 420 If a Client's multiple underlying interfaces are used "one at a time" 421 (i.e., all other interfaces are in standby mode while one interface 422 is active), then Redirect, Predirect and unsolicited NA messages 423 include only a single TLLAO with Link ID set to 0. 425 If the Client has multiple active underlying interfaces, then from 426 the perspective of IPv6 ND it would appear to have a single link- 427 local address with multiple link-layer addresses. In that case, 428 Redirect, Predirect and unsolicited NA messages MAY include multiple 429 TLLAOs -- each with a different Link ID that corresponds to an 430 underlying interface of the Client. Further details on coordination 431 of multiple active underlying interfaces are outside the scope of 432 this specification. 434 3.4. AERO Interface Neighbor Cache Maintenace 436 Each AERO interface maintains a conceptual neighbor cache that 437 includes an entry for each neighbor it communicates with on the AERO 438 link, the same as for any IPv6 interface [RFC4861]. Neighbor cache 439 entries are created and maintained as follows: 441 When an AERO Server relays a DHCPv6 Reply message to an AERO Client, 442 it creates or updates a neighbor cache entry for the Client based on 443 the AERO address corresponding to the Client's CP as the network- 444 layer address and with the Client's encapsulation IP address and UDP 445 port number as the link-layer address. 447 When an AERO Client receives a DHCPv6 Reply message from an AERO 448 Server, it creates or updates a neighbor cache entry for the Server 449 based on the Reply message link-local source address as the network- 450 layer address, and the encapsulation IP source address and UDP source 451 port number as the link-layer address. 453 When an AERO Client receives a valid Predirect message it creates or 454 updates a neighbor cache entry for the Predirect target network-layer 455 and link-layer addresses, and also creates an IP forwarding table 456 entry for the predirected (source) CP. The node then sets an 457 "AcceptTime" variable for the neighbor and uses this value to 458 determine whether packets received from the predirected neighbor can 459 be accepted. 461 When an AERO Client receives a valid Redirect message it creates or 462 updates a neighbor cache entry for the Redirect target network-layer 463 and link-layer addresses, and also creates an IP forwarding table 464 entry for the redirected (destination) CP. The node then sets a 465 "ForwardTime" variable for the neighbor and uses this value to 466 determine whether packets can be sent directly to the redirected 467 neighbor. The node also maintains a constant value MAX_RETRY to 468 limit the number of keepalives sent when a neighbor may have gone 469 unreachable. 471 When an AERO Client receives a valid NS message it (re)sets 472 AcceptTime for the neighbor to ACCEPT_TIME. 474 When an AERO Client receives a valid solicited NA message, it 475 (re)sets ForwardTime for the neighbor to FORWARD_TIME. (When an AERO 476 Client receives a valid unsolicited NA message, it updates the 477 neighbor's link-layer address but DOES NOT reset ForwardTime.) 479 It is RECOMMENDED that FORWARD_TIME be set to the default constant 480 value 30 seconds to match the default REACHABLE_TIME value specified 481 for IPv6 ND [RFC4861]. 483 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 484 value 40 seconds to allow a 10 second window so that the AERO 485 redirection procedure can converge before AcceptTime decrements below 486 FORWARD_TIME. 488 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 489 for IPv6 ND address resolution in Section 7.3.3 of [RFC4861]. 491 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 492 administratively set, if necessary, to better match the AERO link's 493 performance characteristics; however, if different values are chosen, 494 all nodes on the link MUST consistently configure the same values. 495 Most importantly, ACCEPT_TIME SHOULD be set to a value that is 496 sufficiently longer than FORWARD_TIME to allow the AERO redirection 497 procedure to converge. 499 3.5. AERO Interface Data Origin Authentication 501 AERO nodes use a simple data origin authentication for encapsulated 502 packets they receive from other nodes. In particular, AERO nodes 503 accept encapsulated packets with a link-layer source address 504 belonging to one of their current AERO Servers and accept 505 encapsulated packets with a link-layer source address that is correct 506 for the network-layer source address. 508 The AERO node considers the link-layer source address correct for the 509 network-layer source address if there is an IP forwarding table entry 510 that matches the network-layer source address as well as a neighbor 511 cache entry corresponding to the next hop that includes the link- 512 layer address and AcceptTime is non-zero. 514 Note that this simple data origin authentication only applies to 515 environments in which link-layer addresses cannot be spoofed. 516 Additional security mitigations may be necessary in other 517 environments. 519 3.6. AERO Interface MTU Considerations 521 The AERO link Maximum Transmission Unit (MTU) is 64KB minus the 522 encapsulation overhead for IPv4 as the link-layer [RFC0791] and 4GB 523 minus the encapsulation overhead for IPv6 as the link layer 524 [RFC2675]. This is the most that IPv4 and IPv6 (respectively) can 525 convey within the constraints of protocol constants, but actual sizes 526 available for tunneling will frequently be much smaller. 528 The base tunneling specifications for IPv4 and IPv6 typically set a 529 static MTU on the tunnel interface to 1500 bytes minus the 530 encapsulation overhead or smaller still if the tunnel is likely to 531 incur additional encapsulations on the path. This can result in path 532 MTU related black holes when packets that are too large to be 533 accommodated over the AERO link are dropped, but the resulting ICMP 534 Packet Too Big (PTB) messages are lost on the return path. As a 535 result, AERO nodes use the following MTU mitigations to accommodate 536 larger packets. 538 AERO nodes set their AERO interface MTU to the larger of the 539 underlying interface MTU minus the encapsulation overhead, and 1500 540 bytes. (If there are multiple underlying interfaces, the node sets 541 the AERO interface MTU according to the largest underlying interface 542 MTU, or 64KB /4G minus the encapsulation overhead if the largest MTU 543 cannot be determined.) AERO nodes optionally cache other per- 544 neighbor MTU values in the underlying IP path MTU discovery cache 545 initialized to the underlying interface MTU. 547 AERO nodes admit packets that are no larger than 1280 bytes minus the 548 encapsulation overhead (*) as well as packets that are larger than 549 1500 bytes into the tunnel without fragmentation, i.e., as long as 550 they are no larger than the AERO interface MTU before encapsulation 551 and also no larger than the cached per-neighbor MTU following 552 encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit 553 to 0 for packets no larger than 1280 bytes minus the encapsulation 554 overhead (*) and sets the DF bit to 1 for packets larger than 1500 555 bytes. If a large packet is lost in the path, the node may 556 optionally cache the MTU reported in the resulting PTB message or may 557 ignore the message, e.g., if there is a possibility that the message 558 is spurious. 560 For packets destined to an AERO node that are larger than 1280 bytes 561 minus the encapsulation overhead (*) but no larger than 1500 bytes, 562 the node uses IP fragmentation to fragment the encapsulated packet 563 into two pieces (where the first fragment contains 1024 bytes of the 564 original IP packet) then admits the fragments into the tunnel. If 565 the link-layer protocol is IPv4, the node admits each fragment into 566 the tunnel with DF set to 0 and subject to rate limiting to avoid 567 reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the 568 node also sends a 1500 byte probe message (**) to the neighbor, 569 subject to rate limiting. 571 To construct a probe, the node prepares an NS message with a Nonce 572 option plus trailing padding octets added to a length of 1500 bytes 573 without including the length of the padding in the IPv6 Payload 574 Length field. The node then encapsulates the NS in the encapsulation 575 headers (while including the length of the padding in the 576 encapsulation header length fields), sets DF to 1 (for IPv4) and 577 sends the padded NS message to the neighbor. If the neighbor returns 578 an NA message with a correct Nonce value, the node may then send 579 whole packets within this size range and (for IPv4) relax the rate 580 limiting requirement. (Note that the trailing padding SHOULD NOT be 581 included within the Nonce option itself but rather as padding beyond 582 the last option in the NS message; otherwise, the (large) Nonce 583 option would be echoed back in the solicited NA message and may be 584 lost at a link with a small MTU along the reverse path.) 586 AERO nodes MUST be capable of reassembling packets up to 1500 bytes 587 plus the encapsulation overhead length. It is therefore RECOMMENDED 588 that AERO nodes be capable of reassembling at least 2KB. 590 (*) Note that if it is known without probing that the minimum Path 591 MTU to an AERO node is MINMTU bytes (where 1280 < MINMTU < 1500) then 592 MINMTU can be used instead of 1280 in the fragmentation threshold 593 considerations listed above. 595 (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used 596 for MTU probing purposes, since smaller probes may be fragmented if 597 there is a nested tunnel somewhere on the path to the neighbor. 598 Probe sizes larger than 1500 bytes MAY be used, but may be 599 unnecessary since original sources are expected to implement 600 [RFC4821] when sending large packets. 602 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 604 AERO interfaces encapsulate IP packets according to whether they are 605 entering the AERO interface for the first time or if they are being 606 forwarded out the same AERO interface that they arrived on. This 607 latter form of encapsulation is known as "re-encapsulation". 609 AERO interfaces encapsulate packets per the specifications in 610 [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246] except that the 611 interface copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 612 and "Congestion Experienced" values in the packet's IP header into 613 the corresponding fields in the encapsulation header. For packets 614 undergoing re-encapsulation, the AERO interface instead copies the 615 "TTL/Hop Limit", "Type of Service/Traffic Class" and "Congestion 616 Experienced" values in the original encapsulation header into the 617 corresponding fields in the new encapsulation header (i.e., the 618 values are transferred between encapsulation headers and *not* copied 619 from the encapsulated packet's network-layer header). 621 When AERO UDP encapsulation is used, the AERO interface encapsulates 622 the packet per the specifications in [RFC2003][RFC2473][RFC4213] 623 except that it inserts a UDP header between the encapsulation header 624 and the packet's IP header. The AERO interface sets the UDP source 625 port to a constant value that it will use in each successive packet 626 it sends, sets the UDP checksum field to zero (see: 628 [RFC6935][RFC6936]) and sets the UDP length field to the length of 629 the IP packet plus 8 bytes for the UDP header itself. For packets 630 sent via a Server, the AERO interface sets the UDP destination port 631 to 8060 (i.e., the IANA-registered port number for AERO) when AERO- 632 only encapsulation is used. For packets sent to a neighboring 633 Client, the AERO interface sets the UDP destination port to the port 634 value stored in the neighbor cache entry for this neighbor. 636 The AERO interface next sets the IP protocol number in the 637 encapsulation header to the appropriate value for the first protocol 638 layer within the encapsulation (e.g., IPv4, IPv6, UDP, IPsec, etc.). 639 When IPv6 is used as the encapsulation protocol, the interface then 640 sets the flow label value in the encapsulation header the same as 641 described in [RFC6438]. When IPv4 is used as the encapsulation 642 protocol, the AERO interface sets the DF bit as discussed in 643 Section 3.6. 645 AERO interfaces decapsulate packets destined either to the node 646 itself or to a destination reached via an interface other than the 647 receiving AERO interface. When AERO UDP encapsulation is used (i.e., 648 when a UDP header with destination port 8060 is present) the 649 interface examines the first octet of the encapsulated packet. If 650 the most significant four bits of the first octet encode the value 651 '0110' (i.e., the version number value for IPv6) or the value '0100' 652 (i.e., the version number value for IPv4), the packet is accepted and 653 the encapsulating UDP header is discarded; otherwise, the packet is 654 discarded. 656 Further decapsulation then proceeds according to the appropriate 657 tunnel type [RFC2003][RFC2473][RFC4213][RFC4301][RFC5246]. 659 3.8. AERO Router Discovery, Prefix Delegation and Address Configuration 661 3.8.1. AERO Server Behavior 663 AERO Servers configure a DHCPv6 relay function on their AERO links. 664 AERO Servers arrange to add their encapsulation layer IP addresses 665 (i.e., their link-layer addresses) to the DNS resource records for 666 the FQDN "linkupnetworks.domainname" before entering service. 668 When an AERO Server relays a prospective Client's DHCPv6 PD messages 669 to the DHCPv6 server, it wraps each message in a "Relay-forward" 670 message per [RFC3315] and includes a DHCPv6 Interface Identifier 671 option that encodes a value that identifies the AERO link to the 672 DHCPv6 server. Without creating internal state, the Server then 673 includes the Client's link-layer address in a DHCPv6 Client Link 674 Layer Address Option (CLLAO) [RFC6939] with the link-layer address 675 format shown in Figure 1 (i.e., Link ID followed by Preference 676 followed by UDP Port Number followed by IP Address). The Server sets 677 the CLLAO 'option-length' field to 22 (2 plus the length of the link- 678 layer address) and sets the 'link-layer type' field to TBD (see: IANA 679 Considerations). The Server finally includes a DHCPv6 Echo Request 680 Option (ERO) [RFC4994] that encodes the option code for the CLLAO in 681 a 'requested-option-code-n' field, then relays the message to the 682 DHCPv6 server. The CLLAO information will therefore subsequently be 683 echoed back in the DHCPv6 server's "Relay-reply" message. 685 When the DHCPv6 server issues the CP prefix delegation in a "Relay- 686 reply" message via the AERO Server (acting as a DHCPv6 relay), the 687 Server obtains the Client's link-layer address from the echoed CLLAO 688 option and also obtains the Client's delegated CP from the message. 689 The Server then creates a neighbor cache entry for the Client's AERO 690 address with the Client's link-layer address as the link-layer 691 address for the neighbor cache entry. The neighbor cache entry is 692 created with both AcceptTime and ForwardTime set to REACHABLE_TIME, 693 since the Client will continue to send RS messages within 694 REACHABLE_TIME seconds as long as it wishes to remain associated with 695 this Server. 697 The Server also configures an IP forwarding table entry that lists 698 the Client's AERO address as the next hop toward the CP with a 699 lifetime derived from the DHCPv6 lease lifetime. The Server finally 700 injects the CP as an IP route into the inter-Server/Relay routing 701 system (see: Appendix A) then relays the DHCPv6 message to the Client 702 while using fe80::ID as the IPv6 source address, the link-local 703 address found in the "peer address" field of the Relay-reply message 704 as the IPv6 destination address, and the Client's link-layer address 705 as the destination link-layer address. 707 Servers respond to NS/RS messages from Clients on their AERO 708 interfaces by returning an NA/RA message. When the Server returns an 709 RA message, it includes the set of AERO link ASPs in PIOs, and MUST 710 set the 'A' and 'L' bits in each PIO to '0' since the ASPs are 711 associated with the AERO link but not assigned to the AERO link. 712 When the Server receives an NS/RS message from the Client, it resets 713 AcceptTime and ForwardTime to REACHABLE_TIME. 715 Servers ignore any RA messages they may receive from a Client, but 716 they MAY examine RA messages received from other Servers for 717 consistency verification purposes. Servers do not send NS messages 718 for the purpose of updating Client neighbor cache timers, since 719 Clients are responsible for refreshing neighbor cache state. 721 3.8.2. AERO Client Behavior 723 AERO Clients discover the link-layer addresses of AERO Servers via 724 static configuration, or through an automated means such as DNS name 725 resolution. In the absence of other information, the Client resolves 726 the Fully-Qualified Domain Name (FQDN) "linkupnetworks.domainname", 727 where "domainname" is the DNS domain appropriate for the Client's 728 attached underlying network. After discovering the link-layer 729 addresses, the Client associates with one or more of the 730 corresponding Servers. 732 To associate with a Server, the Client acts as a requesting router to 733 request a CP through DHCPv6 PD [RFC3315][RFC3633][RFC6355] using 734 fe80::ffff:ffff:ffff:ffff as the IPv6 source address (see 735 Section 3.3), 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 736 destination address and the link-layer address of the Server as the 737 link-layer destination address. The Client includes a DHCPv6 Unique 738 Identifier (DUID) in the Client Identifier option of its DHCPv6 739 messages (as well as a DHCPv6 authentication option if necessary) to 740 identify itself to the DHCPv6 server. If the Client is pre- 741 provisioned with a CP associated with the AERO service, it MAY also 742 include the CP in its DHCPv6 PD Request to indicate its preferred CP 743 to the DHCPv6 server. The Client then sends the encapsulated DHCPv6 744 request via an underlying interface. 746 When the Client receives its CP via a Reply from the DHCPv6 server, 747 it creates a neighbor cache entry with the Server's link-local 748 address (i.e., fe80::ID) as the network-layer address and the 749 Server's encapsulation address as the link-layer addresses. Next, 750 the Client assigns the AERO address derived from the CP to the AERO 751 interface and sub-delegates the CP to nodes and links within its 752 attached EUNs (the AERO address thereafter remains stable as the 753 Client moves). The Client also sets both AcceptTime and ForwardTime 754 for each Server to the constant value REACHABLE_TIME. The Client 755 further renews its CP delegation by performing DHCPv6 Renew/Reply 756 exchanges with its AERO address as the IPv6 source address, 757 'All_DHCP_Relay_Agents_and_Servers' as the IPv6 destination address, 758 the link-layer address of a Server as the link-layer destination 759 address and the same DUID and authentication information. If the 760 Client wishes to associate with multiple Servers, it can perform 761 DHCPv6 Renew/Reply exchanges via each of the Servers. 763 The Client then sends an RS message to each of its associated Servers 764 to receive an RA message with a default router lifetime, any other 765 link-specific parameters and one or more PIOs with ASPs. When the 766 Client receives an RA message, it configures or updates a default 767 route according to the default router lifetime and caches the list of 768 ASPs as the set of service prefixes for the AERO link. The Client 769 further ignores any RS messages it might receive, since only Servers 770 may process RS messages. 772 The Client then sends periodic RS messages to each Server before 773 AcceptTime and ForwardTime expire to obtain new RA messages. When 774 the Client receives a new RA message, it resets AcceptTime and 775 ForwardTime to REACHABLE_TIME. The Client can also forward IP 776 packets destined to networks beyond its local EUNs via a Server as a 777 default router. The Server may in turn return a redirection message 778 informing the Client of a neighbor on the AERO link that is 779 topologically closer to the final destination (see Section 3.9). 781 Since the Client's AERO address is configured from the unique CP 782 delegation it receives, there is no need for Duplicate Address 783 Detection (DAD) on AERO links. Other nodes maliciously attempting to 784 hijack an authorized Client's AERO address will be denied access to 785 the network by the DHCPv6 server due to an unacceptable link-layer 786 address and/or security parameters (see: Security Considerations). 788 AERO Clients do not include S/TLLAO options in ND messages they send 789 directly to another AERO Client (i.e., without involving a Server). 790 AERO Clients ignore any S/TLLAO options in ND messages they receive 791 directly from another AERO Client. 793 When a source Client forwards a packet to a prospective destination 794 Client (i.e., one for which the packet's destination address is 795 covered by an ASP), the source Client initiates an AERO route 796 optimization procedure as specified in Section 3.9. 798 3.9. AERO Redirection 800 3.9.1. Reference Operational Scenario 802 Figure 2 depicts the AERO redirection reference operational scenario, 803 using IPv6 addressing as the example (while not shown, a 804 corresponding example for IPv4 addressing can be easily constructed). 805 The figure shows an AERO Server('A'), two AERO Clients ('B', 'C') and 806 three ordinary IPv6 hosts ('D', 'E', 'F'): 808 .-(::::::::) 809 .-(:::: IP ::::)-. +-------------+ 810 (:: Internetwork ::)--| Host F | 811 `-(::::::::::::)-' +-------------+ 812 `-(::::::)-' 2001:db8:2::1 813 | 814 +--------------+ 815 | AERO Server A| 816 | (D->B; E->C) | 817 +--------------+ 818 fe80::ID 819 L2(A) 820 | 821 X-----+-----------+-----------+--------X 822 | AERO Link | 823 L2(B) L2(C) 824 fe80::2001:db8:0:0 fe80::2001:db8:1:0 .-. 825 +--------------+ +--------------+ ,-( _)-. 826 | AERO Client B| | AERO Client C| .-(_ IP )-. 827 | (default->A) | | (default->A) |--(__ EUN ) 828 +--------------+ +--------------+ `-(______)-' 829 2001:DB8:0::/48 2001:DB8:1::/48 | 830 | 2001:db8:1::1 831 .-. +-------------+ 832 ,-( _)-. 2001:db8:0::1 | Host E | 833 .-(_ IP )-. +-------------+ +-------------+ 834 (__ EUN )--| Host D | 835 `-(______)-' +-------------+ 837 Figure 2: AERO Reference Operational Scenario 839 In Figure 2, AERO Server ('A') connects to the AERO link and connects 840 to the IP Internetwork, either directly or via an AERO Relay (not 841 shown). Server ('A') assigns the address fe80::ID to its AERO 842 interface with link-layer address L2(A). Server ('A') next arranges 843 to add L2(A) to a published list of valid Servers for the AERO link 844 and also arranges to advertise the AERO link's set of ASPs via its RA 845 responses to a Client's RS messages. 847 AERO Client ('B') receives the CP 2001:db8:0::/48 in a DHCPv6 PD 848 exchange via AERO Server ('A') then assigns the address 849 fe80::2001:db8:0:0 to its AERO interface with link-layer address 850 L2(B). Client ('B') configures a default route and neighbor cache 851 entry via the AERO interface with next-hop address fe80::ID and link- 852 layer address L2(A), then sub-delegates the CP to its attached EUNs. 853 IPv6 host ('D') connects to the EUN, and configures the address 854 2001:db8:0::1. 856 AERO Client ('C') receives the CP 2001:db8:1::/48 in a DHCPv6 PD 857 exchange via AERO Server ('A') then assigns the address 858 fe80::2001:db8:1:0 to its AERO interface with link-layer address 859 L2(C). Client ('C') configures a default route and neighbor cache 860 entry via the AERO interface with next-hop address fe80::ID and link- 861 layer address L2(A), then sub-delegates the CP to its attached EUNs. 862 IPv6 host ('E') connects to the EUN, and configures the address 863 2001:db8:1::1. 865 Finally, IPv6 host ('F') connects to a network outside of the AERO 866 link domain. Host ('F') configures its IPv6 interface in a manner 867 specific to its attached IPv6 link, and assigns the address 868 2001:db8:2::1 to its IPv6 link interface. 870 3.9.2. Concept of Operations 872 Again, with reference to Figure 2, when source host ('D') sends a 873 packet to destination host ('E'), the packet is first forwarded over 874 the source host's attached EUN to Client ('B'). Client ('B') then 875 forwards the packet via its AERO interface to Server ('A') and also 876 sends a Predirect message toward Client ('C') via Server ('A') as 877 specified in Section 3.9.4. Server ('A') then re-encapsulates and 878 forwards both the packet and the Predirect message out the same AERO 879 interface toward Client ('C'). 881 After Client ('C') receives the Predirect message, it process the 882 message and returns a Redirect message toward Client ('B') via Server 883 ('A') as specified in Section 3.9.6. During the process, Client 884 ('C') also creates or updates a neighbor cache entry for Client ('B') 885 and creates an IP forwarding table entry for Client ('B')'s CP. 887 When Server ('A') receives the Redirect message, it re-encapsulates 888 the message and forwards it on to Client ('B') as specified in 889 Section 3.9.7. After Client ('B') receives the Redirect message, it 890 processes the message as specified in Section 3.9.8. During the 891 process, Client ('B') also creates or updates a neighbor cache entry 892 for Client ('C') and creates an IP forwarding table entry for Client 893 ('C')'s CP. 895 Following the above Predirect/Redirect message exchange, forwarding 896 of packets from Client ('B') to Client ('C') without involving Server 897 ('A) as an intermediary is enabled. The mechanisms that support this 898 exchange are specified in the following sections. 900 3.9.3. Message Format 902 AERO Redirect/Predirect messages use the same format as for ICMPv6 903 Redirect messages depicted in Section 4.5 of [RFC4861], but also 904 include a new "Prefix Length" field taken from the low-order 8 bits 905 of the Redirect message Reserved field. (For IPv6, valid values for 906 the Prefix Length field are 0 through 64; for IPv4, valid values are 907 0 through 32.) The Redirect/Predirect messages are formatted as 908 shown in Figure 3: 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type (=137) | Code (=0/1) | Checksum | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Reserved | Prefix Length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | 918 + + 919 | | 920 + Target Address + 921 | | 922 + + 923 | | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | | 926 + + 927 | | 928 + Destination Address + 929 | | 930 + + 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Options ... 934 +-+-+-+-+-+-+-+-+-+-+-+- 936 Figure 3: AERO Redirect/Predirect Message Format 938 3.9.4. Sending Predirects 940 When a Client forwards a packet with a source address from one of its 941 CPs toward a destination address covered by an ASP (i.e., toward 942 another AERO Client connected to the same AERO link), the source 943 Client MAY send a Predirect message forward toward the destination 944 Client via the Server. 946 In the reference operational scenario, when Client ('B') forwards a 947 packet toward Client ('C'), it MAY also send a Predirect message 948 forward toward Client ('C'), subject to rate limiting (see 949 Section 8.2 of [RFC4861]). Client ('A') prepares the Predirect 950 message as follows: 952 o the link-layer source address is set to 'L2(B)' (i.e., the link- 953 layer address of Client ('B')). 955 o the link-layer destination address is set to 'L2(A)' (i.e., the 956 link-layer address of Server ('A')). 958 o the network-layer source address is set to fe80::2001:db8:0:0 959 (i.e., the AERO address of Client ('B')). 961 o the network-layer destination address is set to fe80::2001:db8:1:0 962 (i.e., the AERO address of Client ('C')). 964 o the Type is set to 137. 966 o the Code is set to 1 to indicate "Predirect". 968 o the Prefix Length is set to the length of the prefix to be applied 969 to the Target Address. 971 o the Target Address is set to fe80::2001:db8:0:0 (i.e., the AERO 972 address of Client ('B')). 974 o the Destination Address is set to the source address of the 975 originating packet that triggered the Predirection event. (If the 976 originating packet is an IPv4 packet, the address is constructed 977 in IPv4-compatible IPv6 address format). 979 o the message includes a TLLAO with Link ID and Preference set to 980 appropriate values for Client ('B')'s underlying interface, and 981 with UDP Port Number and IP Address set to 'L2(B)'. 983 o the message SHOULD include a Timestamp option. 985 o the message includes a Redirected Header Option (RHO) that 986 contains the originating packet truncated to ensure that at least 987 the network-layer header is included but the size of the message 988 does not exceed 1280 bytes. 990 Note that the act of sending Predirect messages is cited as "MAY", 991 since Client ('B') must test reachability on the direct path to 992 Client ('C') via the NUD procedures in Section 3.10 to determine when 993 AERO route optimization is possible. If the direct path is unusable, 994 Client ('B') simply discontinues the AERO route optimization process 995 for Client ('C') and allows packets to again flow through Server 996 ('A'). 998 3.9.5. Re-encapsulating and Relaying Predirects 1000 When Server ('A') receives a Predirect message from Client ('B'), it 1001 validates the message according to the ICMPv6 Redirect message 1002 validation rules in Section 8.1 of [RFC4861], except that the 1003 Predirect has Code=1. Server ('A') also verifies that Client ('B') 1004 is authorized to use the Prefix Length in the Predirect when applied 1005 to the AERO address in the network-layer source address by searching 1006 for the AERO address' embedded CP in the IP forwarding table. If 1007 validation fails, Server ('A') discards the Predirect; otherwise, it 1008 copies the correct UDP Port number and IP Address for Client ('B') 1009 into the (previously empty) TLLAO. 1011 Server ('A') then examines the network-layer destination address of 1012 the Predirect to determine the next hop toward Client ('C') by 1013 searching for the AERO address' embedded CP in the IP routing table. 1014 If the next hop is reached via the AERO interface, Server ('A') re- 1015 encapsulates the Predirect and relays it on to Client ('C') by 1016 changing the link-layer source address of the message to 'L2(A)' and 1017 changing the link-layer destination address to 'L2(C)'. Server ('A') 1018 finally forwards the re-encapsulated message to Client ('C') without 1019 decrementing the network-layer TTL/Hop Limit field. 1021 3.9.6. Processing Predirects and Sending Redirects 1023 When Client ('C') receives the Predirect message, it accepts the 1024 Predirect only if the message has a link-layer source address of the 1025 Server, i.e. 'L2(A)'. Client ('C') further accepts the message only 1026 if it is willing to serve as a redirection target. Next, Client 1027 ('C') validates the message according to the ICMPv6 Redirect message 1028 validation rules in Section 8.1 of [RFC4861], except that it accepts 1029 the message even though Code=1 and even though the network-layer 1030 source address is not that of it's current first-hop router. 1032 In the reference operational scenario, when Client ('C') receives a 1033 valid Predirect message, it either creates or updates a neighbor 1034 cache entry that stores the Target Address of the message as the 1035 network-layer address of Client ('B') and stores the link-layer 1036 address found in the TLLAO as the link-layer address(es) of Client 1037 ('B'). Client ('C') then sets AcceptTime for the neighbor cache 1038 entry to ACCEPT_TIME. Next, Client ('C') applies the Prefix Length 1039 to the Destination Address and records the resulting CP its IP 1040 forwarding table. 1042 After processing the message, Client ('C') prepares a Redirect 1043 message response as follows: 1045 o the link-layer source address is set to 'L2(C)' (i.e., the link- 1046 layer address of Client ('C')). 1048 o the link-layer destination address is set to 'L2(A)' (i.e., the 1049 link-layer address of Server ('A')). 1051 o the network-layer source address is set to fe80::2001:db8:1:0 1052 (i.e., the AERO address of Client ('C')). 1054 o the network-layer destination address is set to fe80::2001:db8:0:0 1055 (i.e., the AERO address of Client ('B')). 1057 o the Type is set to 137. 1059 o the Code is set to 0 to indicate "Redirect". 1061 o the Prefix Length is set to the length of the prefix to be applied 1062 to the Target Address. 1064 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1065 address of Client ('C')). 1067 o the Destination Address is set to the destination address of the 1068 originating packet that triggered the Redirection event. (If the 1069 originating packet is an IPv4 packet, the address is constructed 1070 in IPv4-compatible IPv6 address format). 1072 o the message includes a TLLAO with Link ID and Preference set to 1073 appropriate values for Client ('C')'s underlying interface, and 1074 with UDP Port Number and IP Address set to '0'. 1076 o the message SHOULD include a Timestamp option. 1078 o the message includes as much of the RHO copied from the 1079 corresponding AERO Predirect message as possible such that at 1080 least the network-layer header is included but the size of the 1081 message does not exceed 1280 bytes. 1083 After Client ('C') prepares the Redirect message, it sends the 1084 message to Server ('A'). 1086 3.9.7. Re-encapsulating and Relaying Redirects 1088 When Server ('A') receives a Redirect message from Client ('C'), it 1089 validates the message according to the ICMPv6 Redirect message 1090 validation rules in Section 8.1 of [RFC4861]. Server ('A') also 1091 verifies that Client ('C') is authorized to use the Prefix Length in 1092 the Redirect message when applied to the AERO address in the network- 1093 layer source of the Redirect message by searching for the AERO 1094 address' embedded CP in the IP forwarding table. If validation 1095 fails, Server ('A') discards the message; otherwise, it copies the 1096 correct UDP Port number and IP Address for Client ('C') into the 1097 (previously empty) TLLAO. 1099 Server ('A') then examines the network-layer destination address of 1100 the message to determine the next hop toward Client ('B') by 1101 searching for the AERO address' embedded CP in the IP forwarding 1102 table. If the next hop is reached via the AERO interface, Server 1103 ('A') re-encapsulates the Redirect and relays it on to Client ('B') 1104 by changing the link-layer source address of the message to 'L2(A)' 1105 and changing the link-layer destination address to 'L2(B)'. Server 1106 ('A') finally forwards the re-encapsulated message to Client ('B') 1107 without decrementing the network-layer TTL/Hop Limit field. 1109 3.9.8. Processing Redirects 1111 When Client ('B') receives the Redirect message, it accepts the 1112 message only if it has a link-layer source address of the Server, 1113 i.e. 'L2(A)'. Next, Client ('B') validates the message according to 1114 the ICMPv6 Redirect message validation rules in Section 8.1 of 1115 [RFC4861], except that it accepts the message even though the 1116 network-layer source address is not that of it's current first-hop 1117 router. Following validation, Client ('B') then processes the 1118 message as follows. 1120 In the reference operational scenario, when Client ('B') receives the 1121 Redirect message, it either creates or updates a neighbor cache entry 1122 that stores the Target Address of the message as the network-layer 1123 address of Client ('C') and stores the link-layer address found in 1124 the TLLAO as the link-layer address of Client ('C'). Client ('B') 1125 then sets ForwardTime for the neighbor cache entry to FORWARD_TIME. 1126 Next, Client ('B') applies the Prefix Length to the Destination 1127 Address and records the resulting CP in its IP forwarding table. 1129 Now, Client ('B') has a forwarding table entry for Client('C')'s CP 1130 and a neighbor cache entry with a valid ForwardTime value, while 1131 Client ('C') has an forwarding table entry for Client ('B')'s CP with 1132 a valid AcceptTime value. Thereafter, Client ('B') may forward 1133 ordinary network-layer data packets directly to Client ("C") without 1134 involving Server ('A') and Client ('C') can verify that the packets 1135 came from an acceptable source. (In order for Client ('C') to 1136 forward packets to Client ('B'), a corresponding Predirect/Redirect 1137 message exchange is required in the reverse direction; hence, the 1138 mechanism is asymmetric.) 1140 3.9.9. AERO Relay Operation 1142 The reference operational scenario shown in Figure 2 applies to the 1143 case when Clients ('B') and ('C') are associated with the same Server 1144 ('A'). 1146 When the Clients are associated with different Servers, Client (B')'s 1147 Server ('S1') forwards packets and Predirect messages to a Relay 1148 ('R') which in turn forwards them to Client ('C')'s Server ('S2'). 1149 Similarly, Client ('C')'s Server ('S2') forwards Redirect messages to 1150 Relay ('R') which in turn forwards them to Client ('B')'s Server 1151 ('S1'). In this process: 1153 o When Server ('S1') forwards a packet or Predirect message to Relay 1154 ('R'), it sets the link-layer source address to its own address 1155 and sets the link-layer destination address to Relay ('R')'s link- 1156 layer address. 1158 o When Relay ('R') forwards a packet or Predirect message to Server 1159 ('S2'), it sets the link-layer source address to its own address 1160 and sets the link-layer destination address to Server ('S2')'s 1161 link-layer address. 1163 o When Server ('S2') forwards a Redirect message to Relay ('R'), it 1164 sets the link-layer source address to its own address and sets the 1165 link-layer destination address to Relay ('R')'s link-layer 1166 address. 1168 o When Relay ('R') forwards a Redirect message to Server ('S1'), it 1169 sets the link-layer source address to its own address and sets the 1170 link-layer destination address to Server ('S1')'s link-layer 1171 address. 1173 See Appendix A for further discussion of AERO Server/Relay 1174 interworking. 1176 3.9.10. Server-Oriented Redirection 1178 In some environments, the Server nearest the destination Client may 1179 need to serve as the redirection target, e.g., if direct Client-to- 1180 Client communications are not possible. In that case, the Server 1181 prepares the Redirect message the same as if it were the destination 1182 Client (see: Section 3.9.6), except that it writes its own link-layer 1183 address in the TLLAO option. The Server must then maintain a 1184 neighbor cache entry for the redirected source Client. 1186 3.10. Neighbor Unreachability Detection (NUD) 1188 AERO nodes perform NUD by sending unicast NS messages to elicit 1189 solicited NA messages from neighbors the same as described in 1190 [RFC4861]. When an AERO node sends an NS/NA message, it MUST use its 1191 link-local address as the IPv6 source address and the link-local 1192 address of the neighbor as the IPv6 destination address. When an 1193 AERO node receives an NS message or a solicited NA message, it 1194 accepts the message if it has a neighbor cache entry for the 1195 neighbor; otherwise, it ignores the message. 1197 When a source Client is redirected to a target Client it SHOULD test 1198 the direct path by sending an initial NS message to elicit a 1199 solicited NA response. While testing the path, the source Client can 1200 optionally continue sending packets via the Server, maintain a small 1201 queue of packets until target reachability is confirmed, or 1202 (optimistically) allow packets to flow directly to the target. The 1203 source Client SHOULD thereafter continue to test the direct path to 1204 the target Client (see Section 7.3 of [RFC4861]) periodically in 1205 order to keep neighbor cache entries alive. 1207 In particular, while the source Client is actively sending packets to 1208 the target Client it SHOULD also send NS messages separated by 1209 RETRANS_TIMER milliseconds in order to receive solicited NA messages. 1210 If the source Client is unable to elicit a solicited NA response from 1211 the target Client after MAX_RETRY attempts, it SHOULD set ForwardTime 1212 to 0 and resume sending packets via the Server which may or may not 1213 result in a new redirection event. Otherwise, the source Client 1214 considers the path usable and SHOULD thereafter process any link- 1215 layer errors as a hint that the direct path to the target Client has 1216 either failed or has become intermittent. 1218 When a target Client receives an NS message from a source Client, it 1219 resets AcceptTime to ACCEPT_TIME if a neighbor cache entry exists; 1220 otherwise, it discards the NS message. 1222 When a source Client receives a solicited NA message from a target 1223 Client, it resets ForwardTime to FORWARD_TIME if a neighbor cache 1224 entry exists; otherwise, it discards the NA message. 1226 When ForwardTime for a neighbor cache entry expires, the source 1227 Client resumes sending any subsequent packets via the Server and may 1228 (eventually) attempt to re-initiate the AERO redirection process. 1229 When AcceptTime for a neighbor cache entry expires, the target Client 1230 discards any subsequent packets received directly from the source 1231 Client. When both ForwardTime and AcceptTime for a neighbor cache 1232 entry expire, the Client deletes both the neighbor cache entry and 1233 the corresponding IP forwarding table entry. 1235 3.11. Mobility Management 1237 3.11.1. Announcing Link-Layer Address Changes 1239 When a Client needs to change its link-layer address, e.g., due to a 1240 mobility event, it performs an immediate DHCPv6 Renew/Reply via each 1241 of its Servers using the new link-layer address as the source. The 1242 DHCPv6 Server will re-authenticate the Client and (assuming 1243 authentication succeeds) the DHCPv6 Renew/Reply exchange will update 1244 each Server's neighbor cache. 1246 Next, the Client sends unsolicited NA messages to each of its active 1247 neighbors using the same procedures as specified in Section 7.2.6 of 1248 [RFC4861], except that it sends the messages as unicast to each 1249 neighbor via a Server instead of multicast. In this process, the 1250 Client should send no more than MAX_NEIGHBOR_ADVERTISEMENT messages 1251 separated by no less than RETRANS_TIMER seconds to each neighbor. 1253 With reference to Figure 2, Client ('C') sends unicast unsolicited NA 1254 messages to Client ('B') via Server ('A') as follows: 1256 o the link-layer source address is set to 'L2(C)' (i.e., the link- 1257 layer address of Client ('C')). 1259 o the link-layer destination address is set to 'L2(A)' (i.e., the 1260 link-layer address of Server ('A')). 1262 o the network-layer source address is set to fe80::2001:db8:1:0 1263 (i.e., the AERO address of Client ('C')). 1265 o the network-layer destination address is set to fe80::2001:db8:0:0 1266 (i.e., the AERO address of Client ('B')). 1268 o the Type is set to 136. 1270 o the Code is set to 0. 1272 o the Solicited flag is set to 0. 1274 o the Override flag is set to 1. 1276 o the Target Address is set to fe80::2001:db8:1:0 (i.e., the AERO 1277 address of Client ('C')). 1279 o the message includes a TLLAO with Link ID and Preference set to 1280 appropriate values for Client ('C')'s underlying interface, and 1281 with UDP Port Number and IP Address set to '0'. 1283 o the message SHOULD include a Timestamp option. 1285 When Server ('A') receives the NA message, it relays the message in 1286 the same way as described for relaying Redirect messages in 1287 Section 3.9.7. In particular, Server ('A') copies the correct UDP 1288 port number and IP address into the TLLAO, changes the link-layer 1289 source address to its own address, changes the link-layer destination 1290 address to the address of Client ('B'), then forwards the NA message 1291 based on an IP forwarding table entry matching the AERO address in 1292 the network-layer destination address. 1294 When Client ('B') receives the NA message, it accepts the message 1295 only if it already has a neighbor cache entry for Client ('C') then 1296 updates the link-layer address for Client ('C') based on the address 1297 in the TLLAO. However, Client ('B') MUST NOT update ForwardTime 1298 since Client ('C') will not have updated AcceptTime. 1300 Note that these unsolicited NA messages are unacknowledged; hence, 1301 Client ('C') has no way of knowing whether Client ('B') has received 1302 them. If the messages are somehow lost, however, Client ('B') will 1303 soon learn of the mobility event via the NUD procedures specified in 1304 Section 3.10. 1306 3.11.2. Moving to a New Server 1308 When a Client associates with a new Server, it issues a new DHCPv6 1309 Renew message via the new Server as the DHCPv6 relay. The new Server 1310 then relays the message to the DHCPv6 server and processes the 1311 resulting exchange. After the Client receives the resulting DHCPv6 1312 Reply message, it sends an RS message to the new Server to receive a 1313 new RA message. 1315 When a Client disassociates with an existing Server, it sends a 1316 "terminating RS" message to the old Server. The terminating RS 1317 message is prepared exactly the same as for an ordinary RS message, 1318 except that the Code field contains the value '1'. When the old 1319 Server receives the terminating RS message, it withdraws the IP route 1320 from the routing system and deletes the neighbor cache entry and IP 1321 forwarding table entry for the Client. The old Server then returns 1322 an RA message with default router lifetime set to 0 which the Client 1323 can use to verify that the termination signal has been processed. 1324 The client then deletes both the default route and the neighbor cache 1325 entry for the old Server. (Note that the Client and the old Server 1326 MAY impose a small delay before deleting the neighbor cache and IP 1327 forwarding table entries so that any packets already in the system 1328 can still be delivered to the Client.) 1330 Clients SHOULD NOT move rapidly between Servers in order to avoid 1331 causing unpredictable oscillations in the Server/Relay routing 1332 system. Such oscillations could result in intermittent reachability 1333 for the Client itself, while causing little harm to the network due 1334 to routing protocol dampening. Examples of when a Client may change 1335 to a different Server include a Server that has gone unreachable, 1336 topological movements of significant distance, etc. 1338 3.12. Encapsulation Protocol Version Considerations 1340 A source Client may connect only to an IPvX underlying network, while 1341 the target Client connects only to an IPvY underlying network. In 1342 that case, the target and source Clients have no means for reaching 1343 each other directly (since they connect to underlying networks of 1344 different IP protocol versions) and so must ignore any redirection 1345 messages and continue to send packets via the Server. 1347 3.13. Multicast Considerations 1349 When the underlying network does not support multicast, AERO nodes 1350 map IPv6 link-scoped multicast addresses (including 1351 'All_DHCP_Relay_Agents_and_Servers') to the link-layer address of a 1352 Server. 1354 When the underlying network supports multicast, AERO nodes use the 1355 multicast address mapping specification found in [RFC2529] for IPv4 1356 underlying networks and use a direct multicast mapping for IPv6 1357 underlying networks. (In the latter case, "direct multicast mapping" 1358 means that if the IPv6 multicast destination address of the 1359 encapsulated packet is "M", then the IPv6 multicast destination 1360 address of the encapsulating header is also "M".) 1362 3.14. Operation on AERO Links Without DHCPv6 Services 1364 When the AERO link does not provide DHCPv6 services, operation can 1365 still be accommodated through administrative configuration of CPs on 1366 AERO Clients. In that case, administrative configurations of IP 1367 forwarding table and AERO interface neighbor cache entries on both 1368 the Server and Client are also necessary. However, this may 1369 interfere with the ability for Clients to dynamically change to new 1370 Servers, and can expose the AERO link to misconfigurations unless the 1371 administrative configurations are carefully coordinated. 1373 3.15. Operation on Server-less AERO Links 1375 In some AERO link scenarios, there may be no Servers on the link and/ 1376 or no need for Clients to use a Server as an intermediary trust 1377 anchor. In that case, each Client acts as a Server unto itself to 1378 establish neighbor cache entries and IP forwarding table entries by 1379 performing direct Client-to-Client Predirect/Redirect exchanges, and 1380 some other form of trust basis must be applied so that each Client 1381 can verify that the prospective neighbor is authorized to use its 1382 claimed CP. 1384 When there is no Server on the link, Clients must arrange to receive 1385 CPs and publish them via a secure alternate prefix delegation 1386 authority through some means outside the scope of this document. 1388 4. Implementation Status 1390 An application-layer implementation is in progress. 1392 5. IANA Considerations 1394 The IANA is instructed to assign a new 2-octet Hardware Type number 1395 for AERO in the "arp-parameters" registry per Section 2 of [RFC5494]. 1396 The number is assigned from the 2-octet Unassigned range with 1397 Hardware Type "AERO" and with this document as the reference. 1399 6. Security Considerations 1401 AERO link security considerations are the same as for standard IPv6 1402 Neighbor Discovery [RFC4861] except that AERO improves on some 1403 aspects. In particular, AERO uses a trust basis between Clients and 1404 Servers, where the Clients only engage in the AERO mechanism when it 1405 is facilitated by a trust anchor. AERO also uses DHCPv6 1406 authentication for Client authentication and network admission 1407 control. 1409 AERO links must be protected against link-layer address spoofing 1410 attacks in which an attacker on the link pretends to be a trusted 1411 neighbor. Links that provide link-layer securing mechanisms (e.g., 1412 IEEE 802.1X WLANs) and links that provide physical security (e.g., 1413 enterprise network wired LANs) provide a first line of defense that 1414 is often sufficient. In other instances, additional securing 1415 mechanisms such as Secure Neighbor Discovery (SeND) [RFC3971], IPsec 1416 [RFC4301] or TLS [RFC5246] may be necessary. 1418 AERO Clients MUST ensure that their connectivity is not used by 1419 unauthorized nodes on EUNs to gain access to a protected network, 1420 i.e., AERO Clients that act as routers MUST NOT provide routing 1421 services for unauthorized nodes. (This concern is no different than 1422 for ordinary hosts that receive an IP address delegation but then 1423 "share" the address with unauthorized nodes via a NAT function.) 1425 On some AERO links, establishment and maintenance of a direct path 1426 between neighbors requires secured coordination such as through the 1427 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 1428 security association. 1430 7. Acknowledgements 1432 Discussions both on IETF lists and in private exchanges helped shape 1433 some of the concepts in this work. Individuals who contributed 1434 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1435 Brian Carpenter, Wojciech Dec, Brian Haberman, Joel Halpern, Sascha 1436 Hlusiak, Lee Howard, Joe Touch and Bernie Volz. Members of the IESG 1437 also provided valuable input during their review process that greatly 1438 improved the document. Special thanks go to Stewart Bryant, Joel 1439 Halpern and Brian Haberman for their shepherding guidance. 1441 This work has further been encouraged and supported by Boeing 1442 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 1443 Balaguruna Chidambaram, Wen Fang, Anthony Gregory, Jeff Holland, Ed 1444 King, Gen MacLean, Kent Shuey, Mike Slane, Julie Wulff, Yueli Yang, 1445 and other members of the BR&T and BIT mobile networking teams. 1447 Earlier works on NBMA tunneling approaches are found in 1448 [RFC2529][RFC5214][RFC5569]. 1450 8. References 1452 8.1. Normative References 1454 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1455 August 1980. 1457 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1458 1981. 1460 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1461 RFC 792, September 1981. 1463 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1464 October 1996. 1466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1467 Requirement Levels", BCP 14, RFC 2119, March 1997. 1469 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1470 (IPv6) Specification", RFC 2460, December 1998. 1472 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1473 IPv6 Specification", RFC 2473, December 1998. 1475 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1476 and M. Carney, "Dynamic Host Configuration Protocol for 1477 IPv6 (DHCPv6)", RFC 3315, July 2003. 1479 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1480 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1481 December 2003. 1483 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1484 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1486 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1487 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1489 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1490 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1491 September 2007. 1493 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1494 Address Autoconfiguration", RFC 4862, September 2007. 1496 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1497 Requirements", RFC 6434, December 2011. 1499 8.2. Informative References 1501 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1502 RFC 879, November 1983. 1504 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1505 selection, and registration of an Autonomous System (AS)", 1506 BCP 6, RFC 1930, March 1996. 1508 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1509 Domains without Explicit Tunnels", RFC 2529, March 1999. 1511 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1512 RFC 2675, August 1999. 1514 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1515 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1517 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1518 Architecture", RFC 4291, February 2006. 1520 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1521 Internet Protocol", RFC 4301, December 2005. 1523 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1524 Discovery", RFC 4821, March 2007. 1526 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1527 Errors at High Data Rates", RFC 4963, July 2007. 1529 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 1530 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 1531 September 2007. 1533 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1534 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1535 March 2008. 1537 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1538 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1540 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 1541 for the Address Resolution Protocol (ARP)", RFC 5494, 1542 April 2009. 1544 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1545 Route Optimization Requirements for Operational Use in 1546 Aeronautics and Space Exploration Mobile Networks", RFC 1547 5522, October 2009. 1549 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1550 Infrastructures (6rd)", RFC 5569, January 2010. 1552 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1553 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1554 5996, September 2010. 1556 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1557 NAT64: Network Address and Protocol Translation from IPv6 1558 Clients to IPv4 Servers", RFC 6146, April 2011. 1560 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1561 Troan, "Basic Requirements for IPv6 Customer Edge 1562 Routers", RFC 6204, April 2011. 1564 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 1565 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 1566 2011. 1568 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1569 for Equal Cost Multipath Routing and Link Aggregation in 1570 Tunnels", RFC 6438, November 2011. 1572 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1573 RFC 6691, July 2012. 1575 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1576 (AERO)", RFC 6706, August 2012. 1578 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1579 RFC 6864, February 2013. 1581 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1582 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1584 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1585 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1586 RFC 6936, April 2013. 1588 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 1589 Address Option in DHCPv6", RFC 6939, May 2013. 1591 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1592 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1594 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 1595 Address Selection Policy Using DHCPv6", RFC 7078, January 1596 2014. 1598 Appendix A. AERO Server and Relay Interworking 1600 Figure 2 depicts a reference AERO operational scenario with a single 1601 Server on the AERO link. In order to support scaling to larger 1602 numbers of nodes, the AERO link can deploy multiple Servers and 1603 Relays, e.g., as shown in Figure 4. 1605 .-(::::::::) 1606 .-(:::: IP ::::)-. 1607 (:: Internetwork ::) 1608 `-(::::::::::::)-' 1609 `-(::::::)-' 1610 | 1611 +--------------+ +------+-------+ +--------------+ 1612 |AERO Server C | | AERO Relay D | |AERO Server E | 1613 | (default->D) | | (A->C; G->E) | | (default->D) | 1614 | (A->B) | +-------+------+ | (G->F) | 1615 +-------+------+ | +------+-------+ 1616 | | | 1617 X---+---+-------------------+------------------+---+---X 1618 | AERO Link | 1619 +-----+--------+ +--------+-----+ 1620 |AERO Client B | |AERO Client F | 1621 | (default->C) | | (default->E) | 1622 +--------------+ +--------------+ 1623 .-. .-. 1624 ,-( _)-. ,-( _)-. 1625 .-(_ IP )-. .-(_ IP )-. 1626 (__ EUN ) (__ EUN ) 1627 `-(______)-' `-(______)-' 1628 | | 1629 +--------+ +--------+ 1630 | Host A | | Host G | 1631 +--------+ +--------+ 1633 Figure 4: AERO Server/Relay Interworking 1635 In this example, Client ('B') associates with Server ('C'), while 1636 Client ('F') associates with Server ('E'). Furthermore, Servers 1637 ('C') and ('E') do not associate with each other directly, but rather 1638 have an association with Relay ('D') (i.e., a router that has full 1639 topology information concerning its associated Servers and their 1640 Clients). Relay ('D') connects to the AERO link, and also connects 1641 to the native IP Internetwork. 1643 When source host ('A') sends a packet toward destination host ('G'), 1644 IP forwarding directs the packet through the EUN to Client ('B'), 1645 which forwards the packet to Server ('C') and also generates a 1646 Predirect message. Server ('C') forwards both the packet and 1647 Predirect through Relay ('D'), which then forwards both the packet 1648 and Predirect to Server ('E'). When Server ('E') receives the packet 1649 and Predirect message, it forwards them to Client ('F'). 1651 After processing the Predirect message, Client ('F') sends a Redirect 1652 message to Server ('E'). Server ('E'), in turn, forwards the 1653 Redirect through Relay ('D') to Server ('C') which forwards the 1654 Redirect to Client ('B') informing it that host 'G's EUN can be 1655 reached via Client ('F'), thus completing the AERO redirection. 1657 The network-layer routing information shared between Servers and 1658 Relays must be carefully coordinated. In particular, Relays require 1659 full topology information, while individual Servers only require 1660 partial topology information, i.e., they only need to know the set of 1661 ASPs associated with the AERO link and the CPs associated with their 1662 current set of associated Clients. This can be accomplished in a 1663 number of ways, but a prominent example is through the use of an 1664 internal instance of the Border Gateway Protocol (BGP) [RFC4271] 1665 coordinated between Servers and Relays. This internal BGP instance 1666 does not interact with the public Internet BGP instance; therefore, 1667 the AERO link is presented to the IP Internetwork as a small set of 1668 ASPs as opposed to the full set of individual CPs. 1670 In a reference BGP arrangement, each AERO Server is configured as an 1671 Autonomous System Border Router (ASBR) for a stub Autonomous System 1672 (AS) (possibly using a private AS Number (ASN) [RFC1930]), and each 1673 Server further peers with each Relay but does not peer with other 1674 Servers. Each Server maintains a working set of associated Clients, 1675 and dynamically announces new CPs and withdraws departed CPs in its 1676 BGP updates. The Relays therefore discover the full topology of the 1677 AERO link in terms of the working set of Clients associated with each 1678 Server. Since Clients are expected to remain associated with their 1679 current set of Servers for extended timeframes, the amount of BGP 1680 control messaging between Servers and Relays should be minimal. 1681 However, Servers SHOULD dampen any route oscillations caused by 1682 impatient Clients that repeatedly associate and disassociate with the 1683 Server. 1685 Author's Address 1687 Fred L. Templin (editor) 1688 Boeing Research & Technology 1689 P.O. Box 3707 1690 Seattle, WA 98124 1691 USA 1693 Email: fltemplin@acm.org