RFC 6706
Asymmetric Extended Route Optimization (AERO)
RFC 6706: Asymmetric Extended Route Optimization (AERO) 🦋
Okay bestie, this one is RFC 6706, and it's all about AERO 💅 It was written by F. Templin, Ed. (the "Ed." means editor, so Templin was the main person wrangling the text) from Boeing Research & Technology. It's an Experimental document, not a Standards Track one, and it's dated August 2012. It has ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🌸
Abstract
Nodes attached to common multi-access link types (e.g., multicast-capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.
The abstract is basically the whole vibe in one place: nodes on a shared link can chat directly, but they might not know the best neighbor to talk to. So they find a trusted router to help, and that router can point them to a closer neighbor. The catch is that normal redirects can get messy, and AERO is the fix 💖
Status of This Memo
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6706.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Motivation ......................................................7
4. Example Use Cases ...............................................8
5. Requirements ....................................................9
6. Asymmetric Extended Route Optimization (AERO) ..................10
6.1. AERO Link Dynamic Routing .................................10
6.2. AERO Node Behavior ........................................11
6.2.1. AERO Node Types ....................................11
6.2.2. AERO Host Behavior .................................11
6.2.3. Edge AERO Router Behavior ..........................11
6.2.4. Intermediate AERO Router Behavior ..................12
6.3. AERO Reference Operational Scenario .......................12
6.4. AERO Specification ........................................14
6.4.1. Traditional Redirection Approaches .................14
6.4.2. AERO Concept of Operations .........................15
6.4.3. Conceptual Data Structures and Protocol Constants ..16
6.4.4. Data Origin Authentication .........................17
6.4.5. AERO Redirection Message Format ....................18
6.4.6. Sending Predirects .................................20
6.4.7. Processing Predirects and Sending Redirects ........21
6.4.8. Forwarding Redirects ...............................22
6.4.9. Processing Redirects ...............................23
6.4.10. Sending Periodic Predirect Keepalives .............24
6.4.11. Neighbor Reachability Considerations ..............26
6.4.12. Mobility Considerations ...........................26
6.4.13. Link-Layer Address Change Considerations ..........27
6.4.14. Prefix Re-provisioning Considerations .............28
6.4.15. Backward Compatibility ............................29
7. IANA Considerations ............................................29
8. Security Considerations ........................................29
9. Acknowledgements ...............................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................30
Appendix A. Intermediate Router Interworking ......................321. Introduction ✨
Nodes attached to common multi-access link types (e.g., multicast-capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. So these nodes should be able to find a trusted intermediate router on the link. That router gives them two things: default forwarding to reach off-link destinations, and redirection that tells the node about an on-link neighbor that's closer to the final destination 🧚
+--------------+
| Router A |
| (D->C) |
+--------------+
|
X--------+--------+--------+------X
| |
+----------+---+ +---+----------+
| Node B | | Router C |
| (default->A) | +-------+------+
+--------------+ .-.
,-( _)-.
.-(_ IPv6 )-.
(__ EUN )
`-(______)-'
+-------+------+
| Node D |
+--------------+Figure 1: Traditional Multi-Access Link Redirection
Figure 1 shows the traditional multi-access link redirection setup. Node ('B') is only given a default route, and its next hop is router ('A'). Router ('A') has a more specific route, and it says router ('C') is the next-hop neighbor on the link for the End User Network (EUN) hanging off node ('D') 👑
So if node ('B') wants to send a packet to node ('D'), node ('B') has to send its first packets through router ('A'). Router ('A') forwards the packet to router ('C'), and it also sends a redirection control message to tell ('B') that ('C') is actually an on-link neighbor that's closer to the final destination ('D'). Once node ('B') gets that redirection message, it can add a more specific route to its forwarding table, so future packets for node ('D') go straight to router ('C'), as shown in Figure 2 🦋
+--------------+
| Router A |
| (D->C) |
+--------------+
|
X--------+--------+--------+------X
| |
+----------+---+ +---+----------+
| Node B | | Router C |
| (default->A) | +-------+------+
| (D->C) | .-.
+--------------+ ,-( _)-.
.-(_ IPv6 )-.
(__ EUN )
`-(______)-'
+-------+------+
| Node D |
+--------------+Figure 2: More Specific Route Following Redirection
This traditional redirection can be a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection can cause operational issues on certain link types and/or in certain deployment scenarios 😬
Here's the tea. When an ingress link neighbor accepts an ordinary redirection control message, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without going through an intermediate router. And the egress has no way of knowing that the ingress is allowed to forward packets from the network-layer source address it's claiming. (This matters a lot on very large links, because any node on the link can spoof the network-layer source address with a low chance of being caught, even if the link-layer source address can't be spoofed.) On top of that, the ingress has no way of knowing whether the direct path to the egress has failed, or whether the final destination has moved away from the egress to some other network attachment point. Yikes 💀
So a new approach is needed, one that can send redirection signaling from the egress to the ingress link node under the mediation of a trusted intermediate router. The mechanism is asymmetric (only the forward direction, from the ingress to the egress, gets optimized) and extended (the redirection extends forward to the egress before it reaches back to the ingress). This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. It's giving main character energy 💜
While the AERO mechanisms were first designed for NBMA tunnel virtual interfaces (e.g., see [RFC2529], [RFC5214], [RFC5569], and [VET]), they can also be applied to any multiple access link types that support redirection. The AERO techniques are discussed here with reference to IPv6 [RFC2460][RFC4861][RFC4862][RFC3315]. They can also be applied to any other network-layer protocol (e.g., IPv4 [RFC0791][RFC0792][RFC2131], etc.) that provides a redirection service. Details of how other network-layer protocols operate are out of scope 🌈
This document is an Experimental RFC, so it doesn't try to set a new standard for the Internet. Experimental status was used instead of Standards Track because the document proposes a new and different dynamic routing mechanism. Experimentation will focus on candidate multi-access link types that can connect large numbers of neighboring nodes, where using existing dynamic routing protocols may be impractical. Examples include NBMA tunnel virtual links, large bridged campus LANs, etc. 🫶
To be continued in part 2 🎀
2. Terminology ✨
okay so the normative references have their own terminology and that applies here too, but this doc defines a few extra terms just for AERO 💅
AERO link any link (either physical or virtual) that the AERO mechanisms can be applied to 🦋 (like a virtual overlay of tunnels can totally serve as an AERO link)
AERO interface a node's attachment to an AERO link 🔗
AERO node a router or host that's connected to an AERO link and participates in the AERO protocol on that link 🫶
intermediate AERO router ("intermediate router") a router that configures an advertising router interface on an AERO link. It can provide default forwarding and redirection services for other AERO nodes, so it's basically the main character of the link 👑
edge AERO router ("edge router") a router that configures a non-advertising router interface on an AERO link. Through it, End User Networks (EUNs) can connect to the AERO link 🌸
AERO host a simple host on an AERO link 🧚
ingress AERO node ("ingress node") a node that injects packets into an AERO link 🍓
egress AERO node ("egress node") a node that receives packets from an AERO link 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official BCP 14 vibes, so read them exactly as the spec intends 🙈
3. Motivation
okay bestie, so AERO was built to be an on-demand route optimization function for nodes sitting on one multi-access link. It's kind of like the standard IPv6 redirection mechanism that runs on ICMPv6 messages [RFC4443][RFC4861] 🎀 BUT here's the twist: the target of the redirection first gets a pre-authorization notification, and only then does it send route optimization info back to the source of the original packet. ✨
Now this raises a fair question: why not just use a standard dynamic routing protocol instead? ngl, a bunch of reasons say standard routing protocols are kinda bad fits for the use cases AERO was made for 💀
First, AERO is designed to work on very large multiple access links that might connect a mix of many thousands of routers and hosts. Traditional proactive dynamic routing protocols like OSPF, IS-IS, RIP, OLSR (Optimized Link State Routing), and TBRPF (Topology Dissemination Based on Reverse-Path Forwarding) can be inefficient in that kind of setup. The reason is control message overhead, which scales up when there are lots of routers and/or when link capacity is low. Overhead heavy, no thank you 😭
Second, AERO works on-demand of data packet arrival, but it only tries to discover neighbors on the same link. It doesn't look for distant nodes that might be many link hops away. Reactive dynamic routing protocols like Ad hoc On-Demand Distance Vector (AODV) and Dynamic Source Routing (DSR) are on-demand too, but they flood specialized route discovery messages. Those reach every node on the link and might even travel across multiple link hops before a route reply comes back. That needs a multicast-capable network, and it doesn't guarantee the original data packet gets delivered, since it can be dropped or delayed during route discovery. Yikes 🙃
Additionally, AERO is designed to override an existing route to a destination when that route sends traffic along a sub-optimal path through an extraneous router on the shared link. AERO nodes keep sending data packets over a preexisting working route, and they may later receive notice of a better route based on route optimization feedback from a trusted on-link neighbor. This is different from on-demand routing protocols, which are built for when no preexisting working route exists. Those protocols multicast explicit route request messages to get a route reply, instead of just unicast-forwarding the data packet over a route that already works 💅
Finally, AERO needs less control message and/or processing overhead than standard dynamic routing protocols on links where each router has to maintain far fewer routes than the total number of routers on the link, and where those routes may change over time. For example, on a link that connects N nodes, each node will often only talk to a small number of link neighbors, and that set of neighbors may shift dynamically. So the number of active neighbor pairs on the link is V*N (where V is a small variable number) instead of N**2. This matters a LOT on very large links, like when N is 1,000 or more 🌈
4. Example Use Cases
AERO was designed to satisfy a bunch of operational use cases, so let's look at a few 🦋
Example one: the airline. A hypothetical major airline has deployed an overlay network on top of the global Internet to track the aircraft in its fleet. The global Internet is basically the "link" the overlay network is configured over. Each aircraft is a mobile router that fronts for an internal network full of devices the airline controls and monitors. But it would be impractical for each aircraft to track the changing locations of every other aircraft in the fleet, because the control message overhead would hit limited capacity communication links hard ✈️
Here's how it plays out. An aircraft ('A') is en route to its destination and needs to report its ETA and share passenger itineraries with other en route aircraft that will be servicing passenger connections. 'A' knows the overlay network addresses of those other aircraft, but it doesn't know their current underlay address mappings. So 'A' sends its initial messages to them via an airline central dispatch router ('D'), which might be located really far away. 'D' forwards the messages, but it also kicks off the AERO redirection procedure so the traffic can step out of that triangular path and allow direct aircraft-to-aircraft communication. Triangle path? Not in this house 🙅♀️
Example two: MANETs. Mobile Ad hoc Networks (MANETs) are often deployed in environments with a high degree of mobility, attrition, and very limited wireless communications link bandwidth. These environments also typically need network-layer security mechanisms that treat the MANET as a "link" over which encrypted messages get forwarded in an overlay network. In that setup, a dynamic routing protocol running in the overlay network could add unacceptable congestion to wireless links that are already overtaxed. So instead, the AERO route optimization mechanism can cut out costly extraneous routing hops without adding any extra control message overhead 🫶
Example three: the campus. A large campus LAN joined by Layer 2 (L2) bridges can connect many thousands of routers and hosts that look like they share a single common multi-access link. In that case, the AERO mechanisms can handle the intra-link route optimization functions without needing an adjunct dynamic routing protocol, which might be inefficient for the reasons mentioned above 🎓
5. Requirements
the route optimization mechanism has to hit the following requirements, no exceptions 👑
- Req 1: Off-load traffic from performance-critical gateways. The mechanism must offload sustained transit through an intermediate AERO router that would otherwise become a traffic concentrator. Nobody wants a gateway getting cooked 🔥
- Req 2: Support route optimization. The ingress AERO node should be able to send packets directly to the egress node, without forwarding through an intermediate router for route optimization purposes. Direct delivery era 💖
- Req 3: Support scaling. For scaling purposes, support interworking and control message forwarding between multiple intermediate routers (see Appendix A). Teamwork makes the dream work 🌈
- Req 4: Do not circumvent ingress filtering. The mechanism must not open an attack vector where network-layer source address spoofing is enabled, even when link-layer source address spoofing is disabled. Absolutely not, that's a huge red flag 🚩
- Req 5: Do not expose packets to loss due to filtering. The ingress AERO node must have a way of knowing that the egress AERO node will accept its forwarded packets. Confirm the vibe before you send ✨
- Req 6: Do not expose packets to loss due to path failure. The ingress AERO node must have a way of discovering whether the AERO egress node has gone unreachable on the route optimized path. Gotta know when the path ghosts you 👻
- Req 7: Do not introduce routing loops. Intermediate routers must not invoke a route optimization that would cause a routing loop to form. Loops are a whole no 🙅♀️
- Req 8: Support mobility. The mechanism must continue to work even if the final destination node/network moves from a first egress node and re-associates with a second egress node. Mobility is a main character trait 🦋
- Req 9: Support link layer address changes. The mechanism must continue to work even if the Layer 2 addresses of ingress and/or egress AERO nodes change. Addresses change, we move on 💅
- Req 10: Support network renumbering. The mechanism must provide graceful transition when an AERO node's attached EUN is renumbered. Smooth transitions only, periodt 🌸
6. Asymmetric Extended Route Optimization (AERO)
okay so the following sections specify an Asymmetric Extended Route Optimization (AERO) capability that fulfills the requirements specified in Section 5. Here's the main event 🎀
6.1. AERO Link Dynamic Routing
in a lot of AERO link scenarios (like small enterprise networks, small and stable MANETs, and so on), routers can run a traditional dynamic routing protocol. That way their routing/forwarding tables get populated and standard forwarding between routers can be used. In other scenarios (like large enterprise/ISP networks, cellular service provider networks, dynamic MANETs, and so on), that might be impractical because of routing protocol control message scaling issues 😩
when a traditional dynamic routing protocol can't be used, the mechanisms in this section can provide a useful on-demand route discovery capability ✨ And if traditional dynamic routing protocols and the AERO mechanism are both active on the same link, routes discovered by the dynamic routing protocol should take precedence over those discovered by AERO. Dynamic routing gets the VIP seat 👑
6.2. AERO Node Behavior
the following sections discuss characteristics of nodes attached to links over which AERO can be used 🧚
6.2.1. AERO Node Types
intermediate AERO routers configure their AERO link interfaces as advertising router interfaces (see [RFC4861], Section 6.2.2). Therefore, they may send Router Advertisement (RA) messages that include non-zero Router Lifetimes. Main character behavior 🌟
edge AERO routers configure their AERO link interfaces as non-advertising router interfaces. Quiet but still essential 🫶
AERO hosts configure their AERO link interfaces as simple host interfaces. Simple, but iconic 💖
6.2.2. AERO Host Behavior
AERO hosts observe the IPv6 host requirements defined in [RFC6434], except that AERO hosts also engage in the AERO route optimization procedure as specified in Section 6.4. So they follow the usual IPv6 host rules, plus the AERO route optimization on top 💅
6.2.3. Edge AERO Router Behavior 💅
okay so edge AERO routers follow the IPv6 router requirements from [RFC6434], but with a twist 🎀 on their non-advertising AERO link router interfaces they act as "hosts", the same way IPv6 Customer Premises Equipment (CPE) routers do [RFC6204]. this is how they get managed prefix delegations that an intermediate router has aggregated. they can grab those through DHCPv6 Prefix Delegation [RFC3633], administrative configuration, etc. ✨
once the edge router has its prefixes, it sub-delegates them to nodes and links inside its attached EUNs 🌸 then any outbound packets from those EUNs get forwarded through the intermediate router. the edge router also runs the AERO route optimization procedure from Section 6.4, so it's not sleeping on that either 💖
6.2.4. Intermediate AERO Router Behavior 🦋
intermediate AERO routers follow the IPv6 router requirements in [RFC6434] too 🧚 they answer Router Solicitation (RS) messages from AERO hosts and edge routers on their advertising AERO link router interfaces by sending back an RA message. they also set up a DHCP relay/server function on their AERO links and/or provide an administrative interface for delegating network-layer addresses and prefixes. main character energy 👑
when the intermediate router finishes a stateful network-layer address or prefix delegation (like acting as a DHCPv6 relay/server), it creates forwarding table entries. these entries list the link-layer address of the client AERO node as the link-layer address of the next hop toward the delegated network-layer addresses/prefixes. it's giving organized 🍓
and when the intermediate router forwards a packet back out the same AERO interface it arrived on, it kicks off an AERO route optimization procedure from Section 6.4. ⭐
6.3. AERO Reference Operational Scenario 🌈
okay, Figure 3 shows the AERO reference operational scenario 😭 it has an intermediate AERO router ('A'), two edge AERO routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts ('C', 'E', 'G'). ✨
.-(::::::::)
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::)--| Host G |
`-(::::::::::::)-' +-------------+
`-(::::::)-' 2001:db8:3::1
|
+--------------+ +--------------+
| Intermediate | | AERO Host F |
| AERO Router A| | (default->A) |
| (C->B; E->D) | +--------------+
+--------------+ 2001:db8:2:1
L3(A) L3(F)
L3(A) L2(F)
| |
X-----+-----------+-----------+-----------+---X
| AERO Link |
L2(B) L2(D)
L3(B) L3(D)
+--------------+ +--------------+ .-.
| AERO Edge | | AERO Edge | ,-( _)-.
| Router B | | Router D | .-(_ IPv6 )-.
| (default->A) | | (default->A) |--(__ EUN )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | Host E |
.-(_ IPv6 )-. +-------------+ +-------------+
(__ EUN )--| Host C |
`-(______)-' +-------------+Figure 3: AERO Reference Operational Scenario
so in Figure 3, the intermediate AERO router ('A') hooks up to the AERO link and also connects to the IPv6 Internet, either directly or through other IPv6 routers (not drawn) 🫶 'A' sets up an AERO link interface with a link-local network-layer address L3(A) and a link-layer address L2(A). then it adds L2(A) to a published list of valid intermediate routers for the link. ✨
AERO node ('B') is an edge router connected to the AERO link through an interface with link-local network-layer address L3(B) and link-layer address L2(B) 💜 'B' sets a default route whose next-hop network-layer address is L3(A) via the AERO interface, and it gives the prefix 2001:db8:0::/48 to its attached EUN link. IPv6 host ('C') joins that EUN and configures the network-layer address 2001:db8:0::1 🎀
AERO node ('D') is also an edge router, connected to the AERO link with link-local network-layer address L3(D) and link-layer address L2(D) 🌸 'D' sets a default route with next-hop network-layer address L3(A) via the AERO interface, and it assigns the prefix 2001:db8:1::/48 to its attached EUN link. IPv6 host ('E') attaches to the EUN and configures the network-layer address 2001:db8:1::1 🧚
AERO host ('F') connects to the AERO link through an interface with link-local network-layer address L3(F) and link-layer address L2(F) 🦋 'F' sets a default route with next-hop network-layer address L3(A) via the AERO interface, and it assigns the network-layer address 2001:db8:2::1 to the AERO interface. 💅
last but not least, IPv6 host ('G') is outside the AERO link domain, connected to some other IPv6 network 🌈 'G' configures its IPv6 interface however its attached IPv6 link needs, and it assigns the network-layer address 2001:db8:3::1 to that link interface. 🍓
okay, here's the important bit 😭 the intermediate AERO router ('A') has to keep state that ties the delegated network-layer addresses/prefixes to the link-local network-layer addresses of the right edge routers and/or hosts on the AERO link. the nodes, in turn, must keep at least a default route pointing at 'A', and they can discover more-specific routes either through a proactive dynamic routing protocol or through the AERO mechanisms in Section 6.4. ✨
6.4. AERO Specification 💖
Section 6.3 describes the AERO reference operational scenario 🎀 now we get into how AERO actually works and its protocol details, using that same scenario as our reference.
6.4.1. Traditional Redirection Approaches 🦋
so, looking at Figure 3, when the IPv6 source host ('C') sends a packet to the IPv6 destination host ('E'), the packet first gets forwarded over the EUN to the ingress AERO node ('B') 🌸 the ingress node ('B') then forwards it over its AERO interface to the intermediate router ('A'), which forwards it on to the egress AERO node ('D'). finally, 'D' forwards the packet to the IPv6 destination host ('E') 💜 when 'A' forwards the packet back out on its advertising AERO interface, it must arrange to redirect the ingress node ('B') toward the egress node ('D') as a better next-hop node on the AERO link, one that's closer to the final destination. but this redirection should only happen if there's assurance that both the ingress and egress nodes are willing participants. no cap, that's a big if 🫶
let's look at a first alternative, where 'A' only tells the ingress node ('B') and does not tell the egress node ('D') (aka "traditional redirection") 💀 in that case, the egress node has no way of knowing the ingress is allowed to forward packets using their claimed source network-layer addresses, so it might just drop the packets 😭 the ingress also has no way of knowing whether the egress is doing some kind of source address filtering that would reject packets from any node other than a trusted default router. it can't even tell whether the egress is reachable through a direct path that doesn't go through the intermediate router. and finally, the ingress has no idea whether the final destination has moved away from the egress node 🙈
now a second alternative, where 'A' tells both the ingress node ('B') and the egress node ('D') separately, using independent redirection control messages (aka "augmented redirection") 🔥 this can go wrong in a few ways. first, if the ingress gets the redirection control message but the egress doesn't, later packets from the ingress could be dropped by filtering, because the egress wouldn't have neighbor state to verify their source network-layer addresses 💅 second, if the egress gets the message but the ingress doesn't, packets going the other way from the egress would get lost 🥺 and finally, the timing around setting up and garbage collecting neighbor state at the ingress and egress can lead to unpredictable behavior. unless the timing is carefully coordinated through some kind of synchronization loop, there will always be times when one node has the correct neighbor state and the other doesn't, which means non-deterministic packet loss 💀
since neither alternative can meet the requirements listed in Section 5, we need a new redirection technique, called "AERO redirection" ✨👑
6.4.2. AERO Concept of Operations ✨
okay so, AERO redirection is only used on links where the traditional redirection approaches from Section 6.4.1 are insufficient to satisfy all requirements 💅 those old methods just aren't cutting it for everything, so we need this new approach. let's walk through how it's giving 🦋
again, looking at Figure 3, when source host ('C') sends a packet to destination host ('E'), the packet first goes over the source host's attached EUN to ingress node ('B'). then ingress node ('B') forwards it through its AERO interface to intermediate router ('A') 🌸
now here's where it gets iconic. using AERO redirection, intermediate router ('A') forwards the packet out the same AERO interface toward egress node ('D') 🔥 and it also sends an AERO "Predirect" message forward to the egress node, as specified in Section 6.4.6. the Predirect message includes the identity of ingress node ('B'), plus info that egress node ('D') can use to figure out the longest-match prefixes covering the source and destination network-layer addresses of the packet that triggered the predirection event 🧚 once egress node ('D') gets the Predirect message, it processes it and sends back an AERO Redirect message to intermediate router ('A'), as specified in Section 6.4.7. (while it's doing that, it also creates or updates neighbor state for ingress node ('B'), and keeps this (src, dst) "prefix pair" as ingress filtering info, so it can accept future packets using addresses matched by the prefixes from ingress node ('B') 🫶)
when intermediate router ('A') gets the AERO Redirect message, it processes it and forwards it on to ingress node ('B'), as specified in Section 6.4.8 💖 the message includes the identity of egress node ('D') and info that ingress node ('B') can use to find the longest-match prefixes covering the source and destination network-layer addresses of the packet that triggered the redirection event. after ingress node ('B') receives the AERO Redirect message, it processes it as specified in Section 6.4.9. (during that, it also creates or updates neighbor state for egress node ('D'), and keeps this prefix pair as forwarding info, so future packets using addresses matched by those prefixes can go to egress node ('D') ✨)
so after this whole AERO Predirect/Redirect message exchange, forwarding of packets whose source and destination network-layer addresses are covered by the longest-match prefix pair is turned on in the forward direction, from ingress node ('B') to egress node ('D') 👑 the mechanisms that make this exchange work are specified in the sections that follow. no cap, it's a whole production 🎀
6.4.3. Conceptual Data Structures and Protocol Constants
every AERO node keeps a per-AERO interface conceptual neighbor cache. it has an entry for each neighbor it talks to on the AERO link, same as for any IPv6 interface (see [RFC4861]) 🌈
each AERO interface neighbor cache entry also keeps two lists of (src, dst) prefix pairs. the AERO node adds a prefix pair to the ACCEPT list if a trusted intermediate router has told it that it's safe to accept packets from the neighbor using network-layer source and destination addresses covered by that prefix pair 🍓 the AERO node adds a prefix pair to the FORWARD list if a trusted intermediate router has told it that it's allowed to forward packets to the neighbor using network-layer addresses covered by that prefix pair 💜
when the node adds a prefix pair to an ACCEPT list in a neighbor cache entry, it also starts an expiration timer for that prefix pair, set to ACCEPT_TIME seconds ⏰ when the node adds a prefix pair to a FORWARD list, it starts an expiration timer set to FORWARD_TIME seconds. the node also keeps a keepalive interval, KEEPALIVE_TIME, which limits how many keepalive control messages get sent. and finally, the node keeps a constant, MAX_RETRY, which limits how many keepalives get sent when a neighbor has gone unreachable 😭
it is RECOMMENDED that FORWARD_TIME be set to the default constant value 30 seconds, to match the default REACHABLE_TIME value specified for IPv6 neighbor discovery [RFC4861] ✨
it is RECOMMENDED that ACCEPT_TIME be set to the default constant value 40 seconds. that gives a 10 second window so the AERO redirection procedure can converge before the ACCEPT_TIME timer drops below FORWARD_TIME 🦋
it is RECOMMENDED that KEEPALIVE_TIME be set to the default constant value 5 seconds, to provide timely reachability verification without causing excessive control message overhead 🫶
it is RECOMMENDED that MAX_RETRY be set to 3, the same as described for IPv6 neighbor discovery address resolution in Section 7.3.3 of [RFC4861] 🔥
different values for FORWARD_TIME, ACCEPT_TIME, KEEPALIVE_TIME, and MAX_RETRY MAY be set administratively, if necessary, to better match the AERO link's performance characteristics. BUT, if you pick different values, all nodes on the link MUST consistently configure the same values 🙈 ACCEPT_TIME SHOULD also be set to a value that's sufficiently longer than FORWARD time, so the AERO redirection procedure has room to converge 💅
6.4.4. Data Origin Authentication
AERO nodes MUST employ a data origin authentication check on the packets they receive on an AERO interface. specifically, the node considers the network-layer source address correct for the link-layer source address if at least one of the following is true: 🔐
- the network-layer source address is an on-link address that embeds the link-layer source address, or
- the network-layer source address is explicitly linked to the link-layer source address through per-neighbor state, or
- the link-layer source address is the address of a trusted intermediate AERO router.
when the AERO node receives a packet on an AERO interface, it processes the packet further if it satisfies one of these data origin authentication conditions. otherwise, it drops the packet 🚫
⚠️ heads up, bestie: on links where link-layer address spoofing is possible, AERO nodes may need additional securing mechanisms. to deal with this, future work will define a strong data origin authentication scheme, such as using digital signatures 🥺
6.4.5. AERO Redirection Message Format
AERO Redirect/Predirect messages use the same format as the ICMPv6 Redirect messages shown in Section 4.5 of [RFC4861]. the difference is that they get encapsulated in a UDP header [RFC0768], so they can be told apart from ordinary ICMPv6 Redirect messages 🎀 that means AERO Redirect messages need a brand new UDP service port number, AERO_PORT 🧚
AERO Redirect/Predirect messages are formatted as shown in Figure 4 🌸
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (=0) | Code (=0) | Checksum (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: AERO Redirect/Predirect Message Formatthe AERO Redirect/Predirect message sender sets the 'Type' field to 0, since this isn't an actual ICMPv6 message 🙃 it also sets the 'Checksum' field to 0, since the UDP checksum covers the entire packet and does the protecting 🔒 the sender sets the 'P' bit to 1 if this is a 'Predirect' message, and sets the 'P' bit to 0 if this is a 'Redirect' message (as described below) 🦋
next, the sender wraps the AERO Redirect message in IP/UDP headers, as shown in Figure 5 🎀
+--------------------+
~ IP header ~
+--------------------+
~ UDP header ~
+--------------------+
| |
~ AERO Redirect ~
~ Message ~
| |
+--------------------+
Figure 5: AERO Message UDP Encapsulation Formatthe AERO Redirect/Predirect message sender sets the UDP destination port number to AERO_PORT and sets the UDP source port number to a (pseudo-)random value 🎲 it then sets the UDP length field to the length of the UDP message, and calculates the checksum across the message and writes it into the UDP checksum field 💖 last, the sender sets the IP TTL/Hop-limit field to a small integer value, picked to provide a quick exit from any temporal routing loops 🌀
it is RECOMMENDED that the sender set IP TTL/Hop-limit to the value 8, unless it has better knowledge of the AERO link characteristics ✨
6.4.6. Sending Predirects ✨
Okay bestie, so when an intermediate AERO router forwards a packet out the same AERO interface it arrived on, it doesn't send an ICMPv6 Redirect back to the ingress node. Instead, it sends an AERO Predirect message forward toward the egress AERO node 💅🦋
In the reference operational scenario, when the intermediate router (A) forwards a packet from the ingress node (B) toward the egress node (D), it also sends an AERO Predirect message forward toward the egress, subject to rate limiting (see Section 8.2 of [RFC4861]). Here's how the intermediate router (A) builds that Predirect 🎀
- the link-layer source address is set to
L2(A)(i.e., the link-layer address of the intermediate router). - the link-layer destination address is set to
L2(D)(i.e., the link-layer address of the egress node). - the network-layer source address is set to
L3(A)(i.e., the link-local network-layer address of the intermediate router). - the network-layer destination address is set to
L3(D)(i.e., the link-local network-layer address of the egress node). - the UDP destination port is set to
AERO_PORT. - the Target and Destination Addresses are both set to
L3(B)(i.e., the link-local network-layer address of the ingress node). - on links that require stateful address mapping, the message includes a Target Link Layer Address Option (TLLAO) set to
L2(B)(i.e., the link-layer address of the ingress node). - the message includes a Route Information Option (RIO) [RFC4191] that encodes the ingress node's network-layer address/prefix delegation that covers the network-layer source address of the originating packet.
- the message includes a Redirected Header Option (RHO) that contains the originating packet truncated to ensure that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
- the
Pbit is set toP=1.
Then the intermediate router (A) sends the message forward to the egress node (D) 🚀
6.4.7. Processing Predirects and Sending Redirects 🔥
When the egress node (D) receives an AERO Predirect message, it only accepts it if it satisfies the data origin authentication requirements specified in Section 6.4.4. It also only accepts the message if it's willing to serve as a redirection target 🫶
Next, the egress node (D) validates the message using the ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861], with one exception: the message includes a Type value of 0, a Checksum value of 0, and a link-local address in the ICMP destination field that differs from the destination address of the packet header encapsulated in the RHO.
In the reference operational scenario, when the egress node (D) receives a valid AERO Predirect message, it either creates or updates a neighbor cache entry that stores the Target address of the message (i.e., the link-local network-layer address of the ingress node (B)). The egress node (D) then records the prefix found in the RIO, along with its own prefix that matches the network-layer destination address in the packet header found in the RHO, as an acceptable (src, dst) prefix pair in that neighbor cache entry. It adds the prefix pair to the neighbor cache entry ACCEPT list and sets or resets an expiration timer for the prefix pair to ACCEPT_TIME seconds. If the timer later expires, the egress node (D) deletes the prefix pair 🧚
After processing the message, the egress node (D) prepares an AERO Redirect message response like this:
- the link-layer source address is set to
L2(D)(i.e., the link-layer address of the egress node). - the link-layer destination address is set to
L2(A)(i.e., the link-layer address of the intermediate router). - the network-layer source address is set to
L3(D)(i.e., the link-local network-layer address of the egress node). - the network-layer destination address is set to
L3(B)(i.e., the link-local network-layer address of the ingress node). - the UDP destination port is set to
AERO_PORT. - the Target and the Destination Addresses are both set to
L3(D)(i.e., the link-local network-layer address of the egress node). - on links that require stateful address mapping, the message includes a Target Link Layer Address Option (TLLAO) set to
L2(D). - the message includes an RIO that encodes the egress node's network-layer address/prefix delegation that covers the network-layer destination address of the originating packet.
- the message includes as much of the RHO copied from the corresponding AERO Predirect message as possible, such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
- the
Pbit is set toP=0.
After the egress node (D) prepares the AERO Redirect message, it sends the message to the intermediate router (A) 💜
6.4.8. Forwarding Redirects 🌸
When the intermediate router (A) receives an AERO Redirect message, it only accepts it if it satisfies the data origin authentication requirements specified in Section 6.4.4. Next, the intermediate router (A) validates the message the same way as described in Section 6.4.7. After validation, it processes the Redirect and then forwards a corresponding Redirect on to the ingress node (B), as follows 👑
In the reference operational scenario, the intermediate router (A) receives the AERO Redirect message from the egress node (D) and gets ready to forward a corresponding AERO Redirect message to the ingress node (B). The intermediate router (A) then verifies that the RIO encodes a network-layer address/prefix that the egress node (D) is authorized to use, and it discards the message if that verification fails. Otherwise, the intermediate router (A) changes the link-layer source address of the message to L2(A), changes the network-layer source address of the message to the link-local network-layer address L3(A), and changes the link-layer destination address to L2(B). Last but not least, the intermediate router (A) decrements the IP TTL/Hop-limit and forwards the message to the ingress node (B) 🦋
6.4.9. Processing Redirects ✨
When the ingress node (B) receives an AERO Redirect message (i.e., one with P=0), it only accepts it if it satisfies the data origin authentication requirements specified in Section 6.4.4. Next, the ingress node (B) validates the message the same way as described in Section 6.4.6. After validation, the ingress node (B) processes the message as follows 🎀
In the reference operational scenario, when the ingress node (B) receives the AERO Redirect message, it either creates or updates a neighbor cache entry that stores the Target address of the message (i.e., the link-local network-layer address of the egress node L3(D)). The ingress node (B) then records the (src, dst) prefix pair associated with the triggering packet in the neighbor cache entry FORWARD list. In other words, it records its prefix that matches the redirected packet's network-layer source address, together with the prefix listed in the RIO, as the prefix pair. It then sets or resets an expiration timer for the prefix pair to FORWARD_TIME seconds. If the timer later expires, the ingress node (B) deletes the entry 🌈
Now, the ingress node (B) has a neighbor cache FORWARD list entry for the prefix pair, and the egress node (D) has a neighbor cache ACCEPT list entry for the prefix pair. So, the ingress node (B) may forward ordinary network-layer data packets, whose network-layer source and destination addresses match the prefix pair, directly to the egress node (D) without forwarding them through the intermediate router (A). Note that the ingress node must have a way of informing the network layer of a route that associates the destination prefix with this neighbor cache entry. The manner of establishing such a route (and deleting it when it is no longer necessary) is left to the implementation 🧠
To enable packet forwarding in the reverse direction, a separate AERO redirection operation is required. It's the mirror image of the forward operation described above, but the link segments traversed in the forward and reverse directions may be different, i.e., the operations are asymmetric 🔄
6.4.10. Sending Periodic Predirect Keepalives ✨
Okay so, to stop prefix pairs from expiring while data is actively flowing, the ingress node ('B') can send AERO Predirect messages straight to the egress node ('D') as a "keepalive" to solicit AERO Redirect messages 💅. The node should only send these when a data packet covered by the prefix pair has been sent recently, and it should wait at least KEEPALIVE_TIME seconds between each keepalive so it doesn't spam control messages 🫶.
In the reference operational scenario, when the ingress node ('B') needs to refresh the FORWARD timer for a specific prefix pair, it can send an AERO Predirect message directly to the egress node ('D'), prepared like this 🎀:
- the link-layer source address is set to
L2(B)(i.e., the link-layer address of the ingress node). - the link-layer destination address is set to
L2(D)(i.e., the link-layer address of the egress node). - the network-layer source address is set to
L3(B)(i.e., the link-local network-layer address of the ingress node). - the network-layer destination address is set to
L3(D)(i.e., the link-local network-layer address of the egress node). - the UDP destination port is set to
AERO_PORT. - the Predirect Target and Destination Addresses are both set to
L3(B)(i.e., the link-local network-layer address of the ingress node). - the message includes an RHO that contains the originating packet truncated so that at least the network-layer header is included, but the size of the message does not exceed 1280 bytes.
- the 'P' bit is set to P=1.
When the egress node ('D') receives the AERO Predirect message, it validates it the same way as described in Section 6.4.6. After validation, the egress node ('D') resets its ACCEPT timer for the prefix pair that matches the originating packet's network-layer source and destination addresses to ACCEPT_TIME seconds 🦋. It then sends an AERO Redirect message directly to the ingress node ('B'), prepared like this:
- the link-layer source address is set to
L2(D)(i.e., the link-layer address of the egress node). - the link-layer destination address is set to
L2(B)(i.e., the link-layer address of the ingress node). - the network-layer source address is set to
L3(D)(i.e., the link-local network-layer address of the egress node). - the network-layer destination address is set to
L3(B)(i.e., the link-local network-layer address of the ingress node). - the UDP destination port is set to
AERO_PORT. - the Redirect Target and Destination Addresses are both set to
L3(D)(i.e., the link-local network-layer address of the egress node). - the message includes as much of the RHO copied from the corresponding AERO Predirect message as possible, such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
- the 'P' bit is set to P=0.
When the ingress node ('B') receives the AERO Redirect message, it validates it the same way as described in Section 6.4.6. After validation, the ingress node ('B') resets its FORWARD timer for the prefix pair that matches the originating packet's network-layer source and destination addresses to FORWARD_TIME seconds 🌸.
Here's the tea 🍵: if the ingress node sends MAX_RETRY AERO Predirect keepalives without getting an AERO Redirect reply, it can either declare the prefix pair unreachable right away or let the pair expire after FORWARD_TIME seconds 💀.
6.4.11. Neighbor Reachability Considerations 🧚
So when the ingress node ('B') gets an AERO Redirect message telling it about a direct path to a new egress node ('D'), the question is whether that new egress node can actually be reached directly, without going through an intermediate router ('A') 🤔. On some AERO links, it's reasonable for the ingress node ('B') to (optimistically) assume reachability is transitive, and to start forwarding data packets to the egress node ('D') right away without testing it first.
On AERO links where that optimistic assumption would be unreasonable, though, the ingress node ('B') can hold off on the redirection until it tests the direct path to the egress node ('D'). For example, it can send an IPv6 Neighbor Solicitation to get an IPv6 Neighbor Advertisement back 🔍. If the ingress node ('B') still can't get a response after MAX_RETRY attempts, it should consider the direct path to the egress node ('D') unusable 🙈.
Either way, the ingress node ('B') can treat any link errors from data packets sent directly to the egress node ('D') as a hint that the direct path has failed or become intermittent ⚠️. On the flip side, any AERO Redirect messages it receives can be used as evidence that the neighbor is reachable 💜.
6.4.12. Mobility Considerations 🦋
Again, with reference to Figure 3, the egress node ('D') can configure both a non-advertising router interface on a provider AERO link and advertising router interfaces on its connected EUN links. When an EUN node ('E') in one of the egress node's connected EUNs moves to a different network point of attachment, though, it can release its network-layer address/prefix delegations that were registered with the egress node ('D') and re-establish them via a different router 🚶♀️.
When the EUN node ('E') releases its network-layer address/prefix delegations, the egress node ('D') marks its forwarding table entries for those addresses/prefixes as "departed" and stops responding to AERO Predirect messages for them. When the egress node ('D') gets packets from an ingress node ('B') whose network-layer source and destination addresses match a prefix pair on the ACCEPT list, it forwards them to the last-known link-layer address of the EUN node ('E'). This helps avoid mobility-related packet loss during routing changes 🙌. The egress node ('D') also returns a NULL AERO Redirect message to tell the ingress node ('B') about the departure. It's prepared like this:
- the link-layer source address is set to
L2(D). - the link-layer destination address is set to
L2(B). - the network-layer source address is set to the link-local address
L3(D). - the network-layer destination address is set to the link-local address
L3(B). - the UDP destination port is set to
AERO_PORT. - the Redirect Target and Destination Addresses are both set to NULL.
- the message includes an RHO that contains as much of the original packet as possible, such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
- the 'P' bit is set to P=0.
When the ingress node ('B') receives the NULL AERO Redirect message, it deletes the prefix pair associated with the packet in the RHO from its list of forwarding entries for the egress node ('D'). When the egress node ('D')'s ACCEPT_TIME timer for the prefix pair matching the departed prefix expires, it deletes those prefix pairs from its list of ingress filtering entries for the ingress node ('B') 🧹.
Eventually, any correspondent AERO nodes will get a NULL AERO Redirect message and stop using the egress node ('D') as a next hop. They'll go back to sending packets for the EUN node ('E') via a trusted intermediate router, and they may later receive new AERO Redirect messages showing that the EUN node ('E') is now associated with a new AERO edge router 🗺️.
Note that any packets the egress node ('D') forwards via a departed forwarding table entry may be lost if the (mobile) EUN node ('E') moves off-link with respect to its previous EUN point of attachment 😬. This shouldn't be a problem for large links (e.g., large cellular network deployments, large ISP networks, etc.) where all or most mobility events happen within the same link 🌈.
6.4.13. Link-Layer Address Change Considerations 🔄
When an ingress node needs to change its link-layer address, it deletes each FORWARD list entry that was set up under the old link-layer address, changes the link-layer address, and then lets packets flow through an intermediate router again 🫠. Any egress node that receives those packets will also get new AERO Predirect messages from the intermediate router. The egress node then deletes the ACCEPT entry that included the ingress node's old link-layer address and installs a new ACCEPT entry with the ingress node's new link-layer address. After that, the egress returns a new AERO Redirect message to the ingress node via the intermediate router, and the ingress node uses it to set up a new FORWARD list entry 🎉.
When an egress node needs to change its link-layer address, it deletes each entry in the ACCEPT list and SHOULD also send NULL AERO Redirect messages to the corresponding ingress nodes (i.e., the same as described for mobility operations in Section 6.4.12) before changing the link-layer address 🚨. Any ingress node that receives the NULL AERO Redirect messages deletes its corresponding FORWARD list entries and lets packets flow through an intermediate router again. The egress node then changes its link-layer address and sends new AERO Redirect messages in response to any AERO Predirect messages it receives from the intermediate router while using the new link-layer address 💖.
6.4.14. Prefix Re-provisioning Considerations 🧁
When an AERO node configures one or more FORWARD/ACCEPT list prefix pair entries, and the prefixes in the pair are reconfigured or renumbered somehow, the stale FORWARD/ACCEPT list information must be deleted 🗑️.
When an ingress node ('B') reconfigures its network-layer source prefix in a way that makes the ACCEPT list entry in the egress node ('D') no longer valid (e.g., the prefix length of the source prefix changes), the ingress node ('B') simply deletes the prefix pair from its FORWARD list and lets subsequent packets flow through an intermediate router ('A') again 🙃.
When the egress node ('D') reconfigures its network-layer destination prefix in a way that makes the FORWARD list entry in the ingress node ('B') no longer valid, the egress node ('D') sends a NULL AERO Redirect message to the ingress node ('B'). This is the same as described for mobility and link-layer address change considerations, and it happens when the egress node receives either an AERO Predirect message or a data packet from the ingress node ('B') (subject to rate limiting) 🚦.
6.4.15. Backward Compatibility 🎀
There are no backward compatibility considerations, since AERO Redirect/Predirect messages use a new UDP port number that distinguishes them from other kinds of control messages. That means legacy nodes will simply discard any AERO Redirect/Predirect messages they may accidentally receive 🙅♀️.
Note however that AERO redirection requires all three (the ingress, intermediate router, and egress) to participate in the protocol 👯. Additionally, the intermediate router SHOULD disable ordinary ICMPv6 Redirects when AERO redirection is enabled ⚠️.
7. IANA Considerations 🌷
IANA has assigned UDP user port number 8060 for this protocol via the expert review process [RFC5226] 💌.
8. Security Considerations 🛡️✨
okay bestie, security time, and I need you to stay with me on this one 💅 AERO's link security is basically the same as standard IPv6 Neighbor Discovery [RFC4861], but AERO glows up in a few spots 🦋. The big thing is trust. AERO runs on a trust basis between edge nodes and intermediate routers, so an edge node should only use the AERO mechanism when a trusted intermediate router is the one facilitating it. no trusted router, no AERO 🙅♀️
The other scary-cute thing is link-layer address spoofing 💀. That's when an attacker sitting on the link pretends to be a trusted neighbor, and AERO links need protection against it. Good news: links with link-layer security (think WiFi networks) and links with physical security (think enterprise LANs) already give you a first line of defense that is often enough 🫶. And if those aren't an option, you can still get sufficient assurance against spoofing if the sender can digitally sign its messages. How you do the signing is outside the scope of this document, so that one's a homework question for later 🧚
9. Acknowledgements 💜
Okay, shoutout time 📣 Discussions on the v6ops list and in private chats helped shape a bunch of the ideas here. The people who dropped insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, Brian Carpenter, Brian Haberman, Joel Halpern, and Lee Howard 🌸 The IESG members also gave valuable input during their review process, and it made the document so much better 🌈 Special thanks to Stewart Bryant, Joel Halpern, and Brian Haberman for their shepherding guidance. literally iconic 👑
10. References 🍓
10.1. Normative References
- [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
10.2. Informative References
- [IRON] Templin, F., "The Internet Routing Overlay Network (IRON)", Work in Progress, June 2012.
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
- [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
- [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
- [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
- [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
- [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
- [VET] Templin, F., "Virtual Enterprise Traversal (VET)", Work in Progress, June 2012.
Appendix A. Intermediate Router Interworking 🧚♀️
Okay so Figure 3 shows a reference AERO setup with one intermediate router on the AERO link 🎀 But to scale up to more nodes, the AERO link can deploy multiple intermediate routers, like the setup in Figure 6 🌈
+--------------+ +--------------+
| Intermediate | +--------------+ | Intermediate |
| Router C | | Core Router D| | Router E |
| (default->D) | | (A->C; G->E) | | (default->D) |
| (A->B) | +--------------+ | (G->F) |
+-------+------+ +------+-------+
| |
X---+---+--------------------------------------+---+---X
| AERO Link |
+-----+--------+ +--------+-----+
| Edge Router B| | Edge Router F|
| (default->C) | | (default->E) |
+--------------+ +--------------+
.-. .-.
,-( _)-. ,-( _)-.
.-(_ IPv6 )-. .-(_ IPv6 )-.
(__ EUN ) (__ EUN )
`-(______)-' `-(______)-'
| |
+--------+ +--------+
| Host A | | Host G |
+--------+ +--------+
Figure 6: Multiple Intermediate RoutersHere's the scene 🎬 The ingress AERO node ('B') (an edge router in this case, though it could also be a host) hooks up with intermediate AERO router ('C'). Meanwhile the egress AERO node ('F') (also an edge router here, but could be a host too) hooks up with intermediate AERO router ('E'). Intermediate routers ('C') and ('E') don't associate with each other directly 🙈 Instead, they each have an association with a "core" router ('D'), meaning a router that has full topology information about its associated intermediate routers. Core router ('D') may connect to the AERO link, or to other physical or virtual links (not shown) that intermediate routers ('C') and ('E') also connect to.
Now the packet journey 🚀 When host ('A') sends a packet toward host ('G'), IPv6 forwarding sends it through the EUN to edge router ('B'). Without more-specific forwarding info, edge router ('B') forwards it to intermediate router ('C'). Intermediate router ('C') forwards the packet, and it also generates an AERO Predirect message. That message gets forwarded through core router ('D') to intermediate router ('E'). When intermediate router ('E') gets the message, it forwards it to egress router ('F').
After processing the AERO Predirect message, egress router ('F') sends an AERO Redirect message back to intermediate router ('E') ✨
Intermediate router ('E') then forwards that message through core router ('D') to intermediate router ('C'). When intermediate router ('C') receives it, the message goes to ingress edge router ('B'), telling it that host 'G's EUN can be reached via egress router ('F'). And just like that, the AERO redirection is complete 🥳
The interworkings between intermediate and core routers, including the conveyance of pseudo Predirects and Redirects, must be carefully coordinated in a manner outside the scope of this document. The intermediate and core routers must make sure that any routing loops that may form are temporal in nature. For an architectural discussion of coordination between intermediate and core routers, check out [IRON] 💖
Author's Address 🦋
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
EMail: fltemplin@acm.org
📦 where this page comes from
- ietf: rfc6706 2012-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms