idnits 2.17.1 draft-templin-aero-00.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 == Line 148 has weird spacing: '...RO link any m...' == Line 151 has weird spacing: '...RO node a gat...' == Line 153 has weird spacing: '...gateway a rou...' == Line 157 has weird spacing: '... router a rou...' == Line 161 has weird spacing: '...RO host a sim...' -- The document date (March 30, 2011) is 4769 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 (-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 (~~), 7 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 March 30, 2011 5 Expires: October 1, 2011 7 Asymmetric Extended Route Optimization (AERO) 8 draft-templin-aero-00.txt 10 Abstract 12 Nodes (i.e., gateways, routers and hosts) attached to link types such 13 as multicast-capable, shared media and non-broadcast multiple access 14 (NBMA), etc. can exchange packets as neighbors on the link. Each 15 node should therefore be able to discover a neighboring gateway that 16 can provide default routing services to reach off-link destinations, 17 and should also accept redirection messages from the gateway 18 informing it of a neighbor that is closer to the final destination. 19 This redirect function can provide a useful route optimization, since 20 the triangular path from the ingress link neighbor, to the gateway, 21 and finally to the egress link neighbor may be considerably longer 22 than the direct path between the neighbors. However, ordinary 23 redirection may lead to operational issues on certain link types 24 and/or in certain deployment scenarios. This document therefore 25 introduces an Asymmetric Extended Route Optimization (AERO) 26 capability that 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 October 1, 2011. 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 Expedited 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 . . . . . . . . . . . . . . . . . . 6 71 4.2.4. AERO Router Behavior . . . . . . . . . . . . . . . . . 7 72 4.2.5. AERO Gateway Behavior . . . . . . . . . . . . . . . . 7 73 4.3. AERO Reference Operational Scenario . . . . . . . . . . . 7 74 4.4. AERO Specification . . . . . . . . . . . . . . . . . . . . 9 75 4.4.1. Sending Predirects . . . . . . . . . . . . . . . . . . 10 76 4.4.2. Processing Predirects and Sending Redirects . . . . . 12 77 4.4.3. Proxying Redirects . . . . . . . . . . . . . . . . . . 13 78 4.4.4. Processing Redirects . . . . . . . . . . . . . . . . . 14 79 4.4.5. Sending Periodic Predirect Keepalives . . . . . . . . 14 80 4.4.6. Reachability Considerations . . . . . . . . . . . . . 16 81 4.5. Mobility Considerations . . . . . . . . . . . . . . . . . 16 82 4.6. Scaling Considerations . . . . . . . . . . . . . . . . . . 17 83 4.7. Proxy Chaining . . . . . . . . . . . . . . . . . . . . . . 18 84 4.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 18 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 Nodes (i.e., routers and hosts) attached to link types such as 96 multicast-capable, shared media, non-broadcast multiple access 97 (NBMA), etc. can exchange packets with each other as neighbors on the 98 link. Each node should therefore be able to discover a neighboring 99 gateway that can provide default routing services to reach off-link 100 destinations, and should also accept redirection messages from the 101 gateway informing it of a different link neighbor that is closer to 102 the final destination. This redirect function can provide a useful 103 route optimization, since the triangular path from the ingress link 104 neighbor, to the gateway, and finally to the egress link neighbor may 105 be considerably longer than the direct path between the neighbors. 106 However, ordinary redirection may lead to operational issues on 107 certain link types and/or in 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 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 multiple access and 136 redirection [RFC0792][RFC4861]. The rest of this document refers to 137 this class 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 multiple access 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 any multiple access link over which the AERO mechanisms 149 can be applied. 151 AERO node a gateway, router or host connected to an AERO link. 153 AERO gateway a router that configures an advertising router 154 interface on the AERO link, and that can provide default routing 155 services for forwarding packets to off-link destinations. 157 AERO router a router that configures a non-advertising router 158 interface on the AERO link, and that connects End User Networks to 159 the AERO link. 161 AERO host a simple host on the AERO link. 163 ingress AERO node ("ingress") a node that injects packets into the 164 AERO link. 166 egress AERO node ("egress") a node that removes packets from the 167 AERO link. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. When used 172 in lower case (e.g., must, must not, etc.), these words MUST NOT be 173 interpreted as described in [RFC2119], but are rather interpreted as 174 they would be in common English. 176 3. Requirements 178 The route optimization mechanism must satisfy the following 179 requirements: 181 Req 1: Off-load traffic from performance-critical gateways. The 182 mechanism must offload sustained transit though a gateway that 183 would become a traffic concentrator. 185 Req 2: Support route optimization. Ingress nodes must be able to 186 send packets directly to egress nodes without involving a gateway 187 as an intermediary hop. 189 Req 3: Support multiple levels of hierarchy. For scaling purposes, 190 allow multiple levels of hierarchy in which gateways in higher 191 levels have progressively more topology knowledge than those in 192 lower levels. 194 Req 4: Do not circumvent ingress filtering. The mechanism must not 195 open an attack vector where network-layer source address spoofing 196 is enabled even when link-layer source address spoofing is 197 disabled. 199 Req 5: Do not open expose packets to loss due to filtering. The 200 ingress node must have a way of knowing that the egress node will 201 accept its forwarded packets. 203 Req 6: Do not open expose packets to loss due to failure of the path 204 to the egress. The ingress node must have a way of discovering 205 whether the egress has gone unreachable on the route optimized 206 path. 208 Req 7: Do not introduce routing loops. The gateway must not perform 209 a route optimization that would cause a routing loop to form. 211 Req 8: Support mobility. The mechanism must continue to work even if 212 the final destination node/network moves from a first egress node 213 and re-associates with a second egress node. 215 4. Asymmetric Expedited Route Optimization (AERO) 217 The following sections specify an Asymmetric Extended Route 218 Optimization (AERO) capability that fulfills the requirements 219 specified in Section 3. 221 4.1. AERO Link Dynamic Routing 223 In many AERO link use case scenarios (e.g., enterprise networks, 224 small and stable MANETs, etc.), AERO gateways and routers can engage 225 in a proactive dynamic routing protocol (e.g., OSPF, RIP, IS-IS, 226 etc.) so that routing/forwarding tables can be populated and standard 227 forwarding between routers can be used. In other scenarios (e.g., 228 large ISP networks, cellular service provider networks, dynamic 229 MANETs, etc.), this might be impractical dues to scaling issues. 231 When a proactive dynamic routing protocol cannot be used, the on- 232 demand dynamic routing capabilities specified in this section should 233 be used. 235 4.2. AERO Node Behavior 237 The following sections discuss characteristics of nodes attached to 238 links over which AERO can be used: 240 4.2.1. AERO Node Types 242 AERO gateways configure their AERO link interfaces as advertising 243 router interfaces (see: [RFC4861], Section 6.2.2), and therefore may 244 send Router Advertisement (RA) messages that include non-zero Router 245 Lifetimes. 247 AERO routers configure their AERO link interfaces as non-advertising 248 router interfaces. 250 AERO hosts configure their AERO link interfaces as simple host 251 interfaces. 253 4.2.2. Source Address Verification 255 AERO nodes must employ a source address verification check for the 256 packets they receive on an AERO interface; namely, the node considers 257 the network-layer source address correct for the link-layer source 258 address if: 260 o the link-layer source address is the address of an AERO gateway, 261 or 263 o the link-layer source address is explicitly linked to the network- 264 layer source address (i.e., through stateless or stateful address 265 mapping), or 267 o a forwarding table entry exists that lists the packet's link-layer 268 source address as the link layer address corresponding to the next 269 hop toward the network-layer source address on the AERO link. 271 The latter of these checks can be established through static 272 configuration, a proactive dynamic routing protocol, or through the 273 AERO mechanisms specified in Section 4.4. 275 4.2.3. AERO Host Behavior 277 AERO hosts send Router Solicitation (RS) messages to obtain RA 278 messages from an AERO gateway. Whether or not non-link-local 279 prefixes are advertised, the host can acquire network-layer addresses 280 via the gateway, e.g., through the use of DHCP stateful address 281 autoconfiguration [RFC2131][RFC3315]). 283 After the host receives addresses, it assigns them to its AERO 284 interface and forwards any of its outbound packets via the gateway as 285 a default router. The host may subsequently receive redirection 286 messages from the gateway listing a better next hop. 288 4.2.4. AERO Router Behavior 290 AERO routers send RS messages to obtain RA messages from an AERO 291 gateway, i.e., they act as "hosts" on their non-advertising AERO link 292 router interfaces. 294 Routers can also acquire prefixes, e.g., through the use of DHCPv6 295 Prefix Delegation [RFC3633] via an AERO gateway in the same fashion 296 as described above for host-based stateful address autoconfiguration. 298 After the router acquires prefixes, it can sub-delegate them to nodes 299 and links within its attached End User Networks (EUNs), then can 300 forward any outbound packets coming from its EUNs via the gateway. 301 The router may subsequently receive redirection messages from the 302 gateway listing a better next hop. 304 4.2.5. AERO Gateway Behavior 306 AERO gateways respond to RS messages from hosts and routers on the 307 AERO link by returning an RA message. Gateways further configure a 308 DHCP relay or server function on their AERO links. 310 When the gateway completes a DHCP address or prefix delegation 311 transaction (i.e., either as a DHCP relay or a DHCP server), it 312 establishes forwarding table entries that list the link-layer address 313 of the DHCP client as the link-layer address of the next hop toward 314 the delegated addresses/prefixes. 316 When the gateway forwards a packet out the same AERO interface it 317 arrived on, it initiates an AERO route optimization procedure as 318 specified in Section 4.4. 320 4.3. AERO Reference Operational Scenario 322 Figure 1 depicts a reference AERO network topology. IPv6 is used 323 only as an example network layer protocol, and the same fundamental 324 AERO techniques can be applied for other network layer protocols. 325 The figure shows an AERO gateway ('A'), two non-advertising AERO 326 routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts 327 ('C', 'E', 'G') in a typical operational scenario: 329 .-(::::::::) 2001:db8:3::1 330 .-(::: IPv6 :::)-. +-------------+ 331 (:::: Internet ::::) | IPv6 Host G | 332 `-(::::::::::::)-' +-------------+ 333 `-(::::::)-' 334 ,................., 335 |companion gateway| 336 '.................' +---------------+ 337 +--------------+ | Host F | 338 | Gateway A | +---------------+ 339 +--------------+ 2001:db8:2:1 340 L3(A) L3(F) 341 L2(A) L2(F) 342 | AERO Link | 343 X-----+--+-----------------+--+---X 344 | | 345 L2(B) L2(D) .-. 346 L3(B) L3(D) ,-( _)-. 347 +--------------+ +--------------+ .-(_ IPv6 )-. 348 | Router B | | Router D |--(__ EUN ) 349 +--------------+ +--------------+ `-(______)-' 350 2001:db8::/48 2001:db8:1::/48 | 351 | 2001:db8:1::1 352 .-. +-------------+ 353 ,-( _)-. 2001:db8::1 | IPv6 Host E | 354 .-(_ IPv6 )-. +-------------+ +-------------+ 355 (__ EUN )--| IPv6 Host C | 356 `-(______)-' +-------------+ 358 Figure 1: Reference AERO Network Topology 360 In Figure 1, Gateway 'A' connects to the AERO link and also connects 361 to the IPv6 Internet, either directly or via a companion gateway. 362 'A' configures an AERO link interface with a link-local network-layer 363 address L3(A) and with link-layer address L2(A). 'A' next arranges 364 to add the link-layer address L2(A) to the list of valid gateways for 365 the link. 367 Router 'B' connects to one or more IPv6 End User Networks (EUNs) and 368 also connects to the AERO link via an interface with a link-local 369 network-layer address L3(B) and with link-layer address L2(B). 'B' 370 next configures a default IPv6 route with next-hop address L3(A) via 371 the AERO interface, then receives the IPv6 prefix 2001:db8::/48 372 through a DHCPv6 prefix delegation exchange via 'A'. 'B' finally 373 sub-delegates the prefix to its attached EUNs, where IPv6 host 'C' 374 autoconfigures the address 2001:db8::1. 376 Router 'D' connects to the AERO link via an interface with addresses 377 L3(D)/L2(D), configures a default IPv6 route with next-hop address 378 L3(A) via the AERO interface, and receives a DHCPv6 prefix delegation 379 of 2001:db8:1::/48 in the same fashion as for router 'B'. 'D' 380 finally sub-delegates the prefix to its attached EUNs, where IPv6 381 host 'E' autoconfigures IPv6 address 2001:db8:1::1. 383 Host 'F' connects to the AERO link via an interface with addresses 384 L3(F)/L2(F). 'F' next configures a default IPv6 route with next-hop 385 address L3(A) via the AERO interface, then receives the IPv6 address 386 2001:db8:2::1 from a DHCPv6 address configuration exchange via 'A'. 387 When 'F' receives the IPv6 address, it assigns the address to the 388 AERO interface but does not assign a non-link-local IPv6 prefix to 389 the interface. 391 Finally, IPv6 host 'G' connects to an IPv6 network outside of the 392 AERO link domain. 'G' configures its IPv6 interface in a manner 393 specific to its attached IPv6 link, and autoconfigures the IPv6 394 address 2001:db8:3::1. 396 In these arrangements, 'A' must maintain routes that associate the 397 delegated IPv6 addresses/prefixes with the correct routers and/or 398 hosts on the AERO link. The routers and hosts must maintain at least 399 a default route that points to gateway 'A', and can discover more- 400 specific routes either via a proactive dynamic routing protocol or 401 via the AERO mechanisms specified in Section 4.4. 403 4.4. AERO Specification 405 Figure 1 depicts a reference operational scenario including an AERO 406 link. The figure shows an AERO gateway ('A'), two AERO routers ('B', 407 'D'), an AERO host ('F') and three ordinary IPv6 hosts ('C', 'E', 408 'G') in a typical deployment configuration. We now discuss the 409 operation of AERO with respect to this reference scenario. 411 With reference to Figure 1, when host 'C' sends a packet with source 412 address 'C' and destination address 'E', the packet is first 413 forwarded over 'C's attached EUN to router 'B'. 'B' then forwards 414 the packet over the AERO interface to gateway 'A', which then 415 forwards the packet to router 'D', where the packet is finally 416 forwarded to host 'E' over 'E's attached EUN. When 'A' forwards the 417 packet back out on its advertising AERO interface, it must arrange to 418 redirect 'B' toward 'D' as a better next hop node on the AERO link 419 that is closer to the final destination 'E'. However, this 420 redirection process should only take place if there is assurance that 421 both 'B' and 'D' are willing participants. 423 Consider a first alternative in which 'A' informs 'B' only and does 424 not inform 'D' (i.e., "classic redirection"). In that case, 'D' has 425 no way of knowing that 'B' is authorized to forward packets from a 426 given source address. Also, 'B' has no way of knowing whether 'D' is 427 willing to accept its packets, nor whether 'D' is even reachable. 428 Finally, 'B' has no way of knowing whether the final destination has 429 moved away from 'D'. 431 Consider also a second alternative in which 'A' informs both 'B' and 432 'D' separately via independent redirection messages (i.e., "augmented 433 redirection"). In that case, several conditions can occur that could 434 result in communications failures. First, if 'B' receives the 435 redirection message but 'D' does not, subsequent packets sent by 'B' 436 would be dropped due to filtering since 'D' would not have a 437 forwarding table entry to verify their source addresses. Second, if 438 'D' receives the redirection message but 'B' does not, subsequent 439 packets sent in the reverse direction by 'D' would be lost. Finally, 440 timing issues surrounding the establishment and garbage collection of 441 forwarding table entries at 'B' and 'D' could yield unpredictable 442 behavior. For example, unless the timing were carefully coordinated 443 through some form of synchronization loop, there would invariably be 444 instances in which one node has the correct forwarding table state 445 and the other node does not resulting in non-deterministic packet 446 loss. 448 Since neither of these alternatives can satisfy the requirements 449 listed in Section 3, a new redirection technique is needed. In 450 particular, when 'A' forwards a packet from 'B' out the same AERO 451 interface toward 'D', 'A' must first send a "Predirect" message 452 forward to 'D' to inform it that 'B' is authorized to produce packets 453 using source address 'C'. After 'D' receives the Predirect, it sends 454 a "Redirect" message back to 'B' via 'A' as a trusted intermediary. 455 When 'B' receives the Redirect, it knows that 'D' will accept the 456 packets it sends with source address 'C' as long as 'D' retains the 457 forwarding table entry. This process is known as Asymmetric Extended 458 Route Optimization (AERO), which stands in contrast to the classical 459 and augmented redirection approaches. The following subsections 460 therefore specify the AERO redirection steps necessary to support the 461 reference operational scenario. 463 4.4.1. Sending Predirects 465 When a gateway forwards a packet out the same AERO interface that it 466 arrived on, the gateway sends a "Predirect" message forward to the 467 egress AERO node instead of sending a Redirect message back to the 468 ingress node. The Predirect message is simply an AERO-specific 469 version of an ordinary Redirect message. In the case of IPv6 as the 470 network layer protocol, the Predirect format is the same as depicted 471 in Section 4.5 of [RFC4861], and is identified by two new backward- 472 compatible bits taken from the Reserved field as shown in Figure 2: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type (=137) | Code (=0) | Checksum | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 |A|P| Reserved | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 + + 483 | | 484 + Target Address + 485 | | 486 + + 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 + + 491 | | 492 + Destination Address + 493 | | 494 + + 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Options ... 498 +-+-+-+-+-+-+-+-+-+-+-+- 500 Figure 2: AERO-Specific IPv6 Redirect Message Format 502 Where the new bits are defined as: 504 A (1) the "AERO" bit. Set to 1 to indicate an AERO-specific 505 Redirect message, and set to 0 to indicate an ordinary IPv6 506 Redirect message. 508 P (1) the "Predirect" bit. Set to 1 to indicate a Predirect 509 message, and set to 0 to indicate a Redirect response to a 510 Predirect message. (This bit is valid only when the A bit is set 511 to 1.) 513 In the reference operational scenario, when gateway 'A' forwards a 514 packet sent by 'B' toward 'D', it also sends a Predirect message 515 forward toward 'D', subject to rate limiting (see Section 8.2 of 516 [RFC4861]). 'A' prepares the Predirect message in a similar fashion 517 as for an ordinary IPv6 Redirect message as follows: 519 o the link-layer source address is set to 'L2(A)' 520 o the link-layer destination address is set to 'L2(D)' 522 o the network-layer source address is set to 'L3(B)'. 524 o the network-layer destination address is set to 'L3(D)'. 526 o the Predirect Target and Destination Addresses are both set to 527 'L3(B)'. 529 o on links that require stateful address mapping, the Predirect 530 message includes a Target Link Layer Address Option (TLLAO) set to 531 'L2(B)'. 533 o the Predirect message includes Route Information Options (RIOs) 534 [RFC4191] that encode prefixes taken from 'B's address/prefix 535 delegations, including one that covers the source address of the 536 originating packet. 538 o the Predirect message includes a Redirected Header Option (RHO) 539 that contains the first 128 bytes of the originating packet 540 beginning with the network-layer header (or up to the remainder of 541 the packet if there are fewer than 128 bytes). 543 o the A and P bits in the Predirect message header are both set to 544 1. 546 'A' then sends the Predirect message forward to 'D'. 548 4.4.2. Processing Predirects and Sending Redirects 550 When an AERO router or host receives a Predirect message, it 551 validates the message according to the appropriate redirect message 552 validation rules (e.g., Section 8.1 of [RFC4861] for IPv6). The node 553 further accepts the message only if it came from the link-layer 554 address of either a trusted gateway or the current previous hop on 555 the AERO link for the source address of the originating packet 556 encapsulated in the RHO. Finally, the node only processes the 557 message if the destination address of the originating packet 558 encapsulated in the RHO is covered by one of its CURRENT delegated 559 addresses/prefixes (see Section 4.5). 561 In the reference operational scenario, when router 'D' receives the 562 Predirect message from the gateway it creates forwarding table 563 entries with the prefixes encoded in RIO options as the target 564 prefixes, and associates the forwarding table entries with a node 565 structure (e.g., in a neighbor cache) that stores the source address 566 of the Predirect message (i.e., 'L3(B)'). 'D' places the node 567 structure in the FILTERING state, then sets/resets a filtering 568 expiration timer value of 40 seconds. If the filtering timer later 569 expires, 'D' clears the FILTERING state. If the node structure is 570 not in the FORWARDING state, 'D' then deletes the node structure and 571 all of its associated forwarding table entries. (This suggests that 572 'D's AERO interface should maintain a private forwarding table 573 separate from the primary forwarding table, since the node structure 574 and forwarding table entries must be managed by the AERO interface 575 itself.) 577 After processing the Predirect message and establishing the 578 forwarding table entry, 'D' prepares a Redirect message in response 579 to the Predirect as follows: 581 o the link-layer source address is set to 'L2(D)' 583 o the link-layer destination address is set to 'L2(A)' 585 o the network-layer source address is set to 'L3(D)'. 587 o the network-layer destination address is set to 'L3(B)'. 589 o the Redirect Target and the Redirect Destination Addresses are 590 both set to 'L3(D)'. 592 o on links that require stateful address mapping, the Redirect 593 message includes a TLLAO set to 'L2(D)'. 595 o the Redirect message includes an RHO copied from the corresponding 596 Predirect message. 598 o the (A, P) bits in the Redirect message header are set to (1, 0). 600 After 'D' prepares the Redirect message, it sends the message to 'A'. 601 (Note that the Redirect message does not include RIOs, since the 602 gateway is the only authoritative source of routing information and 603 will supply RIOs when it proxies the message.) 605 4.4.3. Proxying Redirects 607 When an AERO gateway receives a Redirect message, it accepts the 608 message only if it satisfies the redirect message validation rules. 609 The gateway further accepts the message only if it came from the 610 link-layer address of the current next hop toward the destination 611 address of the originating packet encapsulated in the RHO. The 612 gateway then "proxies" the Redirect message back to the original 613 ingress AERO node as described below. 615 In the reference operational scenario, 'A' receives the Redirect 616 message from 'D' then proxies the message back toward 'B'. In 617 particular, 'A' adds RIOs to the message that encode 'D's address/ 618 prefix delegations. Without decrementing the hopcount in the 619 Redirect message, 'A' next changes the link-layer source address of 620 the message to 'L2(A)' and changes the link-layer destination address 621 to 'L2(B)'. 'A' then sends this proxied Redirect message to 'B'. 623 4.4.4. Processing Redirects 625 When an AERO router or host receives a Redirect message, it validates 626 the message according to the appropriate redirect message validation 627 rules. The node further accepts the message only if it came from the 628 link-layer address of either a trusted gateway or the current next 629 hop on the AERO link for the destination address of the originating 630 packet encapsulated in the RHO. 632 In the reference operational scenario, 'B' receives the (proxied) 633 Redirect message then creates forwarding table entries with the 634 prefixes encoded in RIO options as the target prefixes. 'B' further 635 associates the forwarding table entries with a node structure (e.g., 636 in a neighbor cache) that stores the source address of the Predirect 637 message (i.e., 'L3(D)'). 'B' places the node structure in the 638 FORWARDING state, then sets/resets a filtering expiration timer value 639 of 30 seconds. If the filtering timer later expires, 'B' clears the 640 FORWARDING state. If the node structure is not in the FILTERING 641 state, 'B' then deletes the node structure and all of its associated 642 forwarding table entries. 644 Now, 'B' has a node structure for 'D' in the FORWARDING state, and 645 'D' has a node structure for 'B' in the FILTERING state. Therefore, 646 'B' may forward ordinary network-layer data packets with destination 647 addresses covered by 'D's prefixes directly to 'D' without involving 648 'A'. 'D' will in turn accept the packets since it has a forwarding 649 table entry authorizing 'B' to forward packets with source addresses 650 covered by 'B's prefixes. 652 To enable packet forwarding in the reverse direction, a separate AERO 653 operation is required which is the mirror-image of the forward AERO 654 operation described above, i.e., the forward and reverse AERO 655 operations are asymmetric. Following the reverse operation, packets 656 can be exchanged bidirectionally without involving 'A'. 658 4.4.5. Sending Periodic Predirect Keepalives 660 In order to prevent forwarding table entries from expiring while data 661 packets are actively flowing, the ingress node can peridoically send 662 Predircet messages directly to the egress node (subject to rate 663 limiting) to solicit Redirect messages. In the reference operational 664 scenario, when 'B' forwards a packet to 'D' and wishes to update the 665 corresponding FORWARDING state timer, 'B' can also send a Predirect 666 message directly to 'D' prepared as follows: 668 o the link-layer source address is set to 'L2(B)'. 670 o the link-layer destination address is set to 'L2(D)'. 672 o the network-layer source address is set to 'L3(B)'. 674 o the network-layer destination address is set to 'L3(D)'. 676 o the Predirect Target and Destination Addresses are both set to 677 'L3(B)'. 679 o the Predirect message includes a Redirected Header Option (RHO) 680 that contains the first 128 bytes of the originating packet 681 beginning with the network-layer header (or up to the remainder of 682 the packet if there are fewer than 128 bytes). 684 o the A and P bits in the Predirect message header are both set to 685 1. 687 When 'D' receives the Predirect message, it accepts the message only 688 if it satisfies the redirect message validation rules. The node 689 further accepts the message only if it came from the current previous 690 hop on the AERO link for the source address of the originating packet 691 encapsulated in the RHO. 'D' then resets its FILTERING expiration 692 timer for node 'B' to 40 seconds, and sends a Redirect message 693 directly to 'B' prepared as follows: 695 o the link-layer source address is set to 'L2(D)'. 697 o the link-layer destination address is set to 'L2(B)'. 699 o the network-layer source address is set to 'L3(D)'. 701 o the network-layer destination address is set to 'L3(B)'. 703 o the Redirect Target and Destination Addresses are both set to 704 'L3(D)'. 706 o the Redirect message includes an RHO copied from the corresponding 707 Predirect message. 709 o the (A, P) bits in the Redirect message header are set to (1, 0). 711 When 'B' receives the Redirect message, it accepts the message only 712 if it satisfies the redirect message validation rules. The node 713 further accepts the message only if it came from the current next hop 714 on the AERO link for the source address of the originating packet 715 encapsulated in the RHO. 'B' then resets its FORWARDING expiration 716 timer for node 'D' to 30 seconds. 718 Note that in these direct neighbor to neighbor exchanges, neither the 719 Predirect nor Redirect message contain RIOs, since gateways are the 720 only authoritative source of routing information. Therefore, AERO 721 routers and hosts should not include RIOs in the Predirects/Redirects 722 they send, and they must ignore any RIOs included in received 723 Predirect/Redirect messages that did not come from a trusted gateway. 725 4.4.6. Reachability Considerations 727 When an ingress node receives a Redirect message informing it of a 728 direct path to a new egress, there is a question in point as to 729 whether the new egress can be reached directly without involving the 730 gateway as an intermediary. In some environments, it may be 731 reasonable for the ingress to (optimistically) assume that the new 732 egress is reachable, and to immediately begin forwarding data packets 733 to the egress without testing reachability. 735 In environments in which an optimistic assumption of reachability may 736 be inappropriate, however, the ingress can defer the redirection 737 until it tests the direct path to the egress by sending a direct 738 Predirect message to elicit a Redirect as specified in Section 4.4.5. 739 If the ingress is unable to elicit a Redirect message after a small 740 number of attempts, it should consider the direct path to the egress 741 as unusable. 743 In either case, the ingress can process any link errors corresponding 744 to the data packets sent directly to the egress as a hint that the 745 direct path has either failed or has become intermittent. 747 4.5. Mobility Considerations 749 An AERO link egress router 'D' can configure both a non-advertising 750 router interface on a provider AERO link and an advertising router 751 interface to provide gateway services to nodes in EUNs. When node 752 'E' in an EUN that has obtained addresses/prefixes moves to a 753 different network point of attachment, however, 'E' can release its 754 address/prefix delegations via 'D' and re-establish them via a 755 different gateway. 757 When 'E' releases its address/prefix delegations via 'D', 'D' marks 758 the forwarding table entries that cover the addresses/prefixes as 759 DEPARTED (i.e., it clears the CURRENT state). 'D' therefore ceases 760 to respond to Predirect messages correlated with the DEPARTED 761 entries, and also schedules a garbage-collection timer of 60 seconds, 762 after which it deletes the DEPARTED entries. 764 When 'D' receives packets destined to an address covered by the 765 DEPARTED forwarding table entries, it forwards them to the last-known 766 EUN link-layer address of 'E' as a means for avoiding mobility- 767 related packet loss during routing changes. 'D' also returns a NULL 768 Redirect message to inform the correspondent 'B' of the departure. 769 The Redirect message is prepared as follows: 771 o the link-layer source address is set to 'L2(D)'. 773 o the link-layer destination address is set to 'L2(B)'. 775 o the network-layer source address is set to 'L3(D)'. 777 o the network-layer destination address is set to 'L3(B)'. 779 o the Redirect Target and Destination Addresses are both set to 780 NULL. 782 o the Redirect message includes an RHO copied from the corresponding 783 Predirect message. 785 o the (A, P) bits in the Redirect message header are set to (1, 0). 787 Eventually, any correspondents will receive such a NULL Redirect 788 message and will cease to use 'D' as a next hop. They will then 789 revert to sending packets destined to 'E' via their gateways and will 790 receive new Redirect messages to discover that 'E' is now associated 791 with a new egress router. Note that any packets forwarded by 'D' via 792 a forwarding table entry in the DEPARTED state may be lost if the 793 mobile node moves off-link with respect to its previous EUN point of 794 attachment. This should not be a problem for large links (e.g., 795 large cellular network deployments, large ISP networks, etc.) in 796 which all/most mobility events are intra-link. 798 4.6. Scaling Considerations 800 Figure 1 depicts a reference network topology with only a single 801 gateway on the AERO link. In order to support larger numbers of AERO 802 routers and hosts, the AERO link can deploy more gateways to support 803 load balancing and generally shortest-path routing. 805 Such an arrangement requires that the gateways participate in a 806 routing protocol instance (e.g., iBGP) so that address/prefix 807 delegations can be mapped to the correct gateway. The routing 808 protocol instance can be configured as either a full mesh topology 809 involving all gateways, or as a partial mesh topology with each AERO 810 link gateway associating with one or more backhaul network companion 811 gateways and a full mesh between companion gateways. 813 4.7. Proxy Chaining 815 In large AERO link deployments, there may be many gateways - each 816 serving many AERO routers and hosts. The gateways then either 817 require full topology knowledge, or a default route to a companion 818 gateway that does have full topology knowledge. For example, if AERO 819 node 'A' connects to gateway 'B', and AERO node 'E' connects to 820 gateway 'D', then 'B' and 'D' must either have full topology 821 knowledge or have a default route to a companion gateway (e.g., 'C') 822 that does. 824 In that case, when 'A' forwards an initial packet destined to an end 825 system behind 'E', 'B' generates a Predirect message toward 'C', 826 which proxies the message toward 'D' which finally proxies the 827 message toward 'E'. 829 In the reverse direction, when 'E' sends a Redirect response message 830 back to 'A', it first sends the message to 'D', which proxies the 831 message toward 'C', which proxies the message toward 'B', which 832 finally proxies the message toward 'A'. 834 4.8. Backward Compatibility 836 If a legacy host or router receives an AERO Redirect or Predirect 837 message, it will process the message as if it were an ordinary 838 Redirect. This will cause no harmful effects, since the legacy 839 system will ignore the 'A' and P' bits in the Reserved field, and 840 will also ignore any RIOs that are included. The values encoded in 841 the Redirect message target and destination addresses will also not 842 cause the legacy node to create incorrect routing state. The 843 mechanism therefore causes no harm to legacy systems, and supports 844 natural incremental deployment. 846 5. IANA Considerations 848 There are no IANA considerations for this document. 850 6. Security Considerations 852 This document enables ingress filtering, and therefore improves the 853 security of AERO links. 855 7. Acknowledgements 857 Discussions both on the v6ops list and in private exchanges helped 858 shape some of the concepts in this work. Individuals who contributed 859 insights include Mikael Abrahamsson, Fred Baker, Brian Carpenter, 860 Joel Halpern, Lee Howard, 862 8. References 864 8.1. Normative References 866 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 867 September 1981. 869 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 870 RFC 792, September 1981. 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997. 875 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 876 (IPv6) Specification", RFC 2460, December 1998. 878 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 879 More-Specific Routes", RFC 4191, November 2005. 881 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 882 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 883 September 2007. 885 8.2. Informative References 887 [I-D.templin-intarea-vet] 888 Templin, F., "Virtual Enterprise Traversal (VET)", 889 draft-templin-intarea-vet-24 (work in progress), 890 March 2011. 892 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 893 RFC 2131, March 1997. 895 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 896 Domains without Explicit Tunnels", RFC 2529, March 1999. 898 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 899 and M. Carney, "Dynamic Host Configuration Protocol for 900 IPv6 (DHCPv6)", RFC 3315, July 2003. 902 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 903 Host Configuration Protocol (DHCP) version 6", RFC 3633, 904 December 2003. 906 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 907 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 908 March 2008. 910 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 911 Infrastructures (6rd)", RFC 5569, January 2010. 913 Author's Address 915 Fred L. Templin (editor) 916 Boeing Research & Technology 917 P.O. Box 3707 MC 7L-49 918 Seattle, WA 98124 919 USA 921 Email: fltemplin@acm.org