idnits 2.17.1 draft-templin-aero-11.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 12, 2012) is 4329 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4443' is defined on line 1292, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-33 == Outdated reference: A later version (-16) exists of draft-templin-ironbis-10 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Experimental June 12, 2012 5 Expires: December 14, 2012 7 Asymmetric Extended Route Optimization (AERO) 8 draft-templin-aero-11.txt 10 Abstract 12 Nodes attached to common multi-access link types (e.g., multicast- 13 capable, shared media, non-broadcast multiple access (NBMA), etc.) 14 can exchange packets as neighbors on the link, but may not always be 15 provisioned with sufficient routing information for optimal neighbor 16 selection. Such nodes should therefore be able to discover a trusted 17 intermediate router on the link that provides both forwarding 18 services to reach off-link destinations and redirection services to 19 inform the node of an on-link neighbor that is closer to the final 20 destination. This redirection can provide a useful route 21 optimization, since the triangular path from the ingress link 22 neighbor, to the intermediate router, and finally to the egress link 23 neighbor may be considerably longer than the direct path from ingress 24 to egress. However, ordinary redirection may lead to operational 25 issues on certain link types and/or in certain deployment scenarios. 26 This document therefore introduces an Asymmetric Extended Route 27 Optimization (AERO) capability that addresses the issues. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 14, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 10 69 6.1. AERO Link Dynamic Routing . . . . . . . . . . . . . . . . 10 70 6.2. AERO Node Behavior . . . . . . . . . . . . . . . . . . . . 11 71 6.2.1. AERO Node Types . . . . . . . . . . . . . . . . . . . 11 72 6.2.2. AERO Host Behavior . . . . . . . . . . . . . . . . . . 11 73 6.2.3. Edge AERO Router Behavior . . . . . . . . . . . . . . 11 74 6.2.4. Intermediate AERO Router Behavior . . . . . . . . . . 11 75 6.3. AERO Reference Operational Scenario . . . . . . . . . . . 12 76 6.4. AERO Specification . . . . . . . . . . . . . . . . . . . . 14 77 6.4.1. Classical Redirection Approaches . . . . . . . . . . . 14 78 6.4.2. AERO Concept of Operations . . . . . . . . . . . . . . 15 79 6.4.3. Conceptual Data Structures and Protocol Constants . . 16 80 6.4.4. Data Origin Authentication . . . . . . . . . . . . . . 17 81 6.4.5. AERO Redirection Message Format . . . . . . . . . . . 18 82 6.4.6. Sending Predirects . . . . . . . . . . . . . . . . . . 20 83 6.4.7. Processing Predirects and Sending Redirects . . . . . 21 84 6.4.8. Relaying Redirects . . . . . . . . . . . . . . . . . . 22 85 6.4.9. Processing Redirects . . . . . . . . . . . . . . . . . 23 86 6.4.10. Sending Periodic Predirect Keepalives . . . . . . . . 24 87 6.4.11. Neighbor Reachability Considerations . . . . . . . . . 25 88 6.4.12. Mobility Considerations . . . . . . . . . . . . . . . 26 89 6.4.13. Link-Layer Address Change Considerations . . . . . . . 27 90 6.4.14. Prefix Re-Provisioning Considerations . . . . . . . . 28 91 6.4.15. Backward Compatibility . . . . . . . . . . . . . . . . 28 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 97 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 98 Appendix A. Intermediate Router Interworking . . . . . . . . . . 31 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 1. Introduction 103 Nodes attached to common multi-access link types (e.g., multicast- 104 capable, shared media, non-broadcast multiple access (NBMA), etc.) 105 can exchange packets as neighbors on the link, but may not always be 106 provisioned with sufficient routing information for optimal neighbor 107 selection. Such nodes should therefore be able to discover a trusted 108 intermediate router on the link that provides both default forwarding 109 services to reach off-link destinations and redirection services to 110 inform the node of an on-link neighbor that is closer to the final 111 destination. 113 +--------------+ 114 | Router A | 115 | (D->C) | 116 +--------------+ 117 | 118 X--------+--------+--------+------X 119 | | 120 +----------+---+ +---+----------+ 121 | Node B | | Router C | 122 | (default->A) | +-------+------+ 123 +--------------+ .-. 124 ,-( _)-. 125 .-(_ IPv6 )-. 126 (__ EUN ) 127 `-(______)-' 128 +-------+------+ 129 | Node D | 130 +--------------+ 132 Figure 1: Classical Multi-Access Link Redirection 134 Figure 1 shows a classical multi-access link redirection scenario. 135 In this figure, Node 'B' is provisioned with only a default route 136 with Router 'A' as the next hop. Router 'A' in turn has a more- 137 specific route that lists Router 'C' as the next hop neighbor on the 138 link for Node 'D's attached End User Network (EUN). 140 If Node 'B' has a packet to send to Node 'D', 'B' is obliged to send 141 its initial packets via Router 'A'. Router 'A' then forwards the 142 packet to Router 'C' and also returns a redirection message to inform 143 'B' that 'C' is in fact an on-link neighbor that is closer to the 144 final destination 'D'. After receiving the redirection message, 'B' 145 can place a more-specific route in its forwarding table so that 146 future packets destined to 'D' can be sent directly via Router 'C', 147 as shown in Figure 2. 149 +--------------+ 150 | Router A | 151 | (D->C) | 152 +--------------+ 153 | 154 X--------+--------+--------+------X 155 | | 156 +----------+---+ +---+----------+ 157 | Node B | | Router C | 158 | (default->A) | +-------+------+ 159 | (D->C) | .-. 160 +--------------+ ,-( _)-. 161 .-(_ IPv6 )-. 162 (__ EUN ) 163 `-(______)-' 164 +-------+------+ 165 | Node D | 166 +--------------+ 168 Figure 2: More-Specific Routes Following Redirection 170 This classical redirection can provide a useful route optimization, 171 since the triangular path from the ingress link neighbor, to the 172 intermediate router, and finally to the egress link neighbor may be 173 considerably longer than the direct path from ingress to egress. 174 However, ordinary redirection may lead to operational issues on 175 certain link types and/or in certain deployment scenarios. 177 For example, when an ingress link neighbor accepts an ordinary 178 redirection message, it has no way of knowing whether the egress link 179 neighbor is ready and willing to accept packets directly without 180 involving an intermediate router. Likewise, the egress has no way of 181 knowing that the ingress is authorized to forward packets from the 182 claimed network-layer source address. (This is especially important 183 for very large links, since any node on the link can spoof the 184 network-layer source address with low probability of detection even 185 if the link-layer source address cannot be spoofed.) Additionally, 186 the ingress would have no way of knowing whether the direct path to 187 the egress has failed, nor whether the final destination has moved 188 away from the egress to some other network attachment point. 190 Therefore, a new approach is required that can enable redirection 191 signaling from the egress to the ingress link node under the 192 mediation of a trusted intermediate router. The mechanism is 193 asymmetric (since only the forward direction from the ingress to the 194 egress is optimized) and extended (since the redirection extends 195 forward to the egress before reaching back to the ingress). This 196 document therefore introduces an Asymmetric Extended Route 197 Optimization (AERO) capability that addresses the issues. 199 While the AERO mechanisms were initially designed for the specific 200 purpose of NBMA tunnel virtual interfaces (e.g., see: 201 [RFC2529][RFC5214][RFC5569][I-D.templin-intarea-vet]) they can also 202 be applied to any multiple access link types that support 203 redirection. The AERO techniques are discussed herein with reference 204 to IPv6 [RFC2460][RFC4861][RFC4862][RFC3315], however they can also 205 be applied to any other network layer protocol (e.g., IPv4 206 [RFC0791][RFC0792][RFC2131], etc.) that provides a redirection 207 service (details of operation for other network layer protocols are 208 out of scope.) 210 This document is intended for publication on the experimental track, 211 and therefore does not seek to define a new standard for the 212 Internet. Experimental instead of standards-track is requested since 213 the document proposes a new and different dynamic routing mechanism. 214 Experimentation will focus on candidate multiaccess link types that 215 can connect large numbers of neighboring nodes where the use of 216 existing dynamic routing protocols may be impractical. Examples 217 include NBMA tunnel virtual links, large bridged campus LANs, etc. 219 2. Terminology 221 The terminology in the normative references apply; the following 222 terms are defined within the scope of this document: 224 AERO link 225 any link (either physical or virtual) over which the AERO 226 mechanisms can be applied. (For example, a virtual overlay of 227 tunnels can serve as an AERO link.) 229 AERO interface 230 an node's attachment to an AERO link. 232 AERO node 233 a router or host connected to an AERO link, and that participates 234 in the AERO protocol on that link. 236 intermediate AERO router ("intermediate router") 237 a router that configures an advertising router interface on an 238 AERO link over which it can provide default forwarding and 239 redirection services for other AERO nodes. 241 edge AERO router ("edge router") 242 a router that configures a non-advertising router interface on an 243 AERO link over which it can connect End User Networks (EUNs) to 244 the AERO link. 246 AERO host 247 a simple host on an AERO link. 249 ingress AERO node ("ingress node") 250 a node that injects packets into an AERO link. 252 egress AERO node ("egress node") 253 a node that receives packets from an AERO link. 255 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 256 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 257 document, are to be interpreted as described in [RFC2119]. 259 3. Motivation 261 AERO was designed to operate as an on-demand route optimization 262 function for nodes attached to a single multi-access link, i.e., 263 similar to the standard ICMPv6 redirect mechanism. However, AERO 264 differs in that the target of the redirection first receives a pre- 265 authorization notification, after which it returns route optimization 266 information to the source of the original packet. This scenario 267 calls into question whether a standard dynamic routing protocol could 268 be used instead of AERO, but a number of considerations indicate that 269 standard routing protocols may be poorly suited for the use cases 270 AERO was designed to address. 272 First, AERO is designed to work on very large multiple access links 273 that may connect a mix of many thousands of routers and hosts. 274 Classical proactive dynamic routing protocols such as OSPF, IS-IS, 275 RIP, OLSR and TBRPF may be inefficient in such environments due to 276 the control message overhead scaling when large numbers of routers 277 are present and/or when link capacity is low. 279 Secondly, AERO is designed to work on-demand of data packet arrival, 280 but only seeks to discover neighbors on the same link and not distant 281 nodes that may be located many link hops away. Reactive dynamic 282 routing protocols such as AODV and DSR also operate on-demand, 283 however they flood specialized route discovery messages that reach 284 all nodes on the link and may further traverse multiple link hops 285 before a route reply is received. This requires a multicast-capable 286 network and does not ensure delivery of the original data packet 287 which may be dropped or delayed during route discovery. 289 Additionally, AERO is designed to override an existing route to a 290 destination if the existing route directs traffic along a sub-optimal 291 path via an extraneous router on the shared link. AERO nodes send 292 data packets over a pre-existing working route, and may subsequently 293 receive notification of a better route based on route optimization 294 feedback from a trusted on-link neighbor. This stands in contrast to 295 on-demand routing protocols that were designed to operate when no 296 pre-existing working routes are present and that multicast explicit 297 route request messages to receive a route reply rather than simply 298 unicast forwarding the data packet via a pre-existing route. 300 Finally, AERO requires less control message and/or processing 301 overhead than standard dynamic routing protocols on links for which 302 the number of routes that must be maintained by each router is far 303 smaller than the total number of routers on the link, and the routes 304 maintained by each router may be changing over time. For example, on 305 a link that connects N nodes it will often be the case that each node 306 will only communicate with a small number link neighbors, and the set 307 of neighbors may change dynamically over time. Therefore, the number 308 of active neighbor pairs on the link is V*N (where V is a small 309 variable number) instead of N**2. This is especially important on 310 very large links, e.g., for values of N such as 1,000 or more. 312 4. Example Use Cases 314 AERO was designed to satisfy numerous operational use cases. As a 315 first example, a hypothetical major airline has deployed an overlay 316 network on top of the global Internet to track the aircraft in its 317 fleet. The global Internet therefore acts as the "link" over which 318 the overlay network is configured. Each aircraft acts as a mobile 319 router that fronts for an internal network that includes various 320 devices controlled and monitored by the airline. However, it would 321 be impractical for each aircraft to track the changing locations of 322 all other aircraft in the fleet due to control message overhead on 323 limited capacity communication links. 325 In this example, an aircraft 'A' en route to its destination needs to 326 report its ETA and communicate passenger itineraries to other en 327 route aircraft that will be servicing passenger connections. 'A' 328 knows the overlay network addresses of the other aircraft, but does 329 not know the current underlay address mappings. 'A' sends its 330 initial messages targeted to the other aircraft via an airline 331 central dispatch router 'D', which may be located in a far away 332 location. 'D' forwards the messages, but also initiates the AERO 333 redirection procedure to step out of the triangular path and allow 334 direct aircraft-to-aircraft communications. 336 In a second example, Mobile Ad-hoc Networks (MANETs) are often 337 deployed in environments with a high degree of mobility, attrition, 338 and very limited wireless communications link bandwidth. Such 339 environments typically also require the use of network layer security 340 mechanisms that view the MANET as a "link" over which encrypted 341 messages are forwarded in an overlay network. In such environments, 342 a dynamic routing protocol running in the overlay network may serve 343 to add unacceptable additional congestion to the already overtaxed 344 wireless links. In that case, the AERO route optimization mechanism 345 can eliminate costly extraneous routing hops without imparting 346 additional control message overhead. 348 In a further example, a large campus LAN that is joined by L2 bridges 349 may connect many thousands of routers and hosts that appear to share 350 a single common multi-access link. In that case, the AERO mechanisms 351 can be applied to satisfy the necessary intra-link route optimization 352 functions without employing an adjunct dynamic routing protocol that 353 may be inefficient for reasons mentioned above. 355 5. Requirements 357 The route optimization mechanism must satisfy the following 358 requirements: 360 Req 1: Off-load traffic from performance-critical gateways 361 The mechanism must offload sustained transit though an 362 intermediate AERO router that would otherwise become a traffic 363 concentrator. 365 Req 2: Support route optimization 366 The ingress AERO node should be able to send packets directly to 367 the egress node without involving an intermediate router for route 368 optimization purposes. 370 Req 3: Support scaling 371 For scaling purposes, support interworking and control message 372 relaying between multiple intermediate routers (see appendix A). 374 Req 4: Do not circumvent ingress filtering 375 The mechanism must not open an attack vector where network-layer 376 source address spoofing is enabled even when link-layer source 377 address spoofing is disabled. 379 Req 5: Do not expose packets to loss due to filtering 380 The ingress AERO node must have a way of knowing that the egress 381 AERO node will accept its forwarded packets. 383 Req 6: Do not expose packets to loss due to path failure 384 The ingress AERO node must have a way of discovering whether the 385 AERO egress node has gone unreachable on the route optimized path. 387 Req 7: Do not introduce routing loops 388 Intermediate routers must not invoke a route optimization that 389 would cause a routing loop to form. 391 Req 8: Support mobility 392 The mechanism must continue to work even if the final destination 393 node/network moves from a first egress node and re-associates with 394 a second egress node. 396 Req 9: Support link layer address changes 397 The mechanism must continue to work even if the Layer 2 addresses 398 of ingress and/or egress AERO nodes change. 400 Req 10: Support network renumbering 401 The mechanism must provide graceful transition when an AERO node's 402 attached EUN is renumbered. 404 6. Asymmetric Extended Route Optimization (AERO) 406 The following sections specify an Asymmetric Extended Route 407 Optimization (AERO) capability that fulfills the requirements 408 specified in Section 5. 410 6.1. AERO Link Dynamic Routing 412 In many AERO link use case scenarios (e.g., small enterprise 413 networks, small and stable MANETs, etc.), routers can engage in a 414 classical dynamic routing protocol so that routing/forwarding tables 415 can be populated and standard forwarding between routers can be used. 416 In other scenarios (e.g., large enterprise/ISP networks, cellular 417 service provider networks, dynamic MANETs, etc.), this might be 418 impractical due to routing protocol control message scaling issues. 420 When a classical dynamic routing protocol cannot be used, the 421 mechanisms specified in this section can provide a useful on-demand 422 route discovery capability. When both classical dynamic routing 423 protocols and the AERO mechanism are active on the same link, routes 424 discovered by the dynamic routing protocol should take precedence 425 over those discovered by AERO. 427 6.2. AERO Node Behavior 429 The following sections discuss characteristics of nodes attached to 430 links over which AERO can be used: 432 6.2.1. AERO Node Types 434 Intermediate AERO routers configure their AERO link interfaces as 435 advertising router interfaces (see: [RFC4861], Section 6.2.2), and 436 therefore may send Router Advertisement (RA) messages that include 437 non-zero Router Lifetimes. 439 Edge AERO routers configure their AERO link interfaces as non- 440 advertising router interfaces. 442 AERO hosts configure their AERO link interfaces as simple host 443 interfaces. 445 6.2.2. AERO Host Behavior 447 AERO hosts observe the IPv6 host requirements defined in [RFC6434], 448 except that AERO hosts also engage in the AERO route optimization 449 procedure as specified in Section 6.4. 451 6.2.3. Edge AERO Router Behavior 453 Edge AERO routers observe the IPv6 router requirements defined in 454 [RFC6434] except that they act as "hosts" on their non-advertising 455 AERO link router interfaces in the same fashion as for IPv6 CPE 456 routers [RFC6204]. Edge routers can then acquire managed prefix 457 delegations aggregated by an intermediate router through the use of, 458 e.g., DHCPv6 Prefix Delegation [RFC3633], administrative 459 configuration, etc. 461 After the edge router acquires prefixes, it can sub-delegate them to 462 nodes and links within its attached EUNs, then can forward any 463 outbound packets coming from its EUNs via the intermediate router. 464 The edge router also engages in the AERO route optimization procedure 465 as specified in Section 6.4. 467 6.2.4. Intermediate AERO Router Behavior 469 Intermediate AERO routers observe the IPv6 router requirements 470 defined in [RFC6434] and respond to RS messages from AERO hosts and 471 edge routers on their advertising AERO link router interfaces by 472 returning an RA message. Intermediate routers further configure a 473 DHCP relay/server function on their AERO links and/or provide an 474 administrative interface for delegation of network-layer addresses 475 and prefixes. 477 When the intermediate router completes a stateful network-layer 478 address or prefix delegation transaction (e.g., as a DHCPv6 relay/ 479 server, etc.), it establishes forwarding table entries that list the 480 link-layer address of the client AERO node as the link-layer address 481 of the next hop toward the delegated network-layer addresses/ 482 prefixes. 484 When the intermediate router forwards a packet out the same AERO 485 interface it arrived on, it initiates an AERO route optimization 486 procedure as specified in Section 6.4. 488 6.3. AERO Reference Operational Scenario 490 Figure 3 depicts the AERO reference operational scenario. The figure 491 shows an intermediate AERO router ('A'), two edge AERO routers ('B', 492 'D'), an AERO host ('F'), and three ordinary IPv6 hosts ('C', 'E', 493 'G'): 495 .-(::::::::) 496 .-(::: IPv6 :::)-. +-------------+ 497 (:::: Internet ::::)--| Host G | 498 `-(::::::::::::)-' +-------------+ 499 `-(::::::)-' 2001:db8:3::1 500 | 501 +--------------+ +--------------+ 502 | Intermediate | | AERO Host F | 503 | AERO Router A| | (default->A) | 504 | (C->B; E->D) | +--------------+ 505 +--------------+ 2001:db8:2:1 506 L3(A) L3(F) 507 L3(A) L2(F) 508 | | 509 X-----+-----------+-----------+-----------+---X 510 | AERO Link | 511 L2(B) L2(D) 512 L3(B) L3(D) 513 +--------------+ +--------------+ .-. 514 | AERO Edge | | AERO Edge | ,-( _)-. 515 | Router B | | Router D | .-(_ IPv6 )-. 516 | (default->A) | | (default->A) |--(__ EUN ) 517 +--------------+ +--------------+ `-(______)-' 518 2001:db8:0::/48 2001:db8:1::/48 | 519 | 2001:db8:1::1 520 .-. +-------------+ 521 ,-( _)-. 2001:db8:0::1 | Host E | 522 .-(_ IPv6 )-. +-------------+ +-------------+ 523 (__ EUN )--| Host C | 524 `-(______)-' +-------------+ 526 Figure 3: AERO Reference Operational Scenario 528 In Figure 3, intermediate AERO router ('A') connects to the AERO link 529 and also connects to the IPv6 Internet, either directly or via other 530 IPv6 routers (not shown). Intermediate router ('A') configures an 531 AERO link interface with a link-local network-layer address L3(A) and 532 with link-layer address L2(A). The intermediate router next arranges 533 to add L2(A) to a published list of valid intermediate routers for 534 the link. 536 AERO node ('B') is an AERO edge router that connects to the AERO link 537 via an interface with link-local network-layer address L3(B) and with 538 link-layer address L2(B). Node ('B') configures a default route with 539 next-hop network-layer address L3(A) via the AERO interface, and also 540 assigns the network-layer prefix 2001:db8:0::/48 to its attached EUN 541 link. IPv6 host ('C') attaches to the EUN, and configures the 542 network-layer address 2001:db8:0::1. 544 AERO node ('D') is an AERO edge router that connects to the AERO link 545 via an interface with link-local network-layer address L3(D) and with 546 link-layer address L2(D). Node ('D') configures a default route with 547 next-hop network-layer address L3(A) via the AERO interface, and also 548 assigns the network-layer prefix 2001:db8:1::/48 to its attached EUN 549 link. IPv6 host ('E') attaches to the EUN, and configures the 550 network-layer address 2001:db8:1::1. 552 AERO host ('F') connects to the AERO link via an interface with link- 553 local network-layer address L3(F) and with link-layer address L2(F). 554 Host ('F') configures a default route with next-hop network-layer 555 address L3(A) via the AERO interface, and also assigns the network- 556 layer address 2001:db8:2::1 to the AERO interface. 558 Finally, IPv6 host ('G') connects to an IPv6 network outside of the 559 AERO link domain. Host ('G') configures its IPv6 interface in a 560 manner specific to its attached IPv6 link, and assigns the network- 561 layer address 2001:db8:3::1 to its IPv6 link interface. 563 In these arrangements, intermediate router ('A') must maintain state 564 that associates the delegated network-layer addresses/prefixes with 565 the link-local network-layer addresses of the correct edge routers 566 and/or hosts on the AERO link. The nodes must in turn maintain at 567 least a default route that points to intermediate router ('A'), and 568 can discover more-specific routes either via a proactive dynamic 569 routing protocol or via the AERO mechanisms specified in Section 6.4. 571 6.4. AERO Specification 573 Section 6.3 describes the AERO reference operational scenario. We 574 now discuss the operation and protocol details of AERO with respect 575 to this reference scenario. 577 6.4.1. Classical Redirection Approaches 579 With reference to Figure 3, when IPv6 source host ('C') sends a 580 packet to an IPv6 destination host ('E'), the packet is first 581 forwarded via the EUN to ingress AERO node ('B'). The ingress node 582 ('B') then forwards the packet over its AERO interface to 583 intermediate router ('A'), which then forwards the packet to egress 584 AERO node ('D'), where the packet is finally forwarded to the IPv6 585 destination host ('E'). When intermediate router ('A') forwards the 586 packet back out on its advertising AERO interface, it must arrange to 587 redirect ingress node ('B') toward egress node ('D') as a better next 588 hop node on the AERO link that is closer to the final destination. 589 However, this redirection process should only occur if there is 590 assurance that both the ingress and egress nodes are willing 591 participants. 593 Consider a first alternative in which intermediate router ('A') 594 informs ingress node ('B') only and does not inform egress node ('D') 595 (i.e., "classic redirection"). In that case, the egress node has no 596 way of knowing that the ingress is authorized to forward packets from 597 their claimed source network-layer addresses, and may simply elect to 598 drop the packets. Also, the ingress node has no way of knowing 599 whether the egress is performing some form of source address 600 filtering that would reject packets arriving from a node other than a 601 trusted default router, nor whether the egress is even reachable via 602 a direct path that does not involve the intermediate router. 603 Finally, the ingress node has no way of knowing whether the final 604 destination has moved away from egress node. 606 Consider also a second alternative in which intermediate router ('A') 607 informs both ingress node ('B') and egress node ('D') separately via 608 independent redirection messages (i.e., "augmented redirection"). In 609 that case, several conditions can occur that could result in 610 communication failures. First, if the ingress receives the 611 redirection message but the egress does not, subsequent packets sent 612 by the ingress could be dropped due to filtering since the egress 613 would not have neighbor state to verify their source network-layer 614 addresses. Second, if the egress receives the redirection message 615 but the ingress does not, subsequent packets sent in the reverse 616 direction by the egress would be lost. Finally, timing issues 617 surrounding the establishment and garbage collection of neighbor 618 state at the ingress and egress nodes could yield unpredictable 619 behavior. For example, unless the timing were carefully coordinated 620 through some form of synchronization loop, there would invariably be 621 instances in which one node has the correct neighbor state and the 622 other node does not resulting in non-deterministic packet loss. 624 Since neither of these alternatives can satisfy the requirements 625 listed in Section 5, a new redirection technique (i.e., "AERO 626 redirection") is needed. 628 6.4.2. AERO Concept of Operations 630 AERO redirection is used on links for which the classical redirection 631 approaches described in Section 6.4.1 are insufficient to satisfy all 632 requirements. We now discuss the concept of operations for this new 633 approach. 635 Again with reference to Figure 3, when source host ('C') sends a 636 packet to destination host ('E'), the packet is first forwarded over 637 the source host's attached EUN to ingress node ('B'), which then 638 forwards the packet via its AERO interface to intermediate router 639 ('A'). 641 Using AERO redirection, intermediate router ('A') then forwards the 642 packet out the same AERO interface toward egress node ('D') and also 643 sends a "Predirect" message forward to the egress node as specified 644 in Section 6.4.6. The Predirect message includes the identity of 645 ingress node ('B') as well as information that egress node ('D') can 646 use to determine the longest-match prefixes that cover the source and 647 destination network-layer addresses of the packet that triggered the 648 Predirect. After egress node ('D') receives the Predirect, it 649 process the message and returns a Redirect message to the 650 intermediate router ('A') as specified in Section 6.4.7. (During the 651 process, it also creates or updates neighbor state for ingress node 652 ('B'), and retains this (src, dst) "prefix pair" as ingress filtering 653 information to accept future packets using addresses matched by the 654 prefixes from ingress node ('B').) 656 When the intermediate router ('A') receives the Redirect message, it 657 acts as a "proxy" to relay the message to ingress node ('B') as 658 specified in Section 6.4.8. The Redirect message includes the 659 identity of egress node ('D') as well as information that ingress 660 node ('B') can use to determine the longest-match prefixes that cover 661 the source and destination network-layer addresses of the packet that 662 triggered the Redirect. After ingress node ('B') receives the 663 Redirect, it processes the message as specified in Section 6.4.9. 664 (During the process, it also creates or updates neighbor state for 665 egress node ('D'), and retains this prefix pair as forwarding 666 information to forward future packets using addresses matched by the 667 prefixes to the egress node ('D').) 669 Following the above Predirect/Redirect message exchange, forwarding 670 of packets with source and destination network-layer addresses 671 covered by the longest-match prefix pair is enabled in the forward 672 direction from ingress node ('B') to egress node ('D'). The 673 mechanisms that enable this exchange are specified in the following 674 sections. 676 6.4.3. Conceptual Data Structures and Protocol Constants 678 Each AERO node maintains a per AERO interface conceptual neighbor 679 cache that includes an entry for each neighbor it communicates with 680 on the AERO link the same as for any IPv6 interface (see: [RFC4861]). 682 Each AERO interface neighbor cache entry further maintains two lists 683 of (src, dst) prefix pairs. The AERO node adds a prefix pair to the 684 ACCEPT list if it has been informed by a trusted intermediate router 685 that it is safe to accept packets from the neighbor using network- 686 layer source and destination addresses covered by the prefix pair. 687 The AERO node adds a prefix pair to the FORWARD list if it has been 688 informed by a trusted intermediate router that it is permitted to 689 forward packets to the neighbor using network-layer addresses covered 690 by the prefix pair. 692 When the node adds a prefix pair to a neighbor cache entry ACCEPT 693 list, it also sets an expiration timer for the prefix pair to 694 ACCEPT_TIME seconds. When the node adds a prefix pair to a neighbor 695 cache entry FORWARD list, it also sets an expiration timer for the 696 prefix pair to FORWARD_TIME seconds. The node further maintains a 697 keepalive interval KEEPALIVE_TIME used to limit the number of 698 keepalive control messages. Finally, the node maintains a constant 699 value MAX_RETRY to limit the number of keepalives sent when a 700 neighbor has gone unreachable. 702 It is RECOMMENDED that FORWARD_TIME be set to the default constant 703 value 30 seconds to match the default REACHABLE_TIME value specified 704 for IPv6 neighbor discovery [RFC4861]. 706 It is RECOMMENDED that ACCEPT_TIME be set to the default constant 707 value 40 seconds to allow a 10 second window so that the AERO 708 redirection procedure can converge before the ACCEPT_TIME timer 709 decrements below FORWARD_TIME. 711 It is RECOMMENDED that KEEPALIVE_TIME be set to the default constant 712 value 5 seconds to providing timely reachability verification without 713 causing excessive control message overhead. 715 It is RECOMMENDED that MAX_RETRY be set to 3 the same as described 716 for IPv6 neighbor discovery address resolution in Section 7.3.3 of 717 [RFC4861]. 719 Different values for FORWARD_TIME, ACCEPT_TIME, KEEPALIVE_TIME and 720 MAX_RETRY MAY be administratively set if necessary to better match 721 the AERO link's performance characteristics; however, if different 722 values are chosen all nodes on the link MUST consistently configure 723 the same values. ACCEPT_TIME SHOULD further be set to a value that 724 is sufficiently longer than FORWARD time to allow the AERO 725 redirection procedure to converge. 727 6.4.4. Data Origin Authentication 729 AERO nodes MUST employ a data origin authentication check for the 730 packets they receive on an AERO interface. In particular, the node 731 considers the network-layer source address correct for the link-layer 732 source address if at least one of the following is true: 734 o the network-layer source address is an on-link address that embeds 735 the link-layer source address, or 737 o the network-layer source address is explicitly linked to the link- 738 layer source address through per-neighbor state, or 740 o the link-layer source address is the address of a trusted 741 intermediate AERO router, or 743 o the packet includes a digital signature that the node can use to 744 authenticate the origin. 746 When the AERO node receives a packet on an AERO interface, it 747 processed the packet further if it satisfies one of these data origin 748 authentication conditions; otherwise it drops the packet. 750 Note that on links in which link-layer address spoofing is possible, 751 AERO nodes may be obliged to require the use of digital signatures 752 applied through means outside the scope of this document. In that 753 case, only the fourth of the above conditions can be accepted in 754 order to ensure adequate data origin authentication. 756 6.4.5. AERO Redirection Message Format 758 AERO redirection messages use the same format as for ICMPv6 Redirect 759 messages depicted in Section 4.5 of [RFC4861], however the messages 760 are encapsulated in a UDP header [RFC0768] to distinguish them from 761 ordinary ICMPv6 Redirect messages. AERO Redirect messages therefore 762 require a new UDP service port number 'AERO_PORT'. 764 The AERO redirection message is formatted as shown in Figure 4: 766 0 1 2 3 767 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 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Type (=0) | Code (=0) | Checksum (=0) | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 |P| Reserved | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 + + 775 | | 776 + Target Address + 777 | | 778 + + 779 | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 + + 783 | | 784 + Destination Address + 785 | | 786 + + 787 | | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Options ... 790 +-+-+-+-+-+-+-+-+-+-+-+- 792 Figure 4: AERO Redirection Message Format 794 The AERO redirection message sender sets the 'Type' field to 0 (since 795 this is not an actual ICMPv6 message), and also sets the 'Checksum' 796 field to 0 (since the UDP checksum will provide protection for the 797 entire packet). The sender further sets the 'P' bit to 1 if this is 798 a 'Predirect' message and sets the 'P' bit to 0 if this is a 799 'Redirect' message (as described below). 801 The sender then encapsulates the AERO Redirect message in IP/UDP 802 headers as shown in Figure 5: 804 +--------------------+ 805 ~ IP header ~ 806 +--------------------+ 807 ~ UDP header ~ 808 +--------------------+ 809 | | 810 ~ AERO Redirect ~ 811 ~ Message ~ 812 | | 813 +--------------------+ 815 Figure 5: AERO Message UDP Encapsulation Format 817 The AERO redirection message sender sets the UDP destination port 818 number to 'AERO_PORT" and sets the UDP source port number to a 819 (pseudo-)random value. The sender next sets the UDP length field to 820 the length of the UDP message, then calculates the checksum across 821 the message and writes the value into the UDP checksum field. Next, 822 the sender sets the IP TTL/Hop-limit field to a small integer value 823 chosen to provide a quick exit from any temporal routing loops. It 824 is RECOMMENDED that the sender set IP TTL/Hop-limit to the value 8 825 unless it has better knowledge of the AERO link characteristics. 827 6.4.6. Sending Predirects 829 When an intermediate AERO router forwards a packet out the same AERO 830 interface that it arrived on, the router sends an AERO Predirect 831 message forward toward the egress AERO node instead of sending an 832 ICMPv6 Redirect message back to the ingress AERO node. 834 In the reference operational scenario, when the intermediate router 835 ('A') forwards a packet sent by the ingress node ('B') toward the 836 egress node ('D'), it also sends an AERO Predirect message forward 837 toward the egress, subject to rate limiting (see Section 8.2 of 838 [RFC4861]). The intermediate router ('A') prepares the AERO 839 Predirect message as follows: 841 o the link-layer source address is set to 'L2(A)' (i.e., the link- 842 layer address of the intermediate router). 844 o the link-layer destination address is set to 'L2(D)' (i.e., the 845 link-layer address of the egress node). 847 o the network-layer source address is set to 'L3(A)' (i.e., the 848 link-local network-layer address of the intermediate router). 850 o the network-layer destination address is set to 'L3(D)'. (i.e., 851 the link-local network-layer address of the egress node). 853 o the UDP destination port is set to 'AERO_PORT'. 855 o the Target and Destination Addresses are both set to 'L3(B)' 856 (i.e., the link-local network-layer address of the ingress node). 858 o on links that require stateful address mapping, the message 859 includes a Target Link Layer Address Option (TLLAO) set to 'L2(B)' 860 (i.e., the link-layer address of the ingress node). 862 o the message includes a Route Information Option (RIO) [RFC4191] 863 that encodes the ingress node's network-layer address/prefix 864 delegation that covers the network-layer source address of the 865 originating packet. 867 o the message includes a Redirected Header Option (RHO) that 868 contains the originating packet truncated to ensure that at least 869 the network-layer header is included but the size of the message 870 does not exceed 1280 bytes. 872 o the 'P' bit is set to P=1. 874 The intermediate router ('A') then sends the message forward to the 875 egress node ('D'). 877 6.4.7. Processing Predirects and Sending Redirects 879 When the egress node ('D') receives an AERO Predirect message, it 880 accepts the message only if it satisfies the data origin 881 authentication requirements specified in Section 6.4.4. Next, the 882 egress node ('D') validates the message according to the ICMPv6 883 Redirect message validation rules in Section 8.1 of [RFC4861] with 884 the exception that the message includes a Type value of 0, a Checksum 885 value of 0 and a link-local address in the ICMP destination field 886 that differs from the destination address of the packet header 887 encapsulated in the RHO. 889 In the reference operational scenario, when the egress node ('D') 890 receives a valid AERO Predirect message it either creates or updates 891 a neighbor cache entry that stores the Target address of the message 892 (i.e., the link-local network-layer address of the ingress node 893 ('B')). The egress node ('D') then records the prefix found in the 894 RIO along with its own prefix that matches the network-layer 895 destination address in the packet header found in the RHO with the 896 neighbor cache entry as an acceptable (src, dst) prefix pair. The 897 egress node ('D') then adds the prefix pair to the neighbor cache 898 entry ACCEPT list, and sets/resets an expiration timer for the prefix 899 pair to ACCEPT_TIME seconds. If the timer later expires, the egress 900 node ('D') deletes the prefix pair. 902 After processing the message, the egress node ('D') prepares an AERO 903 Redirect message response as follows: 905 o the link-layer source address is set to 'L2(D)' (i.e., the link- 906 layer address of the egress node). 908 o the link-layer destination address is set to 'L2(A)' (i.e., the 909 link-layer address of the intermediate router). 911 o the network-layer source address is set to 'L3(D)' (i.e., the 912 link-local network-layer address of the egress node). 914 o the network-layer destination address is set to 'L3(B)' (i.e., the 915 link-local network-layer address of the ingress node). 917 o the UDP destination port is set to 'AERO_PORT'. 919 o the Target and the Destination Addresses are both set to 'L3(D)' 920 (i.e., the link-local network-layer address of the egress node). 922 o on links that require stateful address mapping, the message 923 includes a Target Link Layer Address Option (TLLAO) set to 924 'L2(D)'. 926 o the message includes an RIO that encodes the egress node's 927 network-layer address/prefix delegation that covers the network- 928 layer destination address of the originating packet. 930 o the message includes as much of the RHO copied from the 931 corresponding AERO Predirect message as possible such that at 932 least the network-layer header is included but the size of the 933 message does not exceed 1280 bytes. 935 o the 'P' bit is set to P=0. 937 After the egress node ('D') prepares the AERO Redirect message, it 938 sends the message to the intermediate router ('A'). 940 6.4.8. Relaying Redirects 942 When the intermediate router ('A') receives an AERO Redirect message, 943 it accepts the message only if it satisfies the data origin 944 authentication requirements specified in Section 6.4.4. Next, the 945 intermediate router ('A') validates the message the same as described 946 in Section 6.4.7. Following validation, the intermediate router 947 ('A') then "relays" the message back to the ingress node ('B') as 948 follows. 950 In the reference operational scenario, the intermediate router ('A') 951 receives the AERO Redirect message from the egress node ('D') and 952 prepares to relay the message to the ingress node ('B'). The 953 intermediate router ('A') then verifies that the RIO encodes a 954 network-layer address/prefix that the egress node ('D') is authorized 955 to use, and discards the message if verification fails. Otherwise, 956 the intermediate router ('A') changes the link-layer source address 957 of the message to 'L2(A)', changes the network-layer source address 958 of the message to the link-local network-layer address 'L3(A)', and 959 changes the link-layer destination address to 'L2(B)' . The 960 intermediate router ('A') finally decrements the IP TTL/Hop-limit and 961 relays the message to the ingress node ('B'). 963 6.4.9. Processing Redirects 965 When the ingress node ('B') receives an AERO Redirect message (i.e., 966 one with P=0), it accepts the message only if it satisfies the data 967 origin authentication requirements specified in Section 6.4.4. Next, 968 the ingress node ('B') validates the message the same as described in 969 Section 6.4.6. Following validation, the ingress node ('B') then 970 processes the message as follows. 972 In the reference operational scenario, when the ingress node ('B') 973 receives the (relayed) AERO Redirect message it either creates or 974 updates a neighbor cache entry that stores the Target address of the 975 message (i.e., the link-local network-layer address of the egress 976 node 'L3(D)'). The ingress node ('B') then records the (src, dst) 977 prefix pair associated with the triggering packet in the neighbor 978 cache entry FORWARD list, i.e., it records its prefix that matches 979 the redirected packet's network-layer source address and the prefix 980 listed in the RIO as the prefix pair. The ingress node ('B') then 981 sets/resets an expiration timer for the prefix pair to FORWARD_TIME 982 seconds. If the timer later expires, the ingress node ('B') deletes 983 the entry. 985 Now, the ingress node ('B') has a neighbor cache FORWARD list entry 986 for the prefix pair, and the egress node ('D') has a neighbor cache 987 ACCEPT list entry for the prefix pair. Therefore, the ingress node 988 ('B') may forward ordinary network-layer data packets with network- 989 layer source and destination addresses that match the prefix pair 990 directly to the egress node ('D') without involving the intermediate 991 router ('A'). Note that the ingress node must have a way of 992 informing the network layer of a route that associates the 993 destination prefix with this neighbor cache entry. The manner of 994 establishing such a route (and deleting it when it is no longer 995 necessary) is left to the implementation. 997 To enable packet forwarding in the reverse direction, a separate AERO 998 redirection operation is required which is the mirror-image of the 999 forward operation described above but the link segments traversed in 1000 the forward and reverse directions may be different, i.e., the 1001 operations are asymmetric. 1003 6.4.10. Sending Periodic Predirect Keepalives 1005 In order to prevent prefix pairs from expiring while data packets are 1006 actively flowing, the ingress node ('B') can send AERO Predirect 1007 keepalive messages directly to the egress node ('D') to solicit AERO 1008 Redirect messages. The node should send a keepalive message only 1009 when a data packet covered by the prefix pair has been sent recently, 1010 and should wait for at least KEEPALIVE_TIME seconds before sending 1011 each successive keepalive message in order to limit control message 1012 overhead. 1014 In the reference operational scenario, when the ingress node ('B') 1015 needs to refresh the FORWARD timer for a specific prefix pair it can 1016 send an AERO Predirect keepalive message directly to the egress node 1017 ('D') prepared as follows: 1019 o the link-layer source address is set to 'L2(B)' (i.e., the link- 1020 layer address of the ingress node). 1022 o the link-layer destination address is set to 'L2(D)' (i.e., the 1023 link-layer address of the egress node). 1025 o the network-layer source address is set to 'L3(B)' (i.e., the 1026 link-local network-layer address of the ingress node). 1028 o the network-layer destination address is set to 'L3(D)' (i.e., the 1029 link-local network-layer address of the egress node). 1031 o the UDP destination port is set to 'AERO_PORT'. 1033 o the Predirect Target and Destination Addresses are both set to 1034 'L3(B)' (i.e., the link-local network-layer address of the ingress 1035 node). 1037 o the Predirect message includes an RHO that contains the 1038 originating packet truncated to ensure that at least the network- 1039 layer header is included but the size of the message does not 1040 exceed 1280 bytes. 1042 o the 'P' bit is set to P=1. 1044 When the egress node ('D') receives the AERO Predirect message, it 1045 validates the message the same as described in Section 6.4.6. 1047 Following validation, the egress node ('D') then resets its ACCEPT 1048 timer for the prefix pair that matches the originating packet's 1049 network-layer source and destination addresses to ACCEPT_TIME 1050 seconds, and sends an AERO Redirect message directly to the ingress 1051 node ('B') prepared as follows: 1053 o the link-layer source address is set to 'L2(D)' (i.e., the link- 1054 layer address of the egress node). 1056 o the link-layer destination address is set to 'L2(B)' (i.e., the 1057 link-layer address of the ingress node). 1059 o the network-layer source address is set to 'L3(D)' (i.e., the 1060 link-local network-layer address of the egress node). 1062 o the network-layer destination address is set to 'L3(B)' (i.e., the 1063 link-local network-layer address of the ingress node). 1065 o the UDP destination port is set to 'AERO_PORT'. 1067 o the Redirect Target and Destination Addresses are both set to 1068 'L3(D)' (i.e., the link-local network-layer address of the egress 1069 node). 1071 o the message includes as much of the RHO copied from the 1072 corresponding AERO Predirect message as possible such that at 1073 least the network-layer header is included but the size of the 1074 message does not exceed 1280 bytes. 1076 o the 'P' bit is set to P=0. 1078 When the ingress node ('B') receives the AERO Redirect message, it 1079 validates the message the same as described in Section 6.4.6. 1080 Following validation, the ingress node ('B') then resets its FORWARD 1081 timer for the prefix pair that matches the originating packet's 1082 network-layer source and destination addresses to FORWARD_TIME 1083 seconds. 1085 In this process, if the ingress node sends MAX_RETRY Predirect 1086 keepalive messages without receiving a Redirect reply it can either 1087 declare the prefix pair unreachable immediately or allow the pair to 1088 expire after FORWARD_TIME seconds. 1090 6.4.11. Neighbor Reachability Considerations 1092 When the ingress node ('B') receives an AERO Redirect message 1093 informing it of a direct path to a new egress node ('D'), there is a 1094 question in point as to whether the new egress node ('D') can be 1095 reached directly without involving an intermediate router ('A'). On 1096 some AERO links, it may be reasonable for the ingress node ('B') to 1097 (optimistically) assume that reachability is transitive, and to 1098 immediately begin forwarding data packets to the egress node ('D') 1099 without testing reachability. 1101 On AERO links in which an optimistic assumption of transitive 1102 reachability may be unreasonable, however, the ingress node ('B') can 1103 defer the redirection until it tests the direct path to the egress 1104 node ('D'), e.g., by sending an IPv6 Neighbor Solicitation to elicit 1105 an IPv6 Neighbor Advertisement response. If the ingress node ('B') 1106 is unable to elicit a response after MAX_RETRY attempts, it should 1107 consider the direct path to the egress node ('D') as unusable. 1109 In either case, the ingress node ('B') can process any link errors 1110 corresponding to the data packets sent directly to the egress node 1111 ('D') as a hint that the direct path has either failed or has become 1112 intermittent. Conversely, the ingress node ('B') can further process 1113 any Redirect messages received as evidence of neighbor reachability. 1115 6.4.12. Mobility Considerations 1117 Again with reference to Figure 3, egress node ('D') can configure 1118 both a non-advertising router interface on a provider AERO link and 1119 advertising router interfaces on its connected EUN links. When an 1120 EUN node ('E') in one of the egress node's connected EUNs moves to a 1121 different network point of attachment, however, it can release its 1122 network-layer address/prefix delegations that were registered with 1123 egress node ('D' ) and re-establish them via a different router. 1125 When the EUN node ('E') releases its network-layer address/prefix 1126 delegations, the egress node ('D') marks its forwarding table entries 1127 corresponding to the network-layer addresses/prefixes as "departed" 1128 and no longer responds to AERO Predirect keepalive messages for the 1129 departed addresses/prefixes. When egress node ('D') receives packets 1130 from an ingress node ('B') with network-layer source and destination 1131 addresses that match a prefix pair on the ACCEPT list, it forwards 1132 them to the last-known link-layer address of EUN node ('E') as a 1133 means for avoiding mobility-related packet loss during routing 1134 changes. Egress node ('D') also returns a NULL AERO Redirect message 1135 to inform the ingress node ('B') of the departure. The message is 1136 prepared as follows: 1138 o the link-layer source address is set to 'L2(D)'. 1140 o the link-layer destination address is set to 'L2(B)'. 1142 o the network-layer source address is set to the link-local address 1143 'L3(D)'. 1145 o the network-layer destination address is set to the link-local 1146 address 'L3(B)'. 1148 o the UDP destination port is set to 'AERO_PORT'. 1150 o the Redirect Target and Destination Addresses are both set to 1151 NULL. 1153 o the message includes an RHO that contains as much of the original 1154 packet as possible such that at least the network-layer header is 1155 included but the size of the message does not exceed 1280 bytes. 1157 o the 'P' bit is set to P=0. 1159 When ingress node ('B') receives the NULL AERO Redirect message, it 1160 deletes the prefix pair associated with the packet in the RHO from 1161 its list of forwarding entries corresponding to egress node ('D'). 1162 When egress node ('D')s ACCEPT_TIME timer for the prefix pair 1163 corresponding to the departed prefix expires, it deletes the prefix 1164 pairs from its list of ingress filtering entries corresponding to 1165 ingress node ('B'). 1167 Eventually, any such correspondent AERO nodes will receive a NULL 1168 AERO Redirect message and will cease to use the egress node ('D') as 1169 a next hop. They will then revert to sending packets destined to the 1170 EUN node ('E') via a trusted intermediate router and may subsequently 1171 receive new AERO Redirect messages to discover that the EUN node ('E' 1172 ) is now associated with a new AERO edge router. 1174 Note that any packets forwarded by the egress node ('D') via a 1175 departed forwarding table entry may be lost if the (mobile) EUN node 1176 ('E') moves off-link with respect to its previous EUN point of 1177 attachment. This should not be a problem for large links (e.g., 1178 large cellular network deployments, large ISP networks, etc.) in 1179 which all/most mobility events are intra-link. 1181 6.4.13. Link-Layer Address Change Considerations 1183 When an ingress node needs to change its link-layer address, it 1184 deletes each FORWARD list entry that was established under the old 1185 link layer address, changes the link layer address, then allows 1186 packets to again flow through an intermediate router. Any egress 1187 node that receives the packets will also receive new Predirect 1188 messages from the intermediate router. The egress node then deletes 1189 the ACCEPT entry that included the ingress node's old link-layer 1190 address and installs a new ACCEPT entry that includes the ingress 1191 node's new link-layer address. The egress then returns a new 1192 Redirect message to the ingress node via the intermediate router, 1193 which the ingress node uses to establish a new FORWARD list entry. 1195 When an egress node needs to change its link-layer address, it 1196 deletes each entry in the ACCEPT list and SHOULD also send NULL AERO 1197 Redirect messages to the corresponding ingress node (i.e., the same 1198 as described for mobility operations in Section 6.4.12) before 1199 changing the link-layer address. Any ingress node that receives the 1200 NULL Redirect messages will delete any corresponding FORWARD list 1201 entries and again allow packets to flow through an intermediate 1202 router. The egress then changes the link-layer address, and sends 1203 new Redirect messages in response to any Predirect messages it 1204 receives from the intermediate router while using the new link-layer 1205 address. 1207 6.4.14. Prefix Re-Provisioning Considerations 1209 When an AERO node configures one or more FORWARD/ACCEPT list prefix 1210 pair entries, and the prefixes associated with the pair are somehow 1211 re-configured or renumbered, the stale FORWARD/ACCEPT list 1212 information must be deleted. 1214 When an ingress node ('B') re-configures it's network-layer source 1215 prefix in such a way that the ACCEPT list entry in the egress node 1216 ('D') would no longer be valid (e.g., the prefix length of the source 1217 prefix changes), the ingress node ('B') simply deletes the prefix 1218 pair form its FORWARD list and allows subsequent packets to again 1219 flow through an intermediate router ('A'). 1221 When the egress node ('D') re-configures it's network-layer 1222 destination prefix in such a way that the FORWARD list entry in the 1223 ingress node ('B') would no longer be valid, the egress node ('D') 1224 sends a NULL AERO Redirect message to the ingress node ('B') the same 1225 as described for mobility and link-layer address change 1226 considerations when it receives either an AERO Predirect message or a 1227 data packet (subject to rate limiting) from the ingress node ('B') . 1229 6.4.15. Backward Compatibility 1231 There are no backward compatibility considerations since AERO 1232 redirection messages use a new UDP port number that distinguishes 1233 them from other kinds of control messages. Therefore, legacy nodes 1234 will simply discard ant AERO redirection messages they may 1235 accidentally receive. 1237 Note however that AERO redirection requires that all three of the 1238 ingress, intermediate router and egress participate in the protocol. 1239 Additionally, the intermediate router SHOULD disable ordinary ICMPv6 1240 Redirects when AERO redirection is enabled. 1242 7. IANA Considerations 1244 IANA have been requested to allocate a UDP user port for this 1245 protocol via the expert review process [RFC5226]. This request is 1246 currently pending. 1248 8. Security Considerations 1250 AERO link security considerations are the same as for standard IPv6 1251 Neighbor Discovery [RFC4861] except that AERO improves on some 1252 aspects. In particular, AERO is dependent on a trust basis between 1253 AERO edge nodes and intermediate routers, where the edge nodes must 1254 only engage in the AERO mechanism when it is facilitated by a trusted 1255 intermediate router. 1257 AERO links must be protected against link-layer address spoofing 1258 attacks in which an attacker on the link pretends to be a trusted 1259 neighbor. Links that provide link-layer securing mechanisms (e.g., 1260 WiFi networks) and links that provide physical security (e.g., 1261 enterprise network LANs) provide a first-line of defense that is 1262 often sufficient. In other instances, sufficient assurances against 1263 link-layer address spoofing attacks are possible if the source can 1264 digitally sign its messages through means outside the scope of this 1265 document. 1267 9. Acknowledgements 1269 Discussions both on the v6ops list and in private exchanges helped 1270 shape some of the concepts in this work. Individuals who contributed 1271 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1272 Brian Carpenter, Brian Haberman, Joel Halpern, and Lee Howard. 1273 Members of the IESG also provided valuable input during their review 1274 process that greatly improved the document. 1276 10. References 1278 10.1. Normative References 1280 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1281 August 1980. 1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1284 Requirement Levels", BCP 14, RFC 2119, March 1997. 1286 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1287 (IPv6) Specification", RFC 2460, December 1998. 1289 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1290 More-Specific Routes", RFC 4191, November 2005. 1292 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1293 Message Protocol (ICMPv6) for the Internet Protocol 1294 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1296 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1297 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1298 September 2007. 1300 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1301 Address Autoconfiguration", RFC 4862, September 2007. 1303 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1304 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1305 May 2008. 1307 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1308 Requirements", RFC 6434, December 2011. 1310 10.2. Informative References 1312 [I-D.templin-intarea-vet] 1313 Templin, F., "Virtual Enterprise Traversal (VET)", 1314 draft-templin-intarea-vet-33 (work in progress), 1315 December 2011. 1317 [I-D.templin-ironbis] 1318 Templin, F., "The Internet Routing Overlay Network 1319 (IRON)", draft-templin-ironbis-10 (work in progress), 1320 December 2011. 1322 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1323 September 1981. 1325 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1326 RFC 792, September 1981. 1328 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1329 RFC 2131, March 1997. 1331 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1332 Domains without Explicit Tunnels", RFC 2529, March 1999. 1334 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1335 and M. Carney, "Dynamic Host Configuration Protocol for 1336 IPv6 (DHCPv6)", RFC 3315, July 2003. 1338 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1339 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1340 December 2003. 1342 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1343 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1344 March 2008. 1346 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1347 Infrastructures (6rd)", RFC 5569, January 2010. 1349 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1350 Troan, "Basic Requirements for IPv6 Customer Edge 1351 Routers", RFC 6204, April 2011. 1353 Appendix A. Intermediate Router Interworking 1355 Figure 3 depicts a reference AERO operational scenario with a single 1356 intermediate router on the AERO link. In order to support scaling to 1357 larger numbers of nodes, the AERO link can deploy multiple 1358 intermediate routers, e.g., as shown in Figure 6 1359 +--------------+ +--------------+ 1360 | Intermediate | +--------------+ | Intermediate | 1361 | Router C | | Core Router D| | Router E | 1362 | (default->D) | | (A->C; G->E) | | (default->D) | 1363 | (A->B) | +--------------+ | (G->F) | 1364 +-------+------+ +------+-------+ 1365 | | 1366 X---+---+--------------------------------------+---+---X 1367 | AERO Link | 1368 +-----+--------+ +--------+-----+ 1369 | Edge Router B| | Edge Router F| 1370 | (default->C) | | (default->E) | 1371 +--------------+ +--------------+ 1372 .-. .-. 1373 ,-( _)-. ,-( _)-. 1374 .-(_ IPv6 )-. .-(_ IPv6 )-. 1375 (__ EUN ) (__ EUN ) 1376 `-(______)-' `-(______)-' 1377 | | 1378 +--------+ +--------+ 1379 | Host A | | Host G | 1380 +--------+ +--------+ 1382 Figure 6: Multiple Intermediate Routers 1384 In this example, the ingress AERO node ('B') (in this case an edge 1385 router, but could also be a host) associates with intermediate AERO 1386 router ('C'), while the egress AERO node ('F') (in this case an edge 1387 router, but could also be a host) associates with intermediate AERO 1388 router ('E'). Furthermore, intermediate routers ('C') and ('E') do 1389 not associate with each other directly, but rather have an 1390 association with a "core" router ('D') (i.e., a router that has full 1391 topology information concerning its associated intermediate routers). 1392 Core router 'D' may connect to either the AERO link, or to other 1393 physical or virtual links (not shown) to which intermediate routers 1394 'C' and 'E' also connect. 1396 When host ('A') sends a packet toward destination host ('G'), IPv6 1397 forwarding directs the packet through the EUN to edge router ('B') 1398 which forwards the packet to intermediate router ('C') in absence of 1399 more-specific forwarding information. Intermediate router ('C') 1400 forwards the packet, and also generates an AERO Predirect message 1401 that is then relayed through core router ('D') to intermediate router 1402 ('E'). When intermediate router ('E') receives the Predirect, it 1403 relays the message to egress router ('F'). 1405 After processing the AERO Predirect message, egress router ('F') 1406 sends an AERO Redirect message to intermediate router ('E'). 1408 Intermediate router ('E') in turn relays the message through core 1409 router ('D') to intermediate router ('C'). When intermediate router 1410 ('C') receives the Redirect, it relays the message to ingress edge 1411 router ('B') informing it that host 'G's EUN can be reached via 1412 egress router 'F', thus completing the AERO redirection. 1414 The interworkings between intermediate and core routers (including 1415 the conveyance of pseudo Predirects and Redirects) must be carefully 1416 coordinated in a manner outside the scope of this document. In 1417 particular, the intermediate and core routers must ensure that any 1418 routing loops that may be formed are temporal in nature. See 1419 [I-D.templin-ironbis] for an architectural discussion of 1420 coordinations between intermediate and core routers. 1422 Author's Address 1424 Fred L. Templin (editor) 1425 Boeing Research & Technology 1426 P.O. Box 3707 MC 7L-49 1427 Seattle, WA 98124 1428 USA 1430 Email: fltemplin@acm.org