Asymmetric Extended Route Optimization (AERO)Boeing Research & TechnologyP.O. Box 3707 MC 7L-49SeattleWA98124USAfltemplin@acm.orgI-DInternet-DraftNodes 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.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. 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 .This classical 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.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 (L3) source address. (This is especially important
for very large links, since any node on the link can spoof the L3 source
address with low probability of detection even if the link-layer (L2)
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: )
they can also be applied to any multiple access link types that support
redirection. The AERO techniques are discussed herein with reference to
IPv6 ,
however they can also be applied to any other network layer protocol
(e.g., IPv4 ) 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:any link (either physical or
virtual) over which the AERO mechanisms can be applied. (For
example, a virtual overlay of tunnels can serve as an AERO
link.)a router or host connected to an
AERO link, and that is configured to apply the AERO protocol on that
link.a
router that configures an advertising router interface on an AERO
link over which it can provide default forwarding and redirection
services for other AERO nodes.a
router that configures a non-advertising router interface on an AERO
link over which it can connect End User Networks (EUNs) to the AERO
link.a simple host on an AERO link.a
node that injects packets into an AERO link.a
node that receives packets from an AERO link.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 .The route optimization mechanism must satisfy the following
requirements:The
mechanism must offload sustained transit though an intermediate AERO
router that would otherwise become a traffic concentrator.The
ingress AERO node should be able to send packets directly to the
egress node without involving an intermediate router for route
optimization purposes.For scaling purposes,
support interworking and control message relaying between multiple
intermediate routers (see appendix A).The
mechanism must not open an attack vector where L3 source address
spoofing is enabled even when L2 source address spoofing is
disabled.The
ingress AERO node must have a way of knowing that the egress AERO
node will accept its forwarded packets.The
ingress AERO node must have a way of discovering whether the AERO
egress node has gone unreachable on the route optimized path.Intermediate
routers must not invoke a route optimization that would cause a
routing loop to form.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.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: ,
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 L3 addresses from the prefixes using Stateless
Address Autoconfiguration (SLAAC) . When managed
L3 address delegation services are available, the host can also (or
instead) acquire L3 addresses taken from prefixes aggregated by the
intermediate router through the use of stateful mechanisms, e.g.,
DHCPv6 , administrative configuration,
etc.After the host receives L3 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
.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 , 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 .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
L3 addresses and prefixes. (In any case, however, each intermediate
router must be made aware of the L3 address/prefix delegations
associated with the AERO edge routers and hosts that it serves.)When the intermediate router completes a stateful L3 address or
prefix delegation transaction (e.g., as a DHCPv6 relay/server,
etc.), it establishes forwarding table entries that list the L2
address of the client AERO node as the L2 address of the next hop
toward the delegated L3 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 . 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'):In , 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). 'A'
configures an AERO link interface with a link-local L3 address L3(A)
and with L2 address L2(A). 'A' next arranges to add L2(A) to a
published list of valid intermediate routers for the link. Finally,
'A' is further provisioned with routing information listing node 'B'
as the next-hop AERO router toward the EUN associated with node 'C',
and listing node 'D' as the next-hop AERO router toward the EUN
associated with node 'E'.AERO edge router 'B' connects to one or more IPv6 EUNs and also
connects to the AERO link via an interface with link-local L3 address
L3(B) and with L2 address L2(B). 'B' next configures a default route
with next-hop L3 address L3(A) via the AERO interface, then receives
the L3 prefix 2001:db8:0::/48 through a stateful prefix delegation
exchange that also establishes routing information in intermediate
router 'A'. 'B' finally sub-delegates the L3 prefix to links and/or
routers within its attached EUNs, where IPv6 host 'C' autoconfigures
the L3 address 2001:db8:0::1.AERO edge router 'D' connects to the AERO link via an interface
with link-local L3 address L3(D) and with L2 address L2(D). 'D' next
configures a default route with next-hop L3 address L3(A) via the AERO
interface, then receives the L3 prefix 2001:db8:1::/48 through a
stateful prefix delegation exchange in the same fashion as for router
'B'. 'D' finally sub-delegates the L3 prefix to links and/or routers
within its attached EUNs, where IPv6 host 'E' autoconfigures L3
address 2001:db8:1::1.Host 'F' connects to the AERO link via an interface with link-local
L3 address L3(F) and with L2 address L2(F). 'F' next configures a
default route with next-hop L3 address L3(A) via the AERO interface,
then receives the L3 address 2001:db8:2::1 from a stateful address
configuration exchange that also establishes routing information in
intermediate router 'A'. When 'F' receives the L3 address, it assigns
the address to the AERO interface.Finally, IPv6 host 'G' connects to an IPv6 network outside of the
AERO link domain. 'G' configures its IPv6 interface in a manner
specific to its attached IPv6 link, and autoconfigures the L3 address
2001:db8:3::1.In these arrangements, intermediate router 'A' must maintain state
that associate the delegated L3 addresses/prefixes with the link-local
L3 addresses of the correct edge routers and/or hosts on the AERO
link. The routers and hosts must maintain at least a default route
that points to 'A', and can discover more-specific routes either via a
proactive dynamic routing protocol or via the AERO mechanisms
specified in . 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 ,
when source host 'C' sends a packet with source L3 address 'C' and
destination L3 address 'E', the packet is first forwarded over 'C's
attached EUN to the ingress AERO node 'B'. 'B' then forwards the
packet over the AERO interface to the AERO link intermediate router
'A', which then forwards the packet to the egress AERO node 'D',
where the packet is finally forwarded to destination host 'E'. When
intermediate router 'A' forwards the packet back out on its
advertising AERO interface, it must arrange to redirect 'B' toward
'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 'B' and 'D' are willing
participants.Consider a first alternative in which intermediate router 'A'
informs ingress AERO node 'B' only and does not inform egress AERO
node 'D' (i.e., "classic redirection"). In that case, 'D' has no way
of knowing that 'B' is authorized to forward packets from their
claimed source L3 addresses, and may simply elect to drop the
packets. Also, 'B' has no way of knowing whether 'D' is willing to
accept its packets, nor whether 'D' is even reachable via a direct
path that does not involve 'A'. Finally, 'B' has no way of knowing
whether the final destination has moved away from 'D'.Consider also a second alternative in which intermediate router
'A' informs both ingress AERO node 'B' and egress AERO 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 'B' receives the
redirection message but 'D' does not, subsequent packets sent by 'B'
could be dropped due to filtering since 'D' would not have neighbor
state to verify their source L3 addresses. Second, if 'D' receives
the redirection message but 'B' does not, subsequent packets sent in
the reverse direction by 'D' would be lost. Finally, timing issues
surrounding the establishment and garbage collection of neighbor
state at 'B' and 'D' 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 is needed. In this
new method (i.e., "AERO redirection"), when intermediate router 'A'
forwards a packet from ingress AERO node 'B' out the same AERO
interface toward egress AERO node 'D', 'A' first sends a "Predirect"
message forward to 'D' to inform it that 'B' is authorized to
originate packets using source L3 address 'C'. After 'D' receives
the Predirect, it creates neighbor state for 'B' and sends a
Redirect message back to 'B' via 'A' as a trusted intermediary. When
'B' receives the Redirect, it both creates neighbor state for 'D'
and knows that 'D' will accept the packets it sends with source L3
address 'C'. This process addresses the issues inherent to the
classical and augmented redirection approaches; the following
subsections therefore specify the AERO redirection steps necessary
to support the reference operational scenario.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: ).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 L3
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 L3 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 . 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 L3 source address correct for the L2 source address
if:the L2 source address is the address of a trusted
intermediate AERO router, orthe L2 source address is explicitly linked to the L3 source
address (i.e., through stateless or stateful address mapping),
orthe packet includes a digital signature that the node can use
to authenticate the origin.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 L2 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 ,
and is identified by three new bits known as the "AERO bits" taken
from the Reserved field as shown in :Where the new AERO bits are defined as:Set to 1 to indicate an AERO-specific
Redirect message, and set to 0 to indicate an ordinary IPv6
Redirect message.Set to 1 to indicate a Predirect message,
and set to 0 to indicate a Redirect response to a Predirect
message. (This bit is valid only when the A bit is set to
1.)Set to 1 to indicate that this message has
already been Relayed by an intermediate router; otherwise, set
to 0. (This bit is valid only when the A bit is set to 1.)In the reference operational scenario, when intermediate router
'A' forwards a packet sent by ingress node 'B' toward egress node
'D', it also sends a Predirect message forward toward 'D', subject
to rate limiting (see Section 8.2 of ). The intermediate router ('A') prepares
the Predirect message in a similar fashion as for an ordinary IPv6
Redirect message as follows:the L2 source address is set to 'L2(A)' (i.e., the L2 address
of the intermediate router).the L2 destination address is set to 'L2(D)' (i.e., the L2
address of the egress node).the L3 source address is set to 'L3(A)' (i.e., the link-local
L3 address of the intermediate router).the L3 destination address is set to 'L3(D)'. (i.e., the
link-local L3 address of the egress node).the Predirect Target and Destination Addresses are both set
to 'L3(B)' (i.e., the link-local L3 address of the ingress
node).on links that require stateful address mapping, the Predirect
message includes a Target Link Layer Address Option (TLLAO) set
to 'L2(B)' (i.e., the L2 address of the ingress node).the Predirect message includes a Route Information Option
(RIO) that encodes the ingress
node's L3 address/prefix delegation that covers the L3 source
address of the originating packet.the Predirect message includes a Redirected Header Option
(RHO) that contains the original packet truncated to ensure that
at least the L3 destination address is included but the size of
the Predirect message does not exceed 1280 bytes.the AERO bits in the Predirect message header are set to A=1;
P=1; R=0.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.3. (In particular, the egress node ('D')
only accepts the message if it originated from a trusted
intermediate router ('A') unless and until additional authenticating
state has been established.) Next, the egress node ('D') validates
the message according to the ICMPv6 Redirect message validation
rules in Section 8.1 of .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 L3 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 L3
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:the L2 source address is set to 'L2(D)' (i.e., the L2 address
of the egress node).the L2 destination address is set to 'L2(A)' (i.e., the L2
address of the intermediate router).the L3 source address is set to 'L3(D)' (i.e., the link-local
L3 address of the egress node).the L3 destination address is set to 'L3(B)' (i.e., the
link-local L3 address of the ingress node).the Redirect Target and the Redirect Destination Addresses
are both set to 'L3(D)' (i.e., the link-local L3 address of the
egress node).on links that require stateful address mapping, the Redirect
message includes a Target Link Layer Address Option (TLLAO) set
to 'L2(D)'.the Redirect message includes an RIO that encodes the egress
node's L3 address/prefix delegation that covers the L3
destination address of the originating packet.the Redirect message includes as much of the RHO copied from
the corresponding Predirect message as possible such that at
least the L3 source address is included but the size of the
Predirect message does not exceed 1280 bytes.the AERO bits in the Redirect message header are set to A=1;
P=0; R=0.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.3. Next, the intermediate router ('A')
validates the message according to the ICMPv6 Redirect message
validation rules in Section 8.1 of .
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 an L3
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 L2 source address of the
message to 'L2(A)', changes the L3 source address of the message to
the link-local L3 address 'L3(A)', and changes the L2 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.3. (In particular, the ingress node ('B') only accepts
the message if it originated from a trusted intermediate router
('A') unless and until additional authenticating state has been
established.) Next, the ingress node ('B') validates the message
according to the ICMPv6 Redirect message validation rules in Section
8.1 of . 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 L3 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 L3 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 L3
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:the L2 source address is set to 'L2(B)' (i.e., the L2 address
of the ingress node).the L2 destination address is set to 'L2(D)' (i.e., the L2
address of the egress node).the L3 source address is set to 'L3(B)' (i.e., the link-local
L3 address of the ingress node).the L3 destination address is set to 'L3(D)' (i.e., the
link-local L3 address of the egress node).the Predirect Target and Destination Addresses are both set
to 'L3(B)' (i.e., the link-local L3 address of the ingress
node).the Predirect message includes a Redirected Header Option
(RHO) that contains the original packet truncated to ensure that
at least the L3 source and destination addresses are included
but the size of the Predirect message does not exceed 1280
bytes.the AERO bits in the Predirect message header are set to A=1;
P=1; R=0.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.4. The egress node ('D') then
resets its ACCEPT timer for the prefix pair that matches the
originating packet's L3 source and destination addresses to
ACCEPT_TIME seconds, and sends a Redirect message directly to the
ingress node ('B') prepared as follows:the L2 source address is set to 'L2(D)' (i.e., the L2 address
of the egress node).the L2 destination address is set to 'L2(B)' (i.e., the L2
address of the ingress node).the L3 source address is set to 'L3(D)' (i.e., the link-local
L3 address of the egress node).the L3 destination address is set to 'L3(B)' (i.e., the
link-local L3 address of the ingress node).the Redirect Target and Destination Addresses are both set to
'L3(D)' (i.e., the link-local L3 address of the egress
node).the Redirect message includes as much of the RHO copied from
the corresponding Predirect message as possible such that at
least the L3 source and destination addresses are included but
the size of the Redirect message does not exceed 1280 bytes.the AERO bits in the Redirect message header are set to A=1;
P=0; R=0.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.6. The ingress node ('B') then
resets its FORWARD timer for the prefix pair that matches the
originating packet's L3 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.8. 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 , 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 node
'E' in one of the egress node's connected EUNs moves to a different
network point of attachment, however, the EUN node ('E') can release
its L3 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 L3 address/prefix
delegations, the egress node ('D') marks the forwarding table
entries that cover the L3 addresses/prefixes as "departed". When
egress node ('D') receives packets from ingress node 'B' with L3
source and destination addresses that match a prefix pair on the
ACCEPT list, it forwards them to the last-known L2 address of the
EUN node ('E') as a means for avoiding mobility-related packet loss
during routing changes. The 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:the L2 source address is set to 'L2(D)'.the L2 destination address is set to 'L2(B)'.the L3 source address is set to the link-local address
'L3(D)'.the L3 destination address is set to the link-local address
'L3(B)'.the Redirect Target and Destination Addresses are both set to
NULL.the Redirect message includes an RHO that contains the
original packet truncated to ensure that at least the L3 source
and destination addresses are included but the size of the
Predirect message does not exceed 1280 bytes.the AERO bits in the Redirect message header are set to A=1;
P=0; R=0.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 L3 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 L3 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 L3
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 L2 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.3 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, 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 In this example, ingress node 'B' associates with
intermediate router 'C', while egress node 'F' associates with
intermediate router 'E'. Furthermore, intermediate routers 'C' and 'E'
do not associate with each other directly, but rather have an
association with a "core" router 'D' (i.e., a router that has full
topology information concerning its associated intermediate routers).
The core router may connect to either the AERO link, or to other
physical or virtual links to which the intermediate routers also
connect.When ingress AERO node 'B' forwards a packet from host 'A' toward
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 'E'
receives the pseudo Predirect, it sends an actual Predirect message to
egress AERO 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 '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
for an architectural discussion of coordinations between intermediate
and core routers.