[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6706

Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                         December 05, 2011
Expires: June 7, 2012


             Asymmetric Extended Route Optimization (AERO)
                       draft-templin-aero-05.txt

Abstract

   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.

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 June 7, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Templin                   Expires June 7, 2012                  [Page 1]

Internet-Draft                     VET                     December 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
     4.9.  Alternate Means of Source Address Verification . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 21







Templin                   Expires June 7, 2012                  [Page 2]

Internet-Draft                     VET                     December 2011


1.  Introduction

   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.

   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 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.

   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-ironbis]) they can also be
   applied to any link types that support 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 June 7, 2012                  [Page 3]

Internet-Draft                     VET                     December 2011


   includes 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 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 receives packets from the AERO link.


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 a gateway that
      would otherwise 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.






Templin                   Expires June 7, 2012                  [Page 4]

Internet-Draft                     VET                     December 2011


   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
   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 proactive dynamic routing protocol cannot be used, the
   mechanisms specified in this section can provide a useful on-demand
   dynamic routing capability.



Templin                   Expires June 7, 2012                  [Page 5]

Internet-Draft                     VET                     December 2011


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  the packet includes a signature that the node can use to
      authenticate the source, or

   o  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.

   The latter of these checks can be established through static
   configuration, via a proactive dynamic routing protocol, or through
   the AERO mechanisms specified in Section 4.4.






Templin                   Expires June 7, 2012                  [Page 6]

Internet-Draft                     VET                     December 2011


4.2.3.  AERO Host Behavior

   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) [RFC4861][RFC4862].  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
   [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 for the purpose of default router discovery.

   The router can then acquire managed prefix delegations 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 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.

   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.




Templin                   Expires June 7, 2012                  [Page 7]

Internet-Draft                     VET                     December 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 June 7, 2012                  [Page 8]

Internet-Draft                     VET                     December 2011


   the link.

   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.

   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.

   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.

   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 an 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 June 7, 2012                  [Page 9]

Internet-Draft                     VET                     December 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 occur 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 this
   new method (i.e., "AERO redirection"), when 'A' forwards a packet
   from 'B' out the same AERO interface toward 'D', 'A' first sends 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



Templin                   Expires June 7, 2012                 [Page 10]

Internet-Draft                     VET                     December 2011


   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.  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:
   [I-D.templin-ironbis]).

   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 augmented 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



Templin                   Expires June 7, 2012                 [Page 11]

Internet-Draft                     VET                     December 2011


   Where the new bits are defined as:

   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 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
   [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 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.

   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 June 7, 2012                 [Page 12]

Internet-Draft                     VET                     December 2011


4.4.2.  Processing Predirects and Sending Redirects

   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 [RFC4861] 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
   Section 4.5).

   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.)

   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)'.

   o  the Redirect message includes Route Information Options (RIOs)
      [RFC4191] that encode prefixes taken from 'D's address/prefix
      delegations, including one that covers the destination address of



Templin                   Expires June 7, 2012                 [Page 13]

Internet-Draft                     VET                     December 2011


      the originating packet.

   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'.

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' and verifies that the RIOs encode addresses/prefixes
   that 'D' is authorized to use.  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 June 7, 2012                 [Page 14]

Internet-Draft                     VET                     December 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 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.

   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 June 7, 2012                 [Page 15]

Internet-Draft                     VET                     December 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.  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.

   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



Templin                   Expires June 7, 2012                 [Page 16]

Internet-Draft                     VET                     December 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' thereafter 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 June 7, 2012                 [Page 17]

Internet-Draft                     VET                     December 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 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.

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., 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.

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', it forwards the packet to 'B'.  Next, 'B' forwards
   the packet toward 'C', which both forwards the packet and generates a
   Predirect message toward 'D'.  'D' then either processes the
   Predirect message locally or proxies it toward 'E'.

   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'.




Templin                   Expires June 7, 2012                 [Page 18]

Internet-Draft                     VET                     December 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.

4.9.  Alternate Means of Source Address Verification

   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: [I-D.templin-ironbis]).


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.




Templin                   Expires June 7, 2012                 [Page 19]

Internet-Draft                     VET                     December 2011


   [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.ietf-savi-framework]
              Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
              "Source Address Validation Improvement Framework",
              draft-ietf-savi-framework-05 (work in progress),
              July 2011.

   [I-D.templin-ironbis]
              Templin, F., "The Internet Routing Overlay Network
              (IRON)", draft-templin-ironbis-09 (work in progress),
              November 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



Templin                   Expires June 7, 2012                 [Page 20]

Internet-Draft                     VET                     December 2011


              Infrastructures (6rd)", RFC 5569, January 2010.


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 June 7, 2012                 [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/