idnits 2.17.1 draft-templin-aero-10.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 (March 6, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == 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) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Experimental March 6, 2012 5 Expires: September 7, 2012 7 Asymmetric Extended Route Optimization (AERO) 8 draft-templin-aero-10.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 September 7, 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 8 67 4.1. AERO Link Dynamic Routing . . . . . . . . . . . . . . . . 8 68 4.2. AERO Node Behavior . . . . . . . . . . . . . . . . . . . . 8 69 4.2.1. AERO Node Types . . . . . . . . . . . . . . . . . . . 8 70 4.2.2. AERO Host Behavior . . . . . . . . . . . . . . . . . . 8 71 4.2.3. Edge AERO Router Behavior . . . . . . . . . . . . . . 9 72 4.2.4. Intermediate AERO Router Behavior . . . . . . . . . . 9 73 4.3. AERO Reference Operational Scenario . . . . . . . . . . . 10 74 4.4. AERO Specification . . . . . . . . . . . . . . . . . . . . 12 75 4.4.1. Classical Redirection Approaches . . . . . . . . . . . 12 76 4.4.2. AERO Concept of Operations . . . . . . . . . . . . . . 13 77 4.4.3. Conceptual Data Structures and Protocol Constants . . 14 78 4.4.4. Data Origin Authentication . . . . . . . . . . . . . . 14 79 4.4.5. AERO Redirection Message Format . . . . . . . . . . . 15 80 4.4.6. Sending Predirects . . . . . . . . . . . . . . . . . . 16 81 4.4.7. Processing Predirects and Sending Redirects . . . . . 17 82 4.4.8. Relaying Redirects . . . . . . . . . . . . . . . . . . 19 83 4.4.9. Processing Redirects . . . . . . . . . . . . . . . . . 19 84 4.4.10. Sending Periodic Predirect Keepalives . . . . . . . . 20 85 4.4.11. Reachability Considerations . . . . . . . . . . . . . 22 86 4.4.12. Mobility Considerations . . . . . . . . . . . . . . . 22 87 4.4.13. Prefix Re-Provisioning Considerations . . . . . . . . 24 88 4.4.14. Backward Compatibility . . . . . . . . . . . . . . . . 24 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 26 95 Appendix A. Intermediate Router Interworking . . . . . . . . . . 26 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 1. Introduction 100 Nodes attached to common multi-access link types (e.g., multicast- 101 capable, shared media, non-broadcast multiple access (NBMA), etc.) 102 can exchange packets as neighbors on the link, but may not always be 103 provisioned with sufficient routing information for optimal neighbor 104 selection. Such nodes should therefore be able to discover a trusted 105 intermediate router on the link that provides both default forwarding 106 services to reach off-link destinations and redirection services to 107 inform the node of an on-link neighbor that is closer to the final 108 destination. 110 +--------------+ 111 | Router A | 112 | (D->C) | 113 +--------------+ 114 | 115 X--------+--------+--------+------X 116 | | 117 +----------+---+ +---+----------+ 118 | Node B | | Router C | 119 | (default->A) | +-------+------+ 120 +--------------+ .-. 121 ,-( _)-. 122 .-(_ IPv6 )-. 123 (__ EUN ) 124 `-(______)-' 125 +-------+------+ 126 | Node D | 127 +--------------+ 129 Figure 1: Classical Multi-Access Link Redirection 131 Figure 1 shows a classical multi-access link redirection scenario. 132 In this figure, Node 'B' is provisioned with only a default route 133 with Router 'A' as the next hop. Router 'A' in turn has a more- 134 specific route that lists Router 'C' as the next hop neighbor on the 135 link for Node 'D's attached network. 137 If Node 'B' has a packet to send to Node 'D', 'B' is obliged to send 138 its initial packets via Router 'A'. Router 'A' then forwards the 139 packet to Router 'C' and also returns a redirect message to inform 140 'B' that 'C' is in fact an on-link neighbor that is closer to the 141 final destination 'D'. After receiving the redirect message, 'B' can 142 place a more-specific route in its forwarding table so that future 143 packets destined to 'D' can be sent directly via Router 'C', as shown 144 in Figure 2. 146 +--------------+ 147 | Router A | 148 | (D->C) | 149 +--------------+ 150 | 151 X--------+--------+--------+------X 152 | | 153 +----------+---+ +---+----------+ 154 | Node B | | Router C | 155 | (default->A) | +-------+------+ 156 | (D->C) | .-. 157 +--------------+ ,-( _)-. 158 .-(_ IPv6 )-. 159 (__ EUN ) 160 `-(______)-' 161 +-------+------+ 162 | Node D | 163 +--------------+ 165 Figure 2: More-Specific Routes Following Redirection 167 This classical redirection can provide a useful route optimization, 168 since the triangular path from the ingress link neighbor, to the 169 intermediate router, and finally to the egress link neighbor may be 170 considerably longer than the direct path from ingress to egress. 171 However, ordinary redirection may lead to operational issues on 172 certain link types and/or in certain deployment scenarios. 174 For example, when an ingress link neighbor accepts an ordinary 175 redirect message, it has no way of knowing whether the egress link 176 neighbor is ready and willing to accept packets directly without 177 involving an intermediate router. Likewise, the egress has no way of 178 knowing that the ingress is authorized to forward packets from the 179 claimed network-layer source address. (This is especially important 180 for very large links, since any node on the link can spoof the 181 network-layer source address with low probability of detection even 182 if the link-layer source address cannot be spoofed.) Additionally, 183 the ingress would have no way of knowing whether the direct path to 184 the egress has failed, nor whether the final destination has moved 185 away from the egress to some other network attachment point. 187 Therefore, a new approach is required that can enable redirection 188 signaling from the egress to the ingress link node under the 189 mediation of a trusted intermediate router. The mechanism is 190 asymmetric (since only the forward direction from the ingress to the 191 egress is optimized) and extended (since the redirection extends 192 forward to the egress before reaching back to the ingress). This 193 document therefore introduces an Asymmetric Extended Route 194 Optimization (AERO) capability that addresses the issues. 196 While the AERO mechanisms were initially designed for the specific 197 purpose of NBMA tunnel virtual interfaces (e.g., see: 198 [RFC2529][RFC5214][RFC5569][I-D.templin-intarea-vet]) they can also 199 be applied to any multiple access link types that support 200 redirection. The AERO techniques are discussed herein with reference 201 to IPv6 [RFC2460][RFC4861], however they can also be applied to any 202 other network layer protocol (e.g., IPv4 [RFC0791][RFC0792][RFC2131]) 203 that provides a redirection service (details of operation for other 204 network layer protocols are out of scope.) 206 2. Terminology 208 The terminology in the normative references apply; the following 209 terms are defined within the scope of this document: 211 AERO link 212 any link (either physical or virtual) over which the AERO 213 mechanisms can be applied. (For example, a virtual overlay of 214 tunnels can serve as an AERO link.) 216 AERO node 217 a router or host connected to an AERO link, and that is configured 218 to apply the AERO protocol on that link. 220 intermediate AERO router ("intermediate router") 221 a router that configures an advertising router interface on an 222 AERO link over which it can provide default forwarding and 223 redirection services for other AERO nodes. 225 edge AERO router ("edge router") 226 a router that configures a non-advertising router interface on an 227 AERO link over which it can connect End User Networks (EUNs) to 228 the AERO link. 230 AERO host 231 a simple host on an AERO link. 233 ingress AERO node ("ingress node") 234 a node that injects packets into an AERO link. 236 egress AERO node ("egress node") 237 a node that receives packets from an AERO link. 239 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 240 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 241 document, are to be interpreted as described in [RFC2119]. 243 3. Requirements 245 The route optimization mechanism must satisfy the following 246 requirements: 248 Req 1: Off-load traffic from performance-critical gateways 249 The mechanism must offload sustained transit though an 250 intermediate AERO router that would otherwise become a traffic 251 concentrator. 253 Req 2: Support route optimization 254 The ingress AERO node should be able to send packets directly to 255 the egress node without involving an intermediate router for route 256 optimization purposes. 258 Req 3: Support scaling 259 For scaling purposes, support interworking and control message 260 relaying between multiple intermediate routers (see appendix A). 262 Req 4: Do not circumvent ingress filtering 263 The mechanism must not open an attack vector where network-layer 264 source address spoofing is enabled even when link-layer source 265 address spoofing is disabled. 267 Req 5: Do not expose packets to loss due to filtering 268 The ingress AERO node must have a way of knowing that the egress 269 AERO node will accept its forwarded packets. 271 Req 6: Do not expose packets to loss due to path failure 272 The ingress AERO node must have a way of discovering whether the 273 AERO egress node has gone unreachable on the route optimized path. 275 Req 7: Do not introduce routing loops 276 Intermediate routers must not invoke a route optimization that 277 would cause a routing loop to form. 279 Req 8: Support mobility 280 The mechanism must continue to work even if the final destination 281 node/network moves from a first egress node and re-associates with 282 a second egress node. 284 4. Asymmetric Extended Route Optimization (AERO) 286 The following sections specify an Asymmetric Extended Route 287 Optimization (AERO) capability that fulfills the requirements 288 specified in Section 3. 290 4.1. AERO Link Dynamic Routing 292 In many AERO link use case scenarios (e.g., small enterprise 293 networks, small and stable MANETs, etc.), routers can engage in a 294 classical dynamic routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so 295 that routing/forwarding tables can be populated and standard 296 forwarding between routers can be used. In other scenarios (e.g., 297 large enterprise/ISP networks, cellular service provider networks, 298 dynamic MANETs, etc.), this might be impractical due to routing 299 protocol control message scaling issues. 301 When a classical dynamic routing protocol cannot be used, the 302 mechanisms specified in this section can provide a useful on-demand 303 route discovery capability. When both classical dynamic routing 304 protocols and the AERO mechanism are active on the same link, routes 305 discovered by the dynamic routing protocol should take precedence 306 over those discovered by AERO. 308 4.2. AERO Node Behavior 310 The following sections discuss characteristics of nodes attached to 311 links over which AERO can be used: 313 4.2.1. AERO Node Types 315 Intermediate AERO routers configure their AERO link interfaces as 316 advertising router interfaces (see: [RFC4861], Section 6.2.2), and 317 therefore may send Router Advertisement (RA) messages that include 318 non-zero Router Lifetimes. 320 Edge AERO routers configure their AERO link interfaces as non- 321 advertising router interfaces. 323 AERO hosts configure their AERO link interfaces as simple host 324 interfaces. 326 4.2.2. AERO Host Behavior 328 AERO hosts send Router Solicitation (RS) messages to obtain RA 329 messages from an intermediate AERO router. When the RA contains 330 Prefix Information Options with non-link-local prefixes, the host 331 autoconfigures network-layer addresses from the prefixes using 332 Stateless Address Autoconfiguration (SLAAC) [RFC4861][RFC4862]. When 333 managed network-layer address delegation services are available, the 334 host can also (or instead) acquire network-layer addresses taken from 335 prefixes aggregated by the intermediate router through the use of 336 stateful mechanisms, e.g., DHCPv6 [RFC3315], administrative 337 configuration, etc. 339 After the host receives network-layer addresses, it assigns them to 340 its AERO interface and forwards any of its outbound packets via the 341 intermediate router as a default router. The host may subsequently 342 engage in the AERO route optimization procedure as specified in 343 Section 4.4. 345 4.2.3. Edge AERO Router Behavior 347 Edge AERO routers send RS messages to obtain RA messages from an 348 intermediate AERO router, i.e., they act as "hosts" on their non- 349 advertising AERO link router interfaces for the purpose of default 350 router discovery. Edge routers can then acquire managed prefix 351 delegations aggregated by an intermediate router through the use of, 352 e.g., DHCPv6 Prefix Delegation [RFC3633], administrative 353 configuration, etc. 355 After the edge router acquires prefixes, it can sub-delegate them to 356 nodes and links within its attached End User Networks (EUNs), then 357 can forward any outbound packets coming from its EUNs via the 358 intermediate router. The edge router may subsequently engage in the 359 AERO route optimization procedure as specified in Section 4.4. 361 4.2.4. Intermediate AERO Router Behavior 363 Intermediate AERO routers respond to RS messages from AERO hosts and 364 edge routers by returning an RA message. Intermediate routers may 365 further configure a DHCP relay or server function on their AERO links 366 and/or provide an administrative interface for delegation of network- 367 layer addresses and prefixes. (In any case, however, each 368 intermediate router must be made aware of the network-layer address/ 369 prefix delegations associated with the AERO edge routers and hosts 370 that it serves.) 372 When the intermediate router completes a stateful network-layer 373 address or prefix delegation transaction (e.g., as a DHCPv6 relay/ 374 server, etc.), it establishes forwarding table entries that list the 375 link-layer address of the client AERO node as the link-layer address 376 of the next hop toward the delegated network-layer addresses/ 377 prefixes. 379 When the intermediate router forwards a packet out the same AERO 380 interface it arrived on, it initiates an AERO route optimization 381 procedure as specified in Section 4.4. 383 4.3. AERO Reference Operational Scenario 385 Figure 3 depicts the AERO reference operational scenario. The figure 386 shows an intermediate AERO router ('A'), two edge AERO routers ('B', 387 'D'), an AERO host ('F'), and three ordinary IPv6 hosts ('C', 'E', 388 'G'): 389 .-(::::::::) 390 .-(::: IPv6 :::)-. +-------------+ 391 (:::: Internet ::::)--| Host G | 392 `-(::::::::::::)-' +-------------+ 393 `-(::::::)-' 2001:db8:3::1 394 | 395 +--------------+ +--------------+ 396 | Intermediate | | AERO Host F | 397 | AERO Router A| | (default->A) | 398 | (C->B; E->D) | +--------------+ 399 +--------------+ 2001:db8:2:1 400 L3(A) L3(F) 401 L3(A) L2(F) 402 | | 403 X-----+-----------+-----------+-----------+---X 404 | AERO Link | 405 L2(B) L2(D) 406 L3(B) L3(D) 407 +--------------+ +--------------+ .-. 408 | AERO Edge | | AERO Edge | ,-( _)-. 409 | Router B | | Router D | .-(_ IPv6 )-. 410 | (default->A) | | (default->A) |--(__ EUN ) 411 +--------------+ +--------------+ `-(______)-' 412 2001:db8:0::/48 2001:db8:1::/48 | 413 | 2001:db8:1::1 414 .-. +-------------+ 415 ,-( _)-. 2001:db8:0::1 | Host E | 416 .-(_ IPv6 )-. +-------------+ +-------------+ 417 (__ EUN )--| Host C | 418 `-(______)-' +-------------+ 420 Figure 3: AERO Reference Operational Scenario 422 In Figure 3, intermediate AERO router ('A') connects to the AERO link 423 and also connects to the IPv6 Internet, either directly or via other 424 IPv6 routers (not shown). Intermediate router ('A') configures an 425 AERO link interface with a link-local network-layer address L3(A) and 426 with link-layer address L2(A). The intermediate router next arranges 427 to add L2(A) to a published list of valid intermediate routers for 428 the link. Finally, the intermediate router is further provisioned 429 with routing information listing AERO node ('B') as the next-hop 430 toward the IPv6 EUN that connects node ('C'), and listing AERO node 431 ('D') as the next-hop AERO router toward the IPv6 EUN that connects 432 node ('E'). 434 AERO node ('B') is an AERO edge router that connects to one or more 435 IPv6 EUNs and also connects to the AERO link via an interface with 436 link-local network-layer address L3(B) and with link-layer address 437 L2(B). Node ('B') next configures a default route with next-hop 438 network-layer address L3(A) via the AERO interface, then receives the 439 network-layer prefix 2001:db8:0::/48 through a stateful prefix 440 delegation exchange that also establishes routing information in 441 intermediate router ('A'). Node ('B') finally sub-delegates the 442 network-layer prefix to links and/or routers within its attached 443 EUNs, where IPv6 host ('C') autoconfigures the network-layer address 444 2001:db8:0::1. 446 AERO node ('D') is an AERO edge router that connects to the AERO link 447 via an interface with link-local network-layer address L3(D) and with 448 link-layer address L2(D). Note ('D') next configures a default route 449 with next-hop network-layer address L3(A) via the AERO interface, 450 then receives the network-layer prefix 2001:db8:1::/48 through a 451 stateful prefix delegation exchange in the same fashion as for node 452 ('B'). Node ('D') finally sub-delegates the network-layer prefix to 453 links and/or routers within its attached EUNs, where IPv6 host ('E') 454 autoconfigures network-layer address 2001:db8:1::1. 456 AERO host ('F') connects to the AERO link via an interface with link- 457 local network-layer address L3(F) and with link-layer address L2(F). 458 Host ('F') next configures a default route with next-hop network- 459 layer address L3(A) via the AERO interface, then receives the 460 network-layer address 2001:db8:2::1 from a stateful address 461 configuration exchange that also establishes routing information in 462 intermediate router ('A'). When host ('F') receives the network- 463 layer address, it assigns the address to the AERO interface. 465 Finally, IPv6 host ('G') connects to an IPv6 network outside of the 466 AERO link domain. Host ('G') configures its IPv6 interface in a 467 manner specific to its attached IPv6 link, and autoconfigures the 468 network-layer address 2001:db8:3::1. 470 In these arrangements, intermediate router ('A') must maintain state 471 that associate the delegated network-layer addresses/prefixes with 472 the link-local network-layer addresses of the correct edge routers 473 and/or hosts on the AERO link. The nodes must in turn maintain at 474 least a default route that points to intermediate router ('A'), and 475 can discover more-specific routes either via a proactive dynamic 476 routing protocol or via the AERO mechanisms specified in Section 4.4. 478 4.4. AERO Specification 480 Section 4.3 describes the AERO reference operational scenario. We 481 now discuss the operation and protocol details of AERO with respect 482 to this reference scenario. 484 4.4.1. Classical Redirection Approaches 486 With reference to Figure 3, when IPv6 source host ('C') sends a 487 packet with source network-layer address 'C' and destination network- 488 layer address 'E', the packet is first forwarded via the EUN to 489 ingress AERO node ('B'). The ingress node then forwards the packet 490 over the AERO interface to the AERO link intermediate router ('A'), 491 which then forwards the packet to egress AERO node ('D'), where the 492 packet is finally forwarded to the IPv6 destination host ('E'). When 493 intermediate router ('A') forwards the packet back out on its 494 advertising AERO interface, it must arrange to redirect ingress node 495 ('B') toward egress node ('D') as a better next hop node on the AERO 496 link that is closer to the final destination. However, this 497 redirection process should only occur if there is assurance that both 498 the ingress and egress nodes are willing participants. 500 Consider a first alternative in which intermediate router ('A') 501 informs ingress node ('B') only and does not inform egress node ('D') 502 (i.e., "classic redirection"). In that case, the egress node has no 503 way of knowing that the ingress is authorized to forward packets from 504 their claimed source network-layer addresses, and may simply elect to 505 drop the packets. Also, the ingress node has no way of knowing 506 whether the egress is willing to accept its packets, nor whether the 507 egress is even reachable via a direct path that does not involve the 508 intermediate router. Finally, the ingress node has no way of knowing 509 whether the final destination has moved away from egress node. 511 Consider also a second alternative in which intermediate router ('A') 512 informs both ingress node ('B') and egress node ('D') separately via 513 independent redirection messages (i.e., "augmented redirection"). In 514 that case, several conditions can occur that could result in 515 communication failures. First, if the ingress receives the 516 redirection message but the egress does not, subsequent packets sent 517 by the ingress could be dropped due to filtering since the egress 518 would not have neighbor state to verify their source network-layer 519 addresses. Second, if the egress receives the redirection message 520 but the ingress does not, subsequent packets sent in the reverse 521 direction by the egress would be lost. Finally, timing issues 522 surrounding the establishment and garbage collection of neighbor 523 state at the ingress and egress nodes could yield unpredictable 524 behavior. For example, unless the timing were carefully coordinated 525 through some form of synchronization loop, there would invariably be 526 instances in which one node has the correct neighbor state and the 527 other node does not resulting in non-deterministic packet loss. 529 Since neither of these alternatives can satisfy the requirements 530 listed in Section 3, a new redirection technique (i.e., "AERO 531 redirection") is needed. 533 4.4.2. AERO Concept of Operations 535 AERO redirection is used on links for which the classical redirection 536 approaches described in Section 4.4.1 are insufficient to satisfy all 537 requirements. We now discuss the concept of operations for this new 538 approach. 540 Again with reference to Figure 3, when source host ('C') sends a 541 packet with source network-layer address L3(C) and destination 542 network-layer address L3(E), the packet is first forwarded over the 543 source host's attached EUN to ingress node ('B'), which then forwards 544 the packet via its AERO interface to intermediate router ('A'). 546 Using AERO redirection, intermediate router ('A') then forwards the 547 packet out the same AERO interface toward egress node ('D') and also 548 sends a "Predirect" message forward to the egress node. The 549 Predirect message includes the identity of ingress node ('B') as well 550 as information that egress node ('D') can use to determine the 551 longest-match prefixes that cover the source and destination network- 552 layer addresses of the packet that triggered the Predirect. After 553 egress node ('D') receives the Predirect, it creates neighbor state 554 for ingress node ('B') (if necessary) and retains this (src, dst) 555 "prefix pair" as ingress filtering information to accept future 556 packets using addresses matched by the prefixes from ingress node 557 ('B'). 559 After creating this ingress filtering state, egress node ('D') sends 560 a Redirect message back to the intermediate router ('A'), which then 561 acts as a "proxy" to relay the message to ingress node ('B'). The 562 Redirect message includes the identity of egress node ('D') as well 563 as information that ingress node ('B') can use to determine the 564 longest-match prefixes that cover the source and destination network- 565 layer addresses of the packet that triggered the Redirect. After 566 ingress node ('B') receives the Redirect, it creates neighbor state 567 for egress node ('D') (if necessary) and retains this prefix pair as 568 forwarding information to forward future packets using addresses 569 matched by the prefixes to the egress node ('D'). 571 Following the above Predirect/Redirect message exchange, forwarding 572 of packets with source and destination network-layer addresses 573 covered by the longest-match prefix pair is enabled in the forward 574 direction from ingress node ('B') to egress node ('D'). The 575 mechanisms that enable this exchange are specified in the following 576 sections. 578 4.4.3. Conceptual Data Structures and Protocol Constants 580 Each AERO node maintains a per AERO interface conceptual neighbor 581 cache that includes an entry for each neighbor it communicates with 582 on the AERO link the same as for any IPv6 interface (see: [RFC4861]). 584 Each AERO interface neighbor cache entry further maintains two lists 585 of (src, dst) prefix pairs. The AERO node adds a prefix pair to the 586 ACCEPT list if it has been informed by a trusted intermediate router 587 that it is safe to accept packets from the neighbor using network- 588 layer source and destination addresses covered by the prefix pair. 589 The AERO node adds a prefix pair to the FORWARD list if it has been 590 informed by a trusted intermediate router that it is permitted to 591 forward packets to the neighbor using network-layer addresses covered 592 by the prefix pair. 594 When the node adds a prefix pair to a neighbor cache entry ACCEPT 595 list, it also sets an expiration timer for the prefix pair to 596 ACCEPT_TIME seconds. When the node adds a prefix pair to a neighbor 597 cache entry FORWARD list, it sets an expiration timer for the prefix 598 pair to FORWARD_TIME seconds. 600 It is RECOMMENDED that FORWARD_TIME be set to the default constant 601 value 30 seconds to match the default REACHABLE_TIME value specified 602 for IPv6 neighbor discovery [RFC4861]. It is further RECOMMENDED 603 that ACCEPT_TIME be set to the default constant value 40 seconds to 604 allow a 10 second window so that the AERO redirection procedure can 605 converge before the ACCEPT_TIME timer decrements below FORWARD_TIME. 607 Different values for FORWARD_TIME and ACCEPT_TIME MAY be 608 administratively set if necessary to better match the AERO link's 609 performance characteristics; however, if different values are chosen 610 all nodes on the link MUST consistently configure the same values. 611 ACCEPT_TIME SHOULD further be set to a value that is sufficiently 612 longer than FORWARD time to allow the AERO redirection procedure to 613 converge. 615 4.4.4. Data Origin Authentication 617 AERO nodes MUST employ a data origin authentication check for the 618 packets they receive on an AERO interface. In particular, the node 619 considers the network-layer source address correct for the link-layer 620 source address if: 622 o the network-layer source address is an on-link address that embeds 623 the link-layer source address, or 625 o the network-layer source address is explicitly linked to the link- 626 layer source address through per-neighbor state, or 628 o the link-layer source address is the address of a trusted 629 intermediate AERO router, or 631 o the packet includes a digital signature that the node can use to 632 authenticate the origin. 634 When the AERO node receives a packet on an AERO interface, it 635 processed the packet further if it satisfies one of these data origin 636 authentication conditions; otherwise it drops the packet. 638 Note that on links in which link-layer address spoofing is possible, 639 AERO nodes may be obliged to require the use of digital signatures. 640 In that case, only the third of the above conditions can be accepted 641 in order to ensure adequate data origin authentication. 643 4.4.5. AERO Redirection Message Format 645 AERO redirection messages use the same format as for ICMPv6 Redirect 646 messages depicted in Section 4.5 of [RFC4861]. For the purpose of 647 this experimental publication, however, AERO redirection messages use 648 the experimental ICMPv6 message type value of "100" (see: Section 2.1 649 of [RFC4443]) instead of the official type value reserved for ICMPv6 650 Redirect messages. 652 AERO redirection messages are further identified by three new bits 653 known as the "AERO bits" taken from the Reserved field as shown in 654 Figure 4: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type (=137) | Code (=0) | Checksum | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |A|P|R| Reserved | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | 664 + + 665 | | 666 + Target Address + 667 | | 668 + + 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | | 672 + + 673 | | 674 + Destination Address + 675 | | 676 + + 677 | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Options ... 680 +-+-+-+-+-+-+-+-+-+-+-+- 682 Figure 4: AERO-Specific ICMPv6 Redirect Message Format 684 Where the new AERO bits are defined as: 686 A (1) Set to 1 to indicate an AERO-specific Redirect message, and 687 set to 0 to indicate an ordinary ICMPv6 Redirect message. 689 P (1) Set to 1 to indicate a Predirect message, and set to 0 to 690 indicate a Redirect response to a Predirect message. (This bit is 691 valid only when the A bit is set to 1.) 693 R (1) Set to 1 to indicate that this message has already been 694 Relayed by an intermediate router; otherwise, set to 0. (This bit 695 is valid only when the A bit is set to 1.) 697 4.4.6. Sending Predirects 699 When an intermediate AERO router forwards a packet out the same AERO 700 interface that it arrived on, the router sends an AERO Predirect 701 message forward toward the egress AERO node instead of sending an 702 ICMPv6 Redirect message back to the ingress AERO node. 704 In the reference operational scenario, when the intermediate router 705 ('A') forwards a packet sent by the ingress node ('B') toward the 706 egress node ('D'), it also sends an AERO Predirect message forward 707 toward the egress, subject to rate limiting (see Section 8.2 of 708 [RFC4861]). The intermediate router ('A') prepares the AERO 709 Predirect message in a similar fashion as for an ordinary ICMPv6 710 Redirect message as follows: 712 o the link-layer source address is set to 'L2(A)' (i.e., the link- 713 layer address of the intermediate router). 715 o the link-layer destination address is set to 'L2(D)' (i.e., the 716 link-layer address of the egress node). 718 o the network-layer source address is set to 'L3(A)' (i.e., the 719 link-local network-layer address of the intermediate router). 721 o the network-layer destination address is set to 'L3(D)'. (i.e., 722 the link-local network-layer address of the egress node). 724 o the ICMP Target and Destination Addresses are both set to 'L3(B)' 725 (i.e., the link-local network-layer address of the ingress node). 727 o on links that require stateful address mapping, the message 728 includes a Target Link Layer Address Option (TLLAO) set to 'L2(B)' 729 (i.e., the link-layer address of the ingress node). 731 o the message includes a Route Information Option (RIO) [RFC4191] 732 that encodes the ingress node's network-layer address/prefix 733 delegation that covers the network-layer source address of the 734 originating packet. 736 o the message includes a Redirected Header Option (RHO) that 737 contains the originating packet truncated to ensure that at least 738 the network-layer header is included but the size of the message 739 does not exceed 1280 bytes. 741 o the AERO bits in the message header are set to A=1; P=1; R=0. 743 The intermediate router ('A') then sends the message forward to the 744 egress node ('D'). 746 4.4.7. Processing Predirects and Sending Redirects 748 When the egress node ('D') receives an AERO Predirect message, it 749 accepts the message only if it satisfies the data origin 750 authentication requirements specified in Section 4.4.4. Next, the 751 egress node ('D') validates the message according to the ICMPv6 752 Redirect message validation rules in Section 8.1 of [RFC4861] with 753 the exception that the message includes a link-local address in the 754 ICMP destination field that differs from the destination address of 755 the packet header encapsulated in the RHO. 757 In the reference operational scenario, when the egress node ('D') 758 receives a valid AERO Predirect message it creates a neighbor cache 759 entry (if necessary) that stores the Target address of the message 760 (i.e., the link-local network-layer address of the ingress node 761 ('B')). The egress node ('D') then records the prefix found in the 762 RIO along with its own prefix that matches the network-layer 763 destination address in the packet header found in the RHO with the 764 neighbor cache entry as an acceptable (src, dst) prefix pair. The 765 egress node ('D') then adds the prefix pair to the neighbor cache 766 entry ACCEPT list, and sets/resets an expiration timer for the prefix 767 pair to ACCEPT_TIME seconds. If the timer later expires, the egress 768 node ('D') deletes the prefix pair. 770 After processing the message, the egress node ('D') prepares an AERO 771 Redirect message response as follows: 773 o the link-layer source address is set to 'L2(D)' (i.e., the link- 774 layer address of the egress node). 776 o the link-layer destination address is set to 'L2(A)' (i.e., the 777 link-layer address of the intermediate router). 779 o the network-layer source address is set to 'L3(D)' (i.e., the 780 link-local network-layer address of the egress node). 782 o the network-layer destination address is set to 'L3(B)' (i.e., the 783 link-local network-layer address of the ingress node). 785 o the ICMP Target and the Redirect Destination Addresses are both 786 set to 'L3(D)' (i.e., the link-local network-layer address of the 787 egress node). 789 o on links that require stateful address mapping, the message 790 includes a Target Link Layer Address Option (TLLAO) set to 791 'L2(D)'. 793 o the message includes an RIO that encodes the egress node's 794 network-layer address/prefix delegation that covers the network- 795 layer destination address of the originating packet. 797 o the message includes as much of the RHO copied from the 798 corresponding AERO Predirect message as possible such that at 799 least the network-layer header is included but the size of the 800 message does not exceed 1280 bytes. 802 o the AERO bits in the message header are set to A=1; P=0; R=0. 804 After the egress node ('D') prepares the AERO Redirect message, it 805 sends the message to the intermediate router ('A'). 807 4.4.8. Relaying Redirects 809 When the intermediate router ('A') receives an AERO Redirect message, 810 it accepts the message only if it satisfies the data origin 811 authentication requirements specified in Section 4.4.4. Next, the 812 intermediate router ('A') validates the message the same as described 813 in Section 4.4.7. Following validation, the intermediate router 814 ('A') then "relays" the message back to the ingress node ('B') as 815 follows. 817 In the reference operational scenario, the intermediate router ('A') 818 receives the AERO Redirect message from the egress node ('D') and 819 prepares to relay the message to the ingress node ('B'). The 820 intermediate router ('A') then verifies that the RIO encodes a 821 network-layer address/prefix that the egress node ('D') is authorized 822 to use, and discards the message if verification fails. Otherwise, 823 the intermediate router ('A') changes the link-layer source address 824 of the message to 'L2(A)', changes the network-layer source address 825 of the message to the link-local network-layer address 'L3(A)', and 826 changes the link-layer destination address to 'L2(B)' . The 827 intermediate router ('A') finally sets the AERO R bit to 1 and relays 828 the message to the ingress node ('B') without decrementing the 829 hopcount. 831 This relaying procedure therefore requires the intermediate router 832 ('A') to examine the R bit before relaying an AERO Redirect message 833 in order to avoid a free-running loop due to the non-decrementing 834 hopcount. In particular, the intermediate route discards any AERO 835 Redirect message it receives with R==1. 837 4.4.9. Processing Redirects 839 When the ingress node ('B') receives an AERO Redirect message (i.e., 840 one with A=1; P=0), it accepts the message only if it satisfies the 841 data origin authentication requirements specified in Section 4.4.4. 842 Next, the ingress node ('B') validates the message the same as 843 described in Section 4.4.6. Following validation, the ingress node 844 ('B') then processes the message as follows. 846 In the reference operational scenario, when the ingress node ('B') 847 receives the (relayed) AERO Redirect message it creates a neighbor 848 cache entry (if necessary) that stores the Target address of the 849 message (i.e., the link-local network-layer address of the egress 850 node 'L3(D)'). The ingress node ('B') then records the (src, dst) 851 prefix pair associated with the triggering packet in the neighbor 852 cache entry FORWARD list, i.e., it records its prefix that matches 853 the redirected packet's network-layer source address and the prefix 854 listed in the RIO as the prefix pair. The ingress node ('B') then 855 sets/resets an expiration timer for the prefix pair to FORWARD_TIME 856 seconds. If the timer later expires, the ingress node ('B') deletes 857 the entry. 859 Now, the ingress node ('B') has a neighbor cache FORWARD list entry 860 for the prefix pair, and the egress node ('D') has a neighbor cache 861 ACCEPT list entry for the prefix pair. Therefore, the ingress node 862 ('B') may forward ordinary network-layer data packets with network- 863 layer source and destination addresses that match the prefix pair 864 directly to the egress node ('D') without involving the intermediate 865 router ('A'). Note that the ingress node must have a way of 866 informing the network layer of a route that associates the 867 destination prefix with this neighbor cache entry. The manner of 868 establishing such a route (and deleting it when it is no longer 869 necessary) is left to the implementation. 871 To enable packet forwarding in the reverse direction, a separate AERO 872 redirection operation is required which is the mirror-image of the 873 forward operation described above, i.e., the forward and reverse AERO 874 operations are asymmetric. 876 4.4.10. Sending Periodic Predirect Keepalives 878 In order to prevent prefix pairs from expiring while data packets are 879 actively flowing, the ingress node ('B') can periodically send AERO 880 Predirect keepalive messages directly to the egress node ('D') to 881 solicit AERO Redirect messages. Absent specific administrative 882 configuration, it is RECOMMENDED that the ingress node ('B') send no 883 more than 10 keepalive messages during each FORWARD_TIME interval. 885 In the reference operational scenario, when the ingress node ('B') 886 wishes to refresh the FORWARD timer for a specific prefix pair, it 887 can send an AERO Predirect keepalive message directly to the egress 888 node ('D') prepared as follows: 890 o the link-layer source address is set to 'L2(B)' (i.e., the link- 891 layer address of the ingress node). 893 o the link-layer destination address is set to 'L2(D)' (i.e., the 894 link-layer address of the egress node). 896 o the network-layer source address is set to 'L3(B)' (i.e., the 897 link-local network-layer address of the ingress node). 899 o the network-layer destination address is set to 'L3(D)' (i.e., the 900 link-local network-layer address of the egress node). 902 o the Predirect Target and Destination Addresses are both set to 903 'L3(B)' (i.e., the link-local network-layer address of the ingress 904 node). 906 o the Predirect message includes an RHO that contains the 907 originating packet truncated to ensure that at least the network- 908 layer header is included but the size of the message does not 909 exceed 1280 bytes. 911 o the AERO bits in the message header are set to A=1; P=1; R=0. 913 When the egress node ('D') receives the AERO Predirect message, it 914 validates the message the same as described in Section 4.4.6. 915 Following validation, the egress node ('D') then resets its ACCEPT 916 timer for the prefix pair that matches the originating packet's 917 network-layer source and destination addresses to ACCEPT_TIME 918 seconds, and sends an AERO Redirect message directly to the ingress 919 node ('B') prepared as follows: 921 o the link-layer source address is set to 'L2(D)' (i.e., the link- 922 layer address of the egress node). 924 o the link-layer destination address is set to 'L2(B)' (i.e., the 925 link-layer address of the ingress node). 927 o the network-layer source address is set to 'L3(D)' (i.e., the 928 link-local network-layer address of the egress node). 930 o the network-layer destination address is set to 'L3(B)' (i.e., the 931 link-local network-layer address of the ingress node). 933 o the Redirect Target and Destination Addresses are both set to 934 'L3(D)' (i.e., the link-local network-layer address of the egress 935 node). 937 o the message includes as much of the RHO copied from the 938 corresponding AERO Predirect message as possible such that at 939 least the network-layer header is included but the size of the 940 message does not exceed 1280 bytes. 942 o the AERO bits in the Redirect message header are set to A=1; P=0; 943 R=0. 945 When the ingress node ('B') receives the AERO Redirect message, it 946 validates the message the same as described in Section 4.4.6. 947 Following validation, the ingress node ('B') then resets its FORWARD 948 timer for the prefix pair that matches the originating packet's 949 network-layer source and destination addresses to FORWARD_TIME 950 seconds. 952 4.4.11. Reachability Considerations 954 When the ingress node ('B') receives an AERO Redirect message 955 informing it of a direct path to a new egress node ('D'), there is a 956 question in point as to whether the new egress node ('D') can be 957 reached directly without involving an intermediate router ('A'). On 958 some AERO links, it may be reasonable for the ingress node ('B') to 959 (optimistically) assume that reachability is transitive, and to 960 immediately begin forwarding data packets to the egress node ('D') 961 without testing reachability. 963 On AERO links in which an optimistic assumption of transitive 964 reachability may be unreasonable, however, the ingress node ('B') can 965 defer the redirection until it tests the direct path to the egress 966 node ('D'), e.g., by sending an AERO Predirect message to solicit an 967 AERO Redirect as specified in Section 4.4.10. If the ingress node 968 ('B') is unable to elicit an AERO Redirect message after 969 MAX_UNICAST_SOLICIT attempts, it should consider the direct path to 970 the egress node ('D') as unusable. (It is RECOMMENDED that the 971 ingress node set MAX_UNICAST_SOLICIT to 3 the same as described for 972 IPv6 neighbor discovery address resolution in Section 7.3.3 of 973 [RFC4861].) 975 In either case, the ingress node ('B') can process any link errors 976 corresponding to the data packets sent directly to the egress node 977 ('D') as a hint that the direct path has either failed or has become 978 intermittent. 980 4.4.12. Mobility Considerations 982 Again with reference to Figure 3, egress node ('D') can configure 983 both a non-advertising router interface on a provider AERO link and 984 advertising router interfaces on its connected EUN links. When an 985 EUN node ('E') in one of the egress node's connected EUNs moves to a 986 different network point of attachment, however, it can release its 987 network-layer address/prefix delegations that were registered with 988 egress node ('D' ) and re-establish them via a different router. 990 When the EUN node ('E') releases its network-layer address/prefix 991 delegations, the egress node ('D') marks its forwarding table entries 992 corresponding to the network-layer addresses/prefixes as "departed" 993 and no longer responds to AERO Predirect keepalive messages for the 994 departed addresses/prefixes. When egress node ('D') receives packets 995 from an ingress node ('B') with network-layer source and destination 996 addresses that match a prefix pair on the ACCEPT list, it forwards 997 them to the last-known link-layer address of EUN node ('E') as a 998 means for avoiding mobility-related packet loss during routing 999 changes. Egress node ('D') also returns a NULL AERO Redirect message 1000 to inform the ingress node ('B') of the departure. The message is 1001 prepared as follows: 1003 o the link-layer source address is set to 'L2(D)'. 1005 o the link-layer destination address is set to 'L2(B)'. 1007 o the network-layer source address is set to the link-local address 1008 'L3(D)'. 1010 o the network-layer destination address is set to the link-local 1011 address 'L3(B)'. 1013 o the Redirect Target and Destination Addresses are both set to 1014 NULL. 1016 o the message includes an RHO that contains as much of the original 1017 packet as possible such that at least the network-layer header is 1018 included but the size of the message does not exceed 1280 bytes. 1020 o the AERO bits in the message header are set to A=1; P=0; R=0. 1022 When ingress node ('B') receives the NULL AERO Redirect message, it 1023 deletes the prefix pair associated with the packet in the RHO from 1024 its list of forwarding entries corresponding to egress node ('D'). 1025 When egress node ('D')s ACCEPT_TIME timer for the prefix pair 1026 corresponding to the departed prefix expires, it deletes the prefix 1027 pairs from its list of ingress filtering entries corresponding to 1028 ingress node ('B'). 1030 Eventually, any such correspondent AERO nodes will receive a NULL 1031 AERO Redirect message and will cease to use the egress node ('D') as 1032 a next hop. They will then revert to sending packets destined to the 1033 EUN node ('E') via a trusted intermediate router and may subsequently 1034 receive new AERO Redirect messages to discover that the EUN node ('E' 1035 ) is now associated with a new AERO edge router. 1037 Note that any packets forwarded by the egress node ('D') via a 1038 departed forwarding table entry may be lost if the (mobile) EUN node 1039 ('E') moves off-link with respect to its previous EUN point of 1040 attachment. This should not be a problem for large links (e.g., 1041 large cellular network deployments, large ISP networks, etc.) in 1042 which all/most mobility events are intra-link. 1044 4.4.13. Prefix Re-Provisioning Considerations 1046 When an AERO node configures one or more FORWARD/ACCEPT list prefix 1047 pair entries, and the prefixes associated with the pair are somehow 1048 re-configured or renumbered, the stale FORWARD/ACCEPT list 1049 information must be deleted. 1051 When an ingress node ('B') re-configures it's network-layer source 1052 prefix in such a way that the ACCEPT list entry in the egress node 1053 ('D') would no longer be valid (e.g., the prefix length of the source 1054 prefix changes), the ingress node ('B') simply deletes the prefix 1055 pair form its FORWARD list and allows subsequent packets covered by 1056 the prefix pair to again flow through an intermediate router ('A'). 1058 When the egress node ('D') re-configures it's network-layer 1059 destination prefix in such a way that the FORWARD list entry in the 1060 ingress node ('B') would no longer be valid, the egress node ('D') 1061 sends a NULL AERO Redirect message to the ingress node ('B') the same 1062 as described for Mobility Considerations when it receives either an 1063 AERO Predirect message or a data packet (subject to rate limiting) 1064 from the ingress node ('B') . 1066 4.4.14. Backward Compatibility 1068 For the purpose of this experimental publication, there are no 1069 backward compatibility considerations since the AERO Redirect message 1070 uses a different ICMPv6 type value than the standard ICMPv6 Redirect 1071 message. However, future versions of this document may redefine the 1072 AERO Redirect message to use the same ICMPv6 type value as the 1073 standard ICMPv6 Redirect message. 1075 In that case, if a legacy host or router receives an AERO Redirect or 1076 Predirect message, it will process the message as if it were an 1077 ordinary Redirect. This will cause no harmful effects, since the 1078 legacy system will safely ignore the AERO bits in the Reserved field, 1079 and will also ignore any RIOs that are included. The link-local 1080 network-layer addresses encoded in the Redirect message Target and 1081 Destination addresses will also not cause the legacy node to create 1082 incorrect forwarding state. The mechanism therefore causes no harm 1083 to legacy systems, and supports natural incremental deployment. 1085 5. IANA Considerations 1087 This document has no IANA considerations. 1089 6. Security Considerations 1091 AERO link security is dependent on a trust basis between edge nodes 1092 and intermediate routers. In particular, edge nodes must only engage 1093 in the AERO mechanism when it is facilitated by a trusted 1094 intermediate router. 1096 AERO links must be protected against spoofing attacks in which an 1097 attacker on the link pretends to be a trusted neighbor. This is 1098 often possible on links that provide link-layer securing mechanisms 1099 (e.g., WiFi networks) and on links that provide physical security 1100 (e.g., enterprise network LANs). In other instances, sufficient 1101 assurances against on-link spoofing attacks are possible if the 1102 source can digitally sign its messages. In that case, the 1103 destination can use the data origin authentication checks specified 1104 in Section 4.4.4 to verify the signature. 1106 7. Acknowledgements 1108 Discussions both on the v6ops list and in private exchanges helped 1109 shape some of the concepts in this work. Individuals who contributed 1110 insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, 1111 Brian Carpenter, Joel Halpern, Lee Howard, 1113 8. References 1115 8.1. Normative References 1117 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1118 Requirement Levels", BCP 14, RFC 2119, March 1997. 1120 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1121 (IPv6) Specification", RFC 2460, December 1998. 1123 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1124 More-Specific Routes", RFC 4191, November 2005. 1126 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1127 Message Protocol (ICMPv6) for the Internet Protocol 1128 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1130 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1131 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1132 September 2007. 1134 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1135 Address Autoconfiguration", RFC 4862, September 2007. 1137 8.2. Informative References 1139 [I-D.templin-intarea-vet] 1140 Templin, F., "Virtual Enterprise Traversal (VET)", 1141 draft-templin-intarea-vet-33 (work in progress), 1142 December 2011. 1144 [I-D.templin-ironbis] 1145 Templin, F., "The Internet Routing Overlay Network 1146 (IRON)", draft-templin-ironbis-10 (work in progress), 1147 December 2011. 1149 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1150 September 1981. 1152 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1153 RFC 792, September 1981. 1155 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1156 RFC 2131, March 1997. 1158 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1159 Domains without Explicit Tunnels", RFC 2529, March 1999. 1161 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1162 and M. Carney, "Dynamic Host Configuration Protocol for 1163 IPv6 (DHCPv6)", RFC 3315, July 2003. 1165 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1166 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1167 December 2003. 1169 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1170 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1171 March 2008. 1173 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1174 Infrastructures (6rd)", RFC 5569, January 2010. 1176 Appendix A. Intermediate Router Interworking 1178 Figure 3 depicts a reference AERO operational scenario with a single 1179 intermediate router on the AERO link. In order to support scaling to 1180 larger numbers of nodes, the AERO link can deploy multiple 1181 intermediate routers, e.g., as shown in Figure 5 1182 +--------------+ +--------------+ 1183 | Intermediate | +--------------+ | Intermediate | 1184 | Router C | | Core Router D| | Router E | 1185 | (default->D) | | (A->C; G->E) | | (default->D) | 1186 | (A->B) | +--------------+ | (G->F) | 1187 +-------+------+ +------+-------+ 1188 | | 1189 X---+---+--------------------------------------+---+---X 1190 | AERO Link | 1191 +-----+--------+ +--------+-----+ 1192 | AERO Node B | | AERO Node F | 1193 | (default->C) | | (default->E) | 1194 +--------------+ +--------------+ 1195 .-. .-. 1196 ,-( _)-. ,-( _)-. 1197 .-(_ IPv6 )-. .-(_ IPv6 )-. 1198 (__ EUN A ) (__ EUN G ) 1199 `-(______)-' `-(______)-' 1200 | | 1201 +--------+ +--------+ 1202 | Host A | | Host G | 1203 +--------+ +--------+ 1205 Figure 5: Multiple Intermediate Routers 1207 In this example, the ingress node ('B') associates with intermediate 1208 router ('C'), while the egress node ('F') associates with 1209 intermediate router ('E'). Furthermore, intermediate routers ('C') 1210 and ('E') do not associate with each other directly, but rather have 1211 an association with a "core" router ('D') (i.e., a router that has 1212 full topology information concerning its associated intermediate 1213 routers). The core router may connect to either the AERO link, or to 1214 other physical or virtual links to which the intermediate routers 1215 also connect. 1217 When ingress node ('B') forwards a packet from source host ('A') 1218 toward destination host ('G'), it sends the packet to intermediate 1219 router ('C') in absence of more-specific forwarding information. 1220 Intermediate router ('C') in turn generates a "pseudo Predirect" 1221 message that is through some means conveyed through core router ('D') 1222 to intermediate router ('E'). When intermediate router ('E') 1223 receives the pseudo Predirect, it sends an actual AERO Predirect 1224 message to egress node ('F'). 1226 After processing the AERO Predirect message, egress node ('F') sends 1227 an AERO Redirect message to intermediate router ('E'). Intermediate 1228 router ('E') in turn generates a "pseudo Redirect" that is through 1229 some means conveyed through core router ('D') to intermediate router 1230 ('C'). When intermediate router ('C') receives the pseudo Redirect, 1231 it sends an actual AERO Redirect message to ingress node ('B'), thus 1232 completing the AERO redirection. 1234 The interworkings between intermediate and core routers (including 1235 the conveyance of pseudo Predirects and Redirects) must be carefully 1236 coordinated in a manner outside the scope of this document. In 1237 particular, the intermediate and core routers must ensure that no 1238 routing loops are formed. See [I-D.templin-ironbis] for an 1239 architectural discussion of coordinations between intermediate and 1240 core routers. 1242 Author's Address 1244 Fred L. Templin (editor) 1245 Boeing Research & Technology 1246 P.O. Box 3707 MC 7L-49 1247 Seattle, WA 98124 1248 USA 1250 Email: fltemplin@acm.org