[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                          January 27, 2012
Expires: July 30, 2012


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

Abstract

   Nodes attached to common multi-access link types (e.g., multicast-
   capable, shared media, non-broadcast multiple access (NBMA), etc.)
   can exchange packets as neighbors on the link, but may not always be
   provisioned with sufficient routing information for optimal neighbor
   selection.  Such nodes should therefore be able to discover a trusted
   intermediate router on the link that provides both forwarding
   services to reach off-link destinations and redirection services to
   inform the node of an on-link neighbor that is closer to the final
   destination.  This redirection can provide a useful route
   optimization, since the triangular path from the ingress link
   neighbor, to the intermediate router, and finally to the egress link
   neighbor may be considerably longer than the direct path from ingress
   to egress.  However, ordinary redirection may lead to operational
   issues on certain link types and/or in certain deployment scenarios.
   This document therefore introduces an Asymmetric Extended Route
   Optimization (AERO) capability that addresses the issues.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 30, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the



Templin                   Expires July 30, 2012                 [Page 1]

Internet-Draft                     VET                      January 2012


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Asymmetric Extended Route Optimization (AERO)  . . . . . . . .  6
     4.1.  AERO Link Dynamic Routing  . . . . . . . . . . . . . . . .  6
     4.2.  AERO Node Behavior . . . . . . . . . . . . . . . . . . . .  7
       4.2.1.  AERO Node Types  . . . . . . . . . . . . . . . . . . .  7
       4.2.2.  AERO Host Behavior . . . . . . . . . . . . . . . . . .  7
       4.2.3.  Edge AERO Router Behavior  . . . . . . . . . . . . . .  8
       4.2.4.  Intermediate AERO Router Behavior  . . . . . . . . . .  8
     4.3.  AERO Reference Operational Scenario  . . . . . . . . . . .  8
     4.4.  AERO Specification . . . . . . . . . . . . . . . . . . . . 10
       4.4.1.  Discussion . . . . . . . . . . . . . . . . . . . . . . 10
       4.4.2.  Conceptual Data Structures, State Variables and
               Protocol Constants . . . . . . . . . . . . . . . . . . 12
       4.4.3.  Data Origin Authentication . . . . . . . . . . . . . . 12
       4.4.4.  Sending Predirects . . . . . . . . . . . . . . . . . . 13
       4.4.5.  Processing Predirects and Sending Redirects  . . . . . 15
       4.4.6.  Relaying Redirects . . . . . . . . . . . . . . . . . . 16
       4.4.7.  Processing Redirects . . . . . . . . . . . . . . . . . 17
       4.4.8.  Sending Periodic Predirect Keepalives  . . . . . . . . 18
       4.4.9.  Reachability Considerations  . . . . . . . . . . . . . 19
       4.4.10. Mobility Considerations  . . . . . . . . . . . . . . . 19
       4.4.11. Backward Compatibility . . . . . . . . . . . . . . . . 20
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.  Intermediate Router Interworking  . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24




Templin                   Expires July 30, 2012                 [Page 2]

Internet-Draft                     VET                      January 2012


1.  Introduction

   Nodes attached to common multi-access link types (e.g., multicast-
   capable, shared media, non-broadcast multiple access (NBMA), etc.)
   can exchange packets as neighbors on the link, but may not always be
   provisioned with sufficient routing information for optimal neighbor
   selection.  Such nodes should therefore be able to discover a trusted
   intermediate router on the link that provides both default forwarding
   services to reach off-link destinations and redirection services to
   inform the node of an on-link neighbor that is closer to the final
   destination.

                  +--------------+
                  |   Router A   |
                  |    (D->C)    |
                  +--------------+
                         |
       X--------+--------+--------+------X
                |                 |
     +----------+---+         +---+----------+
     |    Node B    |         |   Router C   |
     | (default->A) |         +-------+------+
     +--------------+                .-.
                                  ,-(  _)-.
                               .-(_ IPv6  )-.
                             (__    EUN      )
                                `-(______)-'
                              +-------+------+
                              |    Node D    |
                              +--------------+

             Figure 1: Classical Multi-Access Link Redirection

   Figure 1 shows a classical multi-access link redirection scenario.
   In this figure, Node 'B' is provisioned with only a default route
   with Router 'A' as the next hop.  Router 'A' in turn has a more-
   specific route that lists Router 'C' as the next hop neighbor on the
   link for Node 'D's attached network.

   If Node 'B' has a packet to send to Node 'D', 'B' is obliged to send
   its initial packets via Router 'A'.  Router 'A' then forwards the
   packet to Router 'C' and also returns a redirect message to inform
   'B' that 'C' is in fact an on-link neighbor that is closer to the
   final destination 'D'.  After receiving the redirect message, 'B' can
   place a more-specific route in its forwarding table so that future
   packets destined to 'D' can be sent directly via Router 'C', as shown
   in Figure 2.




Templin                   Expires July 30, 2012                 [Page 3]

Internet-Draft                     VET                      January 2012


                  +--------------+
                  |   Router A   |
                  |    (D->C)    |
                  +--------------+
                         |
       X--------+--------+--------+------X
                |                 |
     +----------+---+         +---+----------+
     |    Node B    |         |   Router C   |
     | (default->A) |         +-------+------+
     |    (D->C)    |                .-.
     +--------------+             ,-(  _)-.
                               .-(_ IPv6  )-.
                             (__    EUN      )
                                `-(______)-'
                              +-------+------+
                              |    Node D    |
                              +--------------+

           Figure 2: More-Specific Routes Following Redirection

   This classical redirection can provide a useful route optimization,
   since the triangular path from the ingress link neighbor, to the
   intermediate router, and finally to the egress link neighbor may be
   considerably longer than the direct path from ingress to egress.
   However, ordinary redirection may lead to operational issues on
   certain link types and/or in certain deployment scenarios.

   For example, when an ingress link neighbor accepts an ordinary
   redirect message, it has no way of knowing whether the egress link
   neighbor is ready and willing to accept packets directly without
   involving an intermediate router.  Likewise, the egress has no way of
   knowing that the ingress is authorized to forward packets from the
   claimed source address.  (This is especially important for very large
   links, since any node on the link can spoof the network-layer source
   address with low probability of detection even if the link-layer
   source address cannot be spoofed.)  Additionally, the ingress would
   have no way of knowing whether the direct path to the egress has
   failed, nor whether the final destination has moved away from the
   egress to some other network attachment point.

   Therefore, a new approach is required that can enable redirection
   signaling from the egress to the ingress link node under the
   mediation of a trusted intermediate router.  The mechanism is
   asymmetric (since only the forward direction from the ingress to the
   egress is optimized) and extended (since the redirection extends
   forward to the egress before reaching back to the ingress).  This
   document therefore introduces an Asymmetric Extended Route



Templin                   Expires July 30, 2012                 [Page 4]

Internet-Draft                     VET                      January 2012


   Optimization (AERO) capability that addresses the issues.

   While the AERO mechanisms were initially designed for the specific
   purpose of NBMA tunnel virtual interfaces (e.g., see:
   [RFC2529][RFC5214][RFC5569][I-D.templin-intarea-vet]) they can also
   be applied to any multiple access link types that support
   redirection.  The AERO techniques are discussed herein with reference
   to IPv6 [RFC2460][RFC4861], however they can also be applied to any
   other network layer protocol (e.g., IPv4 [RFC0791][RFC0792][RFC2131])
   that provides a redirection service (details of operation for other
   network layer protocols are out of scope.)


2.  Terminology

   The terminology in the normative references apply; the following
   terms are defined within the scope of this document:

   AERO link
      any link over which the AERO mechanisms can be applied.

   AERO node
      a router or host connected to an AERO link.

   intermediate AERO router ("intermediate router")
      a router that configures an advertising router interface on the
      AERO link over which it can provide default forwarding and
      redirection services for other AERO nodes.

   edge AERO router ("edge router")
      a router that configures a non-advertising router interface on the
      AERO link over which it can connect End User Networks (EUNs) to
      the AERO link.

   AERO host
      a simple host on the AERO link.

   ingress AERO node ("ingress node")
      a node that injects packets into the AERO link.

   egress AERO node ("egress node")
      a node that receives packets from the AERO link.


3.  Requirements

   The route optimization mechanism must satisfy the following
   requirements:



Templin                   Expires July 30, 2012                 [Page 5]

Internet-Draft                     VET                      January 2012


   Req 1: Off-load traffic from performance-critical gateways
      The mechanism must offload sustained transit though an
      intermediate AERO router that would otherwise become a traffic
      concentrator.

   Req 2: Support route optimization
      The ingress AERO node should be able to send packets directly to
      the egress node without involving an intermediate router for route
      optimization purposes.

   Req 3: Support scaling
      For scaling purposes, support interworking and control message
      relaying between multiple intermediate routers (see appendix A).

   Req 4: Do not circumvent ingress filtering
      The mechanism must not open an attack vector where network-layer
      source address spoofing is enabled even when link-layer source
      address spoofing is disabled.

   Req 5: Do not expose packets to loss due to filtering
      The ingress 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
      node has gone unreachable on the route optimized path.

   Req 7: Do not introduce routing loops
      Intermediate routers must not invoke a route optimization that
      would cause a routing loop to form.

   Req 8: Support mobility
      The mechanism must continue to work even if the final destination
      node/network moves from a first egress node and re-associates with
      a second egress node.


4.  Asymmetric Extended Route Optimization (AERO)

   The following sections specify an Asymmetric Extended Route
   Optimization (AERO) capability that fulfills the requirements
   specified in Section 3.

4.1.  AERO Link Dynamic Routing

   In many AERO link use case scenarios (e.g., small enterprise
   networks, small and stable MANETs, etc.), routers can engage in a
   classical dynamic routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so



Templin                   Expires July 30, 2012                 [Page 6]

Internet-Draft                     VET                      January 2012


   that routing/forwarding tables can be populated and standard
   forwarding between routers can be used.  In other scenarios (e.g.,
   large enterprise/ISP networks, cellular service provider networks,
   dynamic MANETs, etc.), this might be impractical due to routing
   protocol control message scaling issues.

   When a classical dynamic routing protocol cannot be used, the
   mechanisms specified in this section can provide a useful on-demand
   route discovery capability.  When both classical dynamic routing
   protocols and the AERO mechanism are active on the same link, routes
   discovered by the dynamic routing protocol should take precedence
   over those discovered by AERO.

4.2.  AERO Node Behavior

   The following sections discuss characteristics of nodes attached to
   links over which AERO can be used:

4.2.1.  AERO Node Types

   Intermediate AERO routers configure their AERO link interfaces as
   advertising router interfaces (see: [RFC4861], Section 6.2.2), and
   therefore may send Router Advertisement (RA) messages that include
   non-zero Router Lifetimes.

   Edge AERO routers configure their AERO link interfaces as non-
   advertising router interfaces.

   AERO hosts configure their AERO link interfaces as simple host
   interfaces.

4.2.2.  AERO Host Behavior

   AERO hosts send Router Solicitation (RS) messages to obtain RA
   messages from an intermediate AERO router.  When the RA contains
   Prefix Information Options with non-link-local prefixes, the host
   autoconfigures 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 intermediate
   router through the use of stateful mechanisms, e.g., DHCPv6
   [RFC3315], administrative configuration, etc.

   After the host receives addresses, it assigns them to its AERO
   interface and forwards any of its outbound packets via the
   intermediate router as a default router.  The host may subsequently
   receive redirection messages from the intermediate router listing a
   better next hop.



Templin                   Expires July 30, 2012                 [Page 7]

Internet-Draft                     VET                      January 2012


4.2.3.  Edge AERO Router Behavior

   Edge AERO routers send RS messages to obtain RA messages from an
   intermediate AERO router, i.e., they act as "hosts" on their non-
   advertising AERO link router interfaces for the purpose of default
   router discovery.  Edge routers can then acquire managed prefix
   delegations aggregated by an intermediate router through the use of,
   e.g., DHCPv6 Prefix Delegation [RFC3633], administrative
   configuration, etc.

   After the edge router acquires prefixes, it can sub-delegate them to
   nodes and links within its attached End User Networks (EUNs), then
   can forward any outbound packets coming from its EUNs via the
   intermediate router.  The edge router may subsequently receive
   redirection messages from the intermediate router listing a better
   next hop.

4.2.4.  Intermediate AERO Router Behavior

   Intermediate AERO routers respond to RS messages from AERO hosts and
   edge routers by returning an RA message.  Intermediate routers may
   further configure a DHCP relay or server function on their AERO links
   and/or provide an administrative interface for delegation of
   addresses and prefixes.

   When the intermediate router completes a stateful address or prefix
   delegation transaction (e.g., as a DHCPv6 relay/server, etc.), it
   establishes forwarding table entries that list the link-layer address
   of the client AERO node as the link-layer address of the next hop
   toward the delegated addresses/prefixes.

   When the intermediate router forwards a packet out the same AERO
   interface it arrived on, it initiates an AERO route optimization
   procedure as specified in Section 4.4.

4.3.  AERO Reference Operational Scenario

   Figure 3 depicts the AERO reference operational scenario.  The figure
   shows an intermediate AERO router ('A'), two edge AERO routers ('B',
   'D'), an AERO host ('F'), and three ordinary IPv6 hosts ('C', 'E',
   'G'):










Templin                   Expires July 30, 2012                 [Page 8]

Internet-Draft                     VET                      January 2012


                    .-(::::::::)
                 .-(::: IPv6 :::)-.   +-------------+
                (:::: Internet ::::)--|    Host G   |
                 `-(::::::::::::)-'   +-------------+
                    `-(::::::)-'       2001:db8:3::1
                         |
                  +--------------+        +--------------+
                  | Intermediate |        |  AERO Host F |
                  | AERO Router A|        | (default->A) |
                  | (C->B; E->D) |        +--------------+
                  +--------------+          2001:db8:2:1
                       L3(A)                   L3(F)
                       L3(A)                   L2(F)
                         |                       |
       X-----+-----------+-----------+-----------+---X
             |       AERO Link       |
            L2(B)                  L2(D)
            L3(B)                  L3(D)
     +--------------+         +--------------+          .-.
     |  AERO Edge   |         |  AERO Edge   |       ,-(  _)-.
     |   Router B   |         |   Router D   |    .-(_ IPv6  )-.
     | (default->A) |         | (default->A) |--(__    EUN      )
     +--------------+         +--------------+     `-(______)-'
     2001:db8:0::/48           2001:db8:1::/48           |
             |                                     2001:db8:1::1
            .-.                                   +-------------+
         ,-(  _)-.      2001:db8:0::1             |    Host E   |
      .-(_ IPv6  )-.   +-------------+            +-------------+
    (__    EUN      )--|    Host C   |
       `-(______)-'    +-------------+

               Figure 3: AERO Reference Operational Scenario

   In Figure 3, intermediate AERO router 'A' connects to the AERO link
   and also connects to the IPv6 Internet, either directly or via other
   IPv6 routers (not shown).  '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 a
   published list of valid intermediate routers for the link.  Finally,
   'A' is further provisioned with routing information listing node 'B'
   as the next-hop AERO router toward the EUN associated with node 'C',
   and listing node 'D' as the next-hop AERO router toward the EUN
   associated with node 'E'.

   AERO edge router 'B' connects to one or more IPv6 EUNs and also
   connects to the AERO link via an interface with 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



Templin                   Expires July 30, 2012                 [Page 9]

Internet-Draft                     VET                      January 2012


   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.

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

   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, intermediate router 'A' must maintain routes
   that associate the delegated IPv6 addresses/prefixes with the correct
   edge routers and/or hosts on the AERO link.  The routers and hosts
   must maintain at least a default route that points to 'A', and can
   discover more-specific routes either via a proactive dynamic routing
   protocol or via the AERO mechanisms specified in Section 4.4.

4.4.  AERO Specification

   Section 4.3 describes the AERO reference operational scenario.  We
   now discuss the operation and protocol details of AERO with respect
   to this reference scenario.

4.4.1.  Discussion

   With reference to Figure 3, when source host 'C' sends a packet with
   source address 'C' and destination address 'E', the packet is first
   forwarded over 'C's attached EUN to the AERO link ingress node 'B'.
   'B' then forwards the packet over the AERO interface to the AERO link
   intermediate router 'A', which then forwards the packet to the AERO
   link egress node 'D', where the packet is finally forwarded to
   destination host 'E'.  When intermediate router 'A' forwards the
   packet back out on its advertising AERO interface, it must arrange to
   redirect ingress node 'B' toward egress node 'D' as a better next hop



Templin                   Expires July 30, 2012                [Page 10]

Internet-Draft                     VET                      January 2012


   node on the AERO link that is closer to the final destination.
   However, this redirection process should only occur if there is
   assurance that both 'B' and 'D' are willing participants.

   Consider a first alternative in which intermediate router 'A' informs
   ingress node 'B' only and does not inform egress node 'D' (i.e.,
   "classic redirection").  In that case, 'D' has no way of knowing that
   'B' is authorized to forward packets from their claimed source
   addresses, and may simply elect to drop the packets.  Also, 'B' has
   no way of knowing whether 'D' is willing to accept its packets, nor
   whether 'D' is even reachable via a direct path that does not involve
   'A'.  Finally, 'B' has no way of knowing whether the final
   destination has moved away from 'D'.

   Consider also a second alternative in which intermediate router 'A'
   informs both ingress node 'B' and egress node 'D' separately via
   independent redirection messages (i.e., "augmented redirection").  In
   that case, several conditions can occur that could result in
   communication failures.  First, if 'B' receives the redirection
   message but 'D' does not, subsequent packets sent by 'B' could be
   dropped due to filtering since 'D' would not have neighbor state to
   verify their source addresses.  Second, if 'D' receives the
   redirection message but 'B' does not, subsequent packets sent in the
   reverse direction by 'D' would be lost.  Finally, timing issues
   surrounding the establishment and garbage collection of neighbor
   state at 'B' and 'D' could yield unpredictable behavior.  For
   example, unless the timing were carefully coordinated through some
   form of synchronization loop, there would invariably be instances in
   which one node has the correct neighbor state and the other node does
   not resulting in non-deterministic packet loss.

   Since neither of these alternatives can satisfy the requirements
   listed in Section 3, a new redirection technique is needed.  In this
   new method (i.e., "AERO redirection"), when intermediate router 'A'
   forwards a packet from ingress node 'B' out the same AERO interface
   toward egress router 'D', 'A' first sends a "Predirect" message
   forward to 'D' to inform it that 'B' is authorized to originate
   packets using source address 'C'.  After 'D' receives the Predirect,
   it creates neighbor state for 'B' and sends a Redirect message back
   to 'B' via 'A' as a trusted intermediary.  When 'B' receives the
   Redirect, it both creates neighbor state for 'D' and knows that 'D'
   will accept the packets it sends with source address 'C'.  This
   process addresses the issues inherent to the classical and augmented
   redirection approaches; the following subsections therefore specify
   the AERO redirection steps necessary to support the reference
   operational scenario.





Templin                   Expires July 30, 2012                [Page 11]

Internet-Draft                     VET                      January 2012


4.4.2.  Conceptual Data Structures, State Variables and Protocol
        Constants

   Each AERO node maintains a per AERO interface conceptual neighbor
   cache that includes an entry for each neighbor it communicates with
   on the AERO link.  The neighbor cache state could be maintained, for
   example, as ancillary information in the IPv6 conceptual neighbor
   cache [RFC4861].

   Each neighbor cache entry maintains the state variables ACCEPT and
   FORWARD.  The node sets ACCEPT to TRUE if it has been informed by a
   trusted intermediate router that the neighbor is permitted to forward
   packets; otherwise, it sets ACCEPT to FALSE.  The node sets FORWARD
   to TRUE if it has been informed by a trusted intermediate router that
   it is permitted to forward packets to the neighbor; otherwise, it
   sets FORWARD to FALSE.

   When the node sets ACCEPT to TRUE, it also sets an expiration timer
   to ACCEPT_TIME seconds, where ACCEPT_TIME is set to the default
   constant value of 40 seconds.  When the node the node sets FORWARD to
   TRUE, it also sets an expiration timer to FORWARD_TIME seconds, where
   FORWARD_TIME is set to the default constant value of 30 seconds.

   The value 30 is chosen for FORWARD_TIME to match the default
   REACHABLE_TIME value specified for IPv6 neighbor discovery [RFC4861].
   The value 40 is chosen for ACCEPT_TIME to allow a 10 second window so
   that the AERO redirection procedure can converge before the target
   neighbor's ACCEPT_TIME timer decrements below FORWARD_TIME.

   Different values for FORWARD_TIME and ACCEPT_TIME may be set if
   necessary to better match the AERO link's performance
   characteristics; however, if different values are chosen all nodes on
   the link must consistently configure the same values.  ACCEPT_TIME
   must further be set to a value that is sufficiently longer than
   FORWARD time to allow the AERO redirection procedure to converge.

4.4.3.  Data Origin Authentication

   AERO nodes must employ a data origin authentication check for the
   packets they receive on an AERO interface.  In particular, the node
   considers the network-layer source address correct for the link-layer
   source address if:

   o  the link-layer source address is the address of a trusted
      intermediate AERO router, or

   o  the link-layer source address is explicitly linked to the network-
      layer source address (i.e., through stateless or stateful address



Templin                   Expires July 30, 2012                [Page 12]

Internet-Draft                     VET                      January 2012


      mapping), or

   o  the packet includes a digital signature that the node can use to
      authenticate the origin.

   When the AERO node receives a packet on an AERO interface, it
   processed the packet further if it satisfies one of these data origin
   authentication conditions; otherwise it drops the packet.

   Note that on links in which link-layer address spoofing is possible,
   AERO nodes may be obliged to require the use of digital signatures.
   In that case, only the third of the above conditions can be accepted
   in order to ensure adequate data origin authentication.

4.4.4.  Sending Predirects

   Using AERO redirection, when an intermediate router forwards a packet
   out the same AERO interface that it arrived on, the router sends a
   Predirect message forward toward the AERO link egress node instead of
   sending a Redirect message back to the ingress node.

   The Predirect format is the same as the ICMPv6 Redirect message
   format depicted in Section 4.5 of [RFC4861], and is identified by
   three new bits known as the "AERO bits" taken from the Reserved field
   as shown in Figure 4:


























Templin                   Expires July 30, 2012                [Page 13]

Internet-Draft                     VET                      January 2012


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (=137)  |   Code (=0)   |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|P|R|                     Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Target Address                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                     Destination Address                       +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-

          Figure 4: AERO-Specific ICMPv6 Redirect Message Format

   Where the new AERO bits are defined as:

   A (1)  Set to 1 to indicate an AERO-specific Redirect message, and
      set to 0 to indicate an ordinary IPv6 Redirect message.

   P (1)  Set to 1 to indicate a Predirect message, and set to 0 to
      indicate a Redirect response to a Predirect message.  (This bit is
      valid only when the A bit is set to 1.)

   R (1)  Set to 1 to indicate that this message has already been
      Relayed by an intermediate router; otherwise, set to 0.  (This bit
      is valid only when the A bit is set to 1.)

   In the reference operational scenario, when intermediate router 'A'
   forwards a packet sent by ingress node 'B' toward egress node 'D', it
   also sends a Predirect message forward toward 'D', subject to rate
   limiting (see Section 8.2 of [RFC4861]).  'A' prepares the Predirect
   message in a similar fashion as for an ordinary IPv6 Redirect message
   as follows:




Templin                   Expires July 30, 2012                [Page 14]

Internet-Draft                     VET                      January 2012


   o  the link-layer source address is set to 'L2(A)' (i.e., the L2
      address of the intermediate router).

   o  the link-layer destination address is set to 'L2(D)' (i.e., the L2
      address of the egress node).

   o  the network-layer source address is set to 'L3(B)' (i.e., the L3
      address of the ingress node).

   o  the network-layer destination address is set to 'L3(D)'. (i.e.,
      the L3 address of the egress node).

   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)' (i.e., the L2 address of the ingress node).

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

   o  the AERO bits in the Predirect message header are set to A=1; P=1;
      R=0.

   'A' then sends the Predirect message forward to 'D'.

4.4.5.  Processing Predirects and Sending Redirects

   When an AERO link egress node receives an AERO Predirect message
   (i.e., a Redirect message with A=1; P=1), it accepts the message only
   if it satisfies the data origin authentication requirements specified
   in Section 4.4.3.  Next, the node validates the message according to
   the ICMPv6 Redirect message validation rules in Section 8.1 of
   [RFC4861].

   In the reference operational scenario, when egress router 'D'
   receives a Predirect it creates a neighbor cache entry (if necessary)
   that stores the source address of the Predirect message (i.e.,
   'L3(B)') and records the prefixes associated with the packet that
   triggered the Predirect with the neighbor cache entry.  'D' then sets



Templin                   Expires July 30, 2012                [Page 15]

Internet-Draft                     VET                      January 2012


   ACCEPT=TRUE for the neighbor cache entry and sets/resets an
   expiration timer to ACCEPT_TIME seconds.  If the timer later expires,
   'D' sets ACCEPT=FALSE.

   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)' (i.e., the L2
      address of the egress node).

   o  the link-layer destination address is set to 'L2(A)' (i.e., the L2
      address of the intermediate router).

   o  the network-layer source address is set to 'L3(D)' (i.e., the L3
      address of the egress node).

   o  the network-layer destination address is set to 'L3(B)' (i.e., the
      L3 address of the ingress node).

   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 Target Link Layer Address Option (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
      the originating packet.

   o  the Redirect message includes an RHO copied from the corresponding
      Predirect message.

   o  the AERO bits in the Redirect message header are set to A=1; P=0;
      R=0.

   After 'D' prepares the Redirect message, it sends the message to 'A'.

4.4.6.  Relaying Redirects

   When an intermediate router receives an AERO Redirect message (i.e.,
   one with A=1; P=0; R=0), it accepts the message only if it satisfies
   the data origin authentication requirements specified in Section
   4.4.3.  Next, the router validates the message according to the
   ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861].
   The router then "relays" the Redirect message back to the original



Templin                   Expires July 30, 2012                [Page 16]

Internet-Draft                     VET                      January 2012


   ingress node as follows.

   In the reference operational scenario, intermediate router 'A'
   receives the Redirect message from egress router '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'
   finally sets the AERO R bit to 1 and relays the Redirect message to
   ingress node 'B'.

   This relaying procedure therefore requires the intermediate AERO
   router to examine the R bit before relaying a Redirect message in
   order to avoid a free-running loop due to the non-decrementing
   hopcount.  In particular, the intermediate router discards any AERO
   Redirect message it receives with R==1.

4.4.7.  Processing Redirects

   When an ingress node receives an AERO Redirect message (i.e., one
   with A=1; P=0), it accepts the message only if it satisfies the data
   origin authentication requirements specified in Section 4.4.3.  Next,
   the node validates the message according to the ICMPv6 Redirect
   message validation rules in Section 8.1 of [RFC4861].  The node then
   processes the message as follows.

   In the reference operational scenario, when ingress node 'B' receives
   the (relayed) Redirect message it creates a neighbor cache entry (if
   necessary) that stores the source address of the Redirect message
   (i.e., 'L3(D)') and records the prefixes associated with the
   triggering packet with the neighbor cache entry.  'B' then sets
   FORWARD=TRUE for the neighbor cache entry and sets/resets an
   expiration timer to FORWARD_TIME seconds.  If the timer later
   expires, 'D' sets FORWARD=FALSE.

   Now, 'B' has a neighbor cache entry for 'D" with FORWARD==TRUE, and
   'D' has a neighbor cache entry for 'B' with ACCEPT=TRUE.  Therefore,
   'B' may forward ordinary network-layer data packets with destination
   addresses covered by 'D's prefixes directly to 'D' without involving
   'A'.

   To enable packet forwarding in the reverse direction, a separate AERO
   redirection operation is required which is the mirror-image of the
   forward operation described above, i.e., the forward and reverse AERO
   operations are asymmetric.  Following the reverse operation, 'B' and
   'D' can exchange packets bidirectionally without involving 'A'.





Templin                   Expires July 30, 2012                [Page 17]

Internet-Draft                     VET                      January 2012


4.4.8.  Sending Periodic Predirect Keepalives

   In order to prevent neighbor cache 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 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)' (i.e., the L2
      address of the ingress node).

   o  the link-layer destination address is set to 'L2(D)' (i.e., the L2
      address of the egress node).

   o  the network-layer source address is set to 'L3(B)' (i.e., the L3
      address of the ingress node).

   o  the network-layer destination address is set to 'L3(D)' (i.e., the
      L3 address of the egress node).

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

   o  the AERO bits in the Predirect message header are set to A=1; P=1;
      R=0.

   When 'D' receives the Predirect message, it accepts the message only
   if it satisfies the Predirect message validation rules given in
   Section 4.4.4.  'D' then resets its accept timer for node 'B' to
   ACCEPT_TIME seconds, and sends a Redirect message directly to 'B'
   prepared as follows:

   o  the link-layer source address is set to 'L2(D)' (i.e., the L2
      address of the egress node).

   o  the link-layer destination address is set to 'L2(B)' (i.e., the L2
      address of the ingress node).

   o  the network-layer source address is set to 'L3(D)' (i.e., the L3
      address of the egress node).




Templin                   Expires July 30, 2012                [Page 18]

Internet-Draft                     VET                      January 2012


   o  the network-layer destination address is set to 'L3(B)' (i.e., the
      L3 address of the ingress node).

   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 AERO bits in the Redirect message header are set to A=1; P=0;
      R=0.

   When 'B' receives the Redirect message, it accepts the message only
   if it satisfies the redirect message validation rules given in
   Section 4.4.6.  'B' then resets its forwarding timer for node 'D' to
   FORWARD_TIME seconds.

4.4.9.  Reachability Considerations

   When an ingress node receives a Redirect message informing it of a
   direct path to a new egress node, there is a question in point as to
   whether the new egress can be reached directly without involving an
   intermediate router.  On some AERO links, it may be reasonable for
   the ingress to (optimistically) assume that reachability is
   transitive, and to immediately begin forwarding data packets to the
   egress without testing reachability.

   On AERO links in which an optimistic assumption of transitive
   reachability may be unreasonable, however, the ingress can defer the
   redirection until it tests the direct path to the egress by sending a
   Predirect message to elicit a Redirect as specified in Section 4.4.7.
   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.

   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.4.10.  Mobility Considerations

   Again with reference to Figure 3, AERO edge router 'D' can configure
   both a non-advertising router interface on a provider AERO link and
   advertising router interfaces on its connected EUN links.  When node
   'E' in one of 'D's connected EUNs moves to a different network point
   of attachment, however, 'E' can release its address/prefix
   delegations that were registered with 'D' and re-establish them via a
   different router.



Templin                   Expires July 30, 2012                [Page 19]

Internet-Draft                     VET                      January 2012


   When 'E' releases its address/prefix delegations, 'D' marks the
   forwarding table entries that cover the addresses/prefixes as
   "departed".  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 correspondent neighbor '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 AERO bits in the Redirect message header are set to A=1; P=0;
      R=0.

   Eventually, any such correspondent neighbors will receive 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 a trusted
   intermediate router and may subsequently receive new Redirect
   messages to discover that 'E' is now associated with a new edge AERO
   router.  Note that any packets forwarded by 'D' via a departed
   forwarding table entry 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.4.11.  Backward Compatibility

   If a legacy host or router receives an AERO Redirect or Predirect
   message, it will process the message as if it were an ordinary
   Redirect.  This will cause no harmful effects, since the legacy
   system will safely ignore the AERO bits in the Reserved field, and
   will also ignore any RIOs that are included.  The values encoded in
   the Redirect message target and destination addresses will also not
   cause the legacy node to create incorrect forwarding state.  The
   mechanism therefore causes no harm to legacy systems, and supports



Templin                   Expires July 30, 2012                [Page 20]

Internet-Draft                     VET                      January 2012


   natural incremental deployment.


5.  IANA Considerations

   This document defines new bits taken from the ICMPv6 Redirect message
   header Reserved field.  There is currently no registration procedure
   for such bits, so there are no IANA considerations for this document.


6.  Security Considerations

   AERO link security is dependent on a trust basis between edge nodes
   and intermediate routers.  In particular, edge nodes must only engage
   in the AERO mechanism when it is facilitated by a trusted
   intermediate router.

   AERO links must be protected against spoofing attacks in which an
   attacker on the link pretends to be a trusted neighbor.  This is
   often possible on links that provide L2 securing mechanisms (e.g.,
   WiFi networks) and on links that provide physical security (e.g.,
   enterprise network LANs).  In other instances, sufficient assurances
   against on-link spoofing attacks are possible if the source can
   digitally sign its messages.  In that case, the destination can use
   the data origin authentication checks specified in Section 4.4.3 to
   verify the signature.


7.  Acknowledgements

   Discussions both on the v6ops list and in private exchanges helped
   shape some of the concepts in this work.  Individuals who contributed
   insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant,
   Brian Carpenter, Joel Halpern, Lee Howard,


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.



Templin                   Expires July 30, 2012                [Page 21]

Internet-Draft                     VET                      January 2012


   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

8.2.  Informative References

   [I-D.templin-intarea-vet]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-intarea-vet-33 (work in progress),
              December 2011.

   [I-D.templin-ironbis]
              Templin, F., "The Internet Routing Overlay Network
              (IRON)", draft-templin-ironbis-10 (work in progress),
              December 2011.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
              Domains without Explicit Tunnels", RFC 2529, March 1999.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd)", RFC 5569, January 2010.






Templin                   Expires July 30, 2012                [Page 22]

Internet-Draft                     VET                      January 2012


Appendix A.  Intermediate Router Interworking

   Figure 3 depicts a reference AERO operational scenario with a single
   intermediate router on the AERO link.  In order to support scaling to
   larger numbers of nodes, the AERO link can deploy multiple
   intermediate routers, e.g., as shown in Figure 5

       +--------------+                        +--------------+
       | Intermediate |    +--------------+    | Intermediate |
       |   Router C   |    | Core Router D|    |   Router E   |
       | (default->D) |    | (A->C; G->E) |    | (default->D) |
       |    (A->B)    |    +--------------+    |    (G->F)    |
       +-------+------+                        +------+-------+
               |                                      |
       X---+---+--------------------------------------+---+---X
           |                  AERO Link                   |
     +-----+--------+                            +--------+-----+
     |  AERO Node B |                            |  AERO Node F |
     | (default->C) |                            | (default->E) |
     +--------------+                            +--------------+
            .-.                                        .-.
         ,-(  _)-.                                  ,-(  _)-.
      .-(_ IPv6  )-.                              .-(_ IPv6  )-.
    (__   EUN A     )                           (__   EUN G     )
       `-(______)-'                                `-(______)-'
             |                                          |
         +--------+                                +--------+
         | Host A |                                | Host G |
         +--------+                                +--------+

                  Figure 5: Multiple Intermediate Routers

   In this example, AERO node 'B' associates with intermediate router
   'C', while AERO node 'F' associates with intermediate router 'E'.
   Furthermore, intermediate routers 'C' and 'E' do not associate with
   each other directly, but rather have an association with a "core"
   router 'D' (i.e., a router that has full topology information
   concerning its associated intermediate routers).  The core router may
   connect to either the AERO link, or to other physical or virtual
   links to which the intermediate routers also connect.

   When ingress AERO node 'B' forwards a packet from host 'A' toward
   host 'G', it sends the packet to intermediate router 'C' in absence
   of more-specific forwarding information.  Intermediate router 'C' in
   turn generates a "pseudo Predirect" message that is through some
   means conveyed through core router 'D' to intermediate router 'E'.
   When 'E' receives the pseudo Predirect, it sends an actual Predirect
   message to egress AERO node 'F'.



Templin                   Expires July 30, 2012                [Page 23]

Internet-Draft                     VET                      January 2012


   After processing the Predirect, AERO node 'F' sends a Redirect
   message to intermediate router 'E'.  Intermediate router 'E' in turn
   generates a "pseudo Redirect" that is through some means conveyed
   through core router 'D' to intermediate router 'C'.  When 'C'
   receives the pseudo Redirect, it sends an actual Redirect message to
   ingress AERO node 'B', thus completing the AERO redirection.

   The interworkings between intermediate and core routers (including
   the conveyance of pseudo Predirects and Redirects) must be carefully
   coordinated in a manner outside the scope of this document.  In
   particular, the intermediate and core routers must ensure that no
   routing loops are formed.  See [I-D.templin-ironbis] for an
   architectural discussion of coordinations between intermediate and
   core routers.


Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org


























Templin                   Expires July 30, 2012                [Page 24]


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