idnits 2.17.1 draft-templin-aero-02.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 (September 19, 2011) is 4602 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) ** 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 (-40) exists of draft-templin-intarea-vet-24 -- 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 (~~), 3 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: Standards Track September 19, 2011 5 Expires: March 22, 2012 7 Asymmetric Extended Route Optimization (AERO) 8 draft-templin-aero-02.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 March 22, 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 Nodes attached to link types such as multicast-capable, shared media, 96 non-broadcast multiple access (NBMA), etc. can exchange packets with 97 each other as neighbors on the link. Each node should therefore be 98 able to discover a trusted neighboring gateway that can provide 99 default routing services to reach off-link destinations, and should 100 also accept redirection messages from the gateway informing it of a 101 different neighbor that is closer to the final destination. This 102 redirect function can provide a useful route optimization, since the 103 triangular path from the ingress link neighbor, to the gateway, and 104 finally to the egress link neighbor may be considerably longer than 105 the direct path between the neighbors. However, ordinary redirection 106 may lead to operational issues on certain link types and/or in 107 certain deployment scenarios. 109 For example, when an ingress link neighbor accepts an ordinary 110 redirect message from a gateway, it has no way of knowing whether the 111 egress link neighbor is ready and willing to accept packets directly 112 without involving the gateway. In particular, without involvement 113 from the gateway, the egress would have no way of knowing that the 114 ingress is authorized to forward packets from a given source address. 115 (This is especially important for very large links, since any node on 116 the link can spoof the network-layer source address with low 117 probability of detection even if the link-layer source address cannot 118 be spoofed.) Additionally, the ingress would have no way of knowing 119 whether the direct path to the egress has failed, nor whether the 120 final destination has moved away from the egress to some other 121 network attachment point. 123 Therefore, a new redirection mechanism is required that can enable a 124 reliable one-way handshake from the egress to the ingress link node 125 under the mediation of trusted gateways. The mechanism is asymmetric 126 (since only the forward direction from the ingress to the egress is 127 optimized) and extended (since the redirection extends forward to the 128 egress before reaching back to the ingress). This document therefore 129 introduces an Asymmetric Extended Route Optimization (AERO) 130 capability that addresses the issues. 132 While the AERO mechanisms were initially designed for the specific 133 purpose of NBMA tunnel virtual interfaces (e.g., see: 134 [RFC2529][RFC5214][RFC5569][I-D.templin-intarea-vet]) they can also 135 be applied to any link types that support redirection 136 [RFC0792][RFC4861]. The rest of this document refers to this class 137 of links collectively as "AERO links". 139 The AERO techniques apply to both the IPv4 [RFC0791] and IPv6 140 [RFC2460] protocols, as well as any other network layer protocol that 141 includes link models that can support redirection. 143 2. Terminology 145 The terminology in the normative references apply; the following 146 terms are defined within the scope of this document: 148 AERO link 149 any link over which the AERO mechanisms can be applied. 151 AERO node 152 a gateway, router or host connected to an AERO link. 154 AERO gateway 155 a router that configures an advertising router interface on the 156 AERO link, and that can provide default routing services for 157 forwarding packets toward their final destinations. 159 AERO router 160 a router that configures a non-advertising router interface on the 161 AERO link, and that connects End User Networks to the AERO link. 163 AERO host 164 a simple host on the AERO link. 166 ingress AERO node ("ingress") 167 a node that injects packets into the AERO link. 169 egress AERO node ("egress") 170 a node that removes packets from the AERO link. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. When used 175 in lower case (e.g., must, must not, etc.), these words MUST NOT be 176 interpreted as described in [RFC2119], but are rather interpreted as 177 they would be in common English. 179 3. Requirements 181 The route optimization mechanism must satisfy the following 182 requirements: 184 Req 1: Off-load traffic from performance-critical gateways 185 The mechanism must offload sustained transit though a gateway that 186 would otherwise become a traffic concentrator. 188 Req 2: Support route optimization 189 Ingress nodes must be able to send packets directly to egress 190 nodes without involving a gateway as an intermediary hop. 192 Req 3: Support multiple levels of hierarchy 193 For scaling purposes, allow multiple levels of hierarchy in which 194 gateways in higher levels have progressively more topology 195 knowledge than those in lower levels. 197 Req 4: Do not circumvent ingress filtering 198 The mechanism must not open an attack vector where network-layer 199 source address spoofing is enabled even when link-layer source 200 address spoofing is disabled. 202 Req 5: Do not expose packets to loss due to filtering 203 The ingress node must have a way of knowing that the egress node 204 will accept its forwarded packets. 206 Req 6: Do not expose packets to loss due to path failure 207 The ingress node must have a way of discovering whether the egress 208 has gone unreachable on the route optimized path. 210 Req 7: Do not introduce routing loops 211 The gateway must not perform a route optimization that would cause 212 a routing loop to form. 214 Req 8: Support mobility 215 The mechanism must continue to work even if the final destination 216 node/network moves from a first egress node and re-associates with 217 a second egress node. 219 4. Asymmetric Extended Route Optimization (AERO) 221 The following sections specify an Asymmetric Extended Route 222 Optimization (AERO) capability that fulfills the requirements 223 specified in Section 3. 225 4.1. AERO Link Dynamic Routing 227 In many AERO link use case scenarios (e.g., small enterprise 228 networks, small and stable MANETs, etc.), AERO gateways and routers 229 can engage in a proactive dynamic routing protocol (e.g., OSPF, RIP, 230 IS-IS, etc.) so that routing/forwarding tables can be populated and 231 standard forwarding between routers can be used. In other scenarios 232 (e.g., large enterprise/ISP networks, cellular service provider 233 networks, dynamic MANETs, etc.), this might be impractical due to 234 routing protocol control message scaling issues. 236 When a proactive dynamic routing protocol cannot be used, the 237 mechanisms specified in this section can provide a useful on-demand 238 dynamic routing capability. 240 4.2. AERO Node Behavior 242 The following sections discuss characteristics of nodes attached to 243 links over which AERO can be used: 245 4.2.1. AERO Node Types 247 AERO gateways configure their AERO link interfaces as advertising 248 router interfaces (see: [RFC4861], Section 6.2.2), and therefore may 249 send Router Advertisement (RA) messages that include non-zero Router 250 Lifetimes. 252 AERO routers configure their AERO link interfaces as non-advertising 253 router interfaces. 255 AERO hosts configure their AERO link interfaces as simple host 256 interfaces. 258 4.2.2. Source Address Verification 260 AERO nodes must employ a source address verification check for the 261 packets they receive on an AERO interface in a manner that is 262 consistent with the Source Address Validation Improvement (SAVI) 263 Framework [I-D.ietf-savi-framework]. In order to perform source 264 address verification, the node considers the network-layer source 265 address correct for the link-layer source address if: 267 o the link-layer source address is the address of an AERO gateway, 268 or 270 o the link-layer source address is explicitly linked to the network- 271 layer source address (i.e., through stateless or stateful address 272 mapping), or 274 o a ingress filtering and/or forwarding table entry exists that 275 lists the packet's link-layer source address as the link layer 276 address corresponding to the next hop toward the network-layer 277 source address on the AERO link. 279 The latter of these checks can be established through static 280 configuration, via a proactive dynamic routing protocol, or through 281 the AERO mechanisms specified in Section 4.4. 283 4.2.3. AERO Host Behavior 285 AERO hosts send Router Solicitation (RS) messages to obtain RA 286 messages from an AERO gateway. When the RA contains Prefix 287 Information Options with non-link-local prefixes, the host 288 autoconfigures addresses from the prefixes using Stateless Address 289 Autoconfiguration (SLAAC) [RFC4861][RFC4862]. When managed address 290 delegation services are available, the host can also (or instead) 291 acquire addresses taken from prefixes aggregated by the gateway 292 through the use of stateful mechanisms, e.g., DHCP 293 [RFC2131][RFC3315], manual configuration, etc. 295 After the host receives addresses, it assigns them to its AERO 296 interface and forwards any of its outbound packets via the gateway as 297 a default router. The host may subsequently receive redirection 298 messages from the gateway listing a better next hop. 300 4.2.4. AERO Router Behavior 302 AERO routers send RS messages to obtain RA messages from an AERO 303 gateway, i.e., they act as "hosts" on their non-advertising AERO link 304 router interfaces for the purpose of default router discovery. 306 The router can then acquire managed prefix delegations aggregated by 307 the gateway through the use of, e.g., DHCPv6 Prefix Delegation 308 [RFC3633], manual configuration, etc. in the same fashion as 309 described above for host-based autoconfiguration. 311 After the router acquires prefixes, it can sub-delegate them to nodes 312 and links within its attached End User Networks (EUNs), then can 313 forward any outbound packets coming from its EUNs via the gateway. 314 The router may subsequently receive redirection messages from the 315 gateway listing a better next hop. 317 4.2.5. AERO Gateway Behavior 319 AERO gateways respond to RS messages from hosts and routers on the 320 AERO link by returning an RA message. Gateways may further configure 321 a DHCP relay or server function on their AERO links and/or provide an 322 administrative interface for manual configuration of address/ 323 prefix-to-client forwarding table entries. 325 When the gateway completes a stateful address or prefix delegation 326 transaction (e.g., as a DHCP relay/server, etc.), it establishes 327 forwarding table entries that list the link-layer address of client 328 as the link-layer address of the next hop toward the delegated 329 addresses/prefixes. 331 When the gateway forwards a packet out the same AERO interface it 332 arrived on, it initiates an AERO route optimization procedure as 333 specified in Section 4.4. 335 4.3. AERO Reference Operational Scenario 337 Figure 1 depicts a reference AERO network topology. IPv6 is used 338 only as an example network layer protocol, and the same fundamental 339 AERO techniques can be applied for other network layer protocols. 340 The figure shows an AERO gateway ('A'), two non-advertising AERO 341 routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts 342 ('C', 'E', 'G') in a typical operational scenario: 343 .-(::::::::) 2001:db8:3::1 344 .-(::: IPv6 :::)-. +-------------+ 345 (:::: Internet ::::) | IPv6 Host G | 346 `-(::::::::::::)-' +-------------+ 347 `-(::::::)-' 348 ,................., 349 |companion gateway| 350 '.................' +---------------+ 351 +--------------+ | Host F | 352 | Gateway A | +---------------+ 353 +--------------+ 2001:db8:2:1 354 L3(A) L3(F) 355 L2(A) L2(F) 356 | AERO Link | 357 X-----+--+-----------------+--+---X 358 | | 359 L2(B) L2(D) .-. 360 L3(B) L3(D) ,-( _)-. 361 +--------------+ +--------------+ .-(_ IPv6 )-. 362 | Router B | | Router D |--(__ EUN ) 363 +--------------+ +--------------+ `-(______)-' 364 2001:db8:0::/48 2001:db8:1::/48 | 365 | 2001:db8:1::1 366 .-. +-------------+ 367 ,-( _)-. 2001:db8:0::1 | IPv6 Host E | 368 .-(_ IPv6 )-. +-------------+ +-------------+ 369 (__ EUN )--| IPv6 Host C | 370 `-(______)-' +-------------+ 372 Figure 1: Reference AERO Network Topology 374 In Figure 1, Gateway 'A' connects to the AERO link and also connects 375 to the IPv6 Internet, either directly or via a companion gateway. 376 'A' configures an AERO link interface with a link-local network-layer 377 address L3(A) and with link-layer address L2(A). 'A' next arranges 378 to add the link-layer address L2(A) to the list of valid gateways for 379 the link. 381 Router 'B' connects to one or more IPv6 EUNs and also connects to the 382 AERO link via an interface with a link-local network-layer address 383 L3(B) and with link-layer address L2(B). 'B' next configures a 384 default IPv6 route with next-hop address L3(A) via the AERO 385 interface, then receives the IPv6 prefix 2001:db8:0::/48 through a 386 stateful prefix delegation exchange via 'A'. 'B' finally sub- 387 delegates the prefix to its attached EUNs, where IPv6 host 'C' 388 autoconfigures the address 2001:db8:0::1. 390 Router 'D' connects to the AERO link via an interface with addresses 391 L3(D)/L2(D), configures a default IPv6 route with next-hop address 392 L3(A) via the AERO interface, and receives a stateful prefix 393 delegation of 2001:db8:1::/48 in the same fashion as for router 'B'. 394 'D' finally sub-delegates the prefix to its attached EUNs, where IPv6 395 host 'E' autoconfigures IPv6 address 2001:db8:1::1. 397 Host 'F' connects to the AERO link via an interface with addresses 398 L3(F)/L2(F). 'F' next configures a default IPv6 route with next-hop 399 address L3(A) via the AERO interface, then receives the IPv6 address 400 2001:db8:2::1 from a stateful address configuration exchange via 'A'. 401 When 'F' receives the IPv6 address, it assigns the address to the 402 AERO interface but does not assign a non-link-local IPv6 prefix to 403 the interface. 405 Finally, IPv6 host 'G' connects to an IPv6 network outside of the 406 AERO link domain. 'G' configures its IPv6 interface in a manner 407 specific to its attached IPv6 link, and autoconfigures the IPv6 408 address 2001:db8:3::1. 410 In these arrangements, 'A' must maintain routes that associate the 411 delegated IPv6 addresses/prefixes with the correct routers and/or 412 hosts on the AERO link. The routers and hosts must maintain at least 413 a default route that points to gateway 'A', and can discover more- 414 specific routes either via a proactive dynamic routing protocol or 415 via the AERO mechanisms specified in Section 4.4. 417 4.4. AERO Specification 419 Figure 1 depicts a reference operational scenario including an AERO 420 link. The figure shows an AERO gateway ('A'), two AERO routers ('B', 421 'D'), an AERO host ('F') and three ordinary IPv6 hosts ('C', 'E', 422 'G') in a typical deployment configuration. We now discuss the 423 operation of AERO with respect to this reference scenario. 425 With reference to Figure 1, when host 'C' sends a packet with source 426 address 'C' and destination address 'E', the packet is first 427 forwarded over 'C's attached EUN to router 'B'. 'B' then forwards 428 the packet over the AERO interface to gateway 'A', which then 429 forwards the packet to router 'D', where the packet is finally 430 forwarded to host 'E' over 'E's attached EUN. When 'A' forwards the 431 packet back out on its advertising AERO interface, it must arrange to 432 redirect 'B' toward 'D' as a better next hop node on the AERO link 433 that is closer to the final destination 'E'. However, this 434 redirection process should only take place if there is assurance that 435 both 'B' and 'D' are willing participants. 437 Consider a first alternative in which 'A' informs 'B' only and does 438 not inform 'D' (i.e., "classic redirection"). In that case, 'D' has 439 no way of knowing that 'B' is authorized to forward packets from a 440 given source address. Also, 'B' has no way of knowing whether 'D' is 441 willing to accept its packets, nor whether 'D' is even reachable via 442 a direct path that does not involve 'A'. Finally, 'B' has no way of 443 knowing whether the final destination has moved away from 'D'. 445 Consider also a second alternative in which 'A' informs both 'B' and 446 'D' separately via independent redirection messages (i.e., "augmented 447 redirection"). In that case, several conditions can occur that could 448 result in communications failures. First, if 'B' receives the 449 redirection message but 'D' does not, subsequent packets sent by 'B' 450 would be dropped due to filtering since 'D' would not have a 451 forwarding table entry to verify their source addresses. Second, if 452 'D' receives the redirection message but 'B' does not, subsequent 453 packets sent in the reverse direction by 'D' would be lost. Finally, 454 timing issues surrounding the establishment and garbage collection of 455 forwarding table entries at 'B' and 'D' could yield unpredictable 456 behavior. For example, unless the timing were carefully coordinated 457 through some form of synchronization loop, there would invariably be 458 instances in which one node has the correct forwarding table state 459 and the other node does not resulting in non-deterministic packet 460 loss. 462 Since neither of these alternatives can satisfy the requirements 463 listed in Section 3, a new redirection technique is needed. In this 464 new method (i.e., "AERO redirection"), when 'A' forwards a packet 465 from 'B' out the same AERO interface toward 'D', 'A' must first send 466 a "Predirect" message forward to 'D' to inform it that 'B' is 467 authorized to produce packets using source address 'C'. After 'D' 468 receives the Predirect, it sends a "Redirect" message back to 'B' via 469 'A' as a trusted intermediary. When 'B' receives the Redirect, it 470 knows that 'D' will accept the packets it sends with source address 471 'C' as long as 'D' retains the forwarding table entry. This process 472 stands in contrast to the classical and augmented redirection 473 approaches; the following subsections therefore specify the AERO 474 redirection steps necessary to support the reference operational 475 scenario. 477 4.4.1. Sending Predirects 479 When a gateway forwards a packet out the same AERO interface that it 480 arrived on, the gateway sends a "Predirect" message forward to the 481 egress AERO node instead of sending a Redirect message back to the 482 ingress node. The Predirect message is simply an AERO-specific 483 version of an ordinary Redirect message. In the case of IPv6 as the 484 network layer protocol, the Predirect format is the same as depicted 485 in Section 4.5 of [RFC4861], and is identified by two new backward- 486 compatible bits taken from the Reserved field as shown in Figure 2: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type (=137) | Code (=0) | Checksum | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |A|P| Reserved | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 + + 497 | | 498 + Target Address + 499 | | 500 + + 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 + + 505 | | 506 + Destination Address + 507 | | 508 + + 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Options ... 512 +-+-+-+-+-+-+-+-+-+-+-+- 514 Figure 2: AERO-Specific IPv6 Redirect Message Format 516 Where the new bits are defined as: 518 A (1) the "AERO" bit. Set to 1 to indicate an AERO-specific 519 Redirect message, and set to 0 to indicate an ordinary IPv6 520 Redirect message. 522 P (1) the "Predirect" bit. Set to 1 to indicate a Predirect 523 message, and set to 0 to indicate a Redirect response to a 524 Predirect message. (This bit is valid only when the A bit is set 525 to 1.) 527 In the reference operational scenario, when gateway 'A' forwards a 528 packet sent by 'B' toward 'D', it also sends a Predirect message 529 forward toward 'D', subject to rate limiting (see Section 8.2 of 530 [RFC4861]). 'A' prepares the Predirect message in a similar fashion 531 as for an ordinary IPv6 Redirect message as follows: 533 o the link-layer source address is set to 'L2(A)' 535 o the link-layer destination address is set to 'L2(D)' 537 o the network-layer source address is set to 'L3(B)'. 539 o the network-layer destination address is set to 'L3(D)'. 541 o the Predirect Target and Destination Addresses are both set to 542 'L3(B)'. 544 o on links that require stateful address mapping, the Predirect 545 message includes a Target Link Layer Address Option (TLLAO) set to 546 'L2(B)'. 548 o the Predirect message includes Route Information Options (RIOs) 549 [RFC4191] that encode prefixes taken from 'B's address/prefix 550 delegations, including one that covers the source address of the 551 originating packet. 553 o the Predirect message includes a Redirected Header Option (RHO) 554 that contains as much of the originating packet as possible 555 beginning with the network-layer header such that the total length 556 of the Predirect message does not exceed 512 bytes. 558 o the A and P bits in the Predirect message header are both set to 559 1. 561 'A' then sends the Predirect message forward to 'D'. 563 4.4.2. Processing Predirects and Sending Redirects 565 When an AERO router or host receives a Predirect message, it 566 validates the message according to the appropriate redirect message 567 validation rules (e.g., Section 8.1 of [RFC4861] for IPv6). The node 568 further accepts the message only if it came from the link-layer 569 address of a trusted gateway. Finally, the node only processes the 570 message if the destination address of the originating packet 571 encapsulated in the RHO is covered by one of its CURRENT delegated 572 addresses/prefixes (see Section 4.5). 574 In the reference operational scenario, when router 'D' receives the 575 Predirect message from the gateway it creates forwarding table 576 entries with the prefixes encoded in RIO options as the target 577 prefixes, and associates the forwarding table entries with a node 578 structure (e.g., in a neighbor cache) that stores the source address 579 of the Predirect message (i.e., 'L3(B)'). 'D' places the node 580 structure in the FILTERING state, then sets/resets a filtering 581 expiration timer value of 40 seconds. If the filtering timer later 582 expires, 'D' clears the FILTERING state. If the node structure is 583 not in the FORWARDING state, 'D' then deletes the node structure and 584 all of its associated forwarding table entries. (This suggests that 585 'D's AERO interface should maintain a private forwarding table 586 separate from the primary forwarding table, since the node structure 587 and forwarding table entries must be managed by the AERO interface 588 itself.) 590 After processing the Predirect message and establishing the 591 forwarding table entry, 'D' prepares a Redirect message in response 592 to the Predirect as follows: 594 o the link-layer source address is set to 'L2(D)' 596 o the link-layer destination address is set to 'L2(A)' 598 o the network-layer source address is set to 'L3(D)'. 600 o the network-layer destination address is set to 'L3(B)'. 602 o the Redirect Target and the Redirect Destination Addresses are 603 both set to 'L3(D)'. 605 o on links that require stateful address mapping, the Redirect 606 message includes a TLLAO set to 'L2(D)'. 608 o the Redirect message includes an RHO copied from the corresponding 609 Predirect message. 611 o the (A, P) bits in the Redirect message header are set to (1, 0). 613 After 'D' prepares the Redirect message, it sends the message to 'A'. 614 (Note that the Redirect message does not include RIOs, since the 615 gateway is the only authoritative source of routing information and 616 will supply RIOs when it proxies the message.) 618 4.4.3. Proxying Redirects 620 When an AERO gateway receives a Redirect message, it accepts the 621 message only if it satisfies the redirect message validation rules. 622 The gateway further accepts the message only if it came from the 623 link-layer address of the current next hop toward the destination 624 address of the originating packet encapsulated in the RHO. The 625 gateway then "proxies" the Redirect message back to the original 626 ingress AERO node as described below. 628 In the reference operational scenario, 'A' receives the Redirect 629 message from 'D' and adds RIOs to the message that encode 'D's 630 address/prefix delegations. Without decrementing the hopcount in the 631 Redirect message, 'A' next changes the link-layer source address of 632 the message to 'L2(A)' and changes the link-layer destination address 633 to 'L2(B)'. 'A' then sends this proxied Redirect message to 'B'. 635 4.4.4. Processing Redirects 637 When an AERO router or host receives a Redirect message, it validates 638 the message according to the appropriate redirect message validation 639 rules. The node further accepts the message only if it came from the 640 link-layer address of either a trusted gateway or the current next 641 hop on the AERO link for the destination address of the originating 642 packet encapsulated in the RHO. 644 In the reference operational scenario, 'B' receives the (proxied) 645 Redirect message then creates forwarding table entries with the 646 prefixes encoded in RIO options as the target prefixes. 'B' further 647 associates the forwarding table entries with a node structure (e.g., 648 in a neighbor cache) that stores the source address of the Predirect 649 message (i.e., 'L3(D)'). 'B' places the node structure in the 650 FORWARDING state, then sets/resets a filtering expiration timer value 651 of 30 seconds. If the filtering timer later expires, 'B' clears the 652 FORWARDING state. If the node structure is not in the FILTERING 653 state, 'B' then deletes the node structure and all of its associated 654 forwarding table entries. 656 Now, 'B' has a node structure for 'D' in the FORWARDING state, and 657 'D' has a node structure for 'B' in the FILTERING state. Therefore, 658 'B' may forward ordinary network-layer data packets with destination 659 addresses covered by 'D's prefixes directly to 'D' without involving 660 'A'. 'D' will in turn accept the packets since it has a forwarding 661 table entry authorizing 'B' to forward packets with source addresses 662 covered by 'B's prefixes. 664 To enable packet forwarding in the reverse direction, a separate AERO 665 operation is required which is the mirror-image of the forward AERO 666 operation described above, i.e., the forward and reverse AERO 667 operations are asymmetric. Following the reverse operation, packets 668 can be exchanged bidirectionally without involving 'A'. 670 4.4.5. Sending Periodic Predirect Keepalives 672 In order to prevent forwarding table entries from expiring while data 673 packets are actively flowing, the ingress node can periodically send 674 Predirect messages directly to the egress node (subject to rate 675 limiting) to solicit Redirect messages. In the reference operational 676 scenario, when 'B' forwards a packet to 'D' and wishes to update the 677 corresponding FORWARDING state timer, 'B' can also send a Predirect 678 message directly to 'D' prepared as follows: 680 o the link-layer source address is set to 'L2(B)'. 682 o the link-layer destination address is set to 'L2(D)'. 684 o the network-layer source address is set to 'L3(B)'. 686 o the network-layer destination address is set to 'L3(D)'. 688 o the Predirect Target and Destination Addresses are both set to 689 'L3(B)'. 691 o the Predirect message includes a Redirected Header Option (RHO) 692 that contains as much of the originating packet as possible 693 beginning with the network-layer header such that the total length 694 of the Predirect message does not exceed 512 bytes. 696 o the A and P bits in the Predirect message header are both set to 697 1. 699 When 'D' receives the Predirect message, it accepts the message only 700 if it satisfies the redirect message validation rules. The node 701 further accepts the message only if it came from the current previous 702 hop on the AERO link for the source address of the originating packet 703 encapsulated in the RHO. 'D' then resets its FILTERING expiration 704 timer for node 'B' to 40 seconds, and sends a Redirect message 705 directly to 'B' prepared as follows: 707 o the link-layer source address is set to 'L2(D)'. 709 o the link-layer destination address is set to 'L2(B)'. 711 o the network-layer source address is set to 'L3(D)'. 713 o the network-layer destination address is set to 'L3(B)'. 715 o the Redirect Target and Destination Addresses are both set to 716 'L3(D)'. 718 o the Redirect message includes an RHO copied from the corresponding 719 Predirect message. 721 o the (A, P) bits in the Redirect message header are set to (1, 0). 723 When 'B' receives the Redirect message, it accepts the message only 724 if it satisfies the redirect message validation rules. The node 725 further accepts the message only if it came from the current next hop 726 on the AERO link for the source address of the originating packet 727 encapsulated in the RHO. 'B' then resets its FORWARDING expiration 728 timer for node 'D' to 30 seconds. 730 Note that in these direct neighbor to neighbor exchanges, neither the 731 Predirect nor Redirect message contain RIOs, since gateways are the 732 only authoritative source of routing information. Therefore, AERO 733 routers and hosts should not include RIOs in the Predirects/Redirects 734 they send, and they must ignore any RIOs included in received 735 Predirect/Redirect messages that did not come from a trusted gateway. 737 4.4.6. Reachability Considerations 739 When an ingress node receives a Redirect message informing it of a 740 direct path to a new egress, there is a question in point as to 741 whether the new egress can be reached directly without involving the 742 gateway as an intermediary. On some AERO links, it may be reasonable 743 for the ingress to (optimistically) assume that the new egress is 744 reachable, and to immediately begin forwarding data packets to the 745 egress without testing reachability. 747 On AERO links in which an optimistic assumption of reachability may 748 be inappropriate, however, the ingress can defer the redirection 749 until it tests the direct path to the egress by sending a direct 750 Predirect message to elicit a Redirect as specified in Section 4.4.5. 751 If the ingress is unable to elicit a Redirect message after a small 752 number of attempts, it should consider the direct path to the egress 753 as unusable. 755 In either case, the ingress can process any link errors corresponding 756 to the data packets sent directly to the egress as a hint that the 757 direct path has either failed or has become intermittent. 759 4.5. Mobility Considerations 761 An AERO link egress router 'D' can configure both a non-advertising 762 router interface on a provider AERO link and advertising router 763 interfaces on EUN links to provide gateway services to nodes in EUNs. 764 When node 'E' in an EUN that has obtained addresses/prefixes moves to 765 a different network point of attachment, however, 'E' can release its 766 address/prefix delegations via 'D' and re-establish them via a 767 different gateway. 769 When 'E' releases its address/prefix delegations via 'D', 'D' marks 770 the forwarding table entries that cover the addresses/prefixes as 771 DEPARTED (i.e., it clears the CURRENT state). 'D' therefore ceases 772 to respond to Predirect messages correlated with the DEPARTED 773 entries, and also schedules a garbage-collection timer of 60 seconds, 774 after which it deletes the DEPARTED entries. 776 When 'D' receives packets destined to an address covered by the 777 DEPARTED forwarding table entries, it forwards them to the last-known 778 EUN link-layer address of 'E' as a means for avoiding mobility- 779 related packet loss during routing changes. 'D' also returns a NULL 780 Redirect message to inform the correspondent 'B' of the departure. 781 The Redirect message is prepared as follows: 783 o the link-layer source address is set to 'L2(D)'. 785 o the link-layer destination address is set to 'L2(B)'. 787 o the network-layer source address is set to 'L3(D)'. 789 o the network-layer destination address is set to 'L3(B)'. 791 o the Redirect Target and Destination Addresses are both set to 792 NULL. 794 o the Redirect message includes an RHO copied from the corresponding 795 Predirect message. 797 o the (A, P) bits in the Redirect message header are set to (1, 0). 799 Eventually, any correspondents will receive such a NULL Redirect 800 message and will cease to use 'D' as a next hop. They will then 801 revert to sending packets destined to 'E' via their gateways and may 802 subsequently receive new Redirect messages to discover that 'E' is 803 now associated with a new egress router. Note that any packets 804 forwarded by 'D' via a forwarding table entry in the DEPARTED state 805 may be lost if the mobile node moves off-link with respect to its 806 previous EUN point of attachment. This should not be a problem for 807 large links (e.g., large cellular network deployments, large ISP 808 networks, etc.) in which all/most mobility events are intra-link. 810 4.6. Scaling Considerations 812 Figure 1 depicts a reference network topology with only a single 813 gateway on the AERO link. In order to support larger numbers of AERO 814 routers and hosts, the AERO link can deploy more gateways to support 815 load balancing and generally shortest-path routing. 817 Such an arrangement requires that the gateways participate in a 818 routing protocol instance (e.g., an eBGP instance with each gateway 819 configuring a private Autonomous System Number (ASN)) so that 820 address/prefix delegations can be mapped to the correct gateway. The 821 routing protocol instance can be configured as either a full mesh 822 topology involving all gateways, or as a partial mesh topology with 823 each AERO link gateway associating with one or more backhaul network 824 companion gateways and a full mesh between companion gateways. 826 4.7. Proxy Chaining 828 In large AERO link deployments, there may be many gateways - each 829 serving many AERO routers and hosts. The gateways then either 830 require full topology knowledge, or a default route to a companion 831 gateway that does have full topology knowledge. For example, if AERO 832 node 'A' connects to gateway 'B', and AERO node 'E' connects to 833 gateway 'D', then 'B' and 'D' must either have full topology 834 knowledge or have a default route to a companion gateway (e.g., 'C') 835 that does. 837 In that case, when 'A' forwards an initial packet destined to an end 838 system behind 'E', it forwards the packet to 'B'. Next, 'B' forwards 839 the packet toward 'C', which both forwards the packet generates a 840 Predirect message toward 'D'. 'D' then either processes the 841 Predirect message locally or proxies it toward 'E'. 843 In the reverse direction, when 'E'/'D' sends a Redirect response 844 message back to 'A', it first sends the message to 'D'/'C', which 845 proxies the message toward 'B', which finally proxies the message 846 toward 'A'. 848 4.8. Backward Compatibility 850 If a legacy host or router receives an AERO Redirect or Predirect 851 message, it will process the message as if it were an ordinary 852 Redirect. This will cause no harmful effects, since the legacy 853 system will ignore the 'A' and P' bits in the Reserved field, and 854 will also ignore any RIOs that are included. The values encoded in 855 the Redirect message target and destination addresses will also not 856 cause the legacy node to create incorrect routing state. The 857 mechanism therefore causes no harm to legacy systems, and supports 858 natural incremental deployment. 860 5. IANA Considerations 862 There are no IANA considerations for this document. 864 6. Security Considerations 866 This document enables ingress filtering, and therefore improves the 867 security of AERO links. 869 7. Acknowledgements 871 Discussions both on the v6ops list and in private exchanges helped 872 shape some of the concepts in this work. Individuals who contributed 873 insights include Mikael Abrahamsson, Fred Baker, Brian Carpenter, 874 Joel Halpern, Lee Howard, 876 8. References 878 8.1. Normative References 880 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 881 September 1981. 883 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 884 RFC 792, September 1981. 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, March 1997. 889 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 890 (IPv6) Specification", RFC 2460, December 1998. 892 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 893 More-Specific Routes", RFC 4191, November 2005. 895 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 896 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 897 September 2007. 899 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 900 Address Autoconfiguration", RFC 4862, September 2007. 902 8.2. Informative References 904 [I-D.ietf-savi-framework] 905 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 906 "Source Address Validation Improvement Framework", 907 draft-ietf-savi-framework-05 (work in progress), 908 July 2011. 910 [I-D.templin-intarea-vet] 911 Templin, F., "Virtual Enterprise Traversal (VET)", 912 draft-templin-intarea-vet-24 (work in progress), 913 March 2011. 915 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 916 RFC 2131, March 1997. 918 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 919 Domains without Explicit Tunnels", RFC 2529, March 1999. 921 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 922 and M. Carney, "Dynamic Host Configuration Protocol for 923 IPv6 (DHCPv6)", RFC 3315, July 2003. 925 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 926 Host Configuration Protocol (DHCP) version 6", RFC 3633, 927 December 2003. 929 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 930 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 931 March 2008. 933 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 934 Infrastructures (6rd)", RFC 5569, January 2010. 936 Author's Address 938 Fred L. Templin (editor) 939 Boeing Research & Technology 940 P.O. Box 3707 MC 7L-49 941 Seattle, WA 98124 942 USA 944 Email: fltemplin@acm.org