Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-09
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6706.
|
|
|---|---|---|---|
| Author | Fred Templin | ||
| Last updated | 2012-02-28 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6706 (Experimental) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Stewart Bryant | ||
| Send notices to | fltemplin@acm.org, draft-templin-aero@tools.ietf.org |
draft-templin-aero-09
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational February 28, 2012
Expires: August 31, 2012
Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-09.txt
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 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.
Status of this Memo
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 31, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Templin Expires August 31, 2012 [Page 1]
Internet-Draft AERO February 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 7
4.1. AERO Link Dynamic Routing . . . . . . . . . . . . . . . . 7
4.2. AERO Node Behavior . . . . . . . . . . . . . . . . . . . . 7
4.2.1. AERO Node Types . . . . . . . . . . . . . . . . . . . 7
4.2.2. AERO Host Behavior . . . . . . . . . . . . . . . . . . 7
4.2.3. Edge AERO Router Behavior . . . . . . . . . . . . . . 8
4.2.4. Intermediate AERO Router Behavior . . . . . . . . . . 8
4.3. AERO Reference Operational Scenario . . . . . . . . . . . 9
4.4. AERO Specification . . . . . . . . . . . . . . . . . . . . 11
4.4.1. Classical Redirection Approaches . . . . . . . . . . . 11
4.4.2. AERO Concept of Operations . . . . . . . . . . . . . . 12
4.4.3. Conceptual Data Structures and Protocol Constants . . 13
4.4.4. Data Origin Authentication . . . . . . . . . . . . . . 13
4.4.5. Sending Predirects . . . . . . . . . . . . . . . . . . 14
4.4.6. Processing Predirects and Sending Redirects . . . . . 16
4.4.7. Relaying Redirects . . . . . . . . . . . . . . . . . . 18
4.4.8. Processing Redirects . . . . . . . . . . . . . . . . . 18
4.4.9. Sending Periodic Predirect Keepalives . . . . . . . . 19
4.4.10. Reachability Considerations . . . . . . . . . . . . . 21
4.4.11. Mobility Considerations . . . . . . . . . . . . . . . 21
4.4.12. Prefix Re-Provisioning Considerations . . . . . . . . 23
4.4.13. Backward Compatibility . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Intermediate Router Interworking . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Templin Expires August 31, 2012 [Page 2]
Internet-Draft AERO February 2012
1. 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 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: Classical Multi-Access Link Redirection
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.
Templin Expires August 31, 2012 [Page 3]
Internet-Draft AERO February 2012
+--------------+
| Router A |
| (D->C) |
+--------------+
|
X--------+--------+--------+------X
| |
+----------+---+ +---+----------+
| Node B | | Router C |
| (default->A) | +-------+------+
| (D->C) | .-.
+--------------+ ,-( _)-.
.-(_ IPv6 )-.
(__ EUN )
`-(______)-'
+-------+------+
| Node D |
+--------------+
Figure 2: More-Specific Routes Following Redirection
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 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
Templin Expires August 31, 2012 [Page 4]
Internet-Draft AERO February 2012
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.)
2. Terminology
The terminology in the normative references apply; the following
terms are defined within the scope of this document:
AERO link
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.)
AERO node
a router or host connected to an AERO link, and that is configured
to apply the AERO protocol on that link.
intermediate AERO router ("intermediate router")
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.
edge AERO router ("edge router")
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.
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 keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
Templin Expires August 31, 2012 [Page 5]
Internet-Draft AERO February 2012
document, are to be interpreted as described in [RFC2119].
3. Requirements
The route optimization mechanism must satisfy the following
requirements:
Req 1: Off-load traffic from performance-critical gateways
The mechanism must offload sustained transit though an
intermediate AERO router that would otherwise become a traffic
concentrator.
Req 2: Support route optimization
The ingress AERO node should be able to send packets directly to
the egress node without involving an intermediate router for route
optimization purposes.
Req 3: Support scaling
For scaling purposes, support interworking and control message
relaying between multiple intermediate routers (see appendix A).
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.
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.
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.
Req 7: Do not introduce routing loops
Intermediate routers must not invoke a route optimization that
would cause a routing loop to form.
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.
Templin Expires August 31, 2012 [Page 6]
Internet-Draft AERO February 2012
4. Asymmetric Extended Route Optimization (AERO)
The following sections specify an Asymmetric Extended Route
Optimization (AERO) capability that fulfills the requirements
specified in Section 3.
4.1. AERO Link Dynamic Routing
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.
4.2. AERO Node Behavior
The following sections discuss characteristics of nodes attached to
links over which AERO can be used:
4.2.1. AERO Node Types
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.
4.2.2. AERO Host Behavior
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
Templin Expires August 31, 2012 [Page 7]
Internet-Draft AERO February 2012
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.
4.2.3. Edge AERO Router Behavior
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.
4.2.4. Intermediate AERO Router Behavior
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
Templin Expires August 31, 2012 [Page 8]
Internet-Draft AERO February 2012
interface it arrived on, it initiates an AERO route optimization
procedure as specified in Section 4.4.
4.3. AERO Reference Operational Scenario
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 |
`-(______)-' +-------------+
Figure 3: AERO Reference Operational Scenario
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
Templin Expires August 31, 2012 [Page 9]
Internet-Draft AERO February 2012
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
Templin Expires August 31, 2012 [Page 10]
Internet-Draft AERO February 2012
routing protocol or via the AERO mechanisms specified in Section 4.4.
4.4. AERO Specification
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.
4.4.1. Classical Redirection Approaches
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
Templin Expires August 31, 2012 [Page 11]
Internet-Draft AERO February 2012
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.
4.4.2. AERO Concept of Operations
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
Templin Expires August 31, 2012 [Page 12]
Internet-Draft AERO February 2012
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.
4.4.3. Conceptual Data Structures and Protocol Constants
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.
4.4.4. Data Origin Authentication
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
Templin Expires August 31, 2012 [Page 13]
Internet-Draft AERO February 2012
source address if:
o the network-layer source address is an on-link address that embeds
the link-layer source address, or
o the network-layer source address is explicitly linked to the link-
layer source address through per-neighbor state, or
o the link-layer source address is the address of a trusted
intermediate AERO router, or
o the 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 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.
4.4.5. Sending Predirects
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:
Templin Expires August 31, 2012 [Page 14]
Internet-Draft AERO February 2012
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: AERO-Specific ICMPv6 Redirect Message Format
Where the new AERO bits are defined as:
A (1) Set to 1 to indicate an AERO-specific Redirect message, and
set to 0 to indicate an ordinary IPv6 Redirect message.
P (1) 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.)
R (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 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:
Templin Expires August 31, 2012 [Page 15]
Internet-Draft AERO February 2012
o the link-layer source address is set to 'L2(A)' (i.e., the link-
layer address of the intermediate router).
o the link-layer destination address is set to 'L2(D)' (i.e., the
link-layer address of the egress node).
o the network-layer source address is set to 'L3(A)' (i.e., the
link-local network-layer address of the intermediate router).
o the network-layer destination address is set to 'L3(D)'. (i.e.,
the link-local network-layer address of the egress node).
o the Predirect Target and Destination Addresses are both set to
'L3(B)' (i.e., the link-local network-layer address of the ingress
node).
o 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 link-layer address of the ingress node).
o the Predirect 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.
o the Predirect message includes a Redirected Header Option (RHO)
that contains the original packet truncated to ensure that at
least the network-layer destination address is included but the
size of the Predirect message does not exceed 1280 bytes.
o 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').
4.4.6. Processing Predirects and Sending Redirects
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
Templin Expires August 31, 2012 [Page 16]
Internet-Draft AERO February 2012
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:
o the link-layer source address is set to 'L2(D)' (i.e., the link-
layer address of the egress node).
o the link-layer destination address is set to 'L2(A)' (i.e., the
link-layer address of the intermediate router).
o the network-layer source address is set to 'L3(D)' (i.e., the
link-local network-layer address of the egress node).
o the network-layer destination address is set to 'L3(B)' (i.e., the
link-local network-layer address of the ingress node).
o the Redirect Target and the Redirect Destination Addresses are
both set to 'L3(D)' (i.e., the link-local network-layer address of
the egress node).
o on links that require stateful address mapping, the Redirect
message includes a Target Link Layer Address Option (TLLAO) set to
'L2(D)'.
o the Redirect 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.
o the Redirect message includes as much of the RHO copied from the
corresponding Predirect message as possible such that at least the
network-layer source address is included but the size of the
Predirect message does not exceed 1280 bytes.
o 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').
Templin Expires August 31, 2012 [Page 17]
Internet-Draft AERO February 2012
4.4.7. Relaying Redirects
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.
4.4.8. Processing Redirects
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
Templin Expires August 31, 2012 [Page 18]
Internet-Draft AERO February 2012
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.
4.4.9. Sending Periodic Predirect Keepalives
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:
o the link-layer source address is set to 'L2(B)' (i.e., the link-
layer address of the ingress node).
o the link-layer destination address is set to 'L2(D)' (i.e., the
link-layer address of the egress node).
o the network-layer source address is set to 'L3(B)' (i.e., the
link-local network-layer address of the ingress node).
o the network-layer destination address is set to 'L3(D)' (i.e., the
link-local network-layer address of the egress node).
Templin Expires August 31, 2012 [Page 19]
Internet-Draft AERO February 2012
o the Predirect Target and Destination Addresses are both set to
'L3(B)' (i.e., the link-local network-layer address of the ingress
node).
o the Predirect message includes a Redirected Header Option (RHO)
that contains the original packet truncated to ensure that at
least the network-layer source and destination addresses are
included but the size of the Predirect message does not exceed
1280 bytes.
o 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.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:
o the link-layer source address is set to 'L2(D)' (i.e., the link-
layer address of the egress node).
o the link-layer destination address is set to 'L2(B)' (i.e., the
link-layer address of the ingress node).
o the network-layer source address is set to 'L3(D)' (i.e., the
link-local network-layer address of the egress node).
o the network-layer destination address is set to 'L3(B)' (i.e., the
link-local network-layer address of the ingress node).
o the Redirect Target and Destination Addresses are both set to
'L3(D)' (i.e., the link-local network-layer address of the egress
node).
o the Redirect message includes as much of the RHO copied from the
corresponding Predirect message as possible such that at least the
network-layer source and destination addresses are included but
the size of the Redirect message does not exceed 1280 bytes.
o 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.8. The ingress node ('B') then resets its
Templin Expires August 31, 2012 [Page 20]
Internet-Draft AERO February 2012
FORWARD timer for the prefix pair that matches the originating
packet's network-layer source and destination addresses to
FORWARD_TIME seconds.
4.4.10. Reachability Considerations
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.
4.4.11. Mobility Considerations
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
Templin Expires August 31, 2012 [Page 21]
Internet-Draft AERO February 2012
inform the ingress node ('B') of the departure. The Redirect message
is prepared as follows:
o the link-layer source address is set to 'L2(D)'.
o the link-layer destination address is set to 'L2(B)'.
o the network-layer source address is set to the link-local address
'L3(D)'.
o the network-layer destination address is set to the link-local
address 'L3(B)'.
o the Redirect Target and Destination Addresses are both set to
NULL.
o the Redirect message includes an RHO that contains the original
packet truncated to ensure that at least the network-layer source
and destination addresses are included but the size of the
Predirect message does not exceed 1280 bytes.
o the AERO bits in the Redirect message header are set to A=1; P=0;
R=0.
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.
Templin Expires August 31, 2012 [Page 22]
Internet-Draft AERO February 2012
4.4.12. Prefix Re-Provisioning Considerations
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') .
4.4.13. Backward Compatibility
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.
5. IANA Considerations
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.
6. Security Considerations
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.
Templin Expires August 31, 2012 [Page 23]
Internet-Draft AERO February 2012
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.
7. Acknowledgements
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,
8. References
8.1. Normative References
[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.
8.2. Informative References
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-33 (work in progress),
December 2011.
[I-D.templin-ironbis]
Templin, F., "The Internet Routing Overlay Network
Templin Expires August 31, 2012 [Page 24]
Internet-Draft AERO February 2012
(IRON)", draft-templin-ironbis-10 (work in progress),
December 2011.
[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.
[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.
Appendix A. Intermediate Router Interworking
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
Templin Expires August 31, 2012 [Page 25]
Internet-Draft AERO February 2012
+--------------+ +--------------+
| 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 |
+--------+ +--------+
Figure 5: Multiple Intermediate Routers
In this example, the ingress node ('B') associates with intermediate
router ('C'), while the 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 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').
Templin Expires August 31, 2012 [Page 26]
Internet-Draft AERO February 2012
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.
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
Templin Expires August 31, 2012 [Page 27]