idnits 2.17.1 draft-templin-aerolink-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 16, 2014) is 3626 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 1227, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1233, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1239, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1260, but no explicit reference was found in the text == Unused Reference: 'RFC0879' is defined on line 1271, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 1289, but no explicit reference was found in the text == Unused Reference: 'RFC6204' is defined on line 1326, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: 'RFC6706' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: 'RFC6980' is defined on line 1357, 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 (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: rfc6706 (if approved) May 16, 2014 5 Intended status: Standards Track 6 Expires: November 17, 2014 8 Transmission of IPv6 Packets over AERO Links 9 draft-templin-aerolink-20.txt 11 Abstract 13 This document specifies the operation of IPv6 over tunnel virtual 14 Non-Broadcast, Multiple Access (NBMA) links using Asymmetric Extended 15 Route Optimization (AERO). Nodes attached to AERO links can exchange 16 packets via trusted intermediate routers on the link that provide 17 forwarding services to reach off-link destinations and/or redirection 18 services to inform the node of an on-link neighbor that is closer to 19 the final destination. Operation of the IPv6 Neighbor Discovery (ND) 20 protocol over AERO links is based on an IPv6 link local address 21 format known as the AERO address. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 17, 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 Addresses . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. AERO Interface Characteristics . . . . . . . . . . . . . . 7 63 3.4. AERO Interface Data Origin Authentication . . . . . . . . 10 64 3.5. AERO Interface Conceptual Data Structures and Protocol 65 Constants . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.6. AERO Interface MTU Considerations . . . . . . . . . . . . 11 67 3.7. AERO Interface Encapsulation, Re-encapsulation and 68 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 13 69 3.8. AERO Reference Operational Scenario . . . . . . . . . . . 14 70 3.9. AERO Router Discovery, Prefix Delegation and Address 71 Configuration . . . . . . . . . . . . . . . . . . . . . . 15 72 3.9.1. AERO Client Behavior . . . . . . . . . . . . . . . . . 15 73 3.9.2. AERO Server Behavior . . . . . . . . . . . . . . . . . 16 74 3.10. AERO Redirection . . . . . . . . . . . . . . . . . . . . . 18 75 3.10.1. Classical Redirection Approaches . . . . . . . . . . . 18 76 3.10.2. AERO Redirection Concept of Operations . . . . . . . . 19 77 3.10.3. AERO Redirection Message Format . . . . . . . . . . . 19 78 3.10.4. Sending Predirects . . . . . . . . . . . . . . . . . . 20 79 3.10.5. Processing Predirects and Sending Redirects . . . . . 21 80 3.10.6. Re-encapsulating and Relaying Redirects . . . . . . . 22 81 3.10.7. Processing Redirects . . . . . . . . . . . . . . . . . 23 82 3.11. Neighbor Reachability Maintenance . . . . . . . . . . . . 23 83 3.12. Mobility and Link-Layer Address Change Considerations . . 24 84 3.13. Underlying Protocol Version Considerations . . . . . . . . 25 85 3.14. Multicast Considerations . . . . . . . . . . . . . . . . . 25 86 3.15. Operation on Server-less AERO Links . . . . . . . . . . . 26 87 3.16. Other Considerations . . . . . . . . . . . . . . . . . . . 26 88 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 95 Appendix A. AERO Server and Relay Interworking . . . . . . . . . 31 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 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. This redirection provides a route 107 optimization capability that addresses the requirements outlined in 108 [RFC5522]. 110 Nodes on AERO links use an IPv6 link-local address format known as 111 the AERO Address. This address type has properties that statelessly 112 link IPv6 Neighbor Discovery (ND) to IPv6 routing. The AERO link can 113 be used for tunneling to neighboring nodes on either IPv6 or IPv4 114 networks, i.e., AERO views the IPv6 and IPv4 networks as equivalent 115 links for tunneling. The remainder of this document presents the 116 AERO specification. 118 2. Terminology 120 The terminology in the normative references applies; the following 121 terms are defined within the scope of this document: 123 AERO link 124 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 125 configured over a node's attached IPv6 and/or IPv4 networks. All 126 nodes on the AERO link appear as single-hop neighbors from the 127 perspective of IPv6. 129 AERO interface 130 a node's attachment to an AERO link. The AERO interface Maximum 131 Transmission Unit (MTU) is less than or equal to the AERO link 132 MTU. 134 AERO address 135 an IPv6 link-local address assigned to an AERO interface and 136 constructed as specified in Section 3.6. 138 AERO node 139 a node that is connected to an AERO link and that participates in 140 IPv6 Neighbor Discovery over the link. 142 AERO Client ("client") 143 a node that configures either a host interface or a router 144 interface on an AERO link. 146 AERO Server ("server") 147 a node that configures a router interface on an AERO link over 148 which it can provide default forwarding and redirection services 149 for other AERO nodes. 151 AERO Relay ("relay") 152 a node that relays IPv6 packets between Servers on the same AERO 153 link, and/or that forwards IPv6 packets between the AERO link and 154 the IPv6 Internet. An AERO Relay may or may not also be 155 configured as an AERO Server. 157 ingress tunnel endpoint (ITE) 158 an AERO interface endpoint that injects tunneled packets into an 159 AERO link. 161 egress tunnel endpoint (ETE) 162 an AERO interface endpoint that receives tunneled packets from an 163 AERO link. 165 underlying network 166 a connected IPv6 or IPv4 network routing region over which AERO 167 nodes tunnel IPv6 packets. 169 underlying interface 170 an AERO node's interface point of attachment to an underlying 171 network. 173 underlying address 174 an IP address assigned to an AERO node's underlying interface. 175 When UDP encapsulation is used, the UDP port number is also 176 considered as part of the underlying address. Underlying 177 addresses are used as the source and destination addresses of the 178 AERO encapsulation header. 180 link-layer address 181 the same as defined for "underlying address" above, and formed 182 from the concatenation of the UDP port number and underlying 183 address as specified in Section 3.3. 185 network layer address 186 an IPv6 address used as the source or destination address of the 187 inner IPv6 packet header. 189 end user network (EUN) 190 an IPv6 network attached to a downstream interface of an AERO 191 Client (where the AERO interface is seen as the upstream 192 interface). 194 Throughout the document, the simple terms "Server" and "Relay" refer 195 to "AERO Server" and "AERO Relay", respectively. Capitalization is 196 used to distinguish these terms from DHCPv6 server and DHCPv6 relay. 197 This is an important distinction, since an AERO Server may be a 198 DHCPv6 relay, and an AERO Relay may be a DHCPv6 server. 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 3. Asymmetric Extended Route Optimization (AERO) 206 The following sections specify the operation of IPv6 over Asymmetric 207 Extended Route Optimization (AERO) links: 209 3.1. AERO Node Types 211 AERO Relays relay packets between nodes connected to the same AERO 212 link and also forward packets between the AERO link and the native 213 IPv6 network. The relaying process entails re-encapsulation of IPv6 214 packets that were received from a first AERO node and are to be 215 forwarded without modification to a second AERO node. 217 AERO Servers configure their AERO interfaces as router interfaces, 218 and provide default routing services to AERO Clients. AERO Servers 219 configure a DHCPv6 relay or server function and facilitate DHCPv6 220 Prefix Delegation (PD) exchanges. An AERO Server may also act as an 221 AERO Relay. 223 AERO Clients act as requesting routers to receive IPv6 prefixes 224 through a DHCPv6 PD exchange via an AERO Server over the AERO link. 225 (In Server-less environments an alternate AERO link prefix delegation 226 authority may be necessary, but out of scope for this document.) 227 Each AERO Client receives at least a /64 prefix delegation, and may 228 receive even shorter prefixes. 230 AERO Clients that act as routers configure their AERO interfaces as 231 router interfaces and sub-delegate portions of their received prefix 232 delegations to links on EUNs. 234 AERO Clients that act as ordinary hosts configure their AERO 235 interfaces as host interfaces and assign one or more IPv6 addresses 236 taken from their received prefix delegations to the AERO interface 237 but DO NOT assign the delegated prefix itself to the AERO interface. 238 Instead, the host assigns the delegated prefix to a "black hole" 239 route so that unused portions of the prefix are nullified. 241 End system applications on AERO hosts bind directly to the AERO 242 interface, while applications on AERO routers (or IPv6 hosts served 243 by an AERO router) bind to EUN interfaces. 245 3.2. AERO Addresses 247 An AERO address is an IPv6 link-local address assigned to an AERO 248 interface and with an IPv6 prefix embedded within the interface 249 identifier. The AERO address is formatted as: 251 fe80::[IPv6 prefix] 253 Each AERO Client configures an AERO address based on the prefix it 254 has received from the AERO link prefix delegation authority (e.g., 255 the DHCPv6 server). The address begins with the prefix fe80::/64 and 256 includes in its interface identifier the base /64 prefix taken from 257 the Client's delegated IPv6 prefix. The base prefix is determined by 258 masking the delegated prefix with the prefix length. For example, if 259 an AERO Client has received the prefix delegation: 261 2001:db8:1000:2000::/56 263 it would construct its AERO address as: 265 fe80::2001:db8:1000:2000 267 The AERO address remains stable as the Client moves between 268 topological locations, i.e., even if its underlying address changes. 270 3.3. AERO Interface Characteristics 272 AERO interfaces use IPv6-in-IPv6 encapsulation [RFC2473] to exchange 273 tunneled packets with AERO neighbors attached to an underlying IPv6 274 network, and use IPv6-in-IPv4 encapsulation [RFC4213] to exchange 275 tunneled packets with AERO neighbors attached to an underlying IPv4 276 network. AERO interfaces can also use secured tunnel types such as 277 IPsec [RFC4301] or TLS [RFC5246] in environments where strong 278 authentication and confidentiality are required. When NAT traversal 279 and/or filtering middlebox traversal is necessary, a UDP header is 280 further inserted immediately above the outer IP encapsulation header. 282 Servers assign the link-local address 'fe80::0' to their AERO 283 interface; this provides a handle for Clients to insert into a 284 neighbor cache entry for their current Server. Servers and Relays 285 also configure administratively-assigned link-local addresses on 286 their AERO interfaces to support the operation of the inter-Server/ 287 Relay routing system (see: [IRON]). 289 Clients initially use a "temporary" IPv6 link-local address in the 290 DHCPv6 PD exchanges used to receive an IPv6 prefix and derive an AERO 291 address. If the Client is pre-provisioned with an IPv6 prefix 292 associated with the AERO service, it SHOULD use the AERO address 293 derived from the prefix as the temporary address. Otherwise, the 294 Client SHOULD use "fe80::1" as the temporary address since this 295 address will not conflict with any valid AERO addresses and will thus 296 not be used in any AERO neighbor discovery messaging. After the 297 Client receives a prefix delegation, it assigns the corresponding 298 AERO address to the AERO interface. DHCPv6 is therefore used to 299 bootstrap the assignment of link-local addresses on the AERO link. 301 AERO interfaces maintain a neighbor cache and use an augmentation of 302 standard unicast IPv6 ND messaging. AERO interfaces use Redirect, 303 Neighbor Solicitation (NS) and Neighbor Advertisement (NA) Router 304 Solicitation (RS) and Router Advertisement (RA) messages the same as 305 for any IPv6 link. Finally, AERO links use link-local-only 306 addressing; hence, Clients MUST ignore any Prefix Information Options 307 (PIOs) they may receive in RA messages. 309 AERO Redirect messages include a TLLAO the same as for any IPv6 link. 310 The TLLAO includes the link-layer address for the target node, which 311 is formed from the concatenation of the 2-octet UDP port number used 312 by the target when it sends UDP-encapsulated packets over the AERO 313 interface (or 0 when the target does not use UDP encapsulation) 314 followed by the 16-octet IP address. The TLLAO format is shown in 315 Figure 1: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type = 2 | Length = 3 | Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Reserved | UDP Port Number (or 0) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 +-- --+ 326 | | 327 +-- IP Address --+ 328 | | 329 +-- --+ 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 1: AERO TLLAO Format for IPv6 335 (Note that in the above TLLAO format, the IP address is formed as an 336 IPv4-compatible IPv6 address (see: [RFC4291]) when the encapsulation 337 IP address family is IPv4. Note also that more than one TLLAO option 338 may appear in a Redirect message, e.g., if the target node has 339 multiple link-layer addresses.) 341 AERO NS, NA, RS and RA messages do not include Source/Target Link 342 Layer Address Options (S/TLLAOs). Instead, AERO nodes determine the 343 link-layer addresses of neighbors by examining the link-layer source 344 address of any NS/NA/RS/RA messages they receive and ignore any 345 S/TLLAOs included in these messages. This is vital to the operation 346 of AERO links for which neighbors are separated by Network Address 347 Translators (NATs) (either IPv4 or IPv6) since the source may have no 348 way of knowing what its translated address will be and hence may not 349 be able to supply the correct values in a S/TLLAO. 351 Finally, AERO interface NS/NA messages only update existing neighbor 352 cache entires and do not create new neighbor cache entries, whereas 353 Redirect, RS and RA messages both update and create neighbor cache 354 entries. This represents a departure from the normal operation of 355 IPv6 ND over common link types, but is consistent with the spirit of 356 IPv6 over NBMA links as discussed in [RFC4861]. Note however that 357 this restriction may be relaxed and/or redefined on AERO links that 358 participate in a fully distributed mobility management model (i.e., a 359 "Client-only" AERO link) coordinated in a manner outside the scope of 360 this document. 362 3.4. AERO Interface Data Origin Authentication 364 Nodes on AERO interfaces use a simple data origin authentication for 365 encapsulated packets they receive from other nodes. In particular, 366 AERO Clients accept encapsulated packets with a link-layer source 367 address belonging to their current AERO Server. AERO nodes also 368 accept encapsulated packets with a link-layer source address that is 369 correct for the network-layer source address. 371 The AERO node considers the link-layer source address correct for the 372 network-layer source address if there is an IPv6 forwarding table 373 entry that matches the network-layer source address as well as a 374 neighbor cache entry corresponding to the next hop that includes the 375 link-layer address. An exception is that neighbor discovery messages 376 may include a different link-layer address than the one currently in 377 the neighbor cache, and the new link-layer address updates the 378 neighbor cache entry. 380 3.5. AERO Interface Conceptual Data Structures and Protocol Constants 382 Each AERO node maintains a per-AERO interface conceptual neighbor 383 cache that includes an entry for each neighbor it communicates with 384 on the AERO link, the same as for any IPv6 interface (see [RFC4861]). 385 Neighbor cache entries are created and maintained as follows: 387 When an AERO Server relays a DHCPv6 Reply message to an AERO Client, 388 it creates or updates a neighbor cache entry for the Client based on 389 the information in the IA-PD option. 391 When an AERO node receives a valid RS/RA message, it creates or 392 updates a neighbor cache entry the same as described in [RFC4861]. 394 When an AERO Client receives a valid Predirect message (See Section 395 3.10.5) it creates or updates a neighbor cache entry for the 396 Predirect target L3 and L2 addresses, and also creates an IPv6 397 forwarding table entry for the Predirected (source) prefix. The node 398 then sets an ACCEPT timer and uses this timer to validate any 399 messages received from the Predirected neighbor. 401 When an AERO Client receives a valid Redirect message (see Section 402 3.10.7) it creates or updates a dynamic neighbor cache entry for the 403 Redirect target L3 and L2 addresses, and also creates an IPv6 404 forwarding table entry for the Redirected (destination) prefix. The 405 node then sets a FORWARD timer and uses this timer to determine 406 whether packets can be sent directly to the Redirected neighbor. The 407 node also maintains a constant value MAX_RETRY to limit the number of 408 keepalives sent when a neighbor has gone unreachable. 410 It is RECOMMENDED that FORWARD_TIME be set to the default constant 411 value 30 seconds to match the default REACHABLE_TIME value specified 412 for IPv6 neighbor discovery [RFC4861]. 414 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 415 value 40 seconds to allow a 10 second window so that the AERO 416 redirection procedure can converge before the ACCEPT_TIME timer 417 decrements below FORWARD_TIME. 419 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 420 for IPv6 neighbor discovery address resolution in Section 7.3.3 of 421 [RFC4861]. 423 Different values for FORWARD_TIME, ACCEPT_TIME, and MAX_RETRY MAY be 424 administratively set, if necessary, to better match the AERO link's 425 performance characteristics; however, if different values are chosen, 426 all nodes on the link MUST consistently configure the same values. 427 ACCEPT_TIME SHOULD further be set to a value that is sufficiently 428 longer than FORWARD_TIME to allow the AERO redirection procedure to 429 converge. 431 3.6. AERO Interface MTU Considerations 433 The AERO link Maximum Transmission Unit (MTU) is 64KB minus the 434 encapsulation overhead for IPv4 [RFC0791] and 4GB minus the 435 encapsulation overhead for IPv6 [RFC2675]. This is the most that 436 IPv4 and IPv6 (respectively) can convey within the constraints of 437 protocol constants, but actual sizes available for tunneling will 438 frequently be much smaller. 440 The base tunneling specifications for IPv4 and IPv6 typically set a 441 static MTU on the tunnel interface to 1500 bytes minus the 442 encapsulation overhead or smaller still if the tunnel is likely to 443 incur additional encapsulations on the path. This can result in path 444 MTU related black holes when packets that are too large to be 445 accommodated over the AERO link are dropped, but the resulting ICMP 446 Packet Too Big (PTB) messages are lost on the return path. As a 447 result, AERO nodes use the following MTU mitigations to accommodate 448 larger packets. 450 AERO nodes set their AERO interface MTU to the larger of the 451 underlying interface MTU minus the encapsulation overhead, and 1500 452 bytes. AERO nodes optionally cache other per-neighbor MTU values in 453 the underlying IP path MTU discovery cache initialized to the 454 underlying interface MTU. 456 AERO nodes admit packets that are no larger than 1280 bytes minus the 457 encapsulation overhead (*) as well as packets that are larger than 458 1500 bytes into the tunnel without fragmentation, i.e., as long as 459 they are no larger than the AERO interface MTU before encapsulation 460 and also no larger than the cached per-neighbor MTU following 461 encapsulation. For IPv4, the node sets the "Don't Fragment" (DF) bit 462 to 0 for packets no larger than 1280 bytes minus the encapsulation 463 overhead (*) and sets the DF bit to 1 for packets larger than 1500 464 bytes. If a large packet is lost in the path, the node may 465 optionally cache the MTU reported in the resulting PTB message or may 466 ignore the message, e.g., if there is a possibility that the message 467 is spurious. 469 For packets destined to an AERO node that are larger than 1280 bytes 470 minus the encapsulation overhead (*) but no larger than 1500 bytes, 471 the node uses outer IP fragmentation to fragment the packet into two 472 pieces (where the first fragment contains 1024 bytes of the 473 fragmented inner packet) then admits the fragments into the tunnel. 474 If the outer protocol is IPv4, the node admits the packet into the 475 tunnel with DF set to 0 and subject to rate limiting to avoid 476 reassembly errors [RFC4963][RFC6864]. For both IPv4 and IPv6, the 477 node also sends a 1500 byte probe message (**) to the neighbor, 478 subject to rate limiting. To construct a probe, the node prepares an 479 ICMPv6 Neighbor Solicitation (NS) message with trailing padding 480 octets added to a length of 1500 bytes but does not include the 481 length of the padding in the IPv6 Payload Length field. The node 482 then encapsulates the NS in the outer encapsulation headers (while 483 including the length of the padding in the outer length fields), sets 484 DF to 1 (for IPv4) and sends the padded NS message to the neighbor. 485 If the neighbor returns an NA message, the node may then send whole 486 packets within this size range and (for IPv4) relax the rate limiting 487 requirement. 489 AERO nodes MUST be capable of reassembling packets up to 1500 bytes 490 plus the encapsulation overhead length. It is therefore RECOMMENDED 491 that AERO nodes be capable of reassembling at least 2KB. 493 (*) Note that if it is known without probing that the minimum Path 494 MTU to an AERO node is MINMTU bytes (where 1280 < MINMTU < 1500) then 495 MINMTU can be used instead of 1280 in the fragmentation threshold 496 considerations listed above. 498 (**) It is RECOMMENDED that no probes smaller than 1500 bytes be used 499 for MTU probing purposes, since smaller probes may be fragmented if 500 there is a nested tunnel somewhere on the path to the neighbor. 501 Probe sizes larger than 1500 bytes MAY be used, but may be 502 unnecessary since original sources are expected to implement when 503 sending large packets. 505 3.7. AERO Interface Encapsulation, Re-encapsulation and Decapsulation 507 AERO interfaces encapsulate IPv6 packets according to whether they 508 are entering the AERO interface for the first time or if they are 509 being forwarded out the same AERO interface that they arrived on. 510 This latter form of encapsulation is known as "re-encapsulation". 512 AERO interfaces encapsulate packets per the specifications in 513 [RFC2473][RFC4213][RFC4301] except that the interface copies the "Hop 514 Limit", "Traffic Class" and "Congestion Experienced" values in the 515 inner IPv6 header into the corresponding fields in the outer IP 516 header. For packets undergoing re-encapsulation, the AERO interface 517 instead copies the "TTL/Hop Limit", "Type of Service/Traffic Class" 518 and "Congestion Experienced" values in the original outer IP header 519 into the corresponding fields in the new outer IP header (i.e., the 520 values are transferred between outer headers and *not* copied from 521 the inner network layer header). 523 When UDP encapsulation is used, the AERO interface inserts a UDP 524 header immediately above the outer IP header. The AERO interface 525 sets the UDP source port to a constant value that it will use in each 526 successive packet it sends, sets the UDP checksum field to zero (see: 527 [RFC6935][RFC6936]) and sets the UDP length field to the length of 528 the inner packet plus 8 bytes for the UDP header itself. For packets 529 sent via a Server, the AERO interface sets the UDP destination port 530 to 8060 (i.e., the IANA-registerd port number for AERO). For packets 531 sent to a neighboring Client, the AERO interface sets the UDP 532 destination port to the port value stored in the neighbor cache entry 533 for this neighbor. 535 The AERO interface next sets the outer IP protocol number to the 536 appropriate value for the first protocol layer within the 537 encapsulation (e.g., IPv6, UDP, IPsec, etc.). When IPv6 is used as 538 the outer IP protocol, the ITE then sets the flow label value in the 539 outer IPv6 header the same as described in [RFC6438]. When IPv4 is 540 used as the outer IP protocol, the AERO interface sets the DF bit as 541 discussed in Section 3.6. 543 AERO interfaces decapsulate packets destined either to the node 544 itself or to a destination reached via an interface other than the 545 receiving AERO interface per the specifications in 546 [RFC2473][RFC4213]. When the encapsulated packet includes a UDP 547 header, the AERO interface examines the first octet of data following 548 the UDP header. If the most significant four bits of the first octet 549 encode the value '0110', the inner header is an IPv6 header; 550 otherwise, the packet is discarded. During the decapsulation, the 551 AERO interface records the UDP source port in the neighbor cache 552 entry for this neighbor then discards the UDP header. 554 Note that AERO messaging and addressing can also be used in 555 conjunction with other tunnel types such as IPsec [RFC4301] and TLS 556 [RFC5246]. In that case, the native encapsulation format of the 557 tunnel is used, and the AERO messaging and addressing mechanisms are 558 applied as a layered extension. All other aspects of AERO neighbor 559 coordination are as-specified in this document. 561 3.8. AERO Reference Operational Scenario 563 Figure 2 depicts the AERO reference operational scenario. The figure 564 shows an AERO Server('A'), two AERO Clients ('B', 'D') and three 565 ordinary IPv6 hosts ('C', 'E', 'F'): 566 .-(::::::::) 567 .-(::: IPv6 :::)-. +-------------+ 568 (:::: Internet ::::)--| Host F | 569 `-(::::::::::::)-' +-------------+ 570 `-(::::::)-' 2001:db8:2::1 571 | 572 +--------------+ 573 | AERO Server A| 574 | (C->B; E->D) | 575 +--------------+ 576 fe80::0 577 L2(A) 578 | 579 X-----+-----------+-----------+--------X 580 | AERO Link | 581 L2(B) L2(D) 582 fe80::2001:db8:0:0 fe80::2001:db8:1:0 .-. 583 +--------------+ +--------------+ ,-( _)-. 584 | AERO Client B| | AERO Client D| .-(_ IPv6 )-. 585 | (default->A) | | (default->A) |--(__ EUN ) 586 +--------------+ +--------------+ `-(______)-' 587 2001:DB8:0::/48 2001:DB8:1::/48 | 588 | 2001:db8:1::1 589 .-. +-------------+ 590 ,-( _)-. 2001:db8:0::1 | Host E | 591 .-(_ IPv6 )-. +-------------+ +-------------+ 592 (__ EUN )--| Host C | 593 `-(______)-' +-------------+ 595 Figure 2: AERO Reference Operational Scenario 597 In Figure 2, AERO Server ('A') connects to the AERO link and connects 598 to the IPv6 Internet, either directly or via an AERO Relay (not 599 shown). Server ('A') assigns the address fe80::0 to its AERO 600 interface with link-layer address L2(A). Server ('A') next arranges 601 to add L2(A) to a published list of valid Servers for the AERO link. 603 AERO Client ('B') registers the IPv6 prefix 2001:db8:0::/48 in a 604 DHCPv6 PD exchange via AERO Server ('A') then assigns the address 605 fe80::2001:db8:0:0 to its AERO interface with link-layer address 606 L2(B). Client ('B') configures a default route via the AERO 607 interface with next-hop address fe80::0 and link-layer address L2(A), 608 then sub-delegates the prefix 2001:db8:0::/48 to its attached EUNs. 609 IPv6 host ('C') connects to the EUN, and configures the address 2001: 610 db8:0::1. 612 AERO Client ('D') registers the IPv6 prefix 2001:db8:1::/48 in a 613 DHCPv6 PD exchange via AERO Server ('A') then assigns the address 614 fe80::2001:db8:1:0 to its AERO interface with link-layer address 615 L2(D). Client ('D') configures a default route via the AERO 616 interface with next-hop address fe80::0 and link-layer address L2(A), 617 then sub-delegates the prefix 2001:db8:1::/48 to its attached EUNs. 618 IPv6 host ('E') connects to the EUN, and configures the address 2001: 619 db8:1::1. 621 Finally, IPv6 host ('F') connects to an IPv6 network outside of the 622 AERO link domain. Host ('F') configures its IPv6 interface in a 623 manner specific to its attached IPv6 link, and assigns the address 624 2001:db8:2::1 to its IPv6 link interface. 626 3.9. AERO Router Discovery, Prefix Delegation and Address Configuration 628 3.9.1. AERO Client Behavior 630 AERO Clients observe the IPv6 node requirements defined in [RFC6434]. 631 AERO Clients first discover the link-layer address of an AERO Server 632 via static configuration, or through an automated means such as DNS 633 name resolution. In the absence of other information, the Client 634 resolves the Fully-Qualified Domain Name (FQDN) 635 "linkupnetworks.domainname", where "domainname" is the DNS domain 636 appropriate for the Client's attached underlying network. The Client 637 then creates a static neighbor cache entry with fe80::0 as the 638 network-layer address and the discovered address as the link-layer 639 address then creates a static default IPv6 forwarding table entry 640 with fe80::0 as the next hop address. 642 Next, the Client acts as a requesting router to request an IPv6 643 prefix through DHCPv6 PD [RFC3633] via the AERO Server using a 644 temporary link-local address (see: Section 3.3) as the IPv6 source 645 address and fe80::0 as the IPv6 destination address. The Client 646 includes a DHCPv6 Unique Identifier (DUID) in the Client Identifier 647 option of its DHCPv6 messages [RFC3315] and includes any additional 648 authenticating information necessary to authenticate itself to the 649 DHCPv6 server. (Note that other DUID formats such as DUID-UUID 650 [RFC6355] may also be used.) If the Client is pre-provisioned with 651 an IPv6 prefix associated with the AERO service, it MAY also include 652 the prefix in an IA-PD option in its DHCPv6 Request command to 653 indicate its preferred prefix to the DHCPv6 server. 655 After the Client receives its prefix delegation, it assigns the link- 656 local AERO address taken from the prefix to the AERO interface (see: 657 Section 3.3) and sub-delegates the prefix to nodes and links within 658 its attached EUNs (the AERO link-local address thereafter remains 659 stable as the Client moves). The Client further renews its prefix 660 delegation via standard DHCPv6 procedures by sending DHCPv6 Renew 661 messages with its AERO address as the IPv6 source address, fe80::0 as 662 the IPv6 destination address and the same DUID value in the Client 663 Identifier option. 665 The Client then sends an RS message to the Server to receive an RA 666 message with a default router lifetime and other configuration 667 information. The Client ignores any Prefix Information Options 668 (PIOs) included in the RA message, since the AERO link is link-local- 669 only. The Client further ignores any RS messages it might receive, 670 since only Servers may process RS messages. The Client can then send 671 periodic NS messages to the Server to obtain new NA messages for 672 Neighbor Unreachability Detection (NUD) and to refresh any network 673 state, and can send periodic RS messages to obtain new RA messages in 674 order to update the default router lifetimes. (The Client can 675 alternately use RS messages for both purposes, but NS/NA exchanges 676 are the standard method for performing NUD.) The Client can also 677 forward IPv6 packets destined to networks beyond its local EUNs via 678 the Server as an IPv6 default router. The Server may in turn return 679 a Redirect message informing the Client of a neighbor on the AERO 680 link that is topologically closer to the final destination as 681 specified in Section 3.10. 683 Note that, since the Client's AERO address is configured from the 684 unique prefix delegation it receives via the Server, there is no need 685 for Duplicate Address Detection (DAD) on AERO links. Other nodes 686 maliciously attempting to hijack an authorized Client's AERO address 687 will be denied due to an unacceptable link-layer address and/or 688 security parameters (see: Security Considerations). 690 3.9.2. AERO Server Behavior 692 AERO Servers observe the IPv6 router requirements defined in 693 [RFC6434] and further configure a DHCPv6 relay function on their AERO 694 links. When the AERO Server relays a Client's DHCPv6 PD messages to 695 the DHCPv6 server, it wraps each message in a "Relay-forward" message 696 per [RFC3315] and includes a DHCPv6 Interface Identifier option that 697 encodes a value that identifies the AERO link to the DHCPv6 server. 699 The AERO Server then includes the Client's link-layer address in a 700 Client Link Layer Address Option (CLLAO) [RFC6939] with the link- 701 layer address format shown in Figure 1, i.e., a 2-octet UDP port 702 number followed by a 16-octet IP address. The Server sets the CLLAO 703 'option-length' field to 20 (2 plus the length of the link-layer 704 address) and sets the 'link-layer type' field to TBD (see: IANA 705 Considerations). The Server finally includes a DHCPv6 Echo Request 706 Option (ERO) [RFC4994] that encodes the option code for the CLLAO in 707 a 'requested-option-code-n' field. The CLLAO information will 708 therefore subsequently be echoed back in the DHCPv6 Server's "Relay- 709 reply" message. 711 When the DHCPv6 server issues the IPv6 prefix delegation in a "Relay- 712 reply" message via the AERO Server (acting as a DHCPv6 relay), the 713 AERO Server obtains the Client's link-layer address from the echoed 714 CLLAO option and obtains the Client's delegated prefix from the 715 included IA_PD option. The Server then creates a static neighbor 716 cache entry for the Client's AERO address (see: Section 3.3) with the 717 Client's link-layer address as the link-layer address for the 718 neighbor cache entry. The Server also configures an IPv6 forwarding 719 table entry that lists the Client's AERO address as the next hop 720 toward the delegated IPv6 prefix with a lifetime derived from the 721 DHCPv6 lease lifetime. The AERO Server finally injects the Client's 722 prefix as an IPv6 route into the inter-Server/Relay routing system 723 (see: [IRON]) then relays the DHCPv6 message to the Client while 724 using fe80::0 as the IPv6 source address, the link-local address 725 found in the "peer address" field of the Relay-reply message as the 726 IPv6 destination address, and the Client's link-layer address as the 727 destination link-layer address. 729 Servers respond to RS/NS messages from Clients on their AERO 730 interfaces by returning an RA/NA message. When the Server receives 731 an RS/NS message, it updates the neighbor cache entry using the 732 network layer source address as the neighbor's network layer address 733 and using the link-layer source address of the RS/NS message as the 734 neighbor's link-layer address. The Server SHOULD NOT include PIOs in 735 any RA messages it sends to Clients, since the Client will ignore any 736 such options. 738 Servers ignore any RA messages they may receive from a Client. 739 Servers MAY examine RA messages they may receive from other Servers 740 for consistency verification purposes. 742 When the Server forwards a packet via the same AERO interface on 743 which it arrived, it initiates an AERO route optimization procedure 744 as specified in Section 3.10. 746 3.10. AERO Redirection 748 Section 3.8 describes the AERO reference operational scenario. We 749 now discuss the operation and protocol details of AERO Redirection 750 with respect to this reference scenario. 752 3.10.1. Classical Redirection Approaches 754 With reference to Figure 2, when the IPv6 source host ('C') sends a 755 packet to an IPv6 destination host ('E'), the packet is first 756 forwarded via the EUN to AERO Client ('B'). Client ('B') then 757 forwards the packet over its AERO interface to AERO Server ('A'), 758 which then re-encapsulates and forwards the packet to AERO Client 759 ('D'), where the packet is finally forwarded to the IPv6 destination 760 host ('E'). When Server ('A') re-encapsulates and forwards the 761 packet back out on its advertising AERO interface, it must arrange to 762 redirect Client ('B') toward Client ('D') as a better next-hop node 763 on the AERO link that is closer to the final destination. However, 764 this redirection process applied to AERO interfaces must be more 765 carefully orchestrated than on ordinary links since the parties may 766 be separated by potentially many underlying network routing hops. 768 Consider a first alternative in which Server ('A') informs Client 769 ('B') only and does not inform Client ('D') (i.e., "classical 770 redirection"). In that case, Client ('D') has no way of knowing that 771 Client ('B') is authorized to forward packets from the claimed source 772 address, and it may simply elect to drop the packets. Also, Client 773 ('B') has no way of knowing whether Client ('D') is performing some 774 form of source address filtering that would reject packets arriving 775 from a node other than a trusted default router, nor whether Client 776 ('D') is even reachable via a direct path that does not involve 777 Server ('A'). 779 Consider a second alternative in which Server ('A') informs both 780 Client ('B') and Client ('D') separately, via independent redirection 781 control messages (i.e., "augmented redirection"). In that case, if 782 Client ('B') receives the redirection control message but Client 783 ('D') does not, subsequent packets sent by Client ('B') could be 784 dropped due to filtering since Client ('D') would not have a route to 785 verify the claimed source address. Also, if Client ('D') receives 786 the redirection control message but Client ('B') does not, subsequent 787 packets sent in the reverse direction by Client ('D') would be lost. 789 Since both of these alternatives have shortcomings, a new redirection 790 technique (i.e., "AERO redirection") is needed. 792 3.10.2. AERO Redirection Concept of Operations 794 Again, with reference to Figure 2, when source host ('C') sends a 795 packet to destination host ('E'), the packet is first forwarded over 796 the source host's attached EUN to Client ('B'), which then forwards 797 the packet via its AERO interface to Server ('A'). 799 Server ('A') then re-encapsulates and forwards the packet out the 800 same AERO interface toward Client ('D') and also sends an AERO 801 "Predirect" message forward to Client ('D') as specified in 802 Section 3.10.4. The Predirect message includes Client ('B')'s 803 network- and link-layer addresses as well as information that Client 804 ('D') can use to determine the IPv6 prefix used by Client ('B') . 805 After Client ('D') receives the Predirect message, it process the 806 message and returns an AERO Redirect message destined for Client 807 ('B') via Server ('A') as specified in Section 3.10.5. During the 808 process, Client ('D') also creates or updates a dynamic neighbor 809 cache entry for Client ('B'), and creates an IPv6 forwarding table 810 entry for Client ('B')'s IPv6 prefix. 812 When Server ('A') receives the Redirect message, it re-encapsulates 813 the message and forwards it on to Client ('B') as specified in 814 Section 3.10.6. The message includes Client ('D')'s network- and 815 link-layer addresses as well as information that Client ('B') can use 816 to determine the IPv6 prefix used by Client ('D'). After Client 817 ('B') receives the Redirect message, it processes the message as 818 specified in Section 3.10.7. During the process, Client ('B') also 819 creates or updates a dynamic neighbor cache entry for Client ('D'), 820 and creates an IPv6 forwarding table entry for Client ('D')'s IPv6 821 prefix. 823 Following the above Predirect/Redirect message exchange, forwarding 824 of packets from Client ('B') to Client ('D') without involving Server 825 ('A) as an intermediary is enabled. The mechanisms that support this 826 exchange are specified in the following sections. 828 3.10.3. AERO Redirection Message Format 830 AERO Redirect/Predirect messages use the same format as for ICMPv6 831 Redirect messages depicted in Section 4.5 of [RFC4861], but also 832 include a new "Prefix Length" field taken from the low-order 8 bits 833 of the Redirect message Reserved field (valid values for the Prefix 834 Length field are 0 through 64). The Redirect/Predirect messages are 835 formatted as shown in Figure 3: 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Type (=137) | Code (=0/1) | Checksum | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Reserved | Prefix Length | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | | 845 + + 846 | | 847 + Target Address + 848 | | 849 + + 850 | | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | | 853 + + 854 | | 855 + Destination Address + 856 | | 857 + + 858 | | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Options ... 861 +-+-+-+-+-+-+-+-+-+-+-+- 863 Figure 3: AERO Redirect/Predirect Message Format 865 3.10.4. Sending Predirects 867 When an AERO Server forwards a packet out the same AERO interface 868 that it arrived on, the Server sends a Predirect message forward 869 toward the AERO Client nearest the destination instead of sending a 870 Redirect message back to AERO Client nearest the source. 872 In the reference operational scenario, when Server ('A') forwards a 873 packet sent by Client ('B') toward Client ('D'), it also sends a 874 Predirect message forward toward Client ('D'), subject to rate 875 limiting (see Section 8.2 of [RFC4861]). Server ('A') prepares the 876 Predirect message as follows: 878 o the link-layer source address is set to 'L2(A)' (i.e., the 879 underlying address of Server ('A')). 881 o the link-layer destination address is set to 'L2(D)' (i.e., the 882 underlying address of Client ('D')). 884 o the network-layer source address is set to fe80::0 (i.e., the 885 link-local address of Server ('A')). 887 o the network-layer destination address is set to fe80::2001:db8:1:0 888 (i.e., the AERO address of Client ('D')). 890 o the Type is set to 137. 892 o the Code is set to 1 to indicate "Predirect". 894 o the Prefix Length is set to the length of the prefix to be applied 895 to Target address. 897 o the Target Address is set to fe80::2001:db8:0::0 (i.e., the AERO 898 address of Client ('B')). 900 o the Destination Address is set to the IPv6 source address of the 901 packet that triggered the Predirection event. 903 o the message includes one or more TLLAOs set to 'L2(B)' and any 904 other underlying address(es) of Client ('B'). 906 o the message includes a Redirected Header Option (RHO) that 907 contains the originating packet truncated to ensure that at least 908 the network-layer header is included but the size of the message 909 does not exceed 1280 bytes. 911 Server ('A') then sends the message forward to Client ('D'). 913 3.10.5. Processing Predirects and Sending Redirects 915 When Client ('D') receives a Predirect message, it accepts the 916 message only if it has a link-layer source address of the Server, 917 i.e. 'L2(A)'. Client ('D') further accepts the message only if it 918 is willing to serve as a redirection target. Next, Client ('D') 919 validates the message according to the ICMPv6 Redirect message 920 validation rules in Section 8.1 of [RFC4861]. 922 In the reference operational scenario, when the Client ('D') receives 923 a valid Predirect message, it either creates or updates a dynamic 924 neighbor cache entry that stores the Target Address of the message as 925 the network-layer address of Client ('B') and stores the link-layer 926 address(es) found in the TLLAO(s) as the link-layer address(es) of 927 Client ('B'). Client ('D') then applies the Prefix Length to the 928 Interface Identifier portion of the Target Address and records the 929 resulting IPv6 prefix in its IPv6 forwarding table. 931 After processing the message, Client ('D') prepares a Redirect 932 message response as follows: 934 o the link-layer source address is set to 'L2(D)' (i.e., the link- 935 layer address of Client ('D')). 937 o the link-layer destination address is set to 'L2(A)' (i.e., the 938 link-layer address of Server ('A')). 940 o the network-layer source address is set to 'L3(D)' (i.e., the AERO 941 address of Client ('D')). 943 o the network-layer destination address is set to 'L3(B)' (i.e., the 944 AERO address of Client ('B')). 946 o the Type is set to 137. 948 o the Code is set to 0 to indicate "Redirect". 950 o the Prefix Length is set to the length of the prefix to be applied 951 to the Target and Destination address. 953 o the Target Address is set to fe80::2001:db8:1::1 (i.e., the AERO 954 address of Client ('D')). 956 o the Destination Address is set to the IPv6 destination address of 957 the packet that triggered the Redirection event. 959 o the message includes one or more TLLAOs set to 'L2(D)' and any 960 other underlying address(es) of Client ('D'). 962 o the message includes as much of the RHO copied from the 963 corresponding AERO Predirect message as possible such that at 964 least the network-layer header is included but the size of the 965 message does not exceed 1280 bytes. 967 After Client ('D') prepares the Redirect message, it sends the 968 message to Server ('A'). 970 3.10.6. Re-encapsulating and Relaying Redirects 972 When Server ('A') receives a Redirect message, it accepts the message 973 only if it has a neighbor cache entry that associates the message's 974 link-layer source address with the network-layer source address. 975 Next, Server ('A') validates the message according to the ICMPv6 976 Redirect message validation rules in Section 8.1 of [RFC4861]. 977 Following validation, Server ('A') re-encapsulates the Redirect then 978 relays the re-encapsulated Redirect on to Client ('B') as follows. 980 In the reference operational scenario, Server ('A') receives the 981 Redirect message from Client ('D') and prepares to re-encapsulate and 982 forward the message to Client ('B'). Server ('A') first verifies 983 that Client ('D') is authorized to use the Prefix Length in the 984 Redirect message when applied to the AERO address in the network- 985 layer source of the Redirect message, and discards the message if 986 verification fails. Otherwise, Server ('A') re-encapsulates the 987 message by changing the link-layer source address of the message to 988 'L2(A)', changing the network-layer source address of the message to 989 fe80::0, and changing the link-layer destination address to 'L2(B)' . 990 Server ('A') finally relays the re-encapsulated message to the 991 ingress node ('B') without decrementing the network-layer IPv6 header 992 Hop Limit field. 994 While not shown in Figure 2, AERO Relays relay Redirect and Predirect 995 messages in exactly this same fashion described above. See Figure 4 996 in Appendix A for an extension of the reference operational scenario 997 that includes Relays. 999 3.10.7. Processing Redirects 1001 When Client ('B') receives the Redirect message, it accepts the 1002 message only if it has a link-layer source address of the Server, 1003 i.e. 'L2(A)'. Next, Client ('B') validates the message according to 1004 the ICMPv6 Redirect message validation rules in Section 8.1 of 1005 [RFC4861]. Following validation, Client ('B') then processes the 1006 message as follows. 1008 In the reference operational scenario, when Client ('B') receives the 1009 Redirect message, it either creates or updates a dynamic neighbor 1010 cache entry that stores the Target Address of the message as the 1011 network-layer address of Client ('D') and stores the link-layer 1012 address(es) found in the TLLAO(s) as the link-layer address(es) of 1013 Client ('D'). Client ('B') then applies the Prefix Length to the 1014 Interface Identifier portion of the Target Address and records the 1015 resulting IPv6 prefix in its IPv6 forwarding table. 1017 Now, Client ('B') has an IPv6 forwarding table entry for 1018 Client('D')'s prefix, and Client ('D') has an IPv6 forwarding table 1019 entry for Client ('B')'s prefix. Thereafter, the clients may 1020 exchange ordinary network-layer data packets directly without 1021 forwarding through Server ('A'). 1023 3.11. Neighbor Reachability Maintenance 1025 Each AERO node uses its delegated prefix to create an AERO address 1026 (see: Section 3.3). It can then send unicast NS messages to elicit 1027 NA messages from other AERO nodes the same as described for Neighbor 1028 Unreachability Detection (NUD) in [RFC4861] except that the messages 1029 do not include S/TLLAOs. When an AERO node sends an NS/NA message, 1030 it MUST use its AERO address as the IPv6 source address and the AERO 1031 address of the neighbor as the IPv6 destination address. When an 1032 AERO node receives an NS/NA message, it accepts the message if it has 1033 a neighbor cache entry for the neighbor; otherwise, it ignores the 1034 message. 1036 When a source Client is redirected to a target Client it SHOULD test 1037 the direct path to the target by sending an initial NS message to 1038 elicit a solicited NA response. While testing the path, the source 1039 Client SHOULD continue sending packets via the Server until target 1040 Client reachability has been confirmed. The source Client SHOULD 1041 thereafter continue to test the direct path to the target Client (see 1042 Section 7.3 of [RFC4861]) in order to keep dynamic neighbor cache 1043 entries alive. In particular, the source Client sends NS messages to 1044 the target Client subject to rate limiting in order to receive 1045 solicited NA messages. If at any time the direct path appears to be 1046 failing, the source Client can resume sending packets via the Server 1047 which may or may not result in a new redirection event. 1049 When a target Client receives an NS message from a source Client, it 1050 resets the ACCEPT_TIME timer if a neighbor cache entry exists; 1051 otherwise, it discards the NS message. 1053 When a source Client receives a solicited NA message form a target 1054 Client, it resets the FORWARD_TIME timer if a neighbor cache entry 1055 exists; otherwise, it discards the NA message. 1057 When both the FORWARD_TIME and ACCEPT_TIME timers on a dynamic 1058 neighbor cache entry expire, the Client deletes both the neighbor 1059 cache entry and the corresponding IPv6 forwarding table entry. 1061 If the source Client is unable to elicit an NA response from the 1062 target Client after MAX_RETRY attempts, it SHOULD consider the direct 1063 path unusable for forwarding purposes. Otherwise, the source Client 1064 may continue to send packets directly to the target Client and SHOULD 1065 thereafter process any link-layer errors as a hint that the direct 1066 path to the target Client has either failed or has become 1067 intermittent. 1069 3.12. Mobility and Link-Layer Address Change Considerations 1071 When a Client needs to change its link-layer address (e.g., due to a 1072 mobility event, due to a change in underlying network interface, 1073 etc.), it sends an immediate NS message forward to any of its 1074 correspondents (including the Server and any other Clients) which 1075 then discover the new link-layer address. 1077 If two Clients change their link-layer addresses simultaneously, the 1078 NS/NA messages may be lost. In that case, the Clients SHOULD delete 1079 their respective dynamic neighbor cache and IPv6 forwarding table 1080 entries, and allow packets to again flow through their Server(s) 1081 which MAY result in a new AERO redirection exchange. 1083 When a Client needs to change to a new AERO Server, it issues a new 1084 DHCPv6 Request message via the new AERO Server as the DHCPv6 relay. 1085 The new AERO Server then relays the message to the DHCPv6 server and 1086 processes the resulting exchange the same as described in Section 1087 3.9.2. After the Client receives the resulting DHCPv6 Reply message, 1088 it sends an RS message to the new Server to receive a new RA message 1089 and update its neighbor cache entry for fe80::0. 1091 After conducting the DHCPv6 exchange via the new AERO Server, the 1092 Client then sends a "terminating NS" message to the old AERO Server. 1093 The terminating NS message is prepared exactly the same as for an 1094 ordinary NS message, except that the Code field contains the value 1095 '1'. When the old Server receives the terminating NS message, it 1096 withdraws the IPv6 route from the routing system and deletes the 1097 neighbor cache entry and IPv6 forwarding table entry for the Client. 1098 The old Server then returns an NA message which the Client can use to 1099 verify that the termination signal has been processed. (Note that 1100 the old Server can impose a small delay before deleting the neighbor 1101 cache and IPv6 forwarding table entries so that any packets already 1102 in the system can still be delivered to the Client.) 1104 An alternative to sending a "terminating NS" message would be for the 1105 Client to somehow perform a DHCPv6 exchange with the DHCPv6 relay 1106 function on the old AERO Server but without involving the DHCPv6 1107 server. This would be insecure because the Client only has a DHCPv6 1108 security association with the DHCPv6 server and not the DHCPv6 relay. 1109 Conversely, the AERO Client and Server already require an authentic 1110 exchange of IPv6 Neighbor Discovery messages. 1112 3.13. Underlying Protocol Version Considerations 1114 A source Client may connect only to an IPvX underlying network, while 1115 the target Client connects only to an IPvY underlying network. In 1116 that case, the source Client has no means for reaching the target 1117 directly (since they connect to underlying networks of different IP 1118 protocol versions) and so must ignore any Redirects and continue to 1119 send packets via the Server. 1121 3.14. Multicast Considerations 1123 When the underlying network does not support multicast, AERO nodes 1124 map IPv6 link-scoped multicast addresses (including 1125 "All_DHCP_Relay_Agents_and_Servers") to the underlying IP address of 1126 the current AERO Server. 1128 When the underlying network supports multicast, AERO nodes use the 1129 multicast address mapping specification found in [RFC2529] for IPv4 1130 underlying networks and use a direct multicast mapping for IPv6 1131 underlying networks. (In the latter case, "direct multicast mapping" 1132 means that if the IPv6 multicast destination address of the inner 1133 packet is "M", then the IPv6 multicast destination address of the 1134 encapsulating header is also "M".) 1136 3.15. Operation on Server-less AERO Links 1138 In some AERO link scenarios, there may be no Server on the link 1139 and/or no need for Clients to use a Server as an intermediary trust 1140 anchor. In that case, Clients can then establish dynamic neighbor 1141 cache entries and IPv6 forwarding table entries by performing direct 1142 Client-to-Client Predirect/Redirect exchanges, and some other form of 1143 trust basis must be applied so that each Client can verify that the 1144 prospective neighbor is authorized to use its claimed prefix. 1146 When there is no Server on the link, Clients must arrange to receive 1147 prefix delegations and publish the delegations via a secure alternate 1148 prefix delegation authority through some means outside the scope of 1149 this document. 1151 3.16. Other Considerations 1153 IPv6 hosts serviced by an AERO Client can reach IPv4-only services 1154 via a NAT64 gateway [RFC6146] within the IPv6 network. 1156 AERO nodes can use the Default Address Selection Policy with DHCPv6 1157 option [RFC7078] the same as on any IPv6 link. 1159 All other (non-multicast) functions that operate over ordinary IPv6 1160 links operate in the same fashion over AERO links. 1162 4. Implementation Status 1164 An early implementation is available at: 1165 http://linkupnetworks.com/aero/aerov2-0.3.tgz. 1167 5. IANA Considerations 1169 The IANA is instructed to assign a new 2-octet Hardware Type number 1170 for AERO in the "arp-parameters" registry per Section 2 of [RFC5494]. 1172 The number is assigned from the 2-octet Unassigned range with 1173 Hardware Type "AERO" and with this document as the reference. 1175 6. Security Considerations 1177 AERO link security considerations are the same as for standard IPv6 1178 Neighbor Discovery [RFC4861] except that AERO improves on some 1179 aspects. In particular, AERO is dependent on a trust basis between 1180 AERO Clients and Servers, where the Clients only engage in the AERO 1181 mechanism when it is facilitated by a trust anchor. 1183 AERO links must be protected against link-layer address spoofing 1184 attacks in which an attacker on the link pretends to be a trusted 1185 neighbor. Links that provide link-layer securing mechanisms (e.g., 1186 WiFi networks) and links that provide physical security (e.g., 1187 enterprise network wired LANs) provide a first line of defense that 1188 is often sufficient. In other instances, securing mechanisms such as 1189 Secure Neighbor Discovery (SeND) [RFC3971], IPsec [RFC4301] or TLS 1190 [RFC5246] may be necessary. 1192 AERO Clients MUST ensure that their connectivity is not used by 1193 unauthorized nodes on EUNs to gain access to a protected network. 1194 (This concern is no different than for ordinary hosts that receive an 1195 IP address delegation but then "share" the address with unauthorized 1196 nodes via an IPv6/IPv6 NAT function.) 1198 On some AERO links, establishment and maintenance of a direct path 1199 between neighbors requires secured coordination such as through the 1200 Internet Key Exchange (IKEv2) protocol [RFC5996] to establish a 1201 security association. 1203 7. Acknowledgements 1205 Discussions both on the v6ops list and in private exchanges helped 1206 shape some of the concepts in this work. Individuals who contributed 1207 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1208 Brian Carpenter, Wojciech Dec, Brian Haberman, Joel Halpern, Sascha 1209 Hlusiak, Lee Howard, Joe Touch and Bernie Volz. Members of the IESG 1210 also provided valuable input during their review process that greatly 1211 improved the document. Special thanks go to Stewart Bryant, Joel 1212 Halpern and Brian Haberman for their shepherding guidance. 1214 This work has further been encouraged and supported by Boeing 1215 colleagues including Keith Bartley, Dave Bernhardt, Cam Brodie, 1216 Balaguruna Chidambaram, Wen Fang, Anthony Gregory, Jeff Holland, Ed 1217 King, Gen MacLean, Kent Shuey, Mike Slane, Julie Wulff, Yueli Yang, 1218 and other members of the BR&T and BIT mobile networking teams. 1220 Earlier works on NBMA tunneling approaches are found in 1221 [RFC2529][RFC5214][RFC5569]. 1223 8. References 1225 8.1. Normative References 1227 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1228 August 1980. 1230 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1231 September 1981. 1233 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1234 RFC 792, September 1981. 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, March 1997. 1239 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1240 (IPv6) Specification", RFC 2460, December 1998. 1242 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1243 IPv6 Specification", RFC 2473, December 1998. 1245 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1246 and M. Carney, "Dynamic Host Configuration Protocol for 1247 IPv6 (DHCPv6)", RFC 3315, July 2003. 1249 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1250 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1251 December 2003. 1253 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1254 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1256 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1257 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1258 September 2007. 1260 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1261 Address Autoconfiguration", RFC 4862, September 2007. 1263 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1264 Requirements", RFC 6434, December 2011. 1266 8.2. Informative References 1268 [IRON] Templin, F., "The Internet Routing Overlay Network 1269 (IRON)", Work in Progress, June 2012. 1271 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1272 RFC 879, November 1983. 1274 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1275 Domains without Explicit Tunnels", RFC 2529, March 1999. 1277 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1278 RFC 2675, August 1999. 1280 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1281 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1283 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1284 Architecture", RFC 4291, February 2006. 1286 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1287 Internet Protocol", RFC 4301, December 2005. 1289 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1290 Discovery", RFC 4821, March 2007. 1292 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1293 Errors at High Data Rates", RFC 4963, July 2007. 1295 [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, 1296 "DHCPv6 Relay Agent Echo Request Option", RFC 4994, 1297 September 2007. 1299 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1300 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1301 March 2008. 1303 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1304 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1306 [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 1307 for the Address Resolution Protocol (ARP)", RFC 5494, 1308 April 2009. 1310 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1311 Route Optimization Requirements for Operational Use in 1312 Aeronautics and Space Exploration Mobile Networks", 1313 RFC 5522, October 2009. 1315 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1316 Infrastructures (6rd)", RFC 5569, January 2010. 1318 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1319 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1320 RFC 5996, September 2010. 1322 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1323 NAT64: Network Address and Protocol Translation from IPv6 1324 Clients to IPv4 Servers", RFC 6146, April 2011. 1326 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1327 Troan, "Basic Requirements for IPv6 Customer Edge 1328 Routers", RFC 6204, April 2011. 1330 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 1331 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, 1332 August 2011. 1334 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1335 for Equal Cost Multipath Routing and Link Aggregation in 1336 Tunnels", RFC 6438, November 2011. 1338 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1339 RFC 6691, July 2012. 1341 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1342 (AERO)", RFC 6706, August 2012. 1344 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1345 RFC 6864, February 2013. 1347 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1348 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 1350 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1351 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1352 RFC 6936, April 2013. 1354 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 1355 Address Option in DHCPv6", RFC 6939, May 2013. 1357 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1358 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1360 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 1361 Address Selection Policy Using DHCPv6", RFC 7078, 1362 January 2014. 1364 Appendix A. AERO Server and Relay Interworking 1366 Figure 2 depicts a reference AERO operational scenario with a single 1367 Server on the AERO link. In order to support scaling to larger 1368 numbers of nodes, the AERO link can deploy multiple Servers and 1369 Relays, e.g., as shown in Figure 4. 1371 .-(::::::::) 1372 .-(::: IPv6 :::)-. 1373 (:: Internetwork ::) 1374 `-(::::::::::::)-' 1375 `-(::::::)-' 1376 | 1377 +--------------+ +------+-------+ +--------------+ 1378 |AERO Server C | | AERO Relay D | |AERO Server E | 1379 | (default->D) | | (A->C; G->E) | | (default->D) | 1380 | (A->B) | +-------+------+ | (G->F) | 1381 +-------+------+ | +------+-------+ 1382 | | | 1383 X---+---+-------------------+------------------+---+---X 1384 | AERO Link | 1385 +-----+--------+ +--------+-----+ 1386 |AERO Client B | |AERO Client F | 1387 | (default->C) | | (default->E) | 1388 +--------------+ +--------------+ 1389 .-. .-. 1390 ,-( _)-. ,-( _)-. 1391 .-(_ IPv6 )-. .-(_ IPv6 )-. 1392 (__ EUN ) (__ EUN ) 1393 `-(______)-' `-(______)-' 1394 | | 1395 +--------+ +--------+ 1396 | Host A | | Host G | 1397 +--------+ +--------+ 1399 Figure 4: AERO Server/Relay Interworking 1401 In this example, AERO Client ('B') associates with AERO Server ('C'), 1402 while AERO Client ('F') associates with AERO Server ('E'). 1403 Furthermore, AERO Servers ('C') and ('E') do not associate with each 1404 other directly, but rather have an association with AERO Relay ('D') 1405 (i.e., a router that has full topology information concerning its 1406 associated Servers and their Clients). Relay ('D') connects to the 1407 AERO link, and also connects to the native IPv6 Internetwork. 1409 When host ('A') sends a packet toward destination host ('G'), IPv6 1410 forwarding directs the packet through the EUN to Client ('B'), which 1411 forwards the packet to Server ('C') in absence of more-specific 1412 forwarding information. Server ('C') forwards the packet, and it 1413 also generates an AERO Predirect message that is then forwarded 1414 through Relay ('D') to Server ('E'). When Server ('E') receives the 1415 message, it forwards the message to Client ('F'). 1417 After processing the AERO Predirect message, Client ('F') sends an 1418 AERO Redirect message to Server ('E'). Server ('E'), in turn, 1419 forwards the message through Relay ('D') to Server ('C'). When 1420 Server ('C') receives the message, it forwards the message to Client 1421 ('B') informing it that host 'G's EUN can be reached via Client 1422 ('F'), thus completing the AERO redirection. 1424 The network layer routing information shared between Servers and 1425 Relays must be carefully coordinated in a manner outside the scope of 1426 this document. In particular, Relays require full topology 1427 information, while individual Servers only require partial topology 1428 information (i.e., they only need to know the EUN prefixes associated 1429 with their current set of Clients). See [IRON] for an architectural 1430 discussion of routing coordination between Relays and Servers. 1432 Author's Address 1434 Fred L. Templin (editor) 1435 Boeing Research & Technology 1436 P.O. Box 3707 1437 Seattle, WA 98124 1438 USA 1440 Email: fltemplin@acm.org