idnits 2.17.1 draft-templin-aerolink-12.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 (April 2, 2014) is 3677 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 1179, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1185, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 1287, 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 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 (~~), 12 warnings (==), 5 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) April 2, 2014 5 Intended status: Standards Track 6 Expires: October 4, 2014 8 Transmission of IPv6 Packets over AERO Links 9 draft-templin-aerolink-12.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 October 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 6 60 3.1. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. AERO Interface Characteristics . . . . . . . . . . . . . . 7 62 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. AERO Interface Data Origin Authentication . . . . . . . . 9 64 3.5. AERO Interface Conceptual Data Structures and Protocol 65 Constants . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.6. AERO Interface MTU Considerations . . . . . . . . . . . . 10 67 3.7. AERO Interface Encapsulation, Re-encapsulation and 68 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 12 69 3.8. AERO Reference Operational Scenario . . . . . . . . . . . 13 70 3.9. AERO Router Discovery and Prefix Delegation . . . . . . . 15 71 3.9.1. AERO Client Behavior . . . . . . . . . . . . . . . . . 15 72 3.9.2. AERO Server Behavior . . . . . . . . . . . . . . . . . 16 73 3.10. AERO Neighbor Solicitation and Advertisement . . . . . . . 16 74 3.11. AERO Redirection . . . . . . . . . . . . . . . . . . . . . 18 75 3.11.1. Classical Redirection Approaches . . . . . . . . . . . 18 76 3.11.2. AERO Redirection Concept of Operations . . . . . . . . 19 77 3.11.3. AERO Redirection Message Format . . . . . . . . . . . 19 78 3.11.4. Sending Predirects . . . . . . . . . . . . . . . . . . 20 79 3.11.5. Processing Predirects and Sending Redirects . . . . . 21 80 3.11.6. Re-encapsulating and Relaying Redirects . . . . . . . 22 81 3.11.7. Processing Redirects . . . . . . . . . . . . . . . . . 23 82 3.12. Neighbor Reachability Maintenance . . . . . . . . . . . . 23 83 3.13. Mobility and Link-Layer Address Change Considerations . . 24 84 3.14. Underlying Protocol Version Considerations . . . . . . . . 25 85 3.15. Multicast Considerations . . . . . . . . . . . . . . . . . 25 86 3.16. Operation on Server-less AERO Links . . . . . . . . . . . 25 87 3.17. Other Considerations . . . . . . . . . . . . . . . . . . . 25 88 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 95 Appendix A. AERO Server and Relay Interworking . . . . . . . . . 29 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 1. Introduction 100 This document specifies the operation of IPv6 over tunnel virtual 101 Non-Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 102 Route Optimization (AERO). Nodes attached to AERO links can exchange 103 packets via trusted intermediate routers on the link that provide 104 forwarding services to reach off-link destinations and/or redirection 105 services to inform the node of an on-link neighbor that is closer to 106 the final destination. 108 Nodes on AERO links use an IPv6 link-local address format known as 109 the AERO Address. This address type has properties that statelessly 110 link IPv6 Neighbor Discovery (ND) to IPv6 routing. The AERO link can 111 be used for tunneling to neighboring nodes on either IPv6 or IPv4 112 networks, i.e., AERO views the IPv6 and IPv4 networks as equivalent 113 links for tunneling. The remainder of this document presents the 114 AERO specification. 116 2. Terminology 118 The terminology in the normative references applies; the following 119 terms are defined within the scope of this document: 121 AERO link 122 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 123 configured over a node's attached IPv6 and/or IPv4 networks. All 124 nodes on the AERO link appear as single-hop neighbors from the 125 perspective of IPv6. 127 AERO interface 128 a node's attachment to an AERO link. The AERO interface Maximum 129 Transmission Unit (MTU) is less than or equal to the AERO link 130 MTU. 132 AERO address 133 an IPv6 link-local address assigned to an AERO interface and 134 constructed as specified in Section 3.6. 136 AERO node 137 a node that is connected to an AERO link and that participates in 138 IPv6 Neighbor Discovery over the link. 140 AERO Client ("client") 141 a node that configures either a host interface or a router 142 interface on an AERO link. 144 AERO Server ("server") 145 a node that configures a router interface on an AERO link over 146 which it can provide default forwarding and redirection services 147 for other AERO nodes. 149 AERO Relay ("relay") 150 a node that relays IPv6 packets between Servers on the same AERO 151 link, and/or that forwards IPv6 packets between the AERO link and 152 the IPv6 Internet. An AERO Relay may or may not also be 153 configured as an AERO Server. 155 ingress tunnel endpoint (ITE) 156 an AERO interface endpoint that injects tunneled packets into an 157 AERO link. 159 egress tunnel endpoint (ETE) 160 an AERO interface endpoint that receives tunneled packets from an 161 AERO link. 163 underlying network 164 a connected IPv6 or IPv4 network routing region over which AERO 165 nodes tunnel IPv6 packets. 167 underlying interface 168 an AERO node's interface point of attachment to an underlying 169 network. 171 underlying address 172 an IPv6 or IPv4 address assigned to an AERO node's underlying 173 interface. When UDP encapsulation is used, the UDP port number is 174 also considered as part of the underlying address. Underlying 175 addresses are used as the source and destination addresses of the 176 AERO encapsulation header. 178 link-layer address 179 the same as defined for "underlying address" above. 181 network layer address 182 an IPv6 address used as the source or destination address of the 183 inner IPv6 packet header. 185 end user network (EUN) 186 an IPv6 network attached to a downstream interface of an AERO 187 Client (where the AERO interface is seen as the upstream 188 interface). 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 3. Asymmetric Extended Route Optimization (AERO) 196 The following sections specify the operation of IPv6 over Asymmetric 197 Extended Route Optimization (AERO) links: 199 3.1. AERO Node Types 201 AERO Relays relay packets between nodes connected to the same AERO 202 link and also forward packets between the AERO link and the native 203 IPv6 network. The relaying process entails re-encapsulation of IPv6 204 packets that were received from a first AERO node and are to be 205 forwarded without modification to a second AERO node. 207 AERO Servers configure their AERO interfaces as router interfaces, 208 and provide default routing services to AERO Clients. AERO Servers 209 configure a DHCPv6 Relay or Server function and facilitate DHCPv6 210 Prefix Delegation (PD) exchanges. An AERO Server may also act as an 211 AERO Relay. 213 AERO Clients act as requesting routers to receive IPv6 prefixes 214 through a DHCPv6 PD exchange via an AERO Server over the AERO link. 215 Each AERO Client receives at least a /64 prefix delegation, and may 216 receive even shorter prefixes. 218 AERO Clients that act as routers configure their AERO interfaces as 219 router interfaces, i.e., even if the AERO Client otherwise displays 220 the outward characteristics of an ordinary host (for example, the 221 Client may internally configure both an AERO interface and (internal 222 virtual) End User Network (EUN) interfaces). AERO Clients that act 223 as routers sub-delegate portions of their received prefix delegations 224 to links on EUNs. 226 AERO Clients that act as ordinary hosts configure their AERO 227 interfaces as host interfaces and assign one or more IPv6 addresses 228 taken from their received prefix delegations to the AERO interface 229 but DO NOT assign the delegated prefix itself to the AERO interface. 230 Instead, the host assigns the delegated prefix to a "black hole" 231 route so that unused portions of the prefix are nullified. 233 End system applications on AERO hosts bind directly to the AERO 234 interface, while applications on AERO routers (or IPv6 hosts served 235 by an AERO router) bind to EUN interfaces. 237 3.2. AERO Interface Characteristics 239 AERO interfaces use IPv6-in-IPv6 encapsulation [RFC2473] to exchange 240 tunneled packets with AERO neighbors attached to an underlying IPv6 241 network, and use IPv6-in-IPv4 encapsulation [RFC4213] to exchange 242 tunneled packets with AERO neighbors attached to an underlying IPv4 243 network. AERO interfaces can also use IPsec encapsulation [RFC4301] 244 (either IPv6-in-IPsec-in-IPv6 or IPv6-in-IPsec-in-IPv4) in 245 environments where strong authentication and confidentiality are 246 required. When NAT traversal and/or filtering middlebox traversal is 247 necessary, a UDP header is further inserted between the outer IP 248 encapsulation header and the inner packet. 250 Servers assign the address 'fe80::0' to their AERO interface; this 251 provides a link-local address handle for Clients to insert into a 252 neighbor cache entry for their current Server. Clients initially 253 assign no address to their AERO interface, but use 'fe80::1' as the 254 IPv6 link-local address in the DHCPv6 PD exchanges used to derive an 255 AERO address. After the Client receives a prefix delegation, it 256 assigns the corresponding AERO address to the AERO interface. 258 AERO interfaces maintain a neighbor cache and use a variation of 259 standard unicast IPv6 ND messaging. AERO interfaces use Neighbor 260 Solicitation (NS), Neighbor Advertisement (NA) and Redirect messages 261 the same as for any IPv6 link. They do not use Router Solicitation 262 (RS) and Router Advertisement (RA) messages for several reasons. 263 First, default router discovery is supported through other means more 264 appropriate for AERO links as described below. Second, discovery of 265 more-specific routes is through the receipt of Redirect messages. 266 Finally, AERO nodes obtain their delegated IPv6 prefixes using DHCPv6 267 PD; hence, there is no need for RA-based prefix discovery. 269 AERO Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 270 messages do not include Source/Target Link Layer Address Options 271 (S/TLLAO). Instead, AERO nodes determine the link-layer addresses of 272 neighbors by examining the encapsulation IP source address and UDP 273 port number (when UDP encapsulation is used) of any NS/NA messages 274 they receive and ignore any S/TLLAOs included in these messages. 275 This is vital to the operation of AERO links for which neighbors are 276 separated by Network Address Translators (NATs) - either IPv4 or 277 IPv6. 279 AERO Redirect messages include a TLLAO the same as for any IPv6 link. 280 The TLLAO includes the link-layer address of the target node, 281 including both the IP address and the UDP source port number used by 282 the target when it sends UDP-encapsulated packets over the AERO 283 interface (the TLLAO instead encodes the value 0 when the target does 284 not use UDP encapsulation). TLLAOs for target nodes that use an IPv6 285 underlying address include the full 16 bytes of the IPv6 address as 286 shown in Figure 1, while TLLAOs for target nodes that use an IPv4 287 underlying address include only the 4 bytes of the IPv4 address as 288 shown in Figure 2. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type = 2 | Length = 3 | UDP Source Port (or 0) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Reserved | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 +-- --+ 299 | | 300 +-- IPv6 Address --+ 301 | | 302 +-- --+ 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 1: AERO TLLAO Format for IPv6 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type = 2 | Length = 1 | UDP Source Port (or 0) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | IPv4 Address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 2: AERO TLLAO Format for IPv4 318 Finally, AERO interface NS/NA messages only update existing neighbor 319 cache entires and do not create new neighbor cache entries, whereas 320 Redirect messages both update and create neighbor cache entries. 321 This represents a departure from the normal operation of IPv6 ND over 322 common link types, but is consistent with the spirit of IPv6 over 323 NBMA links as discussed in [RFC4861]. Note however that this 324 restriction may be relaxed and/or redefined on AERO links that 325 participate in a fully distributed mobility management model 326 coordinated in a manner outside the scope of this document. 328 3.3. AERO Addresses 330 An AERO address is an IPv6 link-local address assigned to an AERO 331 interface and with an IPv6 prefix embedded within the interface 332 identifier. The AERO address is formatted as: 334 fe80::[IPv6 prefix] 336 Each AERO Client configures an AERO address based on the delegated 337 prefix it has received from the DHCPv6 server. The address begins 338 with the prefix fe80::/64 and includes in its interface identifier 339 the base /64 prefix taken from the Client's delegated IPv6 prefix. 340 The base prefix is determined by masking the delegated prefix with 341 the prefix length. For example, if an AERO Client has received the 342 prefix delegation: 344 2001:db8:1000:2000::/56 346 it would construct its AERO address as: 348 fe80::2001:db8:1000:2000 350 The AERO address remains stable as the Client moves between 351 topological locations, i.e., even if its underlying address changes. 353 3.4. AERO Interface Data Origin Authentication 355 Nodes on AERO interfaces use a simple data origin authentication for 356 encapsulated packets they receive from other nodes. In particular, 357 AERO Clients accept encapsulated packets with a link-layer source 358 address belonging to their current AERO Server. AERO nodes also 359 accept encapsulated packets with a link-layer source address that is 360 correct for the network-layer source address. 362 The AERO node considers the link-layer source address correct for the 363 network-layer source address if there is an IPv6 route that matches 364 the network-layer source address as well as a neighbor cache entry 365 corresponding to the next hop that includes the link-layer address. 366 An exception is that NS, NA and Redirect messages may include a 367 different link-layer address than the one currently in the neighbor 368 cache, and the new link-layer address updates the neighbor cache 369 entry. 371 3.5. AERO Interface Conceptual Data Structures and Protocol Constants 373 Each AERO node maintains a per-AERO interface conceptual neighbor 374 cache that includes an entry for each neighbor it communicates with 375 on the AERO link, the same as for any IPv6 interface (see [RFC4861]). 377 Neighbor cache entries are either static or dynamic. Static neighbor 378 cache entries (including a Client's neighbor cache entry for a Server 379 or a Server's neighbor cache entry for a Client) do not have timeout 380 values and are retained until explicitly deleted. Dynamic neighbor 381 cache entries are created and maintained by the AERO redirection 382 procedures describe in the following sections. 384 When an AERO node receives a valid Predirect message (See Section 385 3.11.5) it creates or updates a dynamic neighbor cache entry for the 386 Predirect target L3 and L2 addresses, and also creates an IPv6 route 387 for the Predirected (source) prefix. The node then sets an ACCEPT 388 timer and uses this timer to validate any messages received from the 389 Predirected neighbor. 391 When an AERO node receives a valid Redirect message (see Section 392 3.11.7) it creates or updates a dynamic neighbor cache entry for the 393 Redirect target L3 and L2 addresses, and also creates an IPv6 route 394 for the Redirected (destination) prefix. The node then sets a 395 FORWARD timer and uses this timer to determine whether packets can be 396 sent directly to the Redirected neighbor. The node also maintains a 397 constant value MAX_RETRY to limit the number of keepalives sent when 398 a neighbor has gone unreachable. 400 It is RECOMMENDED that FORWARD_TIME be set to the default constant 401 value 30 seconds to match the default REACHABLE_TIME value specified 402 for IPv6 neighbor discovery [RFC4861]. 404 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 405 value 40 seconds to allow a 10 second window so that the AERO 406 redirection procedure can converge before the ACCEPT_TIME timer 407 decrements below FORWARD_TIME. 409 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 410 for IPv6 neighbor discovery address resolution in Section 7.3.3 of 411 [RFC4861]. 413 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 414 administratively set, if necessary, to better match the AERO link's 415 performance characteristics; however, if different values are chosen, 416 all nodes on the link MUST consistently configure the same values. 417 ACCEPT_TIME SHOULD further be set to a value that is sufficiently 418 longer than FORWARD_TIME to allow the AERO redirection procedure to 419 converge. 421 3.6. AERO Interface MTU Considerations 423 The AERO link Maximum Transmission Unit (MTU) is 64KB minus the 424 encapsulation overhead for IPv4 [RFC0791] and 4GB minus the 425 encapsulation overhead for IPv6 [RFC2675]. This is the most that 426 IPv4 and IPv6 (respectively) can convey within the constraints of 427 protocol constants, but actual sizes available for tunneling will 428 frequently be much smaller. 430 The base tunneling specifications for IPv4 and IPv6 typically set a 431 static MTU on the tunnel interface to 1500 bytes minus the 432 encapsulation overhead or smaller still if the tunnel is likely to 433 incur additional encapsulations such as IPsec on the path. This can 434 result in path MTU related black holes when packets that are too 435 large to be accommodated over the AERO link are dropped, but the 436 resulting ICMP Packet Too Big (PTB) messages are lost on the return 437 path. As a result, AERO nodes use the following MTU mitigations to 438 accommodate larger packets. 440 AERO nodes set their AERO interface MTU to the larger of 1500 bytes 441 and the underlying interface MTU minus the encapsulation overhead. 442 AERO nodes optionally cache other per-neighbor MTU values in the 443 underlying IP path MTU discovery cache initialized to the underlying 444 interface MTU. 446 AERO nodes admit packets that are no larger than 1280 bytes minus the 447 encapsulation overhead (*) as well as packets that are larger than 448 1500 bytes into the tunnel without fragmentation, i.e., as long as 449 they are no larger than the AERO interface MTU before encapsulation 450 and also no larger than the cached per-neighbor MTU following 451 encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit 452 to 0 for packets no larger than 1280 bytes minus the encapsulation 453 overhead (*) and sets the DF bit to 1 for packets larger than 1500 454 bytes. If a large packet is lost in the path, the node may 455 optionally cache the MTU reported in the resulting PTB message or may 456 ignore the message, e.g., if there is a possibility that the message 457 is spurious. 459 For packets destined to an AERO node that are larger than 1280 bytes 460 minus the encapsulation overhead (*) but no larger than 1500 bytes, 461 the node uses outer IP fragmentation to fragment the packet into two 462 pieces (where the first fragment contains 1024 bytes of the 463 fragmented inner packet) then admits the fragments into the tunnel. 464 If the outer protocol is IPv4, the node admits the packet into the 465 tunnel with DF set to 0 and subject to rate limiting to avoid 466 reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the 467 node also sends a 1500 byte probe message (**) to the neighbor, 468 subject to rate limiting. To construct a probe, the node prepares an 469 ICMPv6 Neighbor Solicitation (NS) message with trailing padding 470 octets added to a length of 1500 bytes but does not include the 471 length of the padding in the IPv6 Payload Length field. The node 472 then encapsulates the NS in the outer encapsulation headers (while 473 including the length of the padding in the outer length fields), sets 474 DF to 1 (for IPv4) and sends the padded NS message to the neighbor. 475 If the neighbor returns an NA message, the node may then send whole 476 packets within this size range and (for IPv4) relax the rate limiting 477 requirement. 479 AERO nodes MUST be capable of reassembling packets up to 1500 bytes 480 plus the encapsulation overhead length. It is therefore RECOMMENDED 481 that AERO nodes be capable of reassembling at least 2KB. 483 (*) Note that if it is known that the minimum Path MTU to an AERO 484 node is MINMTU bytes (where 1280 < MINMTU < 1500) then MINMTU can be 485 used instead of 1280 in the fragmentation threshold considerations 486 listed above. 488 (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used 489 for MTU probing purposes, since smaller probes may be fragmented if 490 there is a nested tunnel somewhere on the path to the neighbor. 492 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 494 AERO interfaces encapsulate IPv6 packets according to whether they 495 are entering the AERO interface for the first time or if they are 496 being forwarded out the same AERO interface that they arrived on. 497 This latter form of encapsulation is known as "re-encapsulation". 499 AERO interfaces encapsulate packets per the specifications in , 500 [RFC2473], [RFC4213] except that the interface copies the "TTL/Hop 501 Limit", "Type of Service/Traffic Class" and "Congestion Experienced" 502 values in the inner network layer header into the corresponding 503 fields in the outer IP header. For packets undergoing re- 504 encapsulation, the AERO interface instead copies the "TTL/Hop Limit", 505 "Type of Service/Traffic Class" and "Congestion Experienced" values 506 in the original outer IP header into the corresponding fields in the 507 new outer IP header (i.e., the values are transferred between outer 508 headers and *not* copied from the inner network layer header). 510 When UDP encapsulation is used, the AERO interface inserts a UDP 511 header between the inner packet and outer IP header. If the outer 512 header is IPv6 and is followed by an IPv6 Fragment header, the AERO 513 interface inserts the UDP header between the outer IPv6 header and 514 IPv6 Fragment header. The AERO interface sets the UDP source port to 515 a constant value that it will use in each successive packet it sends, 516 sets the UDP checksum field to zero (see: [RFC6935][RFC6936]) and 517 sets the UDP length field to the length of the inner packet plus 8 518 bytes for the UDP header itself. For packets sent via a Server, the 519 AERO interface sets the UDP destination port to 8060 (i.e., the IANA- 520 registerd port number for AERO). For packets sent to a neighboring 521 Client, the AERO interface sets the UDP destination port to the port 522 value stored in the neighbor cache entry for this neighbor. 524 The AERO interface next sets the outer IP protocol number to the 525 appropriate value for the first protocol layer within the 526 encapsulation (e.g., IPv6, IPv6 Fragment Header, UDP, etc.). When 527 IPv6 is used as the outer IP protocol, the ITE then sets the flow 528 label value in the outer IPv6 header the same as described in 529 [RFC6438]. When IPv4 is used as the outer IP protocol, the AERO 530 interface sets the DF bit as discussed in Section 3.2. 532 AERO interfaces decapsulate packets destined either to the node 533 itself or to a destination reached via an interface other than the 534 receiving AERO interface per the specifications in , [RFC2473], 535 [RFC4213]. When the encapsulated packet includes a UDP header, the 536 AERO interface examines the first octet of data following the UDP 537 header to determine the inner header type. If the most significant 538 four bits of the first octet encode the value '0110', the inner 539 header is an IPv6 header. Otherwise, the interface considers the 540 first octet as an IP protocol type that encodes the value '44' for 541 IPv6 fragment header, the value '50' for Encapsulating Security 542 Payload, the value '51' for Authentication Header etc. (If the first 543 octet encodes the value '0', the interface instead discards the 544 packet, since this is the value reserved for experimentation under , 545 [RFC6706]). During the decapsulation, the AERO interface records the 546 UDP source port in the neighbor cache entry for this neighbor then 547 discards the UDP header. 549 3.8. AERO Reference Operational Scenario 551 Figure 3 depicts the AERO reference operational scenario. The figure 552 shows an AERO Server('A'), two AERO Clients ('B', 'D') and three 553 ordinary IPv6 hosts ('C', 'E', 'F'): 555 .-(::::::::) 556 .-(::: IPv6 :::)-. +-------------+ 557 (:::: Internet ::::)--| Host F | 558 `-(::::::::::::)-' +-------------+ 559 `-(::::::)-' 2001:db8:3::1 560 | 561 +--------------+ 562 | AERO Server A| 563 | (C->B; E->D) | 564 +--------------+ 565 fe80::0 566 L2(A) 567 | 568 X-----+-----------+-----------+--------X 569 | AERO Link | 570 L2(B) L2(D) 571 fe80::2001:db8:0:0 fe80::2001:db8:1:0 .-. 572 +--------------+ +--------------+ ,-( _)-. 573 | AERO Client B| | AERO Client D| .-(_ IPv6 )-. 574 | (default->A) | | (default->A) |--(__ EUN ) 575 +--------------+ +--------------+ `-(______)-' 576 2001:DB8:0::/48 2001:DB8:1::/48 | 577 | 2001:db8:1::1 578 .-. +-------------+ 579 ,-( _)-. 2001:db8:0::1 | Host E | 580 .-(_ IPv6 )-. +-------------+ +-------------+ 581 (__ EUN )--| Host C | 582 `-(______)-' +-------------+ 584 Figure 3: AERO Reference Operational Scenario 586 In Figure 3, AERO Server ('A') connects to the AERO link and connects 587 to the IPv6 Internet, either directly or via an AERO Relay (not 588 shown). Server ('A') assigns the address fe80::0 to its AERO 589 interface with link-layer address L2(A). Server ('A') next arranges 590 to add L2(A) to a published list of valid Servers for the AERO link. 592 AERO Client ('B') registers the IPv6 prefix 2001:db8:0::/48 in a 593 DHCPv6 PD exchange via Server ('A') then assigns the address fe80:: 594 2001:db8:0:0 to its AERO interface with link-layer address L2(B). 595 Client ('B') configures a default route via the AERO interface with 596 next-hop address fe80::0 and link-layer address L2(A), then sub- 597 delegates the prefix 2001:db8:0::/48 to its attached EUNs. IPv6 host 598 ('C') connects to the EUN, and configures the address 2001:db8:0::1. 600 AERO Client ('D') registers the IPv6 prefix 2001:db8:1::/48 in a 601 DHCPv6 PD exchange via Server ('A') then assigns the address fe80:: 602 2001:db8:1:0 to its AERO interface with link-layer address L2(D). 604 Client ('D') configures a default route via the AERO interface with 605 next-hop address fe80::0 and link-layer address L2(A), then sub- 606 delegates the prefix 2001:db8:1::/48 to its attached EUNs. IPv6 host 607 ('E') connects to the EUN, and configures the address 2001:db8:1::1. 609 Finally, IPv6 host ('F') connects to an IPv6 network outside of the 610 AERO link domain. Host ('F') configures its IPv6 interface in a 611 manner specific to its attached IPv6 link, and assigns the address 612 2001:db8:3::1 to its IPv6 link interface. 614 3.9. AERO Router Discovery and Prefix Delegation 616 3.9.1. AERO Client Behavior 618 AERO Clients observe the IPv6 router requirements defined in 619 [RFC6434]. AERO Clients first discover the link-layer address of an 620 AERO Server via static configuration, or through an automated means 621 such as DNS name resolution. In the absence of other information, 622 the Client resolves the Fully-Qualified Domain Name (FQDN) 623 "linkupnetworks.domainname", where "domainname" is the DNS domain 624 appropriate for the Client's attached underlying network. The Client 625 then creates a static neighbor cache entry with fe80::0 as the 626 network-layer address and the discovered address as the link-layer 627 address. The Client further creates a static default IPv6 route with 628 fe80::0 as the next hop address. 630 Next, the Client acts as a requesting router to register its IPv6 631 prefix through DHCPv6 PD [RFC3633] via the Server using fe80::1 as 632 the IPv6 source address and fe80::0 as the IPv6 destination address. 633 The Client further includes a DHCPv6 Unique Identifier (DUID) based 634 on a Universally Unique Identifier (UUID) (also known as DUID-UUID) 635 as described in [RFC6355]. 637 After the Client registers its prefixes, it assigns the link-local 638 AERO address taken from its delegated prefix to the AERO interface 639 (see: Section 3.3) and sub-delegates the prefix to nodes and links 640 within its attached EUNs (the AERO link-local address thereafter 641 remains stable as the Client moves). 643 The Client sends periodic NS messages to the Server to obtain new NAs 644 in order to refresh any network state. The Client can also forward 645 IPv6 packets destined to networks beyond its local EUNs via the 646 Server as an IPv6 default router. The Server may in turn return a 647 Redirect message informing the Client of a neighbor on the AERO link 648 that is topologically closer to the final destination as specified in 649 Section 3.11. 651 3.9.2. AERO Server Behavior 653 AERO Servers observe the IPv6 router requirements defined in 654 [RFC6434]. They further configure a DHCPv6 relay/server function on 655 their AERO links. When the Server facilitates a DHCPv6 PD exchange, 656 it creates a temporary cache entry referenced by the DHCPv6 request's 657 DUID-UUID. After the PD request is satisfied, the Server creates a 658 static neighbor cache entry for the Client's AERO address (see: 659 Section 3.3) and a static IPv6 forwarding table entry that lists the 660 Client's AERO address as the next hop toward the delegated IPv6 661 prefix . The Server also injects the Client's prefix into the 662 routing system as described in IRON [IRON]. 664 Servers respond to NS messages from Clients on their AERO interfaces 665 by returning an NA message. When the Server receives an NS message, 666 it updates the neighbor cache entry using the network layer source 667 address as the neighbor's network layer address and using the link- 668 layer source address of the NS message as the neighbor's link-layer 669 address. 671 When the Server forwards a packet via the same AERO interface on 672 which it arrived, it initiates an AERO route optimization procedure 673 as specified in Section 3.11. 675 3.10. AERO Neighbor Solicitation and Advertisement 677 Each AERO node uses its delegated prefix to create an AERO address 678 (see: Section 3.3). It can then send NS messages to elicit NA 679 messages from other AERO nodes. When the AERO node sends NS/NA 680 messages, however, it must also include the length of the prefix 681 corresponding to the AERO address. AERO NS/NA messages therefore 682 include an 8-bit "Prefix Length" field take from the low-order 8 bits 683 of the Reserved field as shown in Figure 4 and Figure 5. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Type (=135) | Code | Checksum | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Reserved | Prefix Length | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | | 693 + + 694 | | 695 + Target Address + 696 | | 697 + + 698 | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Options ... 701 +-+-+-+-+-+-+-+-+-+-+-+- 703 Figure 4: AERO Neighbor Solicitation (NS) Message Format 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Type (=136) | Code | Checksum | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | R|S|O| Reserved | Prefix Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 + + 714 | | 715 + Target Address + 716 | | 717 + + 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Options ... 721 +-+-+-+-+-+-+-+-+-+-+-+- 723 Figure 5: AERO Neighbor Advertisement (NA) Message Format 725 When an AERO node sends an NS/NA message, it MUST use its AERO 726 address as the IPv6 source address and the AERO address of the 727 neighbor as the IPv6 destination address. It MUST also include its 728 AERO address prefix length in the Prefix Length field. 730 When an AERO node receives an NS/NA message, it accepts the message 731 if the Prefix Length applied to the source address is correct for the 732 neighbor; otherwise, it ignores the message. 734 3.11. AERO Redirection 736 Section 3.8 describes the AERO reference operational scenario. We 737 now discuss the operation and protocol details of AERO Redirection 738 with respect to this reference scenario. 740 3.11.1. Classical Redirection Approaches 742 With reference to Figure 3, when the IPv6 source host ('C') sends a 743 packet to an IPv6 destination host ('E'), the packet is first 744 forwarded via the EUN to AERO Client ('B'). Client ('B') then 745 forwards the packet over its AERO interface to AERO Server ('A'), 746 which then re-encapsulates and forwards the packet to AERO Client 747 ('D'), where the packet is finally forwarded to the IPv6 destination 748 host ('E'). When Server ('A') re-encapsulates and forwards the 749 packet back out on its advertising AERO interface, it must arrange to 750 redirect Client ('B') toward Client ('D') as a better next-hop node 751 on the AERO link that is closer to the final destination. However, 752 this redirection process applied to AERO interfaces must be more 753 carefully orchestrated than on ordinary links since the parties may 754 be separated by potentially many underlying network routing hops. 756 Consider a first alternative in which Server ('A') informs Client 757 ('B') only and does not inform Client ('D') (i.e., "classical 758 redirection"). In that case, Client ('D') has no way of knowing that 759 Client ('B') is authorized to forward packets from the claimed source 760 address, and it may simply elect to drop the packets. Also, Client 761 ('B') has no way of knowing whether Client ('D') is performing some 762 form of source address filtering that would reject packets arriving 763 from a node other than a trusted default router, nor whether Client 764 ('D') is even reachable via a direct path that does not involve 765 Server ('A'). 767 Consider a second alternative in which Server ('A') informs both 768 Client ('B') and Client ('D') separately, via independent redirection 769 control messages (i.e., "augmented redirection"). In that case, if 770 Client ('B') receives the redirection control message but Client 771 ('D') does not, subsequent packets sent by Client ('B') could be 772 dropped due to filtering since Client ('D') would not have a route to 773 verify the claimed source address. Also, if Client ('D') receives 774 the redirection control message but Client ('B') does not, subsequent 775 packets sent in the reverse direction by Client ('D') would be lost. 777 Since both of these alternatives have shortcomings, a new redirection 778 technique (i.e., "AERO redirection") is needed. 780 3.11.2. AERO Redirection Concept of Operations 782 Again, with reference to Figure 3, when source host ('C') sends a 783 packet to destination host ('E'), the packet is first forwarded over 784 the source host's attached EUN to Client ('B'), which then forwards 785 the packet via its AERO interface to Server ('A'). 787 Server ('A') then re-encapsulates and forwards the packet out the 788 same AERO interface toward Client ('D') and also sends an AERO 789 "Predirect" message forward to Client ('D') as specified in 790 Section 3.11.4. The Predirect message includes Client ('B')'s 791 network- and link-layer addresses as well as information that Client 792 ('D') can use to determine the IPv6 prefix used by Client ('B') . 793 After Client ('D') receives the Predirect message, it process the 794 message and returns an AERO Redirect message destined for Client 795 ('B') via Server ('A') as specified in Section 3.11.5. During the 796 process, Client ('D') also creates or updates a dynamic neighbor 797 cache entry for Client ('B'), and creates an IPv6 route for Client 798 ('B')'s IPv6 prefix. 800 When Server ('A') receives the Redirect message, it re-encapsulates 801 the message and forwards it on to Client ('B') as specified in 802 Section 3.11.6. The message includes Client ('D')'s network- and 803 link-layer addresses as well as information that Client ('B') can use 804 to determine the IPv6 prefix used by Client ('D'). After Client 805 ('B') receives the Redirect message, it processes the message as 806 specified in Section 3.11.7. During the process, Client ('B') also 807 creates or updates a dynamic neighbor cache entry for Client ('D'), 808 and creates an IPv6 route for Client ('D')'s IPv6 prefix. 810 Following the above Predirect/Redirect message exchange, forwarding 811 of packets from Client ('B') to Client ('D') without involving Server 812 ('A) as an intermediary is enabled. The mechanisms that support this 813 exchange are specified in the following sections. 815 3.11.3. AERO Redirection Message Format 817 AERO Redirect/Predirect messages use the same format as for ICMPv6 818 Redirect messages depicted in Section 4.5 of [RFC4861], but also 819 include a new "Prefix Length" field taken from the low-order 8 bits 820 of the Redirect message Reserved field. The Redirect/Predirect 821 messages are formatted as shown in Figure 6: 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type (=137) | Code (=0/1) | Checksum | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Reserved | Prefix Length | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | | 831 + + 832 | | 833 + Target Address + 834 | | 835 + + 836 | | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | | 839 + + 840 | | 841 + Destination Address + 842 | | 843 + + 844 | | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Options ... 847 +-+-+-+-+-+-+-+-+-+-+-+- 849 Figure 6: AERO Redirect/Predirect Message Format 851 3.11.4. Sending Predirects 853 When an AERO Server forwards a packet out the same AERO interface 854 that it arrived on, the Server sends a Predirect message forward 855 toward the AERO Client nearest the destination instead of sending a 856 Redirect message back to AERO Client nearest the source. 858 In the reference operational scenario, when Server ('A') forwards a 859 packet sent by Client ('B') toward Client ('D'), it also sends a 860 Predirect message forward toward Client ('D'), subject to rate 861 limiting (see Section 8.2 of [RFC4861]). Server ('A') prepares the 862 Predirect message as follows: 864 o the link-layer source address is set to 'L2(A)' (i.e., the 865 underlying address of Server ('A')). 867 o the link-layer destination address is set to 'L2(D)' (i.e., the 868 underlying address of Client ('D')). 870 o the network-layer source address is set to fe80::0 (i.e., the 871 link-local address of Server ('A')). 873 o the network-layer destination address is set to fe80::2001:db8:1:0 874 (i.e., the AERO address of Client ('D')). 876 o the Type is set to 137. 878 o the Code is set to 1 to indicate "Predirect". 880 o the Prefix Length is set to the length of the prefix to be applied 881 to Target address. 883 o the Target Address is set to fe80::2001:db8:0::0 (i.e., the AERO 884 address of Client ('B')). 886 o the Destination Address is set to the IPv6 source address of the 887 packet that triggered the Predirection event. 889 o the message includes a TLLAO set to 'L2(B)' (i.e., the underlying 890 address of Client ('B')). 892 o the message includes a Redirected Header Option (RHO) that 893 contains the originating packet truncated to ensure that at least 894 the network-layer header is included but the size of the message 895 does not exceed 1280 bytes. 897 Server ('A') then sends the message forward to Client ('D'). 899 3.11.5. Processing Predirects and Sending Redirects 901 When Client ('D') receives a Predirect message, it accepts the 902 message only if it has a link-layer source address of the Server, 903 i.e. 'L2(A)'. Client ('D') further accepts the message only if it 904 is willing to serve as a redirection target. Next, Client ('D') 905 validates the message according to the ICMPv6 Redirect message 906 validation rules in Section 8.1 of [RFC4861]. 908 In the reference operational scenario, when the Client ('D') receives 909 a valid Predirect message, it either creates or updates a dynamic 910 neighbor cache entry that stores the Target Address of the message as 911 the network-layer address of Client ('B') and stores the link-layer 912 address found in the TLLAO as the link-layer address of Client ('B'). 913 Client ('D') then applies the Prefix Length to the Interface 914 Identifier portion of the Target Address and records the resulting 915 IPv6 prefix in its IPv6 forwarding table. 917 After processing the message, Client ('D') prepares a Redirect 918 message response as follows: 920 o the link-layer source address is set to 'L2(D)' (i.e., the link- 921 layer address of Client ('D')). 923 o the link-layer destination address is set to 'L2(A)' (i.e., the 924 link-layer address of Server ('A')). 926 o the network-layer source address is set to 'L3(D)' (i.e., the AERO 927 address of Client ('D')). 929 o the network-layer destination address is set to 'L3(B)' (i.e., the 930 AERO address of Client ('B')). 932 o the Type is set to 137. 934 o the Code is set to 0 to indicate "Redirect". 936 o the Prefix Length is set to the length of the prefix to be applied 937 to the Target and Destination address. 939 o the Target Address is set to fe80::2001:db8:1::1 (i.e., the AERO 940 address of Client ('D')). 942 o the Destination Address is set to the IPv6 destination address of 943 the packet that triggered the Redirection event. 945 o the message includes a TLLAO set to 'L2(D)' (i.e., the underlying 946 address of Client ('D')). 948 o the message includes as much of the RHO copied from the 949 corresponding AERO Predirect message as possible such that at 950 least the network-layer header is included but the size of the 951 message does not exceed 1280 bytes. 953 After Client ('D') prepares the Redirect message, it sends the 954 message to Server ('A'). 956 3.11.6. Re-encapsulating and Relaying Redirects 958 When Server ('A') receives a Redirect message, it accepts the message 959 only if it has a neighbor cache entry that associates the message's 960 link-layer source address with the network-layer source address. 961 Next, Server ('A') validates the message according to the ICMPv6 962 Redirect message validation rules in Section 8.1 of [RFC4861]. 963 Following validation, Server ('A') re-encapsulates the Redirect then 964 relays the re-encapsulated Redirect on to Client ('B') as follows. 966 In the reference operational scenario, Server ('A') receives the 967 Redirect message from Client ('D') and prepares to re-encapsulate and 968 forward the message to Client ('B'). Server ('A') first verifies 969 that Client ('D') is authorized to use the Prefix Length in the 970 Redirect message when applied to the AERO address in the network- 971 layer source of the Redirect message, and discards the message if 972 verification fails. Otherwise, Server ('A') re-encapsulates the 973 message by changing the link-layer source address of the message to 974 'L2(A)', changing the network-layer source address of the message to 975 fe80::0, and changing the link-layer destination address to 'L2(B)' . 976 Server ('A') finally relays the re-encapsulated message to the 977 ingress node ('B') without decrementing the network-layer IPv6 header 978 Hop Limit field. 980 While not shown in Figure 3, AERO Relays relay Redirect and Predirect 981 messages in exactly this same fashion described above. See Figure 7 982 in Appendix A for an extension of the reference operational scenario 983 that includes Relays. 985 3.11.7. Processing Redirects 987 When Client ('B') receives the Redirect message, it accepts the 988 message only if it has a link-layer source address of the Server, 989 i.e. 'L2(A)'. Next, Client ('B') validates the message according to 990 the ICMPv6 Redirect message validation rules in Section 8.1 of 991 [RFC4861]. Following validation, Client ('B') then processes the 992 message as follows. 994 In the reference operational scenario, when Client ('B') receives the 995 Redirect message, it either creates or updates a dynamic neighbor 996 cache entry that stores the Target Address of the message as the 997 network-layer address of Client ('D') and stores the link-layer 998 address found in the TLLAO as the link-layer address of Client ('D'). 999 Client ('B') then applies the Prefix Length to the Interface 1000 Identifier portion of the Target Address and records the resulting 1001 IPv6 prefix in its IPv6 forwarding table. 1003 Now, Client ('B') has an IPv6 forwarding table entry for 1004 Client('D')'s prefix, and Client ('D') has an IPv6 forwarding table 1005 entry for Client ('B')'s prefix. Thereafter, the clients may 1006 exchange ordinary network-layer data packets directly without 1007 forwarding through Server ('A'). 1009 3.12. Neighbor Reachability Maintenance 1011 When a source Client is redirected to a target Client it MUST test 1012 the direct path to the target by sending an initial NS message to 1013 elicit a solicited NA response. While testing the path, the source 1014 Client SHOULD continue sending packets via the Server until target 1015 Client reachability has been confirmed. The source Client MUST 1016 thereafter continue to test the direct path to the target Client 1017 using Neighbor Unreachability Detection (NUD) (see Section 7.3 of 1018 [RFC4861]) in order to keep dynamic neighbor cache entries alive. In 1019 particular, the source Client sends NS messages to the target Client 1020 subject to rate limiting in order to receive solicited NA messages. 1021 If at any time the direct path appears to be failing, the source 1022 Client can resume sending packets via the Server which may or may not 1023 result in a new redirection event. 1025 When a target Client receives an NS message from a source Client, it 1026 resets the ACCEPT_TIME timer if a neighbor cache entry exists; 1027 otherwise, it discards the NS message. 1029 When a source Client receives a solicited NA message form a target 1030 Client, it resets the FORWARD_TIME timer if a neighbor cache entry 1031 exists; otherwise, it discards the NA message. 1033 When both the FORWARD_TIME and ACCEPT_TIME timers on a dynamic 1034 neighbor cache entry expire, the Client deletes both the neighbor 1035 cache entry and the corresponding IPv6 route. 1037 If the source Client is unable to elicit an NA response from the 1038 target Client after MAX_RETRY attempts, it SHOULD consider the direct 1039 path unusable for forwarding purposes. Otherwise, the source Client 1040 may continue to send packets directly to the target Client and SHOULD 1041 thereafter process any link-layer errors as a hint that the direct 1042 path to the target Client has either failed or has become 1043 intermittent. 1045 3.13. Mobility and Link-Layer Address Change Considerations 1047 When a Client needs to change its link-layer address (e.g., due to a 1048 mobility event, due to a change in underlying network interface, 1049 etc.), it sends an immediate NS message forward to any of its 1050 correspondents (including the Server and any other Clients) which 1051 then discover the new link-layer address. 1053 If two Clients change their link-layer addresses simultaneously, the 1054 NS/NA messages may be lost. In that case, the Clients SHOULD delete 1055 their respective dynamic neighbor cache entries and IPv6 routes, and 1056 allow packets to again flow through their Server(s) which MAY result 1057 in a new AERO redirection exchange. 1059 When a Client needs to change to a new Server, it changes the link- 1060 layer address of the neighbor cache entry for fe80::0 to the address 1061 of the new Server and performs a DHCPv6 PD exchange via the new 1062 Server. After the prefix delegation is satisfied, the Client then 1063 sends a terminating NS message (format TBD) to the old Server, which 1064 in turn deletes its neighbor cache entry and IPv6 route for the 1065 Client and withdraws the IPv6 route from the routing system. 1067 3.14. Underlying Protocol Version Considerations 1069 A source Client may connect only to an IPvX underlying network, while 1070 the target Client connects only to an IPvY underlying network. In 1071 that case, the source Client has no means for reaching the target 1072 directly (since they connect to underlying networks of different IP 1073 protocol versions) and so must ignore any Redirects and continue to 1074 send packets via the Server. 1076 3.15. Multicast Considerations 1078 When the underlying network does not support multicast, AERO nodes 1079 map IPv6 link-scoped multicast addresses (including 1080 "All_DHCP_Relay_Agents_and_Servers") to the underlying IP address of 1081 the AERO Server. 1083 When the underlying network supports multicast, AERO nodes use the 1084 multicast address mapping specification found in [RFC2529] for IPv4 1085 underlying networks and use a direct multicast mapping for IPv6 1086 underlying networks. (In the latter case, "direct multicast mapping" 1087 means that if the IPv6 multicast destination address of the inner 1088 packet is "M", then the IPv6 multicast destination address of the 1089 encapsulating header is also "M".) 1091 3.16. Operation on Server-less AERO Links 1093 In some AERO link scenarios, there may be no Server on the link 1094 and/or no need for Clients to use a Server as an intermediary trust 1095 anchor. In that case, Clients can establish dynamic neighbor cache 1096 entries and IPv6 routes by performing direct Client-to-Client 1097 exchanges, and some other form of trust basis must be applied so that 1098 each Client can verify that the prospective neighbor is authorized to 1099 use its claimed prefix. 1101 When there is no Server on the link, Clients must arrange to receive 1102 prefix delegations and publish the delegations via a secure prefix 1103 discovery service through some means outside the scope of this 1104 document. 1106 3.17. Other Considerations 1108 IPv6 hosts serviced by an AERO Client can reach IPv4-only services 1109 via a NAT64 gateway [RFC6146] within the IPv6 network. 1111 AERO nodes can use the Default Address Selection Policy with DHCPv6 1112 option [RFC7078] the same as on any IPv6 link. 1114 All other (non-multicast) functions that operate over ordinary IPv6 1115 links operate in the same fashion over AERO links. 1117 4. Implementation Status 1119 An early implementation is available at: 1120 http://linkupnetworks.com/aero/aerov2-0.1.tgz. 1122 5. IANA Considerations 1124 This document uses the UDP Service Port Number 8060 reserved by IANA 1125 for AERO in [RFC6706]. Therefore, there are no new IANA actions 1126 required for this document. 1128 6. Security Considerations 1130 AERO link security considerations are the same as for standard IPv6 1131 Neighbor Discovery [RFC4861] except that AERO improves on some 1132 aspects. In particular, AERO is dependent on a trust basis between 1133 AERO Clients and Servers, where the Clients only engage in the AERO 1134 mechanism when it is facilitated by a trust anchor. 1136 AERO links must be protected against link-layer address spoofing 1137 attacks in which an attacker on the link pretends to be a trusted 1138 neighbor. Links that provide link-layer securing mechanisms (e.g., 1139 WiFi networks) and links that provide physical security (e.g., 1140 enterprise network LANs) provide a first line of defense that is 1141 often sufficient. In other instances, securing mechanisms such as 1142 Secure Neighbor Discovery (SeND) [RFC3971] or IPsec [RFC4301] may be 1143 necessary. 1145 AERO Clients MUST ensure that their connectivity is not used by 1146 unauthorized nodes to gain access to a protected network. (This 1147 concern is no different than for ordinary hosts that receive an IP 1148 address delegation but then "share" the address with unauthorized 1149 nodes via an IPv6/IPv6 NAT function.) 1151 On some AERO links, establishment and maintenance of a direct path 1152 between neighbors requires secured coordination such as through the 1153 Internet Key Exchange (IKEv2) protocol [RFC5996]. 1155 7. Acknowledgements 1157 Discussions both on the v6ops list and in private exchanges helped 1158 shape some of the concepts in this work. Individuals who contributed 1159 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1160 Brian Carpenter, Brian Haberman, Joel Halpern, Sascha Hlusiak, Lee 1161 Howard and Joe Touch. Members of the IESG also provided valuable 1162 input during their review process that greatly improved the document. 1163 Special thanks go to Stewart Bryant, Joel Halpern and Brian Haberman 1164 for their shepherding guidance. 1166 This work has further been encouraged and supported by Boeing 1167 colleagues including Keith Bartley, Balaguruna Chidambaram, Jeff 1168 Holland, Cam Brodie, Yueli Yang, Wen Fang, Ed King, Mike Slane, Kent 1169 Shuey, Gen MacLean, and other members of the BR&T and BIT mobile 1170 networking teams. 1172 Earlier works on NBMA tunneling approaches are found in 1173 [RFC2529][RFC5214][RFC5569]. 1175 8. References 1177 8.1. Normative References 1179 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1180 August 1980. 1182 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1183 September 1981. 1185 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1186 RFC 792, September 1981. 1188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1189 Requirement Levels", BCP 14, RFC 2119, March 1997. 1191 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1192 (IPv6) Specification", RFC 2460, December 1998. 1194 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1195 IPv6 Specification", RFC 2473, December 1998. 1197 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1198 and M. Carney, "Dynamic Host Configuration Protocol for 1199 IPv6 (DHCPv6)", RFC 3315, July 2003. 1201 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1202 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1203 December 2003. 1205 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1206 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1208 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1209 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1210 September 2007. 1212 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1213 Address Autoconfiguration", RFC 4862, September 2007. 1215 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 1216 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 1217 August 2011. 1219 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1220 Requirements", RFC 6434, December 2011. 1222 8.2. Informative References 1224 [IRON] Templin, F., "The Internet Routing Overlay Network 1225 (IRON)", Work in Progress, June 2012. 1227 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1228 RFC 879, November 1983. 1230 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1231 Domains without Explicit Tunnels", RFC 2529, March 1999. 1233 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1234 RFC 2675, August 1999. 1236 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1237 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1239 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1240 Internet Protocol", RFC 4301, December 2005. 1242 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1243 Discovery", RFC 4821, March 2007. 1245 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1246 Errors at High Data Rates", RFC 4963, July 2007. 1248 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1249 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1250 March 2008. 1252 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1253 Infrastructures (6rd)", RFC 5569, January 2010. 1255 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1256 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1257 RFC 5996, September 2010. 1259 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1260 NAT64: Network Address and Protocol Translation from IPv6 1261 Clients to IPv4 Servers", RFC 6146, April 2011. 1263 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1264 Troan, "Basic Requirements for IPv6 Customer Edge 1265 Routers", RFC 6204, April 2011. 1267 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1268 for Equal Cost Multipath Routing and Link Aggregation in 1269 Tunnels", RFC 6438, November 2011. 1271 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1272 RFC 6691, July 2012. 1274 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1275 (AERO)", RFC 6706, August 2012. 1277 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1278 RFC 6864, February 2013. 1280 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1281 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1283 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1284 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1285 RFC 6936, April 2013. 1287 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1288 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1290 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 1291 Address Selection Policy Using DHCPv6", RFC 7078, 1292 January 2014. 1294 Appendix A. AERO Server and Relay Interworking 1296 Figure 3 depicts a reference AERO operational scenario with a single 1297 Server on the AERO link. In order to support scaling to larger 1298 numbers of nodes, the AERO link can deploy multiple Servers and 1299 Relays, e.g., as shown in Figure 7. 1301 .-(::::::::) 1302 .-(::: IPv6 :::)-. 1303 (:: Internetwork ::) 1304 `-(::::::::::::)-' 1305 `-(::::::)-' 1306 | 1307 +--------------+ +------+-------+ +--------------+ 1308 |AERO Server C | | AERO Relay D | |AERO Server E | 1309 | (default->D) | | (A->C; G->E) | | (default->D) | 1310 | (A->B) | +-------+------+ | (G->F) | 1311 +-------+------+ | +------+-------+ 1312 | | | 1313 X---+---+-------------------+------------------+---+---X 1314 | AERO Link | 1315 +-----+--------+ +--------+-----+ 1316 |AERO Client B | |AERO Client F | 1317 | (default->C) | | (default->E) | 1318 +--------------+ +--------------+ 1319 .-. .-. 1320 ,-( _)-. ,-( _)-. 1321 .-(_ IPv6 )-. .-(_ IPv6 )-. 1322 (__ EUN ) (__ EUN ) 1323 `-(______)-' `-(______)-' 1324 | | 1325 +--------+ +--------+ 1326 | Host A | | Host G | 1327 +--------+ +--------+ 1329 Figure 7: AERO Server/Relay Interworking 1331 In this example, AERO Client ('B') associates with AERO Server ('C'), 1332 while AERO Client ('F') associates with AERO Server ('E'). 1333 Furthermore, AERO Servers ('C') and ('E') do not associate with each 1334 other directly, but rather have an association with AERO Relay ('D') 1335 (i.e., a router that has full topology information concerning its 1336 associated Servers and their Clients). Relay ('D') connects to the 1337 AERO link, and also connects to the native IPv6 Internetwork. 1339 When host ('A') sends a packet toward destination host ('G'), IPv6 1340 forwarding directs the packet through the EUN to Client ('B'), which 1341 forwards the packet to Server ('C') in absence of more-specific 1342 forwarding information. Server ('C') forwards the packet, and it 1343 also generates an AERO Predirect message that is then forwarded 1344 through Relay ('D') to Server ('E'). When Server ('E') receives the 1345 message, it forwards the message to Client ('F'). 1347 After processing the AERO Predirect message, Client ('F') sends an 1348 AERO Redirect message to Server ('E'). Server ('E'), in turn, 1349 forwards the message through Relay ('D') to Server ('C'). When 1350 Server ('C') receives the message, it forwards the message to Client 1351 ('B') informing it that host 'G's EUN can be reached via Client 1352 ('F'), thus completing the AERO redirection. 1354 The network layer routing information shared between Servers and 1355 Relays must be carefully coordinated in a manner outside the scope of 1356 this document. In particular, Relays require full topology 1357 information, while individual Servers only require partial topology 1358 information (i.e., they only need to know the EUN prefixes associated 1359 with their current set of Clients). See [IRON] for an architectural 1360 discussion of routing coordination between Relays and Servers. 1362 Author's Address 1364 Fred L. Templin (editor) 1365 Boeing Research & Technology 1366 P.O. Box 3707 1367 Seattle, WA 98124 1368 USA 1370 Email: fltemplin@acm.org