idnits 2.17.1 draft-templin-aerolink-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 03, 2014) is 3765 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 852, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 891, but no explicit reference was found in the text == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-65 ** Downref: Normative reference to an Experimental draft: draft-templin-intarea-seal (ref. 'I-D.templin-intarea-seal') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 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) January 03, 2014 5 Intended status: Standards Track 6 Expires: July 7, 2014 8 Transmission of IPv6 Packets over AERO Links 9 draft-templin-aerolink-01.txt 11 Abstract 13 This document specifies the operation of IPv6 over tunnel virtual 14 Non-Broadcast, Multiple Access (NBMA) links using Automatic 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 July 7, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 60 3.1. AERO Interface Characteristics . . . . . . . . . . . . . . 5 61 3.2. AERO Node Types . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. AERO Addresses . . . . . . . . . . . . . . . . . . . . . . 7 63 3.4. AERO Reference Operational Scenario . . . . . . . . . . . 8 64 3.5. AERO Prefix Delegation and Router Discovery . . . . . . . 10 65 3.5.1. AERO Client Behavior . . . . . . . . . . . . . . . . . 10 66 3.5.2. AERO Server Behavior . . . . . . . . . . . . . . . . . 11 67 3.6. AERO Redirection . . . . . . . . . . . . . . . . . . . . . 11 68 3.6.1. Classical Redirection Approaches . . . . . . . . . . . 11 69 3.6.2. AERO Redirection Concept of Operations . . . . . . . . 12 70 3.6.3. AERO Redirection Message Format . . . . . . . . . . . 13 71 3.6.4. Sending Predirects . . . . . . . . . . . . . . . . . . 14 72 3.6.5. Processing Predirects and Sending Redirects . . . . . 15 73 3.6.6. Re-encapsulating and Forwarding Redirects . . . . . . 16 74 3.6.7. Processing Redirects . . . . . . . . . . . . . . . . . 17 75 3.6.8. Neighbor Reachability Considerations . . . . . . . . . 17 76 3.6.9. Mobility and Link-Layer Address Change 77 Considerations . . . . . . . . . . . . . . . . . . . . 18 78 3.6.10. Underlying Protocol Version Considerations . . . . . . 18 79 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Appendix A. AERO Server and Relay Interworking . . . . . . . . . 21 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 1. Introduction 91 This document specifies the operation of IPv6 over tunnel virtual 92 Non-Broadcast, Multiple Access (NBMA) links using Automatic Extended 93 Route Optimization (AERO). Nodes attached to AERO links can exchange 94 packets via trusted intermediate routers on the link that provide 95 forwarding services to reach off-link destinations and/or redirection 96 services to inform the node of an on-link neighbor that is closer to 97 the final destination. 99 Nodes on AERO links use an IPv6 link-local address format known as 100 the AERO Address. This address type has properties that statelessly 101 link IPv6 Neighbor Discovery (ND) to IPv6 routing. The AERO link can 102 be used for tunneling to neighboring nodes on either IPv6 or IPv4 103 networks, i.e., AERO views the IPv6 and IPv4 networks as equivalent 104 links for tunneling. The remainder of this document presents the 105 AERO specification. 107 2. Terminology 109 The terminology in the normative references applies; the following 110 terms are defined within the scope of this document: 112 AERO link 113 a Non-Broadcast, Multiple Access (NBMA) tunnel virtual overlay 114 configured over a node's attached IPv6 and/or IPv4 networks. All 115 nodes on the AERO link appear as single-hop neighbors from the 116 perspective of IPv6. 118 AERO interface 119 a node's attachment to an AERO link. 121 AERO address 122 an IPv6 link-local address assigned to an AERO interface and 123 constructed as specified in Section 3.3. 125 AERO node 126 a node that is connected to an AERO link and that participates in 127 IPv6 Neighbor Discovery over the link. 129 AERO Server ("server") 130 a node that configures an advertising router interface on an AERO 131 link over which it can provide default forwarding and redirection 132 services for other AERO nodes. 134 AERO Client ("client") 135 a node that configures a non-advertising router interface on an 136 AERO link over which it can connect End User Networks (EUNs) to 137 the AERO link. 139 AERO Relay ("relay") 140 a node that relays IPv6 packets between Servers on the same AERO 141 link, and/or that forwards IPv6 packets between the AERO link and 142 the IPv6 Internet. An AERO Relay may or may not also be 143 configured as an AERO Server. 145 ingress tunnel endpoint (ITE) 146 an AERO interface endpoint that injects packets into an AERO link. 148 egress tunnel endpoint (ETE) 149 an AERO interface endpoint that receives tunneled packets from an 150 AERO link. 152 underlying network 153 a connected IPv6 or IPv4 network routing region over which AERO 154 nodes tunnel IPv6 packets. 156 underlying interface 157 an AERO node's interface point of attachment to an underlying 158 network. 160 underlying address 161 an IPv6 or IPv4 address assigned to an AERO node's underlying 162 interface. When UDP encapsulation is used, the UDP port number is 163 also considered as part of the underlying address. Underlying 164 addresses are used as the source and destination addresses of the 165 AERO encapsulation header. 167 link-layer address 168 the same as defined for "underlying address" above. 170 network layer address 171 an IPv6 address used as the source or destination address of the 172 inner IPv6 packet header. 174 end user network (EUN) 175 an IPv6 network attached to a downstream interface of an AERO 176 Client (where the AERO interface is seen as the upstream 177 interface). 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 3. Asymmetric Extended Route Optimization (AERO) 185 The following sections specify the operation of IPv6 over Automatic 186 Extended Route Optimization (AERO) links: 188 3.1. AERO Interface Characteristics 190 All nodes connected to an AERO link configure their AERO interfaces 191 as router interfaces (not host interfaces). End system applications 192 therefore do not bind directly to the AERO interface, but rather bind 193 to end user network (EUN) interfaces beyond which their packets may 194 be forwarded over an AERO interface. 196 AERO interfaces use IPv6-in-IPv6 encapsulation [RFC2473] to exchange 197 tunneled packets with AERO neighbors attached to an underlying IPv6 198 network, and use IPv6-in-IPv4 encapsulation [RFC4213] to exchange 199 tunneled packets with AERO neighbors attached to an underlying IPv4 200 network. AERO interfaces can also use IPsec encapsulation [RFC4301] 201 (either IPv6-in-IPv6 or IPv6-in-IPv4) in environments where strong 202 authentication and confidentiality are required. 204 AERO interfaces further use the Subnetwork Encapsulation and 205 Adaptation Layer (SEAL) [I-D.templin-intarea-seal] and can therefore 206 configure an unlimited Maximum Transmission Unit (MTU). This entails 207 the insertion of a SEAL header (i.e., an IPv6 fragment header with 208 the S bit set to 1) between the inner IPv6 header and the outer IP 209 encapsulation header. When NAT traversal and/or filtering middlebox 210 traversal is necessary, a UDP header is further inserted between the 211 outer IP encapsulation header and the SEAL header. (Note that while 212 [RFC6980] forbids fragmentation of IPv6 ND messages, the SEAL 213 fragmentation header applies only to the outer tunnel encapsulation 214 and not the inner IPv6 ND packet.) 216 AERO interfaces maintain a neighbor cache and use an adaptation of 217 standard unicast IPv6 ND messaging in which Router Solicitation (RS), 218 Router Advertisement (RA), Neighbor Solicitation (NS) and Neighbor 219 Advertisement (NA) messages do not include Source/Target Link Layer 220 Address Options (S/TLLAO). Instead, AERO nodes determine the link- 221 layer addresses of neighbors by examining the encapsulation source 222 address of any RS/RA/NS/NA messages they receive and ignore any 223 S/TLLAOs included in these messages. This is vital to the operation 224 of AERO in environments in which AERO neighbors are separated by 225 Network Address Translators (NATs) - either IPv4 or IPv6. 227 AERO Redirect messages include a TLLAO the same as for any IPv6 link. 228 The TLLAO includes the link-layer address of the target node, 229 including both the IP address and the UDP source port number used by 230 the target when it sends UDP-encapsulated packets over the AERO 231 interface (the TLLAO instead encodes the value 0 when the target does 232 not use UDP encapsulation). TLLAOs for target nodes that use an IPv6 233 underlying address include the full 16 bytes of the IPv6 address as 234 shown in Figure 1, while TLLAOs for target nodes that use an IPv4 235 underlying address include only the 4 bytes of the IPv4 address as 236 shown in Figure 2. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type = 2 | Length = 3 | UDP Source Port (or 0) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Reserved | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 +-- --+ 247 | | 248 +-- IPv6 Address --+ 249 | | 250 +-- --+ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 1: AERO TLLAO Format for IPv6 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type = 2 | Length = 1 | UDP Source Port (or 0) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | IPv4 Address | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 2: AERO TLLAO Format for IPv4 266 Finally, nodes on AERO interfaces use a simple data origin 267 authentication for encapsulated packets they receive from other 268 nodes. In particular, AERO Clients accept encapsulated packets with 269 a link-layer source address belonging to their current AERO Server. 270 AERO nodes also accept encapsulated packets with a link-layer source 271 address that is correct for the network-layer source address. The 272 AERO node considers the link-layer source address correct for the 273 network-layer source address if there is an IPv6 route that matches 274 the network-layer source address as well as a neighbor cache entry 275 corresponding to the next hop that includes the link-layer address. 277 3.2. AERO Node Types 279 AERO Servers configure their AERO link interfaces as advertising 280 router interfaces (see [RFC4861], Section 6.2.2) and may therefore 281 send Router Advertisement (RA) messages that include non-zero Router 282 Lifetimes. 284 AERO Clients configure their AERO link interfaces as non-advertising 285 router interfaces, i.e., even if the AERO Client otherwise displays 286 the outward characteristics of an ordinary host (for example, the 287 Client may internally configure both an AERO interface and (virtual) 288 EUN interfaces). AERO Clients are provisioned with IPv6 Prefix 289 Delegations either through a DHCPv6 Prefix Delegation exchange with 290 an AERO Server over the AERO link or via a static delegation obtained 291 through an out-of-band exchange with an AERO link prefix delegation 292 authority. 294 AERO Relays relay packets between Servers connected to the same AERO 295 link and also forward packets between the AERO link and the native 296 IPv6 network. The relaying process entails re-encapsulation of IPv6 297 packets that were received from a first AERO Server and are to be 298 forwarded without modification to a second AERO Server. 300 3.3. AERO Addresses 302 An AERO address is an IPv6 link-local address assigned to an AERO 303 interface and with a 64-bit IPv6 prefix embedded within the interface 304 identifier. The AERO address is formatted as: 306 fe80::[64-bit IPv6 prefix] 308 Each AERO Client configures an AERO address based on the delegated 309 prefix it has received from the AERO link prefix delegation 310 authority. The address begins with the prefix fe80::/64 and includes 311 in its interface identifier the base /64 prefix taken from the 312 Client's delegated IPv6 prefix. The base prefix is determined by 313 masking the delegated prefix with the prefix length. For example, if 314 an AERO Client has received the prefix delegation: 316 2001:db8:1000:2000::/56 318 it would construct its AERO address as: 320 fe80::2001:db8:1000:2000 322 An AERO Client may receive multiple IPv6 prefix delegations, in which 323 case it would configure multiple AERO addresses - one for each 324 delegated prefix. 326 Each AERO Server configures the special AERO address fe80::1 to 327 support the operation of IPv6 Neighbor Discovery over the AERO link; 328 the address therefore has the properties of an IPv6 Anycast address. 329 While all Servers configure the same AERO address and therefore 330 cannot be distinguished from one another at the network layer, 331 Clients can still distinguish Servers at the link layer by examining 332 the Servers' link-layer addresses. 334 Nodes that are configured as pure AERO Relays (i.e., and that do not 335 also act as Servers) do not configure an IPv6 address of any kind on 336 their AERO interfaces. The Relay's AERO interface is therefore used 337 purely for transit and does not participate in IPv6 ND message 338 exchanges. 340 3.4. AERO Reference Operational Scenario 342 Figure 3 depicts the AERO reference operational scenario. The figure 343 shows an AERO Server('A'), two AERO Clients ('B', 'D') and three 344 ordinary IPv6 hosts ('C', 'E', 'F'): 346 .-(::::::::) 347 .-(::: IPv6 :::)-. +-------------+ 348 (:::: Internet ::::)--| Host F | 349 `-(::::::::::::)-' +-------------+ 350 `-(::::::)-' 2001:db8:3::1 351 | 352 +--------------+ 353 | AERO Server A| 354 | (C->B; E->D) | 355 +--------------+ 356 fe80::1 357 L2(A) 358 | 359 X-----+-----------+-----------+--------X 360 | AERO Link | 361 L2(B) L2(D) 362 fe80::2001:db8:0:0 fe80::2001:db8:1:0 .-. 363 +--------------+ +--------------+ ,-( _)-. 364 | AERO Client B| | AERO Client D| .-(_ IPv6 )-. 365 | (default->A) | | (default->A) |--(__ EUN ) 366 +--------------+ +--------------+ `-(______)-' 367 2001:DB8:0::/48 2001:DB8:1::/48 | 368 | 2001:db8:1::1 369 .-. +-------------+ 370 ,-( _)-. 2001:db8:0::1 | Host E | 371 .-(_ IPv6 )-. +-------------+ +-------------+ 372 (__ EUN )--| Host C | 373 `-(______)-' +-------------+ 375 Figure 3: AERO Reference Operational Scenario 377 In Figure 3, AERO Server ('A') connects to the AERO link and connects 378 to the IPv6 Internet, either directly or via other IPv6 routers (not 379 shown). Server ('A') assigns the address fe80::1 to its AERO 380 interface with link-layer address L2(A). Server ('A') next arranges 381 to add L2(A) to a published list of valid Servers for the AERO link. 383 AERO Client ('B') assigns the address fe80::2001:db8:0:0 to its AERO 384 interface with link-layer address L2(B). Client ('B') configures a 385 default route via the AERO interface with next-hop network-layer 386 address fe80::1 and link-layer address L2(A), then sub-delegates the 387 prefix 2001:db8:0::/48 to its attached EUNs. IPv6 host ('C') 388 connects to the EUN, and configures the network-layer address 2001: 389 db8:0::1. 391 AERO Client ('D') assigns the address fe80::2001:db8:1:0 to its AERO 392 interface with link-layer address L2(D). Client ('D') configures a 393 default route via the AERO interface with next-hop network-layer 394 address fe80::1 and link-layer address L2(A), then sub-delegates the 395 network-layer prefix 2001:db8:1::/48 to its attached EUNs. IPv6 host 396 ('E') connects to the EUN, and configures the network-layer address 397 2001:db8:1::1. 399 Finally, IPv6 host ('F') connects to an IPv6 network outside of the 400 AERO link domain. Host ('F') configures its IPv6 interface in a 401 manner specific to its attached IPv6 link, and assigns the network- 402 layer address 2001:db8:3::1 to its IPv6 link interface. 404 3.5. AERO Prefix Delegation and Router Discovery 406 3.5.1. AERO Client Behavior 408 AERO Clients observe the IPv6 router requirements defined in 409 [RFC6434] except that they act as "hosts" on their AERO interfaces 410 for the purpose of prefix delegation and router discovery in the same 411 fashion as for IPv6 Customer Premises Equipment (CPE) routers 412 [RFC6204]. AERO Clients first discover the link-layer address of an 413 AERO Server via static configuration, or through an automated means 414 such as DNS name resolution. In the absence of other information, 415 the Client resolves the name "linkupnetworks.[domainname]", where 416 [domainname] is the DNS domain appropriate for the Client's attached 417 underlying network. 419 After discovering the link-layer address, the Client then acts as a 420 requesting router to obtain IPv6 prefixes through DHCPv6 Prefix 421 Delegation [RFC3633] via the Server. (The Client can also obtain 422 prefixes through out-of-band means such as static administrative 423 configuration, etc.). After the Client acquires prefixes, it sub- 424 delegates them to nodes and links within its attached EUNs. It also 425 assigns the link-local AERO address(es) taken from its delegated 426 prefix(es) to the AERO interface (see: Section 3.3). 428 After acquiring prefixes, the Client next prepares a unicast IPv6 429 Router Solicitation (RS) message using its AERO address as the 430 network-layer source address and fe80::1 as the network-layer 431 destination address. The Client then tunnels the packet to the 432 Server using one of its underlying addresses as the link-layer source 433 address and using an underlying address of the Server as the link- 434 layer destination address. The Server in turn returns a unicast 435 Router Advertisement (RA) message, which the Client uses to create an 436 IPv6 neighbor cache entry for the Server on the AERO interface per 437 [RFC4861]. The link-layer address for the neighbor cache entry is 438 taken from the link-layer source address of the RA message. 440 After obtaining prefixes and performing an initial RS/RA exchange 441 with a Server, the Client continues to send periodic RS messages to 442 the server to obtain new RAs in order to keep neighbor cache entries 443 alive. The Client can also forward IPv6 packets destined to networks 444 beyond its local EUNs via the Server as an IPv6 default router. The 445 Server may in turn return a Redirect message informing the Client of 446 a neighbor on the AERO link that is topologically closer to the final 447 destination as specified in Section 3.6. 449 3.5.2. AERO Server Behavior 451 AERO Servers observe the IPv6 router requirements defined in 452 [RFC6434]. They further configure a DHCPv6 relay/server function on 453 their AERO links and/or provide an administrative interface for 454 delegation of network-layer addresses and prefixes. When the Server 455 delegates prefixes, it also establishes forwarding table entries that 456 list the AERO address of the Client as the next hop toward the 457 delegated IPv6 prefixes (where the AERO address is constructed as 458 specified in Section 3.3). 460 Servers respond to RS messages from Clients on their advertising AERO 461 interfaces by returning an RA message. When the Server receives an 462 RS message, it creates or updates a neighbor cache entry using the 463 network layer source address as the neighbor's network layer address 464 and using the link-layer source address of the RS message as the 465 neighbor's link-layer address. 467 When the Server forwards a packet via the same AERO interface on 468 which it arrived, it initiates an AERO route optimization procedure 469 as specified in Section 3.6. 471 3.6. AERO Redirection 473 Section 3.4 describes the AERO reference operational scenario. We 474 now discuss the operation and protocol details of AERO Redirection 475 with respect to this reference scenario. 477 3.6.1. Classical Redirection Approaches 479 With reference to Figure 3, when the IPv6 source host ('C') sends a 480 packet to an IPv6 destination host ('E'), the packet is first 481 forwarded via the EUN to AERO Client ('B'). Client ('B') then 482 forwards the packet over its AERO interface to AERO Server ('A'), 483 which then forwards the packet to AERO Client ('D'), where the packet 484 is finally forwarded to the IPv6 destination host ('E'). When Server 485 ('A') forwards the packet back out on its advertising AERO interface, 486 it must arrange to redirect Client ('B') toward Client ('D') as a 487 better next-hop node on the AERO link that is closer to the final 488 destination. However, this redirection process applied to AERO 489 interfaces must be more carefully orchestrated than on ordinary links 490 since the parties may be separated by potentially many underlying 491 network routing hops. 493 Consider a first alternative in which Server ('A') informs Client 494 ('B') only and does not inform Client ('D') (i.e., "classical 495 redirection"). In that case, Client ('D') has no way of knowing that 496 Client ('B') is authorized to forward packets from their claimed 497 network-layer source addresses, and it may simply elect to drop the 498 packets. Also, Client ('B') has no way of knowing whether Client 499 ('D') is performing some form of source address filtering that would 500 reject packets arriving from a node other than a trusted default 501 router, nor whether Client ('D') is even reachable via a direct path 502 that does not involve Server ('A'). 504 Consider a second alternative in which Server ('A') informs both 505 Client ('B') and Client ('D') separately, via independent redirection 506 control messages (i.e., "augmented redirection"). In that case, if 507 Client ('B') receives the redirection control message but Client 508 ('D') does not, subsequent packets sent by Client ('B') could be 509 dropped due to filtering since Client ('D') would not have a route to 510 verify their source network-layer addresses. Also, if Client ('D') 511 receives the redirection control message but Client ('B') does not, 512 subsequent packets sent in the reverse direction by Client ('D') 513 would be lost. 515 Since both of these alternatives have shortcomings, a new redirection 516 technique (i.e., "AERO redirection") is needed. 518 3.6.2. AERO Redirection Concept of Operations 520 Again, with reference to Figure 3, when source host ('C') sends a 521 packet to destination host ('E'), the packet is first forwarded over 522 the source host's attached EUN to Client ('B'), which then forwards 523 the packet via its AERO interface to Server ('A'). 525 Using AERO redirection, Server ('A') then forwards the packet out the 526 same AERO interface toward Client ('D') and also sends an AERO 527 "Predirect" message forward to Client ('D') as specified in 528 Section 3.6.4. The Predirect message includes Client ('B')'s 529 network- and link-layer addresses as well as information that Client 530 ('D') can use to determine the IPv6 prefix used by Client ('B') . 531 After Client ('D') receives the Predirect message, it process the 532 message and returns an AERO Redirect message destined for Client 533 ("B") via Server ('A') as specified in Section 3.6.5. During the 534 process, Client ('D') also creates or updates a neighbor cache entry 535 for Client ('B'), and creates an IPv6 route for Client ('B')'s IPv6 536 prefix. 538 When Server ('A') receives the Redirect message, it processes the 539 message and forwards it on to Client ('B') as specified in 540 Section 3.6.6. The message includes Client ('D')'s network- and 541 link-layer addresses as well as information that Client ('B') can use 542 to determine the IPv6 prefix used by Client ('D'). After Client 543 ('B') receives the Redirect message, it processes the message as 544 specified in Section 3.6.7. During the process, Client ('B') also 545 creates or updates a neighbor cache entry for Client ('D'), and 546 creates an IPv6 route for Client ('D')'s IPv6 prefix. 548 Following the above Predirect/Redirect message exchange, forwarding 549 of packets from Client ('B') to Client ('D') without involving Server 550 ('A) as an intermediary is enabled. The mechanisms that support this 551 exchange are specified in the following sections. 553 3.6.3. AERO Redirection Message Format 555 AERO Redirect/Predirect messages use the same format as for ICMPv6 556 Redirect messages depicted in Section 4.5 of [RFC4861], but also 557 include a new field (the "Prefix Length" field) taken from the 558 Redirect message Reserved field. The Redirect/Predirect messages are 559 formatted as shown in Figure 4: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type (=137) | Code (=0/1) | Checksum | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Prefix Length | Reserved | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 + + 570 | | 571 + Target Address + 572 | | 573 + + 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | | 577 + + 578 | | 579 + Destination Address + 580 | | 581 + + 582 | | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Options ... 585 +-+-+-+-+-+-+-+-+-+-+-+- 587 Figure 4: AERO Redirect/Predirect Message Format 589 3.6.4. Sending Predirects 591 When an AERO Server forwards a packet out the same AERO interface 592 that it arrived on, the Server sends a Predirect message forward 593 toward the AERO Client nearest the destination instead of sending a 594 Redirect message back to AERO Client nearest the source. 596 In the reference operational scenario, when Server ('A') forwards a 597 packet sent by Client ('B') toward Client ('D'), it also sends a 598 Predirect message forward toward Client ('D'), subject to rate 599 limiting (see Section 8.2 of [RFC4861]). Server ('A') prepares the 600 Predirect message as follows: 602 o the link-layer source address is set to 'L2(A)' (i.e., the 603 underlying address of Server ('A')). 605 o the link-layer destination address is set to 'L2(D)' (i.e., the 606 underlying address of Client ('D')). 608 o the network-layer source address is set to fe80::1 (i.e., the AERO 609 address of Server ('A')). 611 o the network-layer destination address is set to fe80::2001:db8:1:0 612 (i.e., the AERO address of Client ('D')). 614 o the Type is set to 137. 616 o the Code is set to 1 to indicate "Predirect". 618 o the Prefix Length is set to the length of the prefix to be applied 619 to Target address. 621 o the Target Address is set to fe80::2001:db8:0::0 (i.e., the AERO 622 address of Client ('B')). 624 o the Destination Address is set to the IPv6 source address of the 625 packet that triggered the Predirection event. 627 o the message includes a TLLAO set to 'L2(B)' (i.e., the underlying 628 address of Client ('B')). 630 o the message includes a Redirected Header Option (RHO) that 631 contains the originating packet truncated to ensure that at least 632 the network-layer header is included but the size of the message 633 does not exceed 1280 bytes. 635 Server ('A') then sends the message forward to Client ('D'). 637 3.6.5. Processing Predirects and Sending Redirects 639 When Client ('D') receives a Predirect message, it accepts the 640 message only if it has a link-layer source address of the Server, 641 i.e. 'L2(A)'. Client ('D') further accepts the message only if it 642 is willing to serve as a redirection target. Next, Client ('D') 643 validates the message according to the ICMPv6 Redirect message 644 validation rules in Section 8.1 of [RFC4861]. 646 In the reference operational scenario, when the Client ('D') receives 647 a valid Predirect message, it either creates or updates a neighbor 648 cache entry that stores the Target Address of the message as the 649 network-layer address of Client ('B') and stores the link-layer 650 address found in the TLLAO as the link-layer address of Client ('B'). 651 Client ('D') then applies the Prefix Length to the Interface 652 Identifier portion of the Target Address and records the resulting 653 IPv6 prefix in its IPv6 forwarding table. 655 After processing the message, Client ('D') prepares a Redirect 656 message response as follows: 658 o the link-layer source address is set to 'L2(D)' (i.e., the link- 659 layer address of Client ('D')). 661 o the link-layer destination address is set to 'L2(A)' (i.e., the 662 link-layer address of Server ('A')). 664 o the network-layer source address is set to 'L3(D)' (i.e., the AERO 665 address of Client ('D')). 667 o the network-layer destination address is set to 'L3(B)' (i.e., the 668 AERO address of Client ('B')). 670 o the Type is set to 137. 672 o the Code is set to 0 to indicate "Redirect". 674 o the Prefix Length is set to the length of the prefix to be applied 675 to the Target and Destination address. 677 o the Target Address is set to fe80::2001:db8:1::1 (i.e., the AERO 678 address of Client ('D')). 680 o the Destination Address is set to the IPv6 destination address of 681 the packet that triggered the Redirection event. 683 o the message includes a TLLAO set to 'L2(D)' (i.e., the underlying 684 address of Client ('D')). 686 o the message includes as much of the RHO copied from the 687 corresponding AERO Predirect message as possible such that at 688 least the network-layer header is included but the size of the 689 message does not exceed 1280 bytes. 691 After Client ('D') prepares the Redirect message, it sends the 692 message to Server ('A'). 694 3.6.6. Re-encapsulating and Forwarding Redirects 696 When Server ('A') receives a Redirect message, it accepts the message 697 only if it has a neighbor cache entry that associates the message's 698 link-layer source address with the network-layer source address. 699 Next, Server ('A') validates the message according to the ICMPv6 700 Redirect message validation rules in Section 8.1 of [RFC4861]. 701 Following validation, Server ('A') re-encapsulates the Redirect as 702 discussed in [I-D.templin-intarea-seal], and then forwards a re- 703 encapsulated Redirect on to Client ('B') as follows. 705 In the reference operational scenario, Server ('A') receives the 706 Redirect message from Client ('D') and prepares to forward a 707 corresponding Redirect message to Client ('B'). Server ('A') then 708 verifies that Client ('D') is authorized to use the Prefix Length in 709 the Redirect message when applied to the AERO address in the network- 710 layer source of the Redirect message, and discards the message if 711 verification fails. Otherwise, Server ('A') re-encapsulates the 712 redirect by changing the link-layer source address of the message to 713 'L2(A)', changing the network-layer source address of the message to 714 fe80::1, and changing the link-layer destination address to 'L2(B)' . 715 Server ('A') finally forwards the re-encapsulated message to the 716 ingress node ('B') without decrementing the network-layer IPv6 header 717 Hop Limit field. 719 While not shown in Figure 3, AERO Relays forward Redirect and 720 Predirect messages in exactly this same fashion described above. See 721 Figure 5 in Appendix A for an extension of the reference operational 722 scenario that includes Relays. 724 3.6.7. Processing Redirects 726 When Client ('B') receives the Redirect message, it accepts the 727 message only if it has a link-layer source address of the Server, 728 i.e. 'L2(A)'. Next, Client ('B') validates the message according to 729 the ICMPv6 Redirect message validation rules in Section 8.1 of 730 [RFC4861]. Following validation, Client ('B') then processes the 731 message as follows. 733 In the reference operational scenario, when Client ('B') receives the 734 Redirect message, it either creates or updates a neighbor cache entry 735 that stores the Target Address of the message as the network-layer 736 address of Client ('D') and stores the link-layer address found in 737 the TLLAO as the link-layer address of Client ('D'). Client ('B') 738 then applies the Prefix Length to the Interface Identifier portion of 739 the Target Address and records the resulting IPv6 prefix in its IPv6 740 forwarding table. 742 Now, Client ('B') has an IPv6 forwarding table entry for 743 Client('D')'s prefix, and Client ('D') has an IPv6 forwarding table 744 entry for Client ('B')'s prefix. Thereafter, the clients may 745 exchange ordinary network-layer data packets directly without 746 forwarding through Server ('A'). 748 3.6.8. Neighbor Reachability Considerations 750 When Client ('B') receives a redirection message informing it of 751 Client ('D') as a better next hop, there is a question in point as to 752 whether Client ('D') can be reached directly without forwarding 753 through Server ('A'). On some AERO links, it may be reasonable for 754 Client ('B') to (optimistically) assume that reachability is 755 transitive, and to immediately begin forwarding data packets to 756 Client ('D') without testing reachability. 758 On AERO links in which an optimistic assumption of transitive 759 reachability may be unreasonable, however, Client ('B') can continue 760 to send packets via Server ('A') until it tests the direct path to 761 Client ('D'), e.g., by sending an initial NS message to elicit an NA 762 response. The Clients thereafter follow the Neighbor Unreachability 763 Detection (NUD) procedures in Section 7.3 of [RFC4861], and can 764 resume sending packets via Server ('A') at any time the direct path 765 appears to be failing. 767 If Client ('B') is unable to elicit an NA response from Client ('D') 768 after MAX_RETRY attempts, it should consider the direct path to be 769 unusable for forwarding purposes but still viable for ingress 770 filtering purposes. 772 If a direct path between the Clients can be established, they can 773 thereafter process any link-layer errors as a hint that the direct 774 path has either failed or has become intermittent. 776 3.6.9. Mobility and Link-Layer Address Change Considerations 778 When Client ('B') needs to change its link-layer address (e.g., due 779 to a mobility event, due to a change in underlying network interface, 780 etc.), it sends an immediate NS message forward to Client ('D'), 781 which then discovers the new link-layer address. 783 If both Client ('B') and Client ('D') change their link-layer 784 addresses simultaneously, the NS/NA exchanges between the two 785 neighbors may fail. In that case, the Clients follow the same 786 neighbor unreachability procedures specified in Section 3.7.9. 788 3.6.10. Underlying Protocol Version Considerations 790 Again with reference to Figure 3, Client ('B') may connect only to an 791 IPvX underlying network, while Client ('D') connects only to an IPvY 792 underlying network. In that case, Client ('B') has no means for 793 reaching Client ('D') directly (since they connect to underlying 794 networks of different IP protocol versions) and so must ignore any 795 Redirects and continue to send packets via Server ('A'). 797 4. Implementation Status 799 An early implementation is available at: 801 http://linkupnetworks.com/seal/sealv2-1.0.tgz. 803 5. IANA Considerations 805 There are no IANA actions required for this document. 807 6. Security Considerations 809 AERO link security considerations are the same as for standard IPv6 810 Neighbor Discovery [RFC4861] except that AERO improves on some 811 aspects. In particular, AERO is dependent on a trust basis between 812 AERO Clients and Servers, where the Clients only engage in the AERO 813 mechanism when it is facilitated by a trusted Server. 815 AERO links must be protected against link-layer address spoofing 816 attacks in which an attacker on the link pretends to be a trusted 817 neighbor. Links that provide link-layer securing mechanisms (e.g., 818 WiFi networks) and links that provide physical security (e.g., 819 enterprise network LANs) provide a first line of defense that is 820 often sufficient. In other instances, securing mechanisms such as 821 Secure Neighbor Discovery (SeND) [RFC3971] or IPsec [RFC4301] must be 822 used. 824 7. Acknowledgements 826 Discussions both on the v6ops list and in private exchanges helped 827 shape some of the concepts in this work. Individuals who contributed 828 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 829 Brian Carpenter, Brian Haberman, Joel Halpern, and Lee Howard. 830 Members of the IESG also provided valuable input during their review 831 process that greatly improved the document. Special thanks go to 832 Stewart Bryant, Joel Halpern and Brian Haberman for their shepherding 833 guidance. 835 This work has further been encouraged and supported by Boeing 836 colleagues including Balaguruna Chidambaram, Jeff Holland, Cam 837 Brodie, Yueli Yang, Wen Fang, Ed King, Mike Slane, Kent Shuey, Gen 838 MacLean, and other members of the BR&T and BIT mobile networking 839 teams. 841 Earlier works on NBMA tunneling approaches are found in 842 [RFC2529][RFC5214][RFC5569]. 844 8. References 845 8.1. Normative References 847 [I-D.templin-intarea-seal] 848 Templin, F., "The Subnetwork Encapsulation and Adaptation 849 Layer (SEAL)", draft-templin-intarea-seal-65 (work in 850 progress), October 2013. 852 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 853 August 1980. 855 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 856 September 1981. 858 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 859 RFC 792, September 1981. 861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 862 Requirement Levels", BCP 14, RFC 2119, March 1997. 864 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 865 (IPv6) Specification", RFC 2460, December 1998. 867 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 868 IPv6 Specification", RFC 2473, December 1998. 870 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 871 for IPv6 Hosts and Routers", RFC 4213, October 2005. 873 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 874 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 875 September 2007. 877 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 878 Address Autoconfiguration", RFC 4862, September 2007. 880 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 881 Requirements", RFC 6434, December 2011. 883 8.2. Informative References 885 [IRON] Templin, F., "The Internet Routing Overlay Network 886 (IRON)", Work in Progress, June 2012. 888 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 889 Domains without Explicit Tunnels", RFC 2529, March 1999. 891 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 892 and M. Carney, "Dynamic Host Configuration Protocol for 893 IPv6 (DHCPv6)", RFC 3315, July 2003. 895 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 896 Host Configuration Protocol (DHCP) version 6", RFC 3633, 897 December 2003. 899 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 900 Neighbor Discovery (SEND)", RFC 3971, March 2005. 902 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 903 Internet Protocol", RFC 4301, December 2005. 905 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 906 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 907 March 2008. 909 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 910 Infrastructures (6rd)", RFC 5569, January 2010. 912 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 913 Troan, "Basic Requirements for IPv6 Customer Edge 914 Routers", RFC 6204, April 2011. 916 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 917 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 919 Appendix A. AERO Server and Relay Interworking 921 Figure 3 depicts a reference AERO operational scenario with a single 922 Server on the AERO link. In order to support scaling to larger 923 numbers of nodes, the AERO link can deploy multiple Servers and 924 Relays, e.g., as shown in Figure 5. 926 .-(::::::::) 927 .-(::: IPv6 :::)-. 928 (:: Internetwork ::) 929 `-(::::::::::::)-' 930 `-(::::::)-' 931 | 932 +--------------+ +------+-------+ +--------------+ 933 |AERO Server C | | AERO Relay D | |AERO Server E | 934 | (default->D) | | (A->C; G->E) | | (default->D) | 935 | (A->B) | +-------+------+ | (G->F) | 936 +-------+------+ | +------+-------+ 937 | | | 938 X---+---+-------------------+------------------+---+---X 939 | AERO Link | 940 +-----+--------+ +--------+-----+ 941 |AERO Client B | |AERO Client F | 942 | (default->C) | | (default->E) | 943 +--------------+ +--------------+ 944 .-. .-. 945 ,-( _)-. ,-( _)-. 946 .-(_ IPv6 )-. .-(_ IPv6 )-. 947 (__ EUN ) (__ EUN ) 948 `-(______)-' `-(______)-' 949 | | 950 +--------+ +--------+ 951 | Host A | | Host G | 952 +--------+ +--------+ 954 Figure 5: AERO Server/Relay Interworking 956 In this example, AERO Client ('B') associates with AERO Server ('C'), 957 while AERO Client ('F') associates with AERO Server ('E'). 958 Furthermore, AERO Servers ('C') and ('E') do not associate with each 959 other directly, but rather have an association with AERO Relay ('D') 960 (i.e., a router that has full topology information concerning its 961 associated Servers and their Clients). Relay ('D') connects to the 962 AERO link, and also connects to the native IPv6 Internetwork. 964 When host ('A') sends a packet toward destination host ('G'), IPv6 965 forwarding directs the packet through the EUN to Client ('B'), which 966 forwards the packet to Server ('C') in absence of more-specific 967 forwarding information. Server ('C') forwards the packet, and it 968 also generates an AERO Predirect message that is then forwarded 969 through Relay ('D') to Server ('E'). When Server ('E') receives the 970 message, it forwards the message to Client ('F'). 972 After processing the AERO Predirect message, Client ('F') sends an 973 AERO Redirect message to Server ('E'). Server ('E'), in turn, 974 forwards the message through Relay ('D') to Server ('C'). When 975 Server ('C') receives the message, it forwards the message to Client 976 ('B') informing it that host 'G's EUN can be reached via Client 977 ('F'), thus completing the AERO redirection. 979 The network layer routing information shared between Servers and 980 Relays must be carefully coordinated in a manner outside the scope of 981 this document. In particular, Relays require full topology 982 information, while individual Servers only require partial topology 983 information (i.e., they only need to know the EUN prefixes associated 984 with their current set of Clients). See [IRON] for an architectural 985 discussion of routing coordination between Relays and Servers. 987 Author's Address 989 Fred L. Templin (editor) 990 Boeing Research & Technology 991 P.O. Box 3707 992 Seattle, WA 98124 993 USA 995 Email: fltemplin@acm.org