One document matched: draft-templin-aero-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="std" docName="draft-templin-aero-04.txt" ipr="trust200902">
<front>
<title abbrev="VET">Asymmetric Extended Route Optimization (AERO)</title>
<author fullname="Fred L. Templin" initials="F." role="editor"
surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="19" month="October" year="2011" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Nodes 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
trusted 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 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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Nodes 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 trusted 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
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.</t>
<t>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.</t>
<t>Therefore, a new redirection approach 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.</t>
<t>While the AERO mechanisms were initially designed for the specific
purpose of NBMA tunnel virtual interfaces (e.g., see: <xref
target="RFC2529"></xref><xref target="RFC5214"></xref><xref
target="RFC5569"></xref><xref target="I-D.templin-ironbis"></xref>) they
can also be applied to any link types that support redirection <xref
target="RFC0792"></xref><xref target="RFC4861"></xref>. The rest of this
document refers to this class of links collectively as "AERO links".</t>
<t>The AERO techniques apply to both the IPv4 <xref
target="RFC0791"></xref> and IPv6 <xref target="RFC2460"></xref>
protocols, as well as any other network layer protocol that includes
link models that can support redirection.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The terminology in the normative references apply; the following
terms are defined within the scope of this document:</t>
<t><list style="hanging">
<t hangText="AERO link"><vspace />any link over which the AERO
mechanisms can be applied.</t>
<t hangText="AERO node"><vspace />a gateway, router or host
connected to an AERO link.</t>
<t hangText="AERO gateway"><vspace />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.</t>
<t hangText="AERO router"><vspace />a router that configures a
non-advertising router interface on the AERO link, and that connects
End User Networks to the AERO link.</t>
<t hangText="AERO host"><vspace />a simple host on the AERO
link.</t>
<t hangText="ingress AERO node ("ingress")"><vspace />a
node that injects packets into the AERO link.</t>
<t hangText="egress AERO node ("egress")"><vspace />a node
that removes packets from the AERO link.</t>
</list>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 <xref
target="RFC2119"></xref>. When used in lower case (e.g., must, must not,
etc.), these words MUST NOT be interpreted as described in <xref
target="RFC2119"></xref>, but are rather interpreted as they would be in
common English.</t>
</section>
<section title="Requirements">
<t>The route optimization mechanism must satisfy the following
requirements:</t>
<t><list style="hanging">
<t
hangText="Req 1: Off-load traffic from performance-critical gateways"><vspace />The
mechanism must offload sustained transit though a gateway that would
otherwise become a traffic concentrator.</t>
<t hangText="Req 2: Support route optimization"><vspace />Ingress
nodes must be able to send packets directly to egress nodes without
involving a gateway as an intermediary hop.</t>
<t
hangText="Req 3: Support multiple levels of hierarchy"><vspace />For
scaling purposes, allow multiple levels of hierarchy in which
gateways in higher levels have progressively more topology knowledge
than those in lower levels.</t>
<t
hangText="Req 4: Do not circumvent ingress filtering"><vspace />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.</t>
<t
hangText="Req 5: Do not expose packets to loss due to filtering"><vspace />The
ingress node must have a way of knowing that the egress node will
accept its forwarded packets.</t>
<t
hangText="Req 6: Do not expose packets to loss due to path failure"><vspace />The
ingress node must have a way of discovering whether the egress has
gone unreachable on the route optimized path.</t>
<t hangText="Req 7: Do not introduce routing loops"><vspace />The
gateway must not perform a route optimization that would cause a
routing loop to form.</t>
<t hangText="Req 8: Support mobility"><vspace />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.</t>
</list></t>
</section>
<section title="Asymmetric Extended Route Optimization (AERO)">
<t>The following sections specify an Asymmetric Extended Route
Optimization (AERO) capability that fulfills the requirements specified
in Section 3.</t>
<section anchor="routing-proto" title="AERO Link Dynamic Routing">
<t>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
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.</t>
<t>When a proactive dynamic routing protocol cannot be used, the
mechanisms specified in this section can provide a useful on-demand
dynamic routing capability.</t>
</section>
<section anchor="no-onlink-prefix" title="AERO Node Behavior">
<t>The following sections discuss characteristics of nodes attached to
links over which AERO can be used:</t>
<section anchor="nodetype" title="AERO Node Types">
<t>AERO gateways configure their AERO link interfaces as advertising
router interfaces (see: <xref target="RFC4861"></xref>, Section
6.2.2), and therefore may send Router Advertisement (RA) messages
that include non-zero Router Lifetimes.</t>
<t>AERO routers configure their AERO link interfaces as
non-advertising router interfaces.</t>
<t>AERO hosts configure their AERO link interfaces as simple host
interfaces.</t>
</section>
<section anchor="verify" title="Source Address Verification">
<t>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 <xref target="I-D.ietf-savi-framework"></xref>. In order
to perform source address verification, the node considers the
network-layer source address correct for the link-layer source
address if:</t>
<t><list style="symbols">
<t>the link-layer source address is the address of an AERO
gateway, or</t>
<t>the link-layer source address is explicitly linked to the
network-layer source address (i.e., through stateless or
stateful address mapping), or</t>
<t>a ingress filtering and/or 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, or</t>
<t>the packet includes a signature that the node can use to
authenticate the source.</t>
</list>The latter of these checks can be established through
static configuration, via a proactive dynamic routing protocol, or
through the AERO mechanisms specified in <xref
target="predirect"></xref>.</t>
</section>
<section anchor="host-behave" title="AERO Host Behavior">
<t>AERO hosts send Router Solicitation (RS) messages to obtain RA
messages from an AERO gateway. When the RA contains Prefix
Information Options with non-link-local prefixes, the host
autoconfigures addresses from the prefixes using Stateless Address
Autoconfiguration (SLAAC) <xref target="RFC4861"></xref><xref
target="RFC4862"></xref>. When managed address delegation services
are available, the host can also (or instead) acquire addresses
taken from prefixes aggregated by the gateway through the use of
stateful mechanisms, e.g., DHCP <xref target="RFC2131"></xref><xref
target="RFC3315"></xref>, manual configuration, etc.</t>
<t>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.</t>
</section>
<section anchor="router-behave" title="AERO Router Behavior">
<t>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 for the purpose of default router
discovery.</t>
<t>The router can then acquire managed prefix delegations aggregated
by the gateway through the use of, e.g., DHCPv6 Prefix Delegation
<xref target="RFC3633"></xref>, manual configuration, etc. in the
same fashion as described above for host-based
autoconfiguration.</t>
<t>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.</t>
</section>
<section anchor="gateway-behave" title="AERO Gateway Behavior">
<t>AERO gateways respond to RS messages from hosts and routers on
the AERO link by returning an RA message. Gateways may 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.</t>
<t>When the gateway completes a stateful address or prefix
delegation transaction (e.g., as a DHCP relay/server, etc.), it
establishes forwarding table entries that list the link-layer
address of client as the link-layer address of the next hop toward
the delegated addresses/prefixes.</t>
<t>When the gateway forwards a packet out the same AERO interface it
arrived on, it initiates an AERO route optimization procedure as
specified in <xref target="predirect"></xref>.</t>
</section>
</section>
<section anchor="avoidance-fig"
title="AERO Reference Operational Scenario">
<t><xref target="no-onlink-prefix-fig"></xref> depicts an example 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:</t>
<figure anchor="no-onlink-prefix-fig"
title="Reference AERO Network Topology">
<artwork><![CDATA[ .-(::::::::) 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 |
`-(______)-' +-------------+
]]></artwork>
</figure>
<t>In <xref target="no-onlink-prefix-fig"></xref>, 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 the link.</t>
<t>Router 'B' connects to one or more IPv6 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 stateful 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.</t>
<t>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 stateful 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.</t>
<t>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 stateful 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.</t>
<t>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.</t>
<t>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 <xref
target="predirect"></xref>.</t>
</section>
<section anchor="predirect" title="AERO Specification">
<t><xref target="no-onlink-prefix-fig"></xref> 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.</t>
<t>With reference to <xref target="no-onlink-prefix-fig"></xref>, when
host 'C' sends a packet with source address 'C' and destination
address 'E', the packet is first 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.</t>
<t>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'.</t>
<t>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.</t>
<t>Since neither of these alternatives can satisfy the requirements
listed in Section 3, a new redirection technique is needed. In this
new method (i.e., "AERO redirection"), when '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 stands in
contrast to the classical and augmented redirection approaches; the
following subsections therefore specify the AERO redirection steps
necessary to support the reference operational scenario.</t>
<section title="Sending Predirects">
<t>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. If there is some way of marking the data packet itself
as a predirect, then the data packet itself serves as a "predirect"
without the need for a separate message (e.g., see: <xref
target="I-D.templin-ironbis"></xref>).</t>
<t>If there is no means for signaling a predirect in the data plane,
the gateway instead sends an explicit Predirect message which 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 <xref
target="RFC4861"></xref>, and is identified by two new
backward-compatible bits taken from the Reserved field as shown in
<xref target="predirect-bits"></xref>:</t>
<t><figure anchor="predirect-bits"
title="AERO-Specific IPv6 Redirect Message Format">
<artwork><![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
</figure></t>
<t>Where the new bits are defined as:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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.)</t>
</list></t>
<t>In the reference operational scenario, when gateway 'A' forwards
a packet sent by 'B' toward 'D', it marks the packet as a
"predirect" if possible. Otherwise, it also sends an explicit
Predirect message forward toward 'D', subject to rate limiting (see
Section 8.2 of <xref target="RFC4861"></xref>). 'A' prepares the
Predirect message in a similar fashion as for an ordinary IPv6
Redirect message as follows:</t>
<t><list style="symbols">
<t>the link-layer source address is set to 'L2(A)'</t>
<t>the link-layer destination address is set to 'L2(D)'</t>
<t>the network-layer source address is set to 'L3(B)'.</t>
<t>the network-layer destination address is set to 'L3(D)'.</t>
<t>the Predirect Target and Destination Addresses are both set
to 'L3(B)'.</t>
<t>on links that require stateful address mapping, the Predirect
message includes a Target Link Layer Address Option (TLLAO) set
to 'L2(B)'.</t>
<t>the Predirect message includes Route Information Options
(RIOs) <xref target="RFC4191"></xref> that encode prefixes taken
from 'B's address/prefix delegations, including one that covers
the source address of the originating packet.</t>
<t>the Predirect message includes a Redirected Header Option
(RHO) that contains as much of the originating packet as
possible beginning with the network-layer header such that the
total length of the Predirect message does not exceed 512
bytes.</t>
<t>the A and P bits in the Predirect message header are both set
to 1.</t>
</list></t>
<t>'A' then sends the Predirect message forward to 'D'.</t>
</section>
<section title="Processing Predirects and Sending Redirects">
<t>When an AERO router or host receives a either a data packet
marked as a predirect or an explicit Predirect message, it validates
the message according to the appropriate redirect message validation
rules (e.g., Section 8.1 of <xref target="RFC4861"></xref> for
IPv6). The node further accepts the message only if it came from the
link-layer address of a trusted gateway. 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 <xref
target="mobility"></xref>).</t>
<t>In the reference operational scenario, when router 'D' receives
the predirect 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.)</t>
<t>After processing the Predirect message and establishing the
forwarding table entry, 'D' prepares a Redirect message in response
to the Predirect as follows:</t>
<t><list style="symbols">
<t>the link-layer source address is set to 'L2(D)'</t>
<t>the link-layer destination address is set to 'L2(A)'</t>
<t>the network-layer source address is set to 'L3(D)'.</t>
<t>the network-layer destination address is set to 'L3(B)'.</t>
<t>the Redirect Target and the Redirect Destination Addresses
are both set to 'L3(D)'.</t>
<t>on links that require stateful address mapping, the Redirect
message includes a TLLAO set to 'L2(D)'.</t>
<t>the Redirect message includes an RHO copied from the
corresponding Predirect message.</t>
<t>the (A, P) bits in the Redirect message header are set to (1,
0).</t>
</list></t>
<t>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.)</t>
</section>
<section title="Proxying Redirects">
<t>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.</t>
<t>In the reference operational scenario, 'A' receives the Redirect
message from 'D' and 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'.</t>
</section>
<section title="Processing Redirects">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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'.</t>
</section>
<section title="Sending Periodic Predirect Keepalives">
<t>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:</t>
<t><list style="symbols">
<t>the link-layer source address is set to 'L2(B)'.</t>
<t>the link-layer destination address is set to 'L2(D)'.</t>
<t>the network-layer source address is set to 'L3(B)'.</t>
<t>the network-layer destination address is set to 'L3(D)'.</t>
<t>the Predirect Target and Destination Addresses are both set
to 'L3(B)'.</t>
<t>the Predirect message includes a Redirected Header Option
(RHO) that contains as much of the originating packet as
possible beginning with the network-layer header such that the
total length of the Predirect message does not exceed 512
bytes.</t>
<t>the A and P bits in the Predirect message header are both set
to 1.</t>
</list></t>
<t>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 timer for node 'B' to 40 seconds, and sends a
Redirect message directly to 'B' prepared as follows:</t>
<t><list style="symbols">
<t>the link-layer source address is set to 'L2(D)'.</t>
<t>the link-layer destination address is set to 'L2(B)'.</t>
<t>the network-layer source address is set to 'L3(D)'.</t>
<t>the network-layer destination address is set to 'L3(B)'.</t>
<t>the Redirect Target and Destination Addresses are both set to
'L3(D)'.</t>
<t>the Redirect message includes an RHO copied from the
corresponding Predirect message.</t>
<t>the (A, P) bits in the Redirect message header are set to (1,
0).</t>
</list>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.</t>
<t>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.</t>
</section>
<section anchor="reachable" title="Reachability Considerations">
<t>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. On some AERO links, 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.</t>
<t>On AERO links 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 number of attempts, it should consider the direct path to the
egress as unusable.</t>
<t>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.</t>
</section>
</section>
<section anchor="mobility" title="Mobility Considerations">
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><list style="symbols">
<t>the link-layer source address is set to 'L2(D)'.</t>
<t>the link-layer destination address is set to 'L2(B)'.</t>
<t>the network-layer source address is set to 'L3(D)'.</t>
<t>the network-layer destination address is set to 'L3(B)'.</t>
<t>the Redirect Target and Destination Addresses are both set to
NULL.</t>
<t>the Redirect message includes an RHO copied from the
corresponding Predirect message.</t>
<t>the (A, P) bits in the Redirect message header are set to (1,
0).</t>
</list>Eventually, any correspondents will receive such a NULL
Redirect 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
may subsequently 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.</t>
</section>
<section anchor="scaling" title="Scaling Considerations">
<t><xref target="no-onlink-prefix-fig"></xref> 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.</t>
<t>Such an arrangement requires that the gateways participate in a
routing protocol instance (e.g., an eBGP instance with each gateway
configuring a private Autonomous System Number (ASN)) 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.</t>
</section>
<section anchor="chaining" title="Proxy Chaining">
<t>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.</t>
<t>In that case, when 'A' forwards an initial packet destined to an
end system behind 'E', it forwards the packet to 'B'. Next, 'B'
forwards the packet toward 'C', which both forwards the packet
generates a Predirect message toward 'D'. 'D' then either processes
the Predirect message locally or proxies it toward 'E'.</t>
<t>In the reverse direction, when 'E'/'D' sends a Redirect response
message back to 'A', it first sends the message to 'D'/'C', which
proxies the message toward 'B', which finally proxies the message
toward 'A'.</t>
</section>
<section anchor="backward" title="Backward Compatibility">
<t>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.</t>
</section>
<section anchor="signature"
title="Alternate Means of Source Address Verification">
<t>On some AERO links, each packet can include a signature that the
link egress nodes can use to authenticate the link ingress node (e.g.,
see: <xref target="I-D.templin-ironbis"></xref>). On those links, the
procedures for maintaining ingress filtering entries described above
are not necessary.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.</t>
</section>
<section anchor="secure" title="Security Considerations">
<t>This document enables ingress filtering, and therefore improves the
security of AERO links.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>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,</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.0792"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.RFC.4862"?>
<?rfc include="reference.RFC.4191"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3633"?>
<?rfc include="reference.I-D.templin-ironbis"?>
<?rfc include="reference.I-D.ietf-savi-framework"?>
<?rfc include="reference.RFC.2131"?>
<?rfc include="reference.RFC.2529"?>
<?rfc include="reference.RFC.5214"?>
<?rfc include="reference.RFC.5569"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:16:47 |