idnits 2.17.1 draft-templin-aero-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 05, 2011) is 4525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 900, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-ietf-savi-framework-05 == Outdated reference: A later version (-16) exists of draft-templin-ironbis-09 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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 Intended status: Informational December 05, 2011 5 Expires: June 7, 2012 7 Asymmetric Extended Route Optimization (AERO) 8 draft-templin-aero-05.txt 10 Abstract 12 Nodes attached to link types such as multicast-capable, shared media 13 and non-broadcast multiple access (NBMA), etc. can exchange packets 14 as neighbors on the link. Each node should therefore be able to 15 discover a trusted neighboring gateway that can provide default 16 routing services to reach off-link destinations, and should also 17 accept redirection messages from the gateway informing it of a 18 different neighbor that is closer to the final destination. This 19 redirect function can provide a useful route optimization, since the 20 triangular path from the ingress link neighbor, to the gateway, and 21 finally to the egress link neighbor may be considerably longer than 22 the direct path between the neighbors. However, ordinary redirection 23 may lead to operational issues on certain link types and/or in 24 certain deployment scenarios. This document therefore introduces an 25 Asymmetric Extended Route Optimization (AERO) capability that 26 addresses the issues. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 7, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5 66 4.1. AERO Link Dynamic Routing . . . . . . . . . . . . . . . . 5 67 4.2. AERO Node Behavior . . . . . . . . . . . . . . . . . . . . 6 68 4.2.1. AERO Node Types . . . . . . . . . . . . . . . . . . . 6 69 4.2.2. Source Address Verification . . . . . . . . . . . . . 6 70 4.2.3. AERO Host Behavior . . . . . . . . . . . . . . . . . . 7 71 4.2.4. AERO Router Behavior . . . . . . . . . . . . . . . . . 7 72 4.2.5. AERO Gateway Behavior . . . . . . . . . . . . . . . . 7 73 4.3. AERO Reference Operational Scenario . . . . . . . . . . . 8 74 4.4. AERO Specification . . . . . . . . . . . . . . . . . . . . 9 75 4.4.1. Sending Predirects . . . . . . . . . . . . . . . . . . 11 76 4.4.2. Processing Predirects and Sending Redirects . . . . . 13 77 4.4.3. Proxying Redirects . . . . . . . . . . . . . . . . . . 14 78 4.4.4. Processing Redirects . . . . . . . . . . . . . . . . . 14 79 4.4.5. Sending Periodic Predirect Keepalives . . . . . . . . 15 80 4.4.6. Reachability Considerations . . . . . . . . . . . . . 16 81 4.5. Mobility Considerations . . . . . . . . . . . . . . . . . 17 82 4.6. Scaling Considerations . . . . . . . . . . . . . . . . . . 18 83 4.7. Proxy Chaining . . . . . . . . . . . . . . . . . . . . . . 18 84 4.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 19 85 4.9. Alternate Means of Source Address Verification . . . . . . 19 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 Nodes attached to link types such as multicast-capable, shared media, 97 non-broadcast multiple access (NBMA), etc. can exchange packets with 98 each other as neighbors on the link. Each node should therefore be 99 able to discover a trusted neighboring gateway that can provide 100 default routing services to reach off-link destinations, and should 101 also accept redirection messages from the gateway informing it of a 102 different neighbor that is closer to the final destination. This 103 redirect function can provide a useful route optimization, since the 104 triangular path from the ingress link neighbor, to the gateway, and 105 finally to the egress link neighbor may be considerably longer than 106 the direct path between the neighbors. However, ordinary redirection 107 may lead to operational issues on certain link types and/or in 108 certain deployment scenarios. 110 For example, when an ingress link neighbor accepts an ordinary 111 redirect message from a gateway, it has no way of knowing whether the 112 egress link neighbor is ready and willing to accept packets directly 113 without involving the gateway. In particular, without involvement 114 from the gateway, the egress would have no way of knowing that the 115 ingress is authorized to forward packets from a given source address. 116 (This is especially important for very large links, since any node on 117 the link can spoof the network-layer source address with low 118 probability of detection even if the link-layer source address cannot 119 be spoofed.) Additionally, the ingress would have no way of knowing 120 whether the direct path to the egress has failed, nor whether the 121 final destination has moved away from the egress to some other 122 network attachment point. 124 Therefore, a new redirection approach is required that can enable a 125 reliable one-way handshake from the egress to the ingress link node 126 under the mediation of trusted gateways. The mechanism is asymmetric 127 (since only the forward direction from the ingress to the egress is 128 optimized) and extended (since the redirection extends forward to the 129 egress before reaching back to the ingress). This document therefore 130 introduces an Asymmetric Extended Route Optimization (AERO) 131 capability that addresses the issues. 133 While the AERO mechanisms were initially designed for the specific 134 purpose of NBMA tunnel virtual interfaces (e.g., see: 135 [RFC2529][RFC5214][RFC5569][I-D.templin-ironbis]) they can also be 136 applied to any link types that support redirection 137 [RFC0792][RFC4861]. The rest of this document refers to this class 138 of links collectively as "AERO links". 140 The AERO techniques apply to both the IPv4 [RFC0791] and IPv6 141 [RFC2460] protocols, as well as any other network layer protocol that 142 includes link models that can support redirection. 144 2. Terminology 146 The terminology in the normative references apply; the following 147 terms are defined within the scope of this document: 149 AERO link 150 any link over which the AERO mechanisms can be applied. 152 AERO node 153 a gateway, router or host connected to an AERO link. 155 AERO gateway 156 a router that configures an advertising router interface on the 157 AERO link, and that can provide default routing services for 158 forwarding packets toward their final destinations. 160 AERO router 161 a router that configures a non-advertising router interface on the 162 AERO link, and that connects End User Networks to the AERO link. 164 AERO host 165 a simple host on the AERO link. 167 ingress AERO node ("ingress") 168 a node that injects packets into the AERO link. 170 egress AERO node ("egress") 171 a node that receives packets from the AERO link. 173 3. Requirements 175 The route optimization mechanism must satisfy the following 176 requirements: 178 Req 1: Off-load traffic from performance-critical gateways 179 The mechanism must offload sustained transit though a gateway that 180 would otherwise become a traffic concentrator. 182 Req 2: Support route optimization 183 Ingress nodes must be able to send packets directly to egress 184 nodes without involving a gateway as an intermediary hop. 186 Req 3: Support multiple levels of hierarchy 187 For scaling purposes, allow multiple levels of hierarchy in which 188 gateways in higher levels have progressively more topology 189 knowledge than those in lower levels. 191 Req 4: Do not circumvent ingress filtering 192 The mechanism must not open an attack vector where network-layer 193 source address spoofing is enabled even when link-layer source 194 address spoofing is disabled. 196 Req 5: Do not expose packets to loss due to filtering 197 The ingress node must have a way of knowing that the egress node 198 will accept its forwarded packets. 200 Req 6: Do not expose packets to loss due to path failure 201 The ingress node must have a way of discovering whether the egress 202 has gone unreachable on the route optimized path. 204 Req 7: Do not introduce routing loops 205 The gateway must not perform a route optimization that would cause 206 a routing loop to form. 208 Req 8: Support mobility 209 The mechanism must continue to work even if the final destination 210 node/network moves from a first egress node and re-associates with 211 a second egress node. 213 4. Asymmetric Extended Route Optimization (AERO) 215 The following sections specify an Asymmetric Extended Route 216 Optimization (AERO) capability that fulfills the requirements 217 specified in Section 3. 219 4.1. AERO Link Dynamic Routing 221 In many AERO link use case scenarios (e.g., small enterprise 222 networks, small and stable MANETs, etc.), AERO gateways and routers 223 can engage in a proactive dynamic routing protocol (e.g., OSPF, RIP, 224 IS-IS, etc.) so that routing/forwarding tables can be populated and 225 standard forwarding between routers can be used. In other scenarios 226 (e.g., large enterprise/ISP networks, cellular service provider 227 networks, dynamic MANETs, etc.), this might be impractical due to 228 routing protocol control message scaling issues. 230 When a proactive dynamic routing protocol cannot be used, the 231 mechanisms specified in this section can provide a useful on-demand 232 dynamic routing capability. 234 4.2. AERO Node Behavior 236 The following sections discuss characteristics of nodes attached to 237 links over which AERO can be used: 239 4.2.1. AERO Node Types 241 AERO gateways configure their AERO link interfaces as advertising 242 router interfaces (see: [RFC4861], Section 6.2.2), and therefore may 243 send Router Advertisement (RA) messages that include non-zero Router 244 Lifetimes. 246 AERO routers configure their AERO link interfaces as non-advertising 247 router interfaces. 249 AERO hosts configure their AERO link interfaces as simple host 250 interfaces. 252 4.2.2. Source Address Verification 254 AERO nodes must employ a source address verification check for the 255 packets they receive on an AERO interface in a manner that is 256 consistent with the Source Address Validation Improvement (SAVI) 257 Framework [I-D.ietf-savi-framework]. In order to perform source 258 address verification, the node considers the network-layer source 259 address correct for the link-layer source address if: 261 o the link-layer source address is the address of an AERO gateway, 262 or 264 o the link-layer source address is explicitly linked to the network- 265 layer source address (i.e., through stateless or stateful address 266 mapping), or 268 o the packet includes a signature that the node can use to 269 authenticate the source, or 271 o a ingress filtering and/or forwarding table entry exists that 272 lists the packet's link-layer source address as the link layer 273 address corresponding to the next hop toward the network-layer 274 source address on the AERO link. 276 The latter of these checks can be established through static 277 configuration, via a proactive dynamic routing protocol, or through 278 the AERO mechanisms specified in Section 4.4. 280 4.2.3. AERO Host Behavior 282 AERO hosts send Router Solicitation (RS) messages to obtain RA 283 messages from an AERO gateway. When the RA contains Prefix 284 Information Options with non-link-local prefixes, the host 285 autoconfigures addresses from the prefixes using Stateless Address 286 Autoconfiguration (SLAAC) [RFC4861][RFC4862]. When managed address 287 delegation services are available, the host can also (or instead) 288 acquire addresses taken from prefixes aggregated by the gateway 289 through the use of stateful mechanisms, e.g., DHCP 290 [RFC2131][RFC3315], manual configuration, etc. 292 After the host receives addresses, it assigns them to its AERO 293 interface and forwards any of its outbound packets via the gateway as 294 a default router. The host may subsequently receive redirection 295 messages from the gateway listing a better next hop. 297 4.2.4. AERO Router Behavior 299 AERO routers send RS messages to obtain RA messages from an AERO 300 gateway, i.e., they act as "hosts" on their non-advertising AERO link 301 router interfaces for the purpose of default router discovery. 303 The router can then acquire managed prefix delegations aggregated by 304 the gateway through the use of, e.g., DHCPv6 Prefix Delegation 305 [RFC3633], manual configuration, etc. in the same fashion as 306 described above for host-based autoconfiguration. 308 After the router acquires prefixes, it can sub-delegate them to nodes 309 and links within its attached End User Networks (EUNs), then can 310 forward any outbound packets coming from its EUNs via the gateway. 311 The router may subsequently receive redirection messages from the 312 gateway listing a better next hop. 314 4.2.5. AERO Gateway Behavior 316 AERO gateways respond to RS messages from hosts and routers on the 317 AERO link by returning an RA message. Gateways may further configure 318 a DHCP relay or server function on their AERO links and/or provide an 319 administrative interface for manual configuration of address/ 320 prefix-to-client forwarding table entries. 322 When the gateway completes a stateful address or prefix delegation 323 transaction (e.g., as a DHCP relay/server, etc.), it establishes 324 forwarding table entries that list the link-layer address of client 325 as the link-layer address of the next hop toward the delegated 326 addresses/prefixes. 328 When the gateway forwards a packet out the same AERO interface it 329 arrived on, it initiates an AERO route optimization procedure as 330 specified in Section 4.4. 332 4.3. AERO Reference Operational Scenario 334 Figure 1 depicts a reference AERO network topology. IPv6 is used 335 only as an example network layer protocol, and the same fundamental 336 AERO techniques can be applied for other network layer protocols. 337 The figure shows an AERO gateway ('A'), two non-advertising AERO 338 routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts 339 ('C', 'E', 'G') in a typical operational scenario: 340 .-(::::::::) 2001:db8:3::1 341 .-(::: IPv6 :::)-. +-------------+ 342 (:::: Internet ::::) | IPv6 Host G | 343 `-(::::::::::::)-' +-------------+ 344 `-(::::::)-' 345 ,................., 346 |companion gateway| 347 '.................' +---------------+ 348 +--------------+ | Host F | 349 | Gateway A | +---------------+ 350 +--------------+ 2001:db8:2:1 351 L3(A) L3(F) 352 L2(A) L2(F) 353 | AERO Link | 354 X-----+--+-----------------+--+---X 355 | | 356 L2(B) L2(D) .-. 357 L3(B) L3(D) ,-( _)-. 358 +--------------+ +--------------+ .-(_ IPv6 )-. 359 | Router B | | Router D |--(__ EUN ) 360 +--------------+ +--------------+ `-(______)-' 361 2001:db8:0::/48 2001:db8:1::/48 | 362 | 2001:db8:1::1 363 .-. +-------------+ 364 ,-( _)-. 2001:db8:0::1 | IPv6 Host E | 365 .-(_ IPv6 )-. +-------------+ +-------------+ 366 (__ EUN )--| IPv6 Host C | 367 `-(______)-' +-------------+ 369 Figure 1: Reference AERO Network Topology 371 In Figure 1, Gateway 'A' connects to the AERO link and also connects 372 to the IPv6 Internet, either directly or via a companion gateway. 373 'A' configures an AERO link interface with a link-local network-layer 374 address L3(A) and with link-layer address L2(A). 'A' next arranges 375 to add the link-layer address L2(A) to the list of valid gateways for 376 the link. 378 Router 'B' connects to one or more IPv6 EUNs and also connects to the 379 AERO link via an interface with a link-local network-layer address 380 L3(B) and with link-layer address L2(B). 'B' next configures a 381 default IPv6 route with next-hop address L3(A) via the AERO 382 interface, then receives the IPv6 prefix 2001:db8:0::/48 through a 383 stateful prefix delegation exchange via 'A'. 'B' finally sub- 384 delegates the prefix to its attached EUNs, where IPv6 host 'C' 385 autoconfigures the address 2001:db8:0::1. 387 Router 'D' connects to the AERO link via an interface with addresses 388 L3(D)/L2(D), configures a default IPv6 route with next-hop address 389 L3(A) via the AERO interface, and receives a stateful prefix 390 delegation of 2001:db8:1::/48 in the same fashion as for router 'B'. 391 'D' finally sub-delegates the prefix to its attached EUNs, where IPv6 392 host 'E' autoconfigures IPv6 address 2001:db8:1::1. 394 Host 'F' connects to the AERO link via an interface with addresses 395 L3(F)/L2(F). 'F' next configures a default IPv6 route with next-hop 396 address L3(A) via the AERO interface, then receives the IPv6 address 397 2001:db8:2::1 from a stateful address configuration exchange via 'A'. 398 When 'F' receives the IPv6 address, it assigns the address to the 399 AERO interface but does not assign a non-link-local IPv6 prefix to 400 the interface. 402 Finally, IPv6 host 'G' connects to an IPv6 network outside of the 403 AERO link domain. 'G' configures its IPv6 interface in a manner 404 specific to its attached IPv6 link, and autoconfigures the IPv6 405 address 2001:db8:3::1. 407 In these arrangements, 'A' must maintain routes that associate the 408 delegated IPv6 addresses/prefixes with the correct routers and/or 409 hosts on the AERO link. The routers and hosts must maintain at least 410 a default route that points to gateway 'A', and can discover more- 411 specific routes either via a proactive dynamic routing protocol or 412 via the AERO mechanisms specified in Section 4.4. 414 4.4. AERO Specification 416 Figure 1 depicts an operational scenario including an AERO link. The 417 figure shows an AERO gateway ('A'), two AERO routers ('B', 'D'), an 418 AERO host ('F') and three ordinary IPv6 hosts ('C', 'E', 'G') in a 419 typical deployment configuration. We now discuss the operation of 420 AERO with respect to this reference scenario. 422 With reference to Figure 1, when host 'C' sends a packet with source 423 address 'C' and destination address 'E', the packet is first 424 forwarded over 'C's attached EUN to router 'B'. 'B' then forwards 425 the packet over the AERO interface to gateway 'A', which then 426 forwards the packet to router 'D', where the packet is finally 427 forwarded to host 'E' over 'E's attached EUN. When 'A' forwards the 428 packet back out on its advertising AERO interface, it must arrange to 429 redirect 'B' toward 'D' as a better next hop node on the AERO link 430 that is closer to the final destination 'E'. However, this 431 redirection process should only occur if there is assurance that both 432 'B' and 'D' are willing participants. 434 Consider a first alternative in which 'A' informs 'B' only and does 435 not inform 'D' (i.e., "classic redirection"). In that case, 'D' has 436 no way of knowing that 'B' is authorized to forward packets from a 437 given source address. Also, 'B' has no way of knowing whether 'D' is 438 willing to accept its packets, nor whether 'D' is even reachable via 439 a direct path that does not involve 'A'. Finally, 'B' has no way of 440 knowing whether the final destination has moved away from 'D'. 442 Consider also a second alternative in which 'A' informs both 'B' and 443 'D' separately via independent redirection messages (i.e., "augmented 444 redirection"). In that case, several conditions can occur that could 445 result in communications failures. First, if 'B' receives the 446 redirection message but 'D' does not, subsequent packets sent by 'B' 447 would be dropped due to filtering since 'D' would not have a 448 forwarding table entry to verify their source addresses. Second, if 449 'D' receives the redirection message but 'B' does not, subsequent 450 packets sent in the reverse direction by 'D' would be lost. Finally, 451 timing issues surrounding the establishment and garbage collection of 452 forwarding table entries at 'B' and 'D' could yield unpredictable 453 behavior. For example, unless the timing were carefully coordinated 454 through some form of synchronization loop, there would invariably be 455 instances in which one node has the correct forwarding table state 456 and the other node does not resulting in non-deterministic packet 457 loss. 459 Since neither of these alternatives can satisfy the requirements 460 listed in Section 3, a new redirection technique is needed. In this 461 new method (i.e., "AERO redirection"), when 'A' forwards a packet 462 from 'B' out the same AERO interface toward 'D', 'A' first sends a 463 "predirect" message forward to 'D' to inform it that 'B' is 464 authorized to produce packets using source address 'C'. After 'D' 465 receives the predirect, it sends a Redirect message back to 'B' via 466 'A' as a trusted intermediary. When 'B' receives the Redirect, it 467 knows that 'D' will accept the packets it sends with source address 468 'C' as long as 'D' retains the forwarding table entry. This process 469 stands in contrast to the classical and augmented redirection 470 approaches; the following subsections therefore specify the AERO 471 redirection steps necessary to support the reference operational 472 scenario. 474 4.4.1. Sending Predirects 476 When a gateway forwards a packet out the same AERO interface that it 477 arrived on, the gateway sends a predirect message forward to the 478 egress AERO node instead of sending a Redirect message back to the 479 ingress node. If there is some way of marking the data packet itself 480 as a predirect, then the data packet itself serves as a "predirect" 481 without the need for a separate message (e.g., see: 482 [I-D.templin-ironbis]). 484 If there is no means for signaling a predirect in the data plane, the 485 gateway instead sends an explicit Predirect message which is simply 486 an augmented version of an ordinary Redirect message. In the case of 487 IPv6 as the network layer protocol, the Predirect format is the same 488 as depicted in Section 4.5 of [RFC4861], and is identified by two new 489 backward-compatible bits taken from the Reserved field as shown in 490 Figure 2: 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type (=137) | Code (=0) | Checksum | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 |A|P| Reserved | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 + + 501 | | 502 + Target Address + 503 | | 504 + + 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 + + 509 | | 510 + Destination Address + 511 | | 512 + + 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Options ... 516 +-+-+-+-+-+-+-+-+-+-+-+- 518 Figure 2: AERO-Specific IPv6 Redirect Message Format 520 Where the new bits are defined as: 522 A (1) the "AERO" bit. Set to 1 to indicate an AERO-specific 523 Redirect message, and set to 0 to indicate an ordinary IPv6 524 Redirect message. 526 P (1) the "Predirect" bit. Set to 1 to indicate a Predirect 527 message, and set to 0 to indicate a Redirect response to a 528 Predirect message. (This bit is valid only when the A bit is set 529 to 1.) 531 In the reference operational scenario, when gateway 'A' forwards a 532 packet sent by 'B' toward 'D', it marks the packet as a "predirect" 533 if possible. Otherwise, it also sends an explicit Predirect message 534 forward toward 'D', subject to rate limiting (see Section 8.2 of 535 [RFC4861]). 'A' prepares the Predirect message in a similar fashion 536 as for an ordinary IPv6 Redirect message as follows: 538 o the link-layer source address is set to 'L2(A)' 540 o the link-layer destination address is set to 'L2(D)' 542 o the network-layer source address is set to 'L3(B)'. 544 o the network-layer destination address is set to 'L3(D)'. 546 o the Predirect Target and Destination Addresses are both set to 547 'L3(B)'. 549 o on links that require stateful address mapping, the Predirect 550 message includes a Target Link Layer Address Option (TLLAO) set to 551 'L2(B)'. 553 o the Predirect message includes Route Information Options (RIOs) 554 [RFC4191] that encode prefixes taken from 'B's address/prefix 555 delegations, including one that covers the source address of the 556 originating packet. 558 o the Predirect message includes a Redirected Header Option (RHO) 559 that contains as much of the originating packet as possible 560 beginning with the network-layer header such that the total length 561 of the Predirect message does not exceed 512 bytes. 563 o the A and P bits in the Predirect message header are both set to 564 1. 566 'A' then sends the Predirect message forward to 'D'. 568 4.4.2. Processing Predirects and Sending Redirects 570 When an AERO router or host receives a either a data packet marked as 571 a predirect or an explicit Predirect message, it validates the 572 message according to the appropriate redirect message validation 573 rules (e.g., Section 8.1 of [RFC4861] for IPv6). The node further 574 accepts the message only if it came from the link-layer address of a 575 trusted gateway. Finally, the node only processes the message if the 576 destination address of the originating packet encapsulated in the RHO 577 is covered by one of its CURRENT delegated addresses/prefixes (see 578 Section 4.5). 580 In the reference operational scenario, when router 'D' receives the 581 predirect it creates forwarding table entries with the prefixes 582 encoded in RIO options as the target prefixes, and associates the 583 forwarding table entries with a node structure (e.g., in a neighbor 584 cache) that stores the source address of the Predirect message (i.e., 585 'L3(B)'). 'D' places the node structure in the FILTERING state, then 586 sets/resets a filtering expiration timer value of 40 seconds. If the 587 filtering timer later expires, 'D' clears the FILTERING state. If 588 the node structure is not in the FORWARDING state, 'D' then deletes 589 the node structure and all of its associated forwarding table 590 entries. (This suggests that 'D's AERO interface should maintain a 591 private forwarding table separate from the primary forwarding table, 592 since the node structure and forwarding table entries must be managed 593 by the AERO interface itself.) 595 After processing the Predirect message and establishing the 596 forwarding table entry, 'D' prepares a Redirect message in response 597 to the Predirect as follows: 599 o the link-layer source address is set to 'L2(D)' 601 o the link-layer destination address is set to 'L2(A)' 603 o the network-layer source address is set to 'L3(D)'. 605 o the network-layer destination address is set to 'L3(B)'. 607 o the Redirect Target and the Redirect Destination Addresses are 608 both set to 'L3(D)'. 610 o on links that require stateful address mapping, the Redirect 611 message includes a TLLAO set to 'L2(D)'. 613 o the Redirect message includes Route Information Options (RIOs) 614 [RFC4191] that encode prefixes taken from 'D's address/prefix 615 delegations, including one that covers the destination address of 616 the originating packet. 618 o the Redirect message includes an RHO copied from the corresponding 619 Predirect message. 621 o the (A, P) bits in the Redirect message header are set to (1, 0). 623 After 'D' prepares the Redirect message, it sends the message to 'A'. 625 4.4.3. Proxying Redirects 627 When an AERO gateway receives a Redirect message, it accepts the 628 message only if it satisfies the redirect message validation rules. 629 The gateway further accepts the message only if it came from the 630 link-layer address of the current next hop toward the destination 631 address of the originating packet encapsulated in the RHO. The 632 gateway then "proxies" the Redirect message back to the original 633 ingress AERO node as described below. 635 In the reference operational scenario, 'A' receives the Redirect 636 message from 'D' and verifies that the RIOs encode addresses/prefixes 637 that 'D' is authorized to use. Without decrementing the hopcount in 638 the Redirect message, 'A' next changes the link-layer source address 639 of the message to 'L2(A)' and changes the link-layer destination 640 address to 'L2(B)'. 'A' then sends this proxied Redirect message to 641 'B'. 643 4.4.4. Processing Redirects 645 When an AERO router or host receives a Redirect message, it validates 646 the message according to the appropriate redirect message validation 647 rules. The node further accepts the message only if it came from the 648 link-layer address of either a trusted gateway or the current next 649 hop on the AERO link for the destination address of the originating 650 packet encapsulated in the RHO. 652 In the reference operational scenario, 'B' receives the (proxied) 653 Redirect message then creates forwarding table entries with the 654 prefixes encoded in RIO options as the target prefixes. 'B' further 655 associates the forwarding table entries with a node structure (e.g., 656 in a neighbor cache) that stores the source address of the Predirect 657 message (i.e., 'L3(D)'). 'B' places the node structure in the 658 FORWARDING state, then sets/resets a filtering expiration timer value 659 of 30 seconds. If the filtering timer later expires, 'B' clears the 660 FORWARDING state. If the node structure is not in the FILTERING 661 state, 'B' then deletes the node structure and all of its associated 662 forwarding table entries. 664 Now, 'B' has a node structure for 'D' in the FORWARDING state, and 665 'D' has a node structure for 'B' in the FILTERING state. Therefore, 666 'B' may forward ordinary network-layer data packets with destination 667 addresses covered by 'D's prefixes directly to 'D' without involving 668 'A'. 'D' will in turn accept the packets since it has a forwarding 669 table entry authorizing 'B' to forward packets with source addresses 670 covered by 'B's prefixes. 672 To enable packet forwarding in the reverse direction, a separate AERO 673 operation is required which is the mirror-image of the forward AERO 674 operation described above, i.e., the forward and reverse AERO 675 operations are asymmetric. Following the reverse operation, packets 676 can be exchanged bidirectionally without involving 'A'. 678 4.4.5. Sending Periodic Predirect Keepalives 680 In order to prevent forwarding table entries from expiring while data 681 packets are actively flowing, the ingress node can periodically send 682 Predirect messages directly to the egress node (subject to rate 683 limiting) to solicit Redirect messages. In the reference operational 684 scenario, when 'B' forwards a packet to 'D' and wishes to update the 685 corresponding FORWARDING state timer, 'B' can also send a Predirect 686 message directly to 'D' prepared as follows: 688 o the link-layer source address is set to 'L2(B)'. 690 o the link-layer destination address is set to 'L2(D)'. 692 o the network-layer source address is set to 'L3(B)'. 694 o the network-layer destination address is set to 'L3(D)'. 696 o the Predirect Target and Destination Addresses are both set to 697 'L3(B)'. 699 o the Predirect message includes a Redirected Header Option (RHO) 700 that contains as much of the originating packet as possible 701 beginning with the network-layer header such that the total length 702 of the Predirect message does not exceed 512 bytes. 704 o the A and P bits in the Predirect message header are both set to 705 1. 707 When 'D' receives the Predirect message, it accepts the message only 708 if it satisfies the redirect message validation rules. The node 709 further accepts the message only if it came from the current previous 710 hop on the AERO link for the source address of the originating packet 711 encapsulated in the RHO. 'D' then resets its FILTERING expiration 712 timer for node 'B' to 40 seconds, and sends a Redirect message 713 directly to 'B' prepared as follows: 715 o the link-layer source address is set to 'L2(D)'. 717 o the link-layer destination address is set to 'L2(B)'. 719 o the network-layer source address is set to 'L3(D)'. 721 o the network-layer destination address is set to 'L3(B)'. 723 o the Redirect Target and Destination Addresses are both set to 724 'L3(D)'. 726 o the Redirect message includes an RHO copied from the corresponding 727 Predirect message. 729 o the (A, P) bits in the Redirect message header are set to (1, 0). 731 When 'B' receives the Redirect message, it accepts the message only 732 if it satisfies the redirect message validation rules. The node 733 further accepts the message only if it came from the current next hop 734 on the AERO link for the source address of the originating packet 735 encapsulated in the RHO. 'B' then resets its FORWARDING expiration 736 timer for node 'D' to 30 seconds. 738 Note that in these direct neighbor to neighbor exchanges, neither the 739 Predirect nor Redirect message contain RIOs, since gateways are the 740 only authoritative source of routing information. Therefore, AERO 741 routers and hosts should not include RIOs in the Predirects/Redirects 742 they send, and they must ignore any RIOs included in received 743 Predirect/Redirect messages that did not come from a trusted gateway. 745 4.4.6. Reachability Considerations 747 When an ingress node receives a Redirect message informing it of a 748 direct path to a new egress, there is a question in point as to 749 whether the new egress can be reached directly without involving the 750 gateway as an intermediary. On some AERO links, it may be reasonable 751 for the ingress to (optimistically) assume that the new egress is 752 reachable, and to immediately begin forwarding data packets to the 753 egress without testing reachability. 755 On AERO links in which an optimistic assumption of reachability may 756 be inappropriate, however, the ingress can defer the redirection 757 until it tests the direct path to the egress by sending a direct 758 Predirect message to elicit a Redirect as specified in Section 4.4.5. 759 If the ingress is unable to elicit a Redirect message after a small 760 number of attempts, it should consider the direct path to the egress 761 as unusable. 763 In either case, the ingress can process any link errors corresponding 764 to the data packets sent directly to the egress as a hint that the 765 direct path has either failed or has become intermittent. 767 4.5. Mobility Considerations 769 An AERO link egress router 'D' can configure both a non-advertising 770 router interface on a provider AERO link and advertising router 771 interfaces on EUN links to provide gateway services to nodes in EUNs. 772 When node 'E' in an EUN that has obtained addresses/prefixes moves to 773 a different network point of attachment, however, 'E' can release its 774 address/prefix delegations via 'D' and re-establish them via a 775 different gateway. 777 When 'E' releases its address/prefix delegations via 'D', 'D' marks 778 the forwarding table entries that cover the addresses/prefixes as 779 DEPARTED (i.e., it clears the CURRENT state). 'D' thereafter ceases 780 to respond to Predirect messages correlated with the DEPARTED 781 entries, and also schedules a garbage-collection timer of 60 seconds, 782 after which it deletes the DEPARTED entries. 784 When 'D' receives packets destined to an address covered by the 785 DEPARTED forwarding table entries, it forwards them to the last-known 786 EUN link-layer address of 'E' as a means for avoiding mobility- 787 related packet loss during routing changes. 'D' also returns a NULL 788 Redirect message to inform the correspondent 'B' of the departure. 789 The Redirect message is prepared as follows: 791 o the link-layer source address is set to 'L2(D)'. 793 o the link-layer destination address is set to 'L2(B)'. 795 o the network-layer source address is set to 'L3(D)'. 797 o the network-layer destination address is set to 'L3(B)'. 799 o the Redirect Target and Destination Addresses are both set to 800 NULL. 802 o the Redirect message includes an RHO copied from the corresponding 803 Predirect message. 805 o the (A, P) bits in the Redirect message header are set to (1, 0). 807 Eventually, any correspondents will receive such a NULL Redirect 808 message and will cease to use 'D' as a next hop. They will then 809 revert to sending packets destined to 'E' via their gateways and may 810 subsequently receive new Redirect messages to discover that 'E' is 811 now associated with a new egress router. Note that any packets 812 forwarded by 'D' via a forwarding table entry in the DEPARTED state 813 may be lost if the mobile node moves off-link with respect to its 814 previous EUN point of attachment. This should not be a problem for 815 large links (e.g., large cellular network deployments, large ISP 816 networks, etc.) in which all/most mobility events are intra-link. 818 4.6. Scaling Considerations 820 Figure 1 depicts a reference network topology with only a single 821 gateway on the AERO link. In order to support larger numbers of AERO 822 routers and hosts, the AERO link can deploy more gateways to support 823 load balancing and generally shortest-path routing. 825 Such an arrangement requires that the gateways participate in a 826 routing protocol instance (e.g., an eBGP instance with each gateway 827 configuring a private Autonomous System Number (ASN)) so that 828 address/prefix delegations can be mapped to the correct gateway. The 829 routing protocol instance can be configured as either a full mesh 830 topology involving all gateways, or as a partial mesh topology with 831 each AERO link gateway associating with one or more backhaul network 832 companion gateways and a full mesh between companion gateways. 834 4.7. Proxy Chaining 836 In large AERO link deployments, there may be many gateways - each 837 serving many AERO routers and hosts. The gateways then either 838 require full topology knowledge, or a default route to a companion 839 gateway that does have full topology knowledge. For example, if AERO 840 node 'A' connects to gateway 'B', and AERO node 'E' connects to 841 gateway 'D', then 'B' and 'D' must either have full topology 842 knowledge or have a default route to a companion gateway (e.g., 'C') 843 that does. 845 In that case, when 'A' forwards an initial packet destined to an end 846 system behind 'E', it forwards the packet to 'B'. Next, 'B' forwards 847 the packet toward 'C', which both forwards the packet and generates a 848 Predirect message toward 'D'. 'D' then either processes the 849 Predirect message locally or proxies it toward 'E'. 851 In the reverse direction, when 'E'/'D' sends a Redirect response 852 message back to 'A', it first sends the message to 'D'/'C', which 853 proxies the message toward 'B', which finally proxies the message 854 toward 'A'. 856 4.8. Backward Compatibility 858 If a legacy host or router receives an AERO Redirect or Predirect 859 message, it will process the message as if it were an ordinary 860 Redirect. This will cause no harmful effects, since the legacy 861 system will ignore the 'A' and P' bits in the Reserved field, and 862 will also ignore any RIOs that are included. The values encoded in 863 the Redirect message target and destination addresses will also not 864 cause the legacy node to create incorrect routing state. The 865 mechanism therefore causes no harm to legacy systems, and supports 866 natural incremental deployment. 868 4.9. Alternate Means of Source Address Verification 870 On some AERO links, each packet can include a signature that the link 871 egress nodes can use to authenticate the link ingress node (e.g., 872 see: [I-D.templin-ironbis]). 874 5. IANA Considerations 876 There are no IANA considerations for this document. 878 6. Security Considerations 880 This document enables ingress filtering, and therefore improves the 881 security of AERO links. 883 7. Acknowledgements 885 Discussions both on the v6ops list and in private exchanges helped 886 shape some of the concepts in this work. Individuals who contributed 887 insights include Mikael Abrahamsson, Fred Baker, Brian Carpenter, 888 Joel Halpern, Lee Howard, 890 8. References 892 8.1. Normative References 894 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 895 September 1981. 897 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 898 RFC 792, September 1981. 900 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 901 Requirement Levels", BCP 14, RFC 2119, March 1997. 903 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 904 (IPv6) Specification", RFC 2460, December 1998. 906 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 907 More-Specific Routes", RFC 4191, November 2005. 909 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 910 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 911 September 2007. 913 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 914 Address Autoconfiguration", RFC 4862, September 2007. 916 8.2. Informative References 918 [I-D.ietf-savi-framework] 919 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 920 "Source Address Validation Improvement Framework", 921 draft-ietf-savi-framework-05 (work in progress), 922 July 2011. 924 [I-D.templin-ironbis] 925 Templin, F., "The Internet Routing Overlay Network 926 (IRON)", draft-templin-ironbis-09 (work in progress), 927 November 2011. 929 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 930 RFC 2131, March 1997. 932 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 933 Domains without Explicit Tunnels", RFC 2529, March 1999. 935 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 936 and M. Carney, "Dynamic Host Configuration Protocol for 937 IPv6 (DHCPv6)", RFC 3315, July 2003. 939 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 940 Host Configuration Protocol (DHCP) version 6", RFC 3633, 941 December 2003. 943 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 944 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 945 March 2008. 947 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 948 Infrastructures (6rd)", RFC 5569, January 2010. 950 Author's Address 952 Fred L. Templin (editor) 953 Boeing Research & Technology 954 P.O. Box 3707 MC 7L-49 955 Seattle, WA 98124 956 USA 958 Email: fltemplin@acm.org