| Network Working Group | F. Templin, Ed. |
| Internet-Draft | Boeing Research & Technology |
| Intended status: Informational | February 28, 2012 |
| Expires: August 29, 2012 |
Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-09.txt
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 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2012.
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.
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 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 default 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.
+--------------+
| Router A |
| (D->C) |
+--------------+
|
X--------+--------+--------+------X
| |
+----------+---+ +---+----------+
| Node B | | Router C |
| (default->A) | +-------+------+
+--------------+ .-.
,-( _)-.
.-(_ IPv6 )-.
(__ EUN )
`-(______)-'
+-------+------+
| Node D |
+--------------+
Figure 1 shows a classical multi-access link redirection scenario. In this figure, Node 'B' is provisioned with only a default route with Router 'A' as the next hop. Router 'A' in turn has a more-specific route that lists Router 'C' as the next hop neighbor on the link for Node 'D's attached network.
If Node 'B' has a packet to send to Node 'D', 'B' is obliged to send its initial packets via Router 'A'. Router 'A' then forwards the packet to Router 'C' and also returns a redirect message to inform 'B' that 'C' is in fact an on-link neighbor that is closer to the final destination 'D'. After receiving the redirect message, 'B' can place a more-specific route in its forwarding table so that future packets destined to 'D' can be sent directly via 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 |
+--------------+
For example, when an ingress link neighbor accepts an ordinary redirect message, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without involving an intermediate router. Likewise, the egress has no way of knowing that the ingress is authorized to forward packets from the claimed network-layer source address. (This is especially important for very large links, since any node on the link can spoof the network-layer source address with low probability of detection even if the link-layer source address cannot be spoofed.) Additionally, the ingress would have no way of knowing whether the direct path to the egress has failed, nor whether the final destination has moved away from the egress to some other network attachment point.
Therefore, a new approach is required that can enable redirection signaling from the egress to the ingress link node under the mediation of a trusted intermediate router. The mechanism is asymmetric (since only the forward direction from the ingress to the egress is optimized) and extended (since the redirection extends forward to the egress before reaching back to the ingress). This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.
While the AERO mechanisms were initially designed for the specific purpose of NBMA tunnel virtual interfaces (e.g., see: [RFC2529][RFC5214][RFC5569][I-D.templin-intarea-vet]) they can also be applied to any multiple access link types that support redirection. The AERO techniques are discussed herein with reference to IPv6 [RFC2460][RFC4861], however they can also be applied to any other network layer protocol (e.g., IPv4 [RFC0791][RFC0792][RFC2131]) that provides a redirection service (details of operation for other network layer protocols are out of scope.)
The terminology in the normative references apply; the following terms are defined within the scope of this document:
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
The route optimization mechanism must satisfy the following requirements:
The following sections specify an Asymmetric Extended Route Optimization (AERO) capability that fulfills the requirements specified in Section 3.
In many AERO link use case scenarios (e.g., small enterprise networks, small and stable MANETs, etc.), routers can engage in a classical dynamic routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so that routing/forwarding tables can be populated and standard forwarding between routers can be used. In other scenarios (e.g., large enterprise/ISP networks, cellular service provider networks, dynamic MANETs, etc.), this might be impractical due to routing protocol control message scaling issues.
When a classical dynamic routing protocol cannot be used, the mechanisms specified in this section can provide a useful on-demand route discovery capability. When both classical dynamic routing protocols and the AERO mechanism are active on the same link, routes discovered by the dynamic routing protocol should take precedence over those discovered by AERO.
The following sections discuss characteristics of nodes attached to links over which AERO can be used:
Intermediate AERO routers configure their AERO link interfaces as advertising router interfaces (see: [RFC4861], Section 6.2.2), and therefore may send Router Advertisement (RA) messages that include non-zero Router Lifetimes.
Edge AERO routers configure their AERO link interfaces as non-advertising router interfaces.
AERO hosts configure their AERO link interfaces as simple host interfaces.
AERO hosts send Router Solicitation (RS) messages to obtain RA messages from an intermediate AERO router. When the RA contains Prefix Information Options with non-link-local prefixes, the host autoconfigures network-layer addresses from the prefixes using Stateless Address Autoconfiguration (SLAAC) [RFC4861][RFC4862]. When managed network-layer address delegation services are available, the host can also (or instead) acquire network-layer addresses taken from prefixes aggregated by the intermediate router through the use of stateful mechanisms, e.g., DHCPv6 [RFC3315], administrative configuration, etc.
After the host receives network-layer addresses, it assigns them to its AERO interface and forwards any of its outbound packets via the intermediate router as a default router. The host may subsequently engage in the AERO route optimization procedure as specified in Section 4.4.
Edge AERO routers send RS messages to obtain RA messages from an intermediate AERO router, i.e., they act as "hosts" on their non-advertising AERO link router interfaces for the purpose of default router discovery. Edge routers can then acquire managed prefix delegations aggregated by an intermediate router through the use of, e.g., DHCPv6 Prefix Delegation [RFC3633], administrative configuration, etc.
After the edge router acquires prefixes, it can sub-delegate them to nodes and links within its attached End User Networks (EUNs), then can forward any outbound packets coming from its EUNs via the intermediate router. The edge router may subsequently engage in the AERO route optimization procedure as specified in Section 4.4.
Intermediate AERO routers respond to RS messages from AERO hosts and edge routers by returning an RA message. Intermediate routers may further configure a DHCP relay or server function on their AERO links and/or provide an administrative interface for delegation of network-layer addresses and prefixes. (In any case, however, each intermediate router must be made aware of the network-layer address/prefix delegations associated with the AERO edge routers and hosts that it serves.)
When the intermediate router completes a stateful network-layer address or prefix delegation transaction (e.g., as a DHCPv6 relay/server, etc.), it establishes forwarding table entries that 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.
When the intermediate router forwards a packet out the same AERO interface it arrived on, it initiates an AERO route optimization procedure as specified in Section 4.4.
Figure 3 depicts the AERO reference operational scenario. The figure shows 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 |
`-(______)-' +-------------+
In Figure 3, intermediate AERO router ('A') connects to the AERO link and also connects to the IPv6 Internet, either directly or via other IPv6 routers (not shown). Intermediate router ('A') configures an AERO link interface with a link-local network-layer address L3(A) and with link-layer address L2(A). The intermediate router next arranges to add L2(A) to a published list of valid intermediate routers for the link. Finally, the intermediate router is further provisioned with routing information listing AERO node ('B') as the next-hop toward the IPv6 EUN that connects node ('C'), and listing AERO node ('D') as the next-hop AERO router toward the IPv6 EUN that connects node ('E').
AERO node ('B') is an AERO edge router that connects to one or more IPv6 EUNs and also connects to the AERO link via an interface with link-local network-layer address L3(B) and with link-layer address L2(B). Node ('B') next configures a default route with next-hop network-layer address L3(A) via the AERO interface, then receives the network-layer prefix 2001:db8:0::/48 through a stateful prefix delegation exchange that also establishes routing information in intermediate router ('A'). Node ('B') finally sub-delegates the network-layer prefix to links and/or routers within its attached EUNs, where IPv6 host ('C') autoconfigures the network-layer address 2001:db8:0::1.
AERO node ('D') is an AERO edge router that connects to the AERO link via an interface with link-local network-layer address L3(D) and with link-layer address L2(D). Note ('D') next configures a default route with next-hop network-layer address L3(A) via the AERO interface, then receives the network-layer prefix 2001:db8:1::/48 through a stateful prefix delegation exchange in the same fashion as for node ('B'). Node ('D') finally sub-delegates the network-layer prefix to links and/or routers within its attached EUNs, where IPv6 host ('E') autoconfigures network-layer address 2001:db8:1::1.
AERO host ('F') connects to the AERO link via an interface with link-local network-layer address L3(F) and with link-layer address L2(F). Host ('F') next configures a default route with next-hop network-layer address L3(A) via the AERO interface, then receives the network-layer address 2001:db8:2::1 from a stateful address configuration exchange that also establishes routing information in intermediate router ('A'). When host ('F') receives the network-layer address, it assigns the address to the AERO interface.
Finally, IPv6 host ('G') connects to an IPv6 network outside of the AERO link domain. Host ('G') configures its IPv6 interface in a manner specific to its attached IPv6 link, and autoconfigures the network-layer address 2001:db8:3::1.
In these arrangements, intermediate router ('A') must maintain state that associate the delegated network-layer addresses/prefixes with the link-local network-layer addresses of the correct edge routers and/or hosts on the AERO link. The nodes must in turn maintain at least a default route that points to intermediate router ('A'), and can discover more-specific routes either via a proactive dynamic routing protocol or via the AERO mechanisms specified in Section 4.4.
Section 4.3 describes the AERO reference operational scenario. We now discuss the operation and protocol details of AERO with respect to this reference scenario.
With reference to Figure 3, when IPv6 source host ('C') sends a packet with source network-layer address 'C' and destination network-layer address 'E', the packet is first forwarded via the EUN to ingress AERO node ('B'). The ingress node then forwards the packet over the AERO interface to the AERO link intermediate router ('A'), which then forwards the packet to egress AERO node ('D'), where the packet is finally forwarded to the IPv6 destination host ('E'). When intermediate router ('A') forwards the packet back out on its advertising AERO interface, it must arrange to redirect ingress node ('B') toward egress node ('D') as a better next hop node on the AERO link that is closer to the final destination. However, this redirection process should only occur if there is assurance that both the ingress and egress nodes are willing participants.
Consider a first alternative in which intermediate router ('A') informs ingress node ('B') only and does not inform egress node ('D') (i.e., "classic redirection"). In that case, the egress node has no way of knowing that the ingress is authorized to forward packets from their claimed source network-layer addresses, and may simply elect to drop the packets. Also, the ingress node has no way of knowing whether the egress is willing to accept its packets, nor whether the egress is even reachable via a direct path that does not involve the intermediate router. Finally, the ingress node has no way of knowing whether the final destination has moved away from egress node.
Consider also a second alternative in which intermediate router ('A') informs both ingress node ('B') and egress node ('D') separately via independent redirection messages (i.e., "augmented redirection"). In that case, several conditions can occur that could result in communication failures. First, if the ingress receives the redirection message but the egress does not, subsequent packets sent by the ingress could be dropped due to filtering since the egress would not have neighbor state to verify their source network-layer addresses. Second, if the egress receives the redirection message but the ingress does not, subsequent packets sent in the reverse direction by the egress would be lost. Finally, timing issues surrounding the establishment and garbage collection of neighbor state at the ingress and egress nodes could yield unpredictable behavior. For example, unless the timing were carefully coordinated through some form of synchronization loop, there would invariably be instances in which one node has the correct neighbor state and the other node does not resulting in non-deterministic packet loss.
Since neither of these alternatives can satisfy the requirements listed in Section 3, a new redirection technique (i.e., "AERO redirection") is needed.
AERO redirection is used on links for which the classical redirection approaches described in Section 4.4.1 are insufficient to satisfy all requirements. We now discuss the concept of operations for this new approach.
Again with reference to Figure 3, when source host ('C') sends a packet with source network-layer address L3(C) and destination network-layer address L3(E), the packet is first forwarded over the source host's attached EUN to ingress node ('B'), which then forwards the packet via its AERO interface to intermediate router ('A').
Using AERO Redirection, intermediate router ('A') then forwards the packet out the same AERO interface toward egress node ('D') and also sends a "Predirect" message forward to the egress node. The Predirect message includes the identity of ingress node ('B') as well as information that egress node ('D') can use to determine the longest-match prefixes that cover the source and destination network-layer addresses of the packet that triggered the Predirect. After egress node ('D') receives the Predirect, it creates neighbor state for ingress node ('B') (if necessary) and retains this (src, dst) "prefix pair" as ingress filtering information to accept future packets using addresses matched by the prefixes from ingress node ('B').
After creating this ingress filtering state, egress node ('D') sends a Redirect message back to the intermediate router ('A'), which then acts as a "proxy" to relay the message to ingress node ('B'). The Redirect message includes the identity of egress node ('D') as well as information that ingress node ('B') can use to determine the longest-match prefixes that cover the source and destination network-layer addresses of the packet that triggered the Redirect. After ingress node ('B') receives the Redirect, it creates neighbor state for egress node ('D') (if necessary) and retains this prefix pair as forwarding information to forward future packets using addresses matched by the prefixes to the egress node ('D').
Following the above Predirect/Redirect message exchange, forwarding of packets with source and destination network-layer addresses covered by the longest-match prefix pair is enabled in the forward direction from ingress node ('B') to egress node ('D'). The mechanisms that enable this exchange are specified in the following sections.
Each AERO node maintains a per AERO interface conceptual neighbor cache that includes an entry for each neighbor it communicates with on the AERO link the same as for any IPv6 interface (see: [RFC4861]).
Each AERO interface neighbor cache entry further maintains two lists of (src, dst) prefix pairs. The AERO node adds a prefix pair to the ACCEPT list if it has been informed by a trusted intermediate router that it is safe to accept packets from the neighbor using network-layer source and destination addresses covered by the prefix pair. The AERO node adds a prefix pair to the FORWARD list if it has been informed by a trusted intermediate router that it is permitted to forward packets to the neighbor using network-layer addresses covered by the prefix pair.
When the node adds a prefix pair to a neighbor cache entry ACCEPT list, it also sets an expiration timer for the prefix pair to ACCEPT_TIME seconds. When the node adds a prefix pair to a neighbor cache entry FORWARD list, it sets an expiration timer for the prefix pair to FORWARD_TIME seconds.
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 further RECOMMENDED that ACCEPT_TIME be set to the default constant value 40 seconds to allow a 10 second window so that the AERO redirection procedure can converge before the ACCEPT_TIME timer decrements below FORWARD_TIME.
Different values for FORWARD_TIME and ACCEPT_TIME MAY be administratively set if necessary to better match the AERO link's performance characteristics; however, if different values are chosen all nodes on the link MUST consistently configure the same values. ACCEPT_TIME SHOULD further be set to a value that is sufficiently longer than FORWARD time to allow the AERO redirection procedure to converge.
AERO nodes MUST employ a data origin authentication check for the packets they receive on an AERO interface. In particular, the node considers the network-layer source address correct for the link-layer source address if:
When the AERO node receives a packet on an AERO interface, it processed the packet further if it satisfies one of these data origin authentication conditions; otherwise it drops the packet.
Note that on links in which link-layer address spoofing is possible, AERO nodes may be obliged to require the use of digital signatures. In that case, only the third of the above conditions can be accepted in order to ensure adequate data origin authentication.
When an intermediate AERO router forwards a packet out the same AERO interface that it arrived on, the router sends a Predirect message forward toward the egress AERO node instead of sending a Redirect message back to the ingress AERO node.
The Predirect format is the same as the ICMPv6 Redirect message format depicted in Section 4.5 of [RFC4861], and is identified by three new bits known as the "AERO bits" taken from the Reserved field 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 (=137) | Code (=0) | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|P|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-
Where the new AERO bits are defined as:
In the reference operational scenario, when the intermediate router ('A') forwards a packet sent by the ingress node ('B') toward the egress node ('D'), it also sends a Predirect message forward toward the egress, subject to rate limiting (see Section 8.2 of [RFC4861]). The intermediate router ('A') prepares the Predirect message in a similar fashion as for an ordinary IPv6 Redirect message as follows:
The intermediate router ('A') then sends the Predirect message forward to the egress node ('D').
When the egress node ('D') receives an AERO Predirect message (i.e., a Redirect message with A=1; P=1), it accepts the message only if it satisfies the data origin authentication requirements specified in Section 4.4.4. Next, the egress node ('D') validates the message according to the ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861].
In the reference operational scenario, when the egress node ('D') receives a Predirect it creates a neighbor cache entry (if necessary) that stores the Target address of the Predirect 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 Predirect message RIO along with its own prefix that matches the network-layer destination address in the packet header found in the RHO with the neighbor cache entry as an acceptable (src, dst) prefix pair. The egress node ('D') then adds the prefix pair to the ACCEPT list, and sets/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 Predirect message, the egress node ('D') prepares a Redirect message response as follows:
After the egress node ('D') prepares the Redirect message, it sends the message to the intermediate router ('A').
When the intermediate router ('A') receives an AERO Redirect message (i.e., one with A=1; P=0; R=0), it accepts the message only if it satisfies the data origin authentication requirements specified in Section 4.4.4. Next, the intermediate router ('A') validates the message according to the ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861]. The intermediate router ('A') then "relays" the Redirect message back to the ingress node ('B') as follows.
In the reference operational scenario, the intermediate router ('A') receives the Redirect message from the egress node ('D') and prepares to relay the 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 discards the message if 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)' . The intermediate router ('A') finally sets the AERO R bit to 1 and relays the Redirect message to the ingress node ('B') without decrementing the hopcount.
This relaying procedure therefore requires the intermediate router ('A') to examine the R bit before relaying a Redirect message in order to avoid a free-running loop due to the non-decrementing hopcount. In particular, the intermediate route discards any AERO Redirect message it receives with R==1.
When the ingress node ('B') receives an AERO Redirect message (i.e., one with A=1; P=0), it accepts the message only if it satisfies the data origin authentication requirements specified in Section 4.4.4. Next, the ingress node ('B') validates the message according to the ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861]. The ingress node ('B') then processes the message as follows.
In the reference operational scenario, when the ingress node ('B') receives the (relayed) Redirect message it creates a neighbor cache entry (if necessary) that stores the Target address of the Redirect 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, i.e., it records its prefix that matches the redirected packet's network-layer source address and the prefix listed in the RIO as the prefix pair. The ingress node ('B') then sets/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. Therefore, the ingress node ('B') may forward ordinary network-layer data packets with network-layer source and destination addresses that match the prefix pair directly to the egress node ('D') without involving 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 which is the mirror-image of the forward operation described above, i.e., the forward and reverse AERO operations are asymmetric.
In order to prevent prefix pairs from expiring while data packets are actively flowing, the ingress node ('B') can periodically send Predirect keepalive messages directly to the egress node ('D') to solicit Redirect messages. Absent specific administrative configuration, it is RECOMMENDED that the ingress node ('B') send no more than 10 Predirect keepalive messages during each FORWARD_TIME interval.
In the reference operational scenario, when the ingress node ('B') wishes to refresh the FORWARD timer for a specific prefix pair, it can send a Predirect keepalive message directly to the egress node ('D') prepared as follows:
When the egress node ('D') receives the Predirect message, it accepts the message only if it satisfies the Predirect message validation rules given in Section 4.4.6. The egress node ('D') then resets its ACCEPT timer for the prefix pair that matches the originating packet's network-layer source and destination addresses to ACCEPT_TIME seconds, and sends a Redirect message directly to the ingress node ('B') prepared as follows:
When the ingress node ('B') receives the Redirect message, it accepts the message only if it satisfies the redirect message validation rules given in Section 4.4.8. The ingress node ('B') then resets its FORWARD timer for the prefix pair that matches the originating packet's network-layer source and destination addresses to FORWARD_TIME seconds.
When the ingress node ('B') receives a Redirect message informing it of a direct path to a new egress node ('D'), there is a question in point as to whether the new egress node ('D') can be reached directly without involving an intermediate router ('A'). On some AERO links, it may be reasonable for the ingress node ('B') to (optimistically) assume that reachability is transitive, and to immediately begin forwarding data packets to the egress node ('D') without testing reachability.
On AERO links in which an optimistic assumption of transitive reachability may be unreasonable, however, the ingress node ('B') can defer the redirection until it tests the direct path to the egress node ('D') by sending a Predirect message to elicit a Redirect as specified in Section 4.4.9. If the ingress node ('B') is unable to elicit a Redirect message after a small number of attempts, it should consider the direct path to the egress node ('D') as unusable.
In either case, the ingress node ('B') can process any link errors corresponding to the data packets sent directly to the egress node ('D') as a hint that the direct path has either failed or has become intermittent.
Again with reference to Figure 3, 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, however, it can release its network-layer address/prefix delegations that were registered with 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 corresponding to the network-layer addresses/prefixes as "departed" and no longer responds to Predirect keepalive messages for the departed addresses/prefixes. When egress node ('D') receives packets from an ingress node ('B') with network-layer source and destination addresses that match a prefix pair on the ACCEPT list, it forwards them to the last-known link-layer address of EUN node ('E') as a means for avoiding mobility-related packet loss during routing changes. Egress node ('D') also returns a NULL Redirect message to inform the ingress node ('B') of the departure. The Redirect message is prepared as follows:
When ingress node ('B') receives the NULL Redirect message, it deletes the prefix pair associated with the packet in the RHO from its list of forwarding entries corresponding to egress node ('D'). When egress node ('D')s ACCEPT_TIME timer for the prefix pair corresponding to the departed prefix expires, it deletes the prefix pairs from its list of ingress filtering entries corresponding to ingress node ('B').
Eventually, any such correspondent AERO nodes will receive a NULL Redirect message and will cease to use the egress node ('D') as a next hop. They will then revert to sending packets destined to the EUN node ('E') via a trusted intermediate router and may subsequently receive new Redirect messages to discover that the EUN node ('E' ) is now associated with a new AERO edge router.
Note that any packets forwarded by the egress node ('D') 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 should not be a problem for large links (e.g., large cellular network deployments, large ISP networks, etc.) in which all/most mobility events are intra-link.
When an AERO node configures one or more FORWARD/ACCEPT list prefix pair entries, and the prefixes associated with the pair are somehow re-configured or renumbered, the stale FORWARD/ACCEPT list information must be deleted.
When an ingress node ('B') re-configures it's network-layer source prefix in such a way that the ACCEPT list entry in the egress node ('D') would no longer be valid (e.g., the prefix length of the source prefix changes), the ingress node ('B') simply deletes the prefix pair form its FORWARD list and allows subsequent packets covered by the prefix pair to again flow through an intermediate router ('A').
When the egress node ('D') re-configures it's network-layer destination prefix in such a way that the FORWARD list entry in the ingress node ('B') would no longer be valid, the egress node ('D') sends a NULL Redirect message to the ingress node ('B') the same as described for Mobility Considerations when it receives either a Predirect message or a data packet (subject to rate limiting) from the ingress node ('B') .
If a legacy host or router receives an AERO Redirect or Predirect message, it will process the message as if it were an ordinary Redirect. This will cause no harmful effects, since the legacy system will safely ignore the AERO bits in the Reserved field, and will also ignore any RIOs that are included. The link-local network-layer addresses encoded in the Redirect message Target and Destination addresses will also not cause the legacy node to create incorrect forwarding state. The mechanism therefore causes no harm to legacy systems, and supports natural incremental deployment.
This document defines new bits taken from the ICMPv6 Redirect message header Reserved field. There is currently no registration procedure for such bits, so there are no IANA considerations for this document.
AERO link security is dependent on a trust basis between edge nodes and intermediate routers. In particular, edge nodes must only engage in the AERO mechanism when it is facilitated by a trusted intermediate router.
AERO links must be protected against spoofing attacks in which an attacker on the link pretends to be a trusted neighbor. This is often possible on links that provide link-layer securing mechanisms (e.g., WiFi networks) and on links that provide physical security (e.g., enterprise network LANs). In other instances, sufficient assurances against on-link spoofing attacks are possible if the source can digitally sign its messages. In that case, the destination can use the data origin authentication checks specified in Section 4.4.4 to verify the signature.
Discussions both on the v6ops list and in private exchanges helped shape some of the concepts in this work. Individuals who contributed insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, Brian Carpenter, Joel Halpern, Lee Howard,
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2460] | Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. |
| [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. |
| [RFC4191] | Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. |
Figure 3 depicts a reference AERO operational scenario with a single intermediate router on the AERO link. In order to support scaling to larger numbers of nodes, the AERO link can deploy multiple intermediate routers, e.g., as shown in Figure 5
+--------------+ +--------------+
| 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 |
+-----+--------+ +--------+-----+
| AERO Node B | | AERO Node F |
| (default->C) | | (default->E) |
+--------------+ +--------------+
.-. .-.
,-( _)-. ,-( _)-.
.-(_ IPv6 )-. .-(_ IPv6 )-.
(__ EUN A ) (__ EUN G )
`-(______)-' `-(______)-'
| |
+--------+ +--------+
| Host A | | Host G |
+--------+ +--------+
When ingress node ('B') forwards a packet from source host ('A') toward destination host ('G'), it sends the packet to intermediate router ('C') in absence of more-specific forwarding information. Intermediate router ('C') in turn generates a "pseudo Predirect" message that is through some means conveyed through core router ('D') to intermediate router ('E'). When intermediate router ('E') receives the pseudo Predirect, it sends an actual Predirect message to egress node ('F').
After processing the Predirect, egress node ('F') sends a Redirect message to intermediate router ('E'). Intermediate router ('E') in turn generates a "pseudo Redirect" that is through some means conveyed through core router ('D') to intermediate router ('C'). When intermediate router ('C') receives the pseudo Redirect, it sends an actual Redirect message to ingress node ('B'), thus completing the AERO redirection.
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. In particular, the intermediate and core routers must ensure that no routing loops are formed. See [I-D.templin-ironbis] for an architectural discussion of coordinations between intermediate and core routers.