Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Standards Track June 23, 2011
Expires: December 25, 2011
Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-01.txt
Abstract
Nodes (i.e., gateways, routers and hosts) attached to link types such
as multicast-capable, shared media and non-broadcast multiple access
(NBMA), etc. can exchange packets as neighbors on the link. Each
node should therefore be able to discover a neighboring gateway that
can provide default routing services to reach off-link destinations,
and should also accept redirection messages from the gateway
informing it of a neighbor that is closer to the final destination.
This redirect function can provide a useful route optimization, since
the triangular path from the ingress link neighbor, to the gateway,
and finally to the egress link neighbor may be considerably longer
than the direct path between the neighbors. 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 December 25, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Templin Expires December 25, 2011 [Page 1]
Internet-Draft VET June 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Asymmetric Extended Route Optimization (AERO) . . . . . . . . 5
4.1. AERO Link Dynamic Routing . . . . . . . . . . . . . . . . 5
4.2. AERO Node Behavior . . . . . . . . . . . . . . . . . . . . 6
4.2.1. AERO Node Types . . . . . . . . . . . . . . . . . . . 6
4.2.2. Source Address Verification . . . . . . . . . . . . . 6
4.2.3. AERO Host Behavior . . . . . . . . . . . . . . . . . . 7
4.2.4. AERO Router Behavior . . . . . . . . . . . . . . . . . 7
4.2.5. AERO Gateway Behavior . . . . . . . . . . . . . . . . 7
4.3. AERO Reference Operational Scenario . . . . . . . . . . . 8
4.4. AERO Specification . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Sending Predirects . . . . . . . . . . . . . . . . . . 11
4.4.2. Processing Predirects and Sending Redirects . . . . . 13
4.4.3. Proxying Redirects . . . . . . . . . . . . . . . . . . 14
4.4.4. Processing Redirects . . . . . . . . . . . . . . . . . 14
4.4.5. Sending Periodic Predirect Keepalives . . . . . . . . 15
4.4.6. Reachability Considerations . . . . . . . . . . . . . 16
4.5. Mobility Considerations . . . . . . . . . . . . . . . . . 17
4.6. Scaling Considerations . . . . . . . . . . . . . . . . . . 18
4.7. Proxy Chaining . . . . . . . . . . . . . . . . . . . . . . 18
4.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Templin Expires December 25, 2011 [Page 2]
Internet-Draft VET June 2011
1. Introduction
Nodes (i.e., routers and hosts) attached to link types such as
multicast-capable, shared media, non-broadcast multiple access
(NBMA), etc. can exchange packets with each other as neighbors on the
link. Each node should therefore be able to discover a neighboring
gateway that can provide default routing services to reach off-link
destinations, and should also accept redirection messages from the
gateway informing it of a different link neighbor that is closer to
the final destination. This redirect function can provide a useful
route optimization, since the triangular path from the ingress link
neighbor, to the gateway, and finally to the egress link neighbor may
be considerably longer than the direct path between the neighbors.
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 from a gateway, it has no way of knowing whether the
egress link neighbor is ready and willing to accept packets directly
without involving the gateway. In particular, without involvement
from the gateway, the egress would have no way of knowing that the
ingress is authorized to forward packets from a given 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 redirection mechanism is required that can enable a
reliable one-way handshake from the egress to the ingress link node
under the mediation of trusted gateways. 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 interfaces (e.g., see:
[RFC2529][RFC5214][RFC5569][I-D.templin-intarea-vet]) they can also
be applied to any link types that support multiple access and
redirection [RFC0792][RFC4861]. The rest of this document refers to
this class of links collectively as "AERO links".
The AERO techniques apply to both the IPv4 [RFC0791] and IPv6
[RFC2460] protocols, as well as any other network layer protocol that
Templin Expires December 25, 2011 [Page 3]
Internet-Draft VET June 2011
includes multiple access link models that can support redirection.
2. Terminology
The terminology in the normative references apply; the following
terms are defined within the scope of this document:
AERO link
any multiple access link over which the AERO mechanisms can be
applied.
AERO node
a gateway, router or host connected to an AERO link.
AERO gateway
a router that configures an advertising router interface on the
AERO link, and that can provide default routing services for
forwarding packets toward their final destinations.
AERO router
a router that configures a non-advertising router interface on the
AERO link, and that connects End User Networks to the AERO link.
AERO host
a simple host on the AERO link.
ingress AERO node ("ingress")
a node that injects packets into the AERO link.
egress AERO node ("egress")
a node that removes packets from the AERO link.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. When used
in lower case (e.g., must, must not, etc.), these words MUST NOT be
interpreted as described in [RFC2119], but are rather interpreted as
they would be in common English.
3. Requirements
The route optimization mechanism must satisfy the following
requirements:
Templin Expires December 25, 2011 [Page 4]
Internet-Draft VET June 2011
Req 1: Off-load traffic from performance-critical gateways
The mechanism must offload sustained transit though a gateway that
would become a traffic concentrator.
Req 2: Support route optimization
Ingress nodes must be able to send packets directly to egress
nodes without involving a gateway as an intermediary hop.
Req 3: Support multiple levels of hierarchy
For scaling purposes, allow multiple levels of hierarchy in which
gateways in higher levels have progressively more topology
knowledge than those in lower levels.
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 node must have a way of knowing that the egress node
will accept its forwarded packets.
Req 6: Do not expose packets to loss due to path failure
The ingress node must have a way of discovering whether the egress
has gone unreachable on the route optimized path.
Req 7: Do not introduce routing loops
The gateway must not perform 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.
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.), AERO gateways and routers
can engage in a proactive dynamic routing protocol (e.g., OSPF, RIP,
IS-IS, etc.) so that routing/forwarding tables can be populated and
Templin Expires December 25, 2011 [Page 5]
Internet-Draft VET June 2011
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
scaling issues.
When a proactive dynamic routing protocol cannot be used, the on-
demand dynamic routing capabilities specified in this section should
be used.
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
AERO gateways 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.
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. Source Address Verification
AERO nodes must employ a source address verification check for the
packets they receive on an AERO interface in a manner that is
consistent with the Source Address Validation Improvement (SAVI)
Framework [I-D.ietf-savi-framework]. In order to perform source
address verification, the node considers the network-layer source
address correct for the link-layer source address if:
o the link-layer source address is the address of an AERO gateway,
or
o the link-layer source address is explicitly linked to the network-
layer source address (i.e., through stateless or stateful address
mapping), or
o a forwarding table entry exists that lists the packet's link-layer
source address as the link layer address corresponding to the next
hop toward the network-layer source address on the AERO link.
The latter of these checks can be established through static
Templin Expires December 25, 2011 [Page 6]
Internet-Draft VET June 2011
configuration, a proactive dynamic routing protocol, or through the
AERO mechanisms specified in Section 4.4.
4.2.3. AERO Host Behavior
AERO hosts send Router Solicitation (RS) messages to obtain RA
messages from an AERO gateway. Whether or not non-link-local
prefixes for stateless address autoconfiguration are advertised, the
host can acquire addresses taken from prefixes aggregated by the
gateway through the use of stateful mechanisms, e.g., DHCP
[RFC2131][RFC3315], manual configuration, etc.
After the host receives addresses, it assigns them to its AERO
interface and forwards any of its outbound packets via the gateway as
a default router. The host may subsequently receive redirection
messages from the gateway listing a better next hop.
4.2.4. AERO Router Behavior
AERO routers send RS messages to obtain RA messages from an AERO
gateway, i.e., they act as "hosts" on their non-advertising AERO link
router interfaces.
The router can then acquire prefixes aggregated by the gateway
through the use of, e.g., DHCPv6 Prefix Delegation [RFC3633], manual
configuration, etc. in the same fashion as described above for host-
based autoconfiguration.
After the 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 gateway.
The router may subsequently receive redirection messages from the
gateway listing a better next hop.
4.2.5. AERO Gateway Behavior
AERO gateways respond to RS messages from hosts and routers on the
AERO link by returning an RA message. Gateways further configure a
DHCP relay or server function on their AERO links and/or provide an
administrative interface for manual configuration of address/
prefix-to-client forwarding table entries.
When the gateway completes a DHCP address or prefix delegation
transaction (i.e., either as a DHCP relay or a DHCP server), it
establishes forwarding table entries that list the link-layer address
of the DHCP client as the link-layer address of the next hop toward
the delegated addresses/prefixes.
Templin Expires December 25, 2011 [Page 7]
Internet-Draft VET June 2011
When the gateway forwards a packet out the same AERO interface it
arrived on, it initiates an AERO route optimization procedure as
specified in Section 4.4.
4.3. AERO Reference Operational Scenario
Figure 1 depicts a reference AERO network topology. IPv6 is used
only as an example network layer protocol, and the same fundamental
AERO techniques can be applied for other network layer protocols.
The figure shows an AERO gateway ('A'), two non-advertising AERO
routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts
('C', 'E', 'G') in a typical operational scenario:
.-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host G |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,.................,
|companion gateway|
'.................' +---------------+
+--------------+ | Host F |
| Gateway A | +---------------+
+--------------+ 2001:db8:2:1
L3(A) L3(F)
L2(A) L2(F)
| AERO Link |
X-----+--+-----------------+--+---X
| |
L2(B) L2(D) .-.
L3(B) L3(D) ,-( _)-.
+--------------+ +--------------+ .-(_ IPv6 )-.
| Router B | | Router D |--(__ EUN )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | IPv6 Host E |
.-(_ IPv6 )-. +-------------+ +-------------+
(__ EUN )--| IPv6 Host C |
`-(______)-' +-------------+
Figure 1: Reference AERO Network Topology
In Figure 1, Gateway 'A' connects to the AERO link and also connects
to the IPv6 Internet, either directly or via a companion gateway.
'A' configures an AERO link interface with a link-local network-layer
address L3(A) and with link-layer address L2(A). 'A' next arranges
to add the link-layer address L2(A) to the list of valid gateways for
Templin Expires December 25, 2011 [Page 8]
Internet-Draft VET June 2011
the link.
Router 'B' connects to one or more IPv6 End User Networks (EUNs) and
also connects to the AERO link via an interface with a link-local
network-layer address L3(B) and with link-layer address L2(B). 'B'
next configures a default IPv6 route with next-hop address L3(A) via
the AERO interface, then receives the IPv6 prefix 2001:db8:0::/48
through a DHCPv6 prefix delegation exchange via 'A'. 'B' finally
sub-delegates the prefix to its attached EUNs, where IPv6 host 'C'
autoconfigures the address 2001:db8:0::1.
Router 'D' connects to the AERO link via an interface with addresses
L3(D)/L2(D), configures a default IPv6 route with next-hop address
L3(A) via the AERO interface, and receives a DHCPv6 prefix delegation
of 2001:db8:1::/48 in the same fashion as for router 'B'. 'D'
finally sub-delegates the prefix to its attached EUNs, where IPv6
host 'E' autoconfigures IPv6 address 2001:db8:1::1.
Host 'F' connects to the AERO link via an interface with addresses
L3(F)/L2(F). 'F' next configures a default IPv6 route with next-hop
address L3(A) via the AERO interface, then receives the IPv6 address
2001:db8:2::1 from a DHCPv6 address configuration exchange via 'A'.
When 'F' receives the IPv6 address, it assigns the address to the
AERO interface but does not assign a non-link-local IPv6 prefix to
the 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 IPv6
address 2001:db8:3::1.
In these arrangements, 'A' must maintain routes that associate the
delegated IPv6 addresses/prefixes with the correct routers and/or
hosts on the AERO link. The routers and hosts must maintain at least
a default route that points to gateway 'A', and can discover more-
specific routes either via a proactive dynamic routing protocol or
via the AERO mechanisms specified in Section 4.4.
4.4. AERO Specification
Figure 1 depicts a reference operational scenario including an AERO
link. The figure shows an AERO gateway ('A'), two AERO routers ('B',
'D'), an AERO host ('F') and three ordinary IPv6 hosts ('C', 'E',
'G') in a typical deployment configuration. We now discuss the
operation of AERO with respect to this reference scenario.
With reference to Figure 1, when host 'C' sends a packet with source
address 'C' and destination address 'E', the packet is first
Templin Expires December 25, 2011 [Page 9]
Internet-Draft VET June 2011
forwarded over 'C's attached EUN to router 'B'. 'B' then forwards
the packet over the AERO interface to gateway 'A', which then
forwards the packet to router 'D', where the packet is finally
forwarded to host 'E' over 'E's attached EUN. When '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 'E'. However, this
redirection process should only take place if there is assurance that
both 'B' and 'D' are willing participants.
Consider a first alternative in which 'A' informs 'B' only and does
not inform 'D' (i.e., "classic redirection"). In that case, 'D' has
no way of knowing that 'B' is authorized to forward packets from a
given source address. 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 'A' informs both 'B' and
'D' separately via independent redirection messages (i.e., "augmented
redirection"). In that case, several conditions can occur that could
result in communications failures. First, if 'B' receives the
redirection message but 'D' does not, subsequent packets sent by 'B'
would be dropped due to filtering since 'D' would not have a
forwarding table entry to verify their source 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
forwarding table entries 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 forwarding table 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
particular, when 'A' forwards a packet from 'B' out the same AERO
interface toward 'D', 'A' must first send a "Predirect" message
forward to 'D' to inform it that 'B' is authorized to produce packets
using source address 'C'. After 'D' receives the Predirect, it sends
a "Redirect" message back to 'B' via 'A' as a trusted intermediary.
When 'B' receives the Redirect, it knows that 'D' will accept the
packets it sends with source address 'C' as long as 'D' retains the
forwarding table entry. This process is known as Asymmetric Extended
Route Optimization (AERO), which stands in contrast to the classical
and augmented redirection approaches. The following subsections
therefore specify the AERO redirection steps necessary to support the
Templin Expires December 25, 2011 [Page 10]
Internet-Draft VET June 2011
reference operational scenario.
4.4.1. Sending Predirects
When a gateway forwards a packet out the same AERO interface that it
arrived on, the gateway sends a "Predirect" message forward to the
egress AERO node instead of sending a Redirect message back to the
ingress node. The Predirect message is simply an AERO-specific
version of an ordinary Redirect message. In the case of IPv6 as the
network layer protocol, the Predirect format is the same as depicted
in Section 4.5 of [RFC4861], and is identified by two new backward-
compatible bits taken from the Reserved field as shown in Figure 2:
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| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: AERO-Specific IPv6 Redirect Message Format
Where the new bits are defined as:
Templin Expires December 25, 2011 [Page 11]
Internet-Draft VET June 2011
A (1) the "AERO" bit. Set to 1 to indicate an AERO-specific
Redirect message, and set to 0 to indicate an ordinary IPv6
Redirect message.
P (1) the "Predirect" bit. 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.)
In the reference operational scenario, when gateway 'A' forwards a
packet sent by 'B' toward 'D', it also sends a Predirect message
forward toward 'D', subject to rate limiting (see Section 8.2 of
[RFC4861]). 'A' prepares the Predirect message in a similar fashion
as for an ordinary IPv6 Redirect message as follows:
o the link-layer source address is set to 'L2(A)'
o the link-layer destination address is set to 'L2(D)'
o the network-layer source address is set to 'L3(B)'.
o the network-layer destination address is set to 'L3(D)'.
o the Predirect Target and Destination Addresses are both set to
'L3(B)'.
o on links that require stateful address mapping, the Predirect
message includes a Target Link Layer Address Option (TLLAO) set to
'L2(B)'.
o the Predirect message includes Route Information Options (RIOs)
[RFC4191] that encode prefixes taken from 'B's address/prefix
delegations, including one that covers the source address of the
originating packet.
o the Predirect message includes a Redirected Header Option (RHO)
that contains the first 128 bytes of the originating packet
beginning with the network-layer header (or up to the remainder of
the packet if there are fewer than 128 bytes).
o the A and P bits in the Predirect message header are both set to
1.
'A' then sends the Predirect message forward to 'D'.
Templin Expires December 25, 2011 [Page 12]
Internet-Draft VET June 2011
4.4.2. Processing Predirects and Sending Redirects
When an AERO router or host receives a Predirect message, it
validates the message according to the appropriate redirect message
validation rules (e.g., Section 8.1 of [RFC4861] for IPv6). The node
further accepts the message only if it came from the link-layer
address of either a trusted gateway or the current previous hop on
the AERO link for the source address of the originating packet
encapsulated in the RHO. Finally, the node only processes the
message if the destination address of the originating packet
encapsulated in the RHO is covered by one of its CURRENT delegated
addresses/prefixes (see Section 4.5).
In the reference operational scenario, when router 'D' receives the
Predirect message from the gateway it creates forwarding table
entries with the prefixes encoded in RIO options as the target
prefixes, and associates the forwarding table entries with a node
structure (e.g., in a neighbor cache) that stores the source address
of the Predirect message (i.e., 'L3(B)'). 'D' places the node
structure in the FILTERING state, then sets/resets a filtering
expiration timer value of 40 seconds. If the filtering timer later
expires, 'D' clears the FILTERING state. If the node structure is
not in the FORWARDING state, 'D' then deletes the node structure and
all of its associated forwarding table entries. (This suggests that
'D's AERO interface should maintain a private forwarding table
separate from the primary forwarding table, since the node structure
and forwarding table entries must be managed by the AERO interface
itself.)
After processing the Predirect message and establishing the
forwarding table entry, 'D' prepares a Redirect message in response
to the Predirect as follows:
o the link-layer source address is set to 'L2(D)'
o the link-layer destination address is set to 'L2(A)'
o the network-layer source address is set to 'L3(D)'.
o the network-layer destination address is set to 'L3(B)'.
o the Redirect Target and the Redirect Destination Addresses are
both set to 'L3(D)'.
o on links that require stateful address mapping, the Redirect
message includes a TLLAO set to 'L2(D)'.
Templin Expires December 25, 2011 [Page 13]
Internet-Draft VET June 2011
o the Redirect message includes an RHO copied from the corresponding
Predirect message.
o the (A, P) bits in the Redirect message header are set to (1, 0).
After 'D' prepares the Redirect message, it sends the message to 'A'.
(Note that the Redirect message does not include RIOs, since the
gateway is the only authoritative source of routing information and
will supply RIOs when it proxies the message.)
4.4.3. Proxying Redirects
When an AERO gateway receives a Redirect message, it accepts the
message only if it satisfies the redirect message validation rules.
The gateway further accepts the message only if it came from the
link-layer address of the current next hop toward the destination
address of the originating packet encapsulated in the RHO. The
gateway then "proxies" the Redirect message back to the original
ingress AERO node as described below.
In the reference operational scenario, 'A' receives the Redirect
message from 'D' then proxies the message back toward 'B'. In
particular, 'A' adds RIOs to the message that encode 'D's address/
prefix delegations. Without decrementing the hopcount in the
Redirect message, 'A' next changes the link-layer source address of
the message to 'L2(A)' and changes the link-layer destination address
to 'L2(B)'. 'A' then sends this proxied Redirect message to 'B'.
4.4.4. Processing Redirects
When an AERO router or host receives a Redirect message, it validates
the message according to the appropriate redirect message validation
rules. The node further accepts the message only if it came from the
link-layer address of either a trusted gateway or the current next
hop on the AERO link for the destination address of the originating
packet encapsulated in the RHO.
In the reference operational scenario, 'B' receives the (proxied)
Redirect message then creates forwarding table entries with the
prefixes encoded in RIO options as the target prefixes. 'B' further
associates the forwarding table entries with a node structure (e.g.,
in a neighbor cache) that stores the source address of the Predirect
message (i.e., 'L3(D)'). 'B' places the node structure in the
FORWARDING state, then sets/resets a filtering expiration timer value
of 30 seconds. If the filtering timer later expires, 'B' clears the
FORWARDING state. If the node structure is not in the FILTERING
state, 'B' then deletes the node structure and all of its associated
forwarding table entries.
Templin Expires December 25, 2011 [Page 14]
Internet-Draft VET June 2011
Now, 'B' has a node structure for 'D' in the FORWARDING state, and
'D' has a node structure for 'B' in the FILTERING state. Therefore,
'B' may forward ordinary network-layer data packets with destination
addresses covered by 'D's prefixes directly to 'D' without involving
'A'. 'D' will in turn accept the packets since it has a forwarding
table entry authorizing 'B' to forward packets with source addresses
covered by 'B's prefixes.
To enable packet forwarding in the reverse direction, a separate AERO
operation is required which is the mirror-image of the forward AERO
operation described above, i.e., the forward and reverse AERO
operations are asymmetric. Following the reverse operation, packets
can be exchanged bidirectionally without involving 'A'.
4.4.5. Sending Periodic Predirect Keepalives
In order to prevent forwarding table entries from expiring while data
packets are actively flowing, the ingress node can periodically send
Predirect messages directly to the egress node (subject to rate
limiting) to solicit Redirect messages. In the reference operational
scenario, when 'B' forwards a packet to 'D' and wishes to update the
corresponding FORWARDING state timer, 'B' can also send a Predirect
message directly to 'D' prepared as follows:
o the link-layer source address is set to 'L2(B)'.
o the link-layer destination address is set to 'L2(D)'.
o the network-layer source address is set to 'L3(B)'.
o the network-layer destination address is set to 'L3(D)'.
o the Predirect Target and Destination Addresses are both set to
'L3(B)'.
o the Predirect message includes a Redirected Header Option (RHO)
that contains the first 128 bytes of the originating packet
beginning with the network-layer header (or up to the remainder of
the packet if there are fewer than 128 bytes).
o the A and P bits in the Predirect message header are both set to
1.
When 'D' receives the Predirect message, it accepts the message only
if it satisfies the redirect message validation rules. The node
further accepts the message only if it came from the current previous
hop on the AERO link for the source address of the originating packet
encapsulated in the RHO. 'D' then resets its FILTERING expiration
Templin Expires December 25, 2011 [Page 15]
Internet-Draft VET June 2011
timer for node 'B' to 40 seconds, and sends a Redirect message
directly to 'B' 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 'L3(D)'.
o the network-layer destination address is set to 'L3(B)'.
o the Redirect Target and Destination Addresses are both set to
'L3(D)'.
o the Redirect message includes an RHO copied from the corresponding
Predirect message.
o the (A, P) bits in the Redirect message header are set to (1, 0).
When 'B' receives the Redirect message, it accepts the message only
if it satisfies the redirect message validation rules. The node
further accepts the message only if it came from the current next hop
on the AERO link for the source address of the originating packet
encapsulated in the RHO. 'B' then resets its FORWARDING expiration
timer for node 'D' to 30 seconds.
Note that in these direct neighbor to neighbor exchanges, neither the
Predirect nor Redirect message contain RIOs, since gateways are the
only authoritative source of routing information. Therefore, AERO
routers and hosts should not include RIOs in the Predirects/Redirects
they send, and they must ignore any RIOs included in received
Predirect/Redirect messages that did not come from a trusted gateway.
4.4.6. Reachability Considerations
When an ingress node receives a Redirect message informing it of a
direct path to a new egress, there is a question in point as to
whether the new egress can be reached directly without involving the
gateway as an intermediary. In some environments, it may be
reasonable for the ingress to (optimistically) assume that the new
egress is reachable, and to immediately begin forwarding data packets
to the egress without testing reachability.
In environments in which an optimistic assumption of reachability may
be inappropriate, however, the ingress can defer the redirection
until it tests the direct path to the egress by sending a direct
Predirect message to elicit a Redirect as specified in Section 4.4.5.
If the ingress is unable to elicit a Redirect message after a small
Templin Expires December 25, 2011 [Page 16]
Internet-Draft VET June 2011
number of attempts, it should consider the direct path to the egress
as unusable.
In either case, the ingress can process any link errors corresponding
to the data packets sent directly to the egress as a hint that the
direct path has either failed or has become intermittent.
4.5. Mobility Considerations
An AERO link egress router 'D' can configure both a non-advertising
router interface on a provider AERO link and advertising router
interfaces on EUN links to provide gateway services to nodes in EUNs.
When node 'E' in an EUN that has obtained addresses/prefixes moves to
a different network point of attachment, however, 'E' can release its
address/prefix delegations via 'D' and re-establish them via a
different gateway.
When 'E' releases its address/prefix delegations via 'D', 'D' marks
the forwarding table entries that cover the addresses/prefixes as
DEPARTED (i.e., it clears the CURRENT state). 'D' therefore ceases
to respond to Predirect messages correlated with the DEPARTED
entries, and also schedules a garbage-collection timer of 60 seconds,
after which it deletes the DEPARTED entries.
When 'D' receives packets destined to an address covered by the
DEPARTED forwarding table entries, it forwards them to the last-known
EUN link-layer address of 'E' as a means for avoiding mobility-
related packet loss during routing changes. 'D' also returns a NULL
Redirect message to inform the correspondent '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 'L3(D)'.
o the network-layer destination address is set to 'L3(B)'.
o the Redirect Target and Destination Addresses are both set to
NULL.
o the Redirect message includes an RHO copied from the corresponding
Predirect message.
o the (A, P) bits in the Redirect message header are set to (1, 0).
Eventually, any correspondents will receive such a NULL Redirect
Templin Expires December 25, 2011 [Page 17]
Internet-Draft VET June 2011
message and will cease to use 'D' as a next hop. They will then
revert to sending packets destined to 'E' via their gateways and will
receive new Redirect messages to discover that 'E' is now associated
with a new egress router. Note that any packets forwarded by 'D' via
a forwarding table entry in the DEPARTED state may be lost if the
mobile node 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.
4.6. Scaling Considerations
Figure 1 depicts a reference network topology with only a single
gateway on the AERO link. In order to support larger numbers of AERO
routers and hosts, the AERO link can deploy more gateways to support
load balancing and generally shortest-path routing.
Such an arrangement requires that the gateways participate in a
routing protocol instance (e.g., iBGP) so that address/prefix
delegations can be mapped to the correct gateway. The routing
protocol instance can be configured as either a full mesh topology
involving all gateways, or as a partial mesh topology with each AERO
link gateway associating with one or more backhaul network companion
gateways and a full mesh between companion gateways.
4.7. Proxy Chaining
In large AERO link deployments, there may be many gateways - each
serving many AERO routers and hosts. The gateways then either
require full topology knowledge, or a default route to a companion
gateway that does have full topology knowledge. For example, if AERO
node 'A' connects to gateway 'B', and AERO node 'E' connects to
gateway 'D', then 'B' and 'D' must either have full topology
knowledge or have a default route to a companion gateway (e.g., 'C')
that does.
In that case, when 'A' forwards an initial packet destined to an end
system behind 'E', 'B' generates a Predirect message toward 'C',
which proxies the message toward 'D' which finally proxies the
message toward 'E'.
In the reverse direction, when 'E' sends a Redirect response message
back to 'A', it first sends the message to 'D', which proxies the
message toward 'C', which proxies the message toward 'B', which
finally proxies the message toward 'A'.
Templin Expires December 25, 2011 [Page 18]
Internet-Draft VET June 2011
4.8. 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 ignore the 'A' and P' bits in the Reserved field, and
will also ignore any RIOs that are included. The values encoded in
the Redirect message target and destination addresses will also not
cause the legacy node to create incorrect routing state. The
mechanism therefore causes no harm to legacy systems, and supports
natural incremental deployment.
5. IANA Considerations
There are no IANA considerations for this document.
6. Security Considerations
This document enables ingress filtering, and therefore improves the
security of AERO links.
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, Brian Carpenter,
Joel Halpern, Lee Howard,
8. References
8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[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.
Templin Expires December 25, 2011 [Page 19]
Internet-Draft VET June 2011
[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.
8.2. Informative References
[I-D.ietf-savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement Framework",
draft-ietf-savi-framework-04 (work in progress),
March 2011.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-24 (work in progress),
March 2011.
[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.
Templin Expires December 25, 2011 [Page 20]
Internet-Draft VET June 2011
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 December 25, 2011 [Page 21]
