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

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5720

Network Working Group                                    F. Templin, Ed.
Internet-Draft                                      Boeing Phantom Works
Intended status: Informational                         December 19, 2008
Expires: June 22, 2009


     Routing and Addressing in Next-Generation EnteRprises (RANGER)
                      draft-templin-ranger-05.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 22, 2009.

Copyright Notice

   Copyright (c) 2008 IETF Trust and the persons identified as the
   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.

Abstract

   Next-generation enterprise networks including the global Internet
   itself will require an architected solution for the coordination of



Templin                   Expires June 22, 2009                 [Page 1]

Internet-Draft                   RANGER                    December 2008


   internal routing and addressing plans with considerations for
   scalability, mobility, multi-homing and security.  Additionally,
   next-generation networks will require support for both Internet
   protocol versions (IPv4 and IPv6) for an indeterminant period;
   perhaps even indefinitely.  These considerations are particularly
   true for existing deployments, but the same principles apply even for
   clean-slate approaches.  The RANGER architecture addresses these
   requirements, and provides a comprehensive framework for IPv6/IPv4
   coexistence.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The RANGER Architecture  . . . . . . . . . . . . . . . . . . .  6
     3.1.  The Enterprise-within-Enterprise Framework . . . . . . . .  6
     3.2.  Virtual Enterprise Traversal (VET) . . . . . . . . . . . .  8
       3.2.1.  Organizational Principles  . . . . . . . . . . . . . .  9
       3.2.2.  Dynamic Routing  . . . . . . . . . . . . . . . . . . . 10
       3.2.3.  Support for Legacy Services  . . . . . . . . . . . . . 11
     3.3.  Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 13
     3.4.  Mobility Management  . . . . . . . . . . . . . . . . . . . 14
     3.5.  Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Related Initiatives  . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  6over4 and ISATAP  . . . . . . . . . . . . . . . . . . . . 16
     4.2.  The Locator Identifier Split Protocol (LISP) . . . . . . . 16
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20

















Templin                   Expires June 22, 2009                 [Page 2]

Internet-Draft                   RANGER                    December 2008


1.  Introduction

   Next-generation enterprise networks including the global Internet
   itself will require an architected solution for the coordination of
   internal routing and addressing plans with considerations for
   scalability, mobility, multi-homing and security.  Additionally,
   next-generation networks will require support for both Internet
   protocol versions (IPv4 and IPv6) for an indeterminant period;
   perhaps even indefinitely.  These considerations are particularly
   true for existing deployments, but the same principles apply even for
   clean-slate approaches.  The RANGER architecture addresses these
   requirements, and provides a comprehensive framework for IPv6/IPv4
   coexistence [I-D.arkko-townsley-coexistence].

   RANGER is a scalable architecture for routing and addressing in next-
   generation enterprises that may either comprise a single interior
   addressing domain or contain multiple disjoint interior addressing
   domains.  Each of these domains may coordinate their own internal
   addressing plans independently of one another such that limited-scope
   addresses (e.g., [RFC1918] private-use IPv4 addresses) may be reused
   with impunity to provide unlimited scaling through spatial reuse.
   Each addressing domain therefore appears as an enterprise unto
   itself, such that a model of recursively nested "enterprises-within-
   enterprises" is enabled.  Logical or physical partitioning of an
   enterprise into multiple sites is also possible and beneficial in
   many scenarios.

   Without an architected approach, routing and addressing within such a
   framework would be fragmented due to limited-scope address/prefix
   reuse between disjoint addressing domains.  With RANGER, however, the
   enterprise can be unified via a virtual overlay architecture
   mainfested by automatic tunneling over disjoint domains
   interconnected via border routers.

   RANGER provides an architecture for operation of virtual overlay
   networks within a diverse range of enterprise network scenarios.
   While this document discusses the specific example of IPv6 as a
   virtual overlay over or IPv4 networks, it is important to note that
   the same architectural principles apply to any combination of IP*
   virtual overlays over IP* networks.

   The RANGER architecture builds on mechanisms documented in the IRTF
   and IETF technical communities.  Composite technologies are found in
   the Virtual Enterprise Traversal (VET) [I-D.templin-autoconf-dhcp],
   Subnetwork Encapsulation and Adaptation Layer (SEAL)
   [I-D.templin-seal] and Intra-Site Automatic Tunnel Addressing
   Protocol (ISATAP) [RFC5214][I-D.templin-isatapv4] specifications.




Templin                   Expires June 22, 2009                 [Page 3]

Internet-Draft                   RANGER                    December 2008


   The RANGER architectural principles can be traced to the
   deliberations of the ROAD group in January 1992 [RFC1380], and also
   to still earlier works including NIMROD [RFC1753], the Catenet model
   for internetworking [CATENET][IEN48] [RFC2775], and many others.
   [RFC1955] captures the high-level architectural aspects of the ROAD
   group deliberations in a "New Scheme for Internet Routing and
   Addressing [ENCAPS] for IPNG".


2.  Terminology

   commons
      a routing region within an enterprise that provides a subnetwork
      for cooperative peering between the border routers of diverse
      organizations that may have competing interests.  A prime example
      of a commons is the Default Free Zone (DFZ) of the global
      Internet.

   enterprise
      the same as defined in [RFC4852], where the enterprise deploys a
      unified routing and addressing plan within the commons, but may
      contain many disjoint interior addressing domains and/or
      organizational groupings that can be considered as enterprises
      unto themselves.  An enterprise therefore need not be "one big
      happy family", but instead provides a commons for the cooperative
      interconnection of diverse organizations that may have competing
      interests (e.g., such as the case within the global Internet
      default free zone).

      Enterprise networks are typically associated with large
      corporations or academic campuses, however the RANGER
      architectural principles apply to any network that has some degree
      of cooperative active management.  This definition can therefore
      be extended to home networks, small office networks, a wide
      variety of mobile ad-hoc networks (MANETs), and even to the global
      Internet itself.

   site
      a logical and/or physical grouping of interfaces within a unified
      addressing region of an enterprise, where the topology of the site
      is a proper subset of the topology of the enterprise.  A site may
      contain many interior sites, which may themselves contain many
      interior sites in a recursive fashion.

      Throughout the remainder of this document, the term "enterprise"
      refers to either enterprise or site, i.e., the RANGER principles
      apply equally to enterprises and sites of any size or shape.  At
      the lowest level of decomposition, a singleton Border Router can



Templin                   Expires June 22, 2009                 [Page 4]

Internet-Draft                   RANGER                    December 2008


      be considered as an enterprise unto itself.

   Border Router (BR)
      a node at the edge of an enterprise that is also configured as a
      router in an overlay network.  BRs connect their directly-attached
      networks to the overlay network, and connect to other networks via
      IP-in-IP tunneling across the commons to other BRs.

   Border Gateway (BG)
      a BR that also connects the enterprise to provider networks and/or
      to the global Internet.  BGs are typically configured as default
      routers in the overlay, and provide forwarding services for
      accessing IP networks not reachable via a BR within the commons.

   overlay network
      a virtual network manifested by routing and addressing over
      virtual links formed through automatic tunneling.  An overlay
      network may span many underlying enterprises.

   6over4
      Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
      [RFC2529]; functional specifications and operational practices for
      automatic tunneling of unicast/multicast IPv6 packets over
      multicast-capable IPv4 enterprises.

   ISATAP
      Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
      [RFC5214][I-D.templin-isatapv4]; functional specifications and
      operational practices for automatic tunneling over unicast-only
      enterprises.

   VET
      Virtual Enterprise Traversal (VET) [I-D.templin-autoconf-dhcp];
      functional specifications and operational practices that provide a
      functional superset of 6over4 and ISATAP.  In addition to both
      unicast and multicast tunneling, VET also supports address/prefix
      autoconfiguration as well as additional encapsulations such as
      IPSec, SEAL, LISP, etc.

   SEAL
      Subnetwork Encapsulation and Adaptation Layer (SEAL)
      [I-D.templin-seal]; a functional specification for robust packet
      identification and link adaptation over tunnels.  SEAL supports
      effective egress filtering and adapts to subnetworks configured
      over links with diverse characteristics.






Templin                   Expires June 22, 2009                 [Page 5]

Internet-Draft                   RANGER                    December 2008


3.  The RANGER Architecture

   The RANGER architecture enables scalable routing and addressing in
   next-generation enterprise networks with sustaining support for
   legacy networks and services.  Key to this approach is a framework
   that accommodates interconnection of diverse organizations within the
   enterprise with a mutual spirit of cooperation, but with the
   potential for competing interests.  The following sections outline
   the RANGER architecture within the context of anticipated use cases:

3.1.  The Enterprise-within-Enterprise Framework

   Enterprise networks traditionally distribute routing information via
   Interior Gateway Protocols (IGPs) such as Open Shortest Path First
   (OSPF), while large enterprises may even use an Exterior Gateway
   Protocol (EGP) internally in place of an IGP.  In particular, it is
   becoming increasingly commonplace for large enterprises to use the
   Border Gateway Protocol (BGP) internally and independently from the
   BGP instance that maintains the routing information base within the
   global Internet Default Free Zone (DFZ).

   As such, large enterprises may run an internal instance of BGP across
   many internal Autonomous Systems (ASs).  Such a large enterprise can
   therefore appear as an Internet unto itself, albeit with default
   routes leading to the true global Internet.  Additionally, each
   internal AS within such an enterprise may itself run BGP internally
   in place of an IGP, and can therefore also appear as an independent
   lower-tier enterprise unto itself.  This enterprise-within-enterprise
   framework can be extended in a hierarchical fashion as broadly and as
   deeply as desired to acheive scaling factors as well as
   organizational and/or functional compartmentalization, e.g., as shown
   in Figure 1.



















Templin                   Expires June 22, 2009                 [Page 6]

Internet-Draft                   RANGER                    December 2008


                               ,---------------.
                            ,-'     Global      `-.  <--------+
                           (       IPv6/IPv4       )     ,----|-----.
                            `-.    Internet     ,-'     ( Enterprises)
                               `+--+..+--+ ...+--+      ( E2 thru EN )
                             _.-|R1|--|R2+----|Rn|-._    `.---------/
                      _.---''   +--+  +--+ ...+--+   -.
                 ,--''           ,---.                 `---.
              ,-'              X5     X6            .---..  `-.
            ,'  ,.X1-..       /         \        ,'       `.   `.
          ,'  ,'       `.    .'  E1.2   '.     X8    E1.m   \    `.
         /   /           \   |   ,--.    |     / _,.._       \     \
        /   /   E1.1      \  | Y3    `.  |    | /     Y7       |     \
       ;   |    ___        | |  ` W  Y4  |... | `Y6  ,'       |      :
       |   | ,-'   `.     X2 |   `--'    |    |   `''         |      |
       :   | |  V  Y2      | \    _      /    |               |      ;
        \  | `-Y1,,'       |  \ .' Y5   /      \    ,-Y8'`-   /      /
         \  \             /    \ \_'  /        X9   `.    ,'/      /
          `. \          X3      `.__,,'          `._  Y9'','     ,'
            ` `._     _,'      ___.......X7_        `---'      ,'
              `  `---'      ,-'             `-.              -'
                 `---.      `.    E1.3   Z   _'        _.--'
                      `-----. \---.......---'   _.---''
                             `----------------''

           <----------------   Enterprise E1  ---------------->

             Figure 1: Enterprise-within-Enterprise Framework

   Figure 1 depicts an enterprise 'E1' connected to the global IPv6/IPv4
   Internet via routers 'R1' through 'Rn' and additional enterprises
   'E2' through 'EN' that also connect to the global Internet.  Within
   the 'E1' commons, there may be arbitrarily-many hosts, routers and
   networks (not shown in the diagram) over which both unencapsulated IP
   packets and IP-in-IP encapsulated packets can be forwarded.  There
   may also be many lower-tier enterprises 'E1.1' through 'E1.m' (shown
   in the diagram) that interconnect within the 'E1' commons via Border
   Routers (BRs) depicted as 'X1' through 'X9' (where 'X1' through 'X9'
   see 'R1' through 'Rn' as Border Gateways (BGs)).  Within each 'E1.*'
   enterprise, there may also be arbitrarily-many lower-tier enterprises
   that interconnect within the 'E1.*' commons via BRs depicted as 'Y1'
   through 'Y9' in the diagram (where 'Y1' through 'Y9' see 'X1' through
   'X9' as BGs).  This hierarchical decomposition can be recursively
   nested as deeply as desired, and ultimately terminates at singleton
   nodes such as those depicted as 'V', 'W' and 'Z' in the diagram.

   It is important to note that nodes such as 'V', 'W' and 'Z' may be
   simple hosts, or they may be BRs that attach arbitrarily-complex edge



Templin                   Expires June 22, 2009                 [Page 7]

Internet-Draft                   RANGER                    December 2008


   networks.  Such edge networks could be as simple as a home network
   behind a residential gateway or as complex as a major corporate/
   academic campus, a large service provider network, etc.

   Again, this enterprise-within-enterprise framework can be recursively
   nested as broadly and deeply as desired.  From the ultimate level of
   the hierarchy, consider now that the global Internet itself can be
   viewed as an "enterprise" that interconnects lower-tier enterprises
   E1 through EN such that all RANGER architectural principles apply
   equally within that context.

   As a specific case in point, the future global Aeronautical
   Telecommuncations Network (ATN) under consideration within the civil
   aviation industry [I-D.bauer-mext-aero-topology] will take the form
   of a large enterprise network that appears as an Internet unto
   itself, i.e., exactly as depicted for 'E1' in Figure 1.  Within the
   ATN, there will be many Air Communications Service Provider (ACSP)
   and Air Navigation Service Provider (ANSP) networks organized as
   autonomous systems internal to the ATN, i.e., exactly as depicted for
   'E1.*' in the diagram.  The ACSP/ANSP network BGs will participate in
   a BGP instance internal to the ATN, and may themselves run
   independent BGP instances internally that are further sub-divided
   into lower-tier enterprises organized as regional, organizational,
   functional, etc. compartments.  It is important to note that, while
   ACSPs/ANSPs within the ATN will share a common objective of safety-
   of-flight for civil aviation services, there may be competing
   business/social/political interests between them such that the ATN is
   not necessarily "one big happy family".  Therefore, the model
   parallels that of the global Internet itself.

   Such an operational framework may indeed be the case for many next-
   generation enterprises.  In particular, although the routing and
   addressing arrangements of all enterprises will require a mutual
   level of cooperative active management at a certain level, free
   market forces, business objectives, political alliances, etc. may
   drive internal competition.

3.2.  Virtual Enterprise Traversal (VET)

   Within the enterprise-within-enterprise framework outlined in
   Section 3.1, the RANGER architecture is based on an overlay network
   approach manifested through Virtual Enterprise Traversal (VET)
   [I-D.templin-autoconf-dhcp] [RFC5214][I-D.templin-isatapv4].  The
   approach uses automatic IP-in-IP tunneling within a hierarchy of
   lower-tier enterprises that are either configured within the same
   addressing region of a parent enterprise or use their own enterprise-
   local routing and addressing internally.




Templin                   Expires June 22, 2009                 [Page 8]

Internet-Draft                   RANGER                    December 2008


   VET and its related works specify the necessary mechanisms and
   operational practices to manifest the RANGER architecture.  The use
   of VET in conjunction with SEAL (see: Section 3.3) is essential in
   certain deployments to avoid issues related to source address
   spoofing and Maximum Transmission Unit (MTU) determination.  The
   following sections discuss operational considerations and use cases
   within the VET approach:

3.2.1.  Organizational Principles

   In the VET approach, logically and/or physically disjoint lower-tier
   enterprises are connected by BGs that appear as BRs within the parent
   enterprise.  In turn, BRs within the parent enterprise request IP
   prefix delegations from BGs that connect to upper-tier enterprises.
   The prefixes could be either provider-independent prefixes owned by
   the BR or provider-aggregated prefixes delegated by the BG, but the
   prefix delegation process is linked with routing over the virtual
   topology in both cases.  Additionally, fault tolerance and
   multihoming is naturally afforded through configuration of multiple
   BGs per enterprise.

   Figure 2 below depits a vertical slice (albeit represented
   horizontally) from the enterprise-within-enterprise framework shown
   in Figure 1.  In this example, an IPv6 host 'H' that is deeply nested
   within Enterprise 'E1' connects to IPv6 server 'S1' located somewhere
   on the IPv6 Internet.  Again, while this and other examples speak of
   the specific instance of IPv6-in-IPv4 encapsulation, the same
   principles apply to any IP-in-IP encapsulation:
                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "   2001:DB8::/56   2001:DB8::/48  2001:DB8::/40"      +--+---+
    "    . . . . . . .       . . . .      . . . .     "        |
   "   .               .    .       .    .       .    "        |
   "   .  +----+   v    +--- +   v  +----+   v   +----+  +-----+-------+
   "   .  | V  +=  e   =+ Y1 +=  e =+ X2 +=  e  =+ R2 +==+   Internet  |
   "   .  +-+--+   t    +----+   t  +----+   t   +----+  +-----+-------+
   "   .    |      1   .    .    2  .    .   3   .    "        |
   "    .   H         .     .       .    .       .    "        |
   "      . . . . . .        . . . .      . . . .     "     +--+---+
    "       <E1.1.1>         <E1.1>        <E1>       "     | IPv4 |
      "      10/8             10/8         10/8      "      |Server|
        " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                     <-- Enterprise E1 -->                  +------+

                  Figure 2: Virutal Enterprise Traversal




Templin                   Expires June 22, 2009                 [Page 9]

Internet-Draft                   RANGER                    December 2008


   Within this vertical slice, Figure 2 depicts each enterprise within
   the 'E1' hierarchy as spanned by automatic IPv6-in-IPv4 tunnels
   'vet1' through 'vet3'.  Each 'vet*' interface within this framework
   is Non-Broadcast, Multiple Access (NBMA), and connects all BRs within
   the same enterprise.  Each enterprise within the 'E1' hierarchy may
   comprise a smaller topological region within a larger IPv4 routing
   region, or they may configure an independent routing and addressing
   plan from a common (but spatially reused) limited-scope IPv4 prefix,
   e.g., depicted as '10/8' in the diagram.  The BR for each 'E1*'
   enterprise receives an IPv6 prefix delegation from a delegating BG,
   depicted above as sub-delegations of the prefix '2001:DB8::/40'.

   In this example, a simple IPv6 host 'H' is attached to a shared link
   with IPv6/IPv4 dual stack node 'V'.  IPv6 host 'H' uses standard IPv6
   neighbor discovery mechanisms to discover 'V' as a default IPv6
   router that can forward its packets off the local link, while 'V'
   sees node 'Y1' as a BG that can be reached via 'vet1' and that can
   forward packets toward IPv6 server 'S1'.  Similarly, node 'Y1' is a
   BR on the enterprise spanned by 'vet2' that sees 'X2' as a BG, and
   node 'X2' is a BR on 'vet3' that sees 'R2' as a BG.  Ultimately, 'R2'
   is a BR that connects 'E1' to the global Internet.

   In this and other examples, it is specifically worth noting that a BR
   may have potentially many VET interfaces over which it can connect to
   the BRs/BGs of neighboring enterprises across the commons.

3.2.2.  Dynamic Routing

   In the example shown in Figure 2, VET allows 'V', 'Y1', 'X2' and 'R2'
   to configure separate 'vet*' interfaces for each enterprise they
   connect to and to discover BRs/BGs through a mapping database and/or
   a dynamic routing protocol.  After tunnels 'vet1' through 'vet3' are
   established and BG's discovered, the BRs connected to a 'vet*'
   interface can run a dynamic routing protocol such as OSPVFv3
   [RFC5340] and form adjacencies between themselves in an on-demand
   fashion while treating the 'vet*' interface as an ordinary link.  It
   is important to note that adjacencies can be formed on-demand and
   allowed to expire after idle periods such that a full mesh of links
   need not be maintained.  This allows an overlay network that spans
   'E1' to dynamically adapt to changing conditions within the
   enterprise.

   In a second example, Figure 3 depicts an instance of on-demand
   discovery of more-specific routes in which an IPv6 host 'H' connects
   to an IPv6 server 'J' located in a different organizational entity
   within 'E1':





Templin                   Expires June 22, 2009                [Page 10]

Internet-Draft                   RANGER                    December 2008


                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "  2001:DB8::/56    2001:DB8::/48  2001:DB8::/40"      +--+---+
    "    . . . . . . .       . . . .      . . . .     "        |
   "   .               .    .       .    .       .    "        |
   "   .  +----+   v   +----+   v   +----+       +----+  +-----+-------+
   "   .  | V  +=  e  =+ Y1 +=  e  =+ X2 +=     =+ R2 +==+   Internet  |
   "   .  +-+--+   t   +----+   t   +----+       +----+  +-----+-------+
   "   .    |      1   .    .   2   .    .       .    "        |
   "    .   H         .     .       .    .   v   .    "        |
   "      . . . . . .        . . . .     .   e   .    "     +--+---+
   "                                     .   t   .    "     | IPv4 |
   "                  . . . . . . ,      .   3   .    "     |Server|
   "                .  +----+   v   +----+       .    "     |  S2  |
   "                .  | Z  +=  e  =+ X7 +=      .    "     +------+
   "                .  +-+--+   t   +----+       .    "
   "                .    |      4   .    .       .    "
   "                .    J         .      . . . .     "
    "                 . . . . . . .                   "
      "           2001:DB8:1::/56     2001:DB8:1::/40"
        " " " " " " " " " " " " " " "" " " " " " " "
                     <-- Enterprise E1 -->

                       Figure 3: On-Demand Discovery

   In this example, tunnel interfaces 'vet1' through 'vet4' as well as
   IPv6 prefix delegations have been established through VET enterprise
   autoconfiguration procedures [I-D.templin-autoconf-dhcp].  When IPv6
   host 'H' sends IPv6 packets to server 'J', unless IPv6 routing
   information is available BR 'X2' must determine that 'J' can be
   reached using a more direct route via 'X7' across the 'E1' commons.
   To do so, 'X2' can perform an on-demand mapping lookup by consulting
   the enterprise name service.  Alternatively, 'X2' can send the packet
   to default router 'R2', and 'R2' can return an ICMPv6 redirect
   message indicating that 'J' can be reached via a more direct route
   through 'X7'.  When 'X2' receives a redirect from 'R2', it can then
   perform a SEcure Neighbor Discovery (SEND) [RFC3971] exchange with
   'X7' then forward subsequent directly packets via the route-optimized
   path to 'X7'.

3.2.3.  Support for Legacy Services

   While the overlay network that spans 'E1' provides a fully-connected
   routing and addressing capability for IP overlay services, access to
   legacy services will still be required for an extended (and possibly
   indefinite) period.  For example, Figure 4 below depicts the



Templin                   Expires June 22, 2009                [Page 11]

Internet-Draft                   RANGER                    December 2008


   applicable IPv4 service access models for the RANGER architecture
   when IPv6 is used as the overlay:

                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "  2001:DB8::/56    2001:DB8::/48  2001:DB8::/40"      +--+---+
    "    . . . . . . .       . . . .      . . . .     "        |
   "   .               .    .       .    .       .    "        |
   "   .  +----+   v   +--- +   v   +----+   v   +----+  +-----+-------+
   "   .  | V  +=  e  =+ Y1 +=  e  =+ X2 +=  e  =+ R2 +==+   Internet  |
   "   .  +----+   t   +----+   t   +----+   t   +----+  +-----+-------+
   "   .           1   .    .   2   .    .   3   .    "        |
   "    .   K   L     .     .       .    . M     .    "        |
   "      . . . . . .        . . . .      . . . .     "     +--+---+
    "       <E1.1.1>         <E1.1>        <E1>       "     | IPv4 |
      "                                              "      |Server|
        " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                     <-- Enterprise E1 -->                  +------+

                   Figure 4: Legacy IPv4 Service Support

   In a first instance, an IPv4 client 'K' within enterprise 'E1.1.1'
   can access IPv4 service 'L' within the same enterprise as-normal and
   without the need for any encapsulation.  Instead, a "mapping" is done
   through a simple name lookup within the enterprise-local name service
   deployed in 'E1.1.1', and enterprise-local native IPv4 services are
   used.  In many instances, this may indeed be the preferred service
   access model even when IPv6 services are widely deployed due to
   factors such as inability to replace legacy IPv4 applications, IPv6
   header overhead avoidance, etc.

   In a second instance, IPv4 client 'K' can access IPv4 server 'S2' on
   the global IPv4 Internet in a number of ways.  First, if the
   recursively nested enterprises are all configured within the same
   IPv4 routing region within E1, 'K' can simply forward its packets
   toward 'R2' that then acts as an IPv4 Network Address Translator
   (NAT) and/or an ordinary IPv4 enterprise border router.  Secondly, if
   the recursively nested enterprises are configured within disjoint
   IPv4 routing regions, all routers 'Y1', 'X2' and 'R2' can provide an
   IPv4 NAT capability however this approach requires multiple instances
   of stateful NAT devices on the path which can lead to an overall
   degree of brittleness and intolerance to routing changes.

   Instead, 'E1' could deploy a "Carrier-Grade NAT (CGN)" at 'R2' (i.e.,
   at the enterprise border with the global Internet) and E1.1.1 could
   discover 'Y1' as an IPv4 default router.  'Y1' could then use the



Templin                   Expires June 22, 2009                [Page 12]

Internet-Draft                   RANGER                    December 2008


   "dual-stack-lite" approach in which IPv4-in-IPv6-in-IPv4 tunneling
   conveys the IPv4 packets from 'K' to the CGN at 'R2', which then
   decapsulates and translates the inner IPv4 packets before sending
   them on to 'S2'.  Finally, 'K' could be configured as an IPv6-only
   node and use standard IPv6 routing to reach an IPv6/IPv4 translator
   located at an IPv6 BR for the enterprise in which 'S2' resides'.  The
   translator would then use IPv6-to-IPv4 translation before sending
   packets onwards toward 'S2'.  These and other alternatives are
   discussed in [I-D.wing-nat-pt-replacement-comparison].

   In a final instance, IPv4 client 'K' can access an IPv4 server 'M' in
   a different enterprise within E1 as long as both enterprises are
   configured over the same underlying IPv4 routing region.  If the
   enterprises are configured over disjoint IPv4 routing regions,
   however, 'K' would still be able to access 'M' using IPv6-only
   services, or by using IPv4 services if an IPv4 overlay were
   configured in parallel with the IPv6 overlay [I-D.templin-isatapv4].

3.3.  Subnetwork Encapsulation and Adaptation Layer (SEAL)

   Whenever the BRs of disjoint enterprises are joined across a commons,
   mechanisms that rely on ICMP feedback from routers within the network
   may become brittle or susceptible to spoofing attacks.  This is due
   to the fact that ICMP messages can be lost due to congestion or
   packet filtering gateways, and that network middleboxes are
   essentially "anonymous" and may include insufficient information in
   ICMPs that can be used to authenticate their source.  Of even greater
   concern is the fact that a rogue node from a different enterprise
   could send spoofed packets of any kind, e.g., for the purpose of
   mounting denial-of-service and traffic amplification attacks.

   The Subnetwork Encapsulation and Encapsulation Layer (SEAL) provides
   effective mitigations by only accepting packets from correspondent
   BRs that can be validated as topologically-correct routers within the
   commons (i.e., the subnetwork) using the SEAL 32-bit packet
   identification value and the Potential Router List (PRL)
   [I-D.templin-autoconf-dhcp].  Moreover, SEAL does not require
   reliable delivery of all ICMPs, but rather supports continued
   operation even if some/many ICMPs are lost.  Finally, SEAL adapts to
   subnetworks that contain links with diverse MTUs properties, and can
   use probing to identifiy marginal links within the path.

   The advantages of using SEAL in conjunction with the RANGER
   enterprise-within-enterprise framework are tangible, and compare
   favorably with the alternative of deploying an all-IPv6
   infrastructure even for clean-slate deployments.  This is especially
   true within enterprises that provide a commons for joining
   organizational/political/functional entities with a spirit of mutual



Templin                   Expires June 22, 2009                [Page 13]

Internet-Draft                   RANGER                    December 2008


   cooperation but with competing interests or objectives.

3.4.  Mobility Management

   Mobility management use cases must be considered along several
   different vectors:

   o  nomadic devices may be satisfied by client-only basic connectivity
      and can tolerate address renumbering events as they move between
      enterprise network attachment points.

   o  mobile devices with provider-independent addresses/prefixes may be
      satisfied by limited-scope routing updates within enterprises as
      long as they do not impart unacceptable churn.

   o  fast moving devices with provider-aggregated addresses/prefixes
      may require additional supporting mechanisms if their movement
      would impart unacceptable routing churn.

   Nomadic device mobility is already satisfied by currently deployed
   technologies.  For example, transporting a laptop computer from a
   wireless access hot spot to a home network LAN would allow the
   nomadic device to regain client-only basic network connectivity at
   the expense of terminated communication sessions.

   Mobile devices that use VET and SEAL can move freely between
   enterprises as long as they withdraw their provider-independent
   prefixes from the mapping/routing systems of departed enterprises and
   inject them into the mapping/routing systems of new enterprises.  For
   movements between lower-tier enterprises within a parent enterprise,
   such limited-scope updates alone can serve as an effective mobility
   management solution with acceptable churn; this is especially true
   when the updates can be isolated within the lower-tier enterprises
   and not leak out into the parent enterprise.  For enterprises that
   require in-the-network confidentiality, MobIKE [RFC4555] may also be
   useful within this context.

   Mobile devices that move quickly between disparate enterprise edge
   network attachment points may impart unacceptable routing churn and
   packet loss in service networks that cannot easily support a well-
   structure enterprise-within-enterprise framework.  Devices that
   connect to such networks should use provider-aggregated addresses/
   prefixes that can be coordinated via a rendezvous service in a home
   enterprise when the device moves to a visited enterprise.  Mobility
   management mechanisms such as Mobile IPv6 [RFC3775] and HIP [RFC4423]
   can be used to maintain a stable identifier for fast moving devices
   even as they move quickly between visited enterprise network
   attachment points.



Templin                   Expires June 22, 2009                [Page 14]

Internet-Draft                   RANGER                    December 2008


   As a use case in point, consider an aircraft with a mobile router
   moving between ground station points of attachment.  If the ground
   stations are located within the same enterprise, or within lower-tier
   sites of the same parent enterprise, it should suffice for the
   aircraft to announce its provider-independent prefixes at its new
   point of attachment and withdraw them from the old.  This would avoid
   excessive routing churn, since the prefixes need not be announced/
   withdrawn within the parent enterprise, i.e., routing churn is
   isolated to lower layers of the recursive hierarchy, which have much
   more finite scaling properties.  Note also that such movement would
   not entail an aircraft-wide readdressing event.

   As a second example, consider a wireless handset moving between
   service coverage areas maintained by independent providers with
   peering arrangements.  Since the coverage range of terrestrial
   cellular wireless technologies is limited, mobility events may occur
   on a much more aggressive timescale than some other examples.  In
   this case, the handset may expect to occur a readdressing event for
   its access interface at least, and may be obliged to arrange for a
   rendezvous linkage with its home network.

   It should specifically be noted that the contingency of mobility
   management solutions is not necessarily mutually exclusive, and must
   be considered in relation to specific use cases.  The RANGER
   architecture is therefore naturally inclusive in this regard.

3.5.  Multihoming

   As with mobility management, multi-homing use cases must be
   considered along multiple vectors.  Within an enterprise, BRs can
   discover multiple BGs and use them in a fault tolerant and load-
   balancing fashion as long as they register their provider-independent
   prefixes with each such BG.  At the enterprise edge, a true location/
   identity split approach such as HIP may be necessary for supporting
   true multihoming across multiple physical links with diverse
   properties.

   As a first case in point, consider the enterprise network of a major
   corporation that obtains services from a number of ISPs.  The
   corporation should be able to register its provider-independent
   prefixes with all of its ISPs, and use any of the ISPs for its
   Internet access services.  As a second use case, consider an aircraft
   with a diverse set of wireless links (e.g., VHF, 802.16, directional,
   SATCOM, etc.).  The aircraft should be able to select and utilize the
   most appropriate link(s) based on phase of flight, and change
   seamlessly between links as necessary.  Other examples include a
   nomadic laptop with both 802.11 and Ethernet links, a wireless
   handset with both CDMA wireless and 802.11, etc.



Templin                   Expires June 22, 2009                [Page 15]

Internet-Draft                   RANGER                    December 2008


   As with mobilitiy management, the contintingency of solutions is not
   necessarily mutually exclusive and can combine to suit use cases
   within the scope of the RANGER architecture.


4.  Related Initiatives

4.1.  6over4 and ISATAP

   Long before the RANGER architecture and VET/SEAL specifications were
   published, 6over4 [RFC2529] specified a means for automatic tunneling
   of unicast/multicast IPv6 packets over multicast-capable IPv4
   enterprises, however it was unable to function in enterprises that
   did not support a full deployment of IPv4 multicast services.

   To address these shortcomings, ISATAP [RFC5214][I-D.templin-isatapv4]
   was specified as a unicast-only variant of 6over4 and widely
   implemented among major software and equipment vendor products.
   ISATAP provides unicast-only neighbor discovery mechanisms and also
   adds a means for determining whether a node on an ISATAP interface is
   authorized to act as an IPv6 router; namely, the Potential Router
   List (PRL).

   VET provides a functional superset of the 6over4 and ISATAP
   mechanisms; VET further combines with SEAL to provide the functional
   elements of the RANGER architecture.

4.2.  The Locator Identifier Split Protocol (LISP)

   The Locator-Identifier Split Protocol (LISP) [I-D.farinacci-lisp]
   proposes a map-and-encaps architecture for scalable routing and
   addressing within the global Internet Default Free Zone (DFZ).
   Several companion documents (e.g., LISP-ALT, LISP-CONS, LISP-EMACS,
   LISP-NERD) propose mapping function solutions.  A related mapping
   function solution proposal is found in [I-D.jen-apt].

   LISP, and a number of related proposals being discussed in the
   Routing Research Group, share common properties with the solution
   proposed here.  They may therefore be architecturally consistent with
   the RANGER architecture.


5.  IANA Considerations

   There are no IANA considerations for this document.






Templin                   Expires June 22, 2009                [Page 16]

Internet-Draft                   RANGER                    December 2008


6.  Security Considerations

   Communications between endpoints within different sites inside an
   enterprise are carried across a commons that joins organizational
   entities with a mutual spirit of cooperation, but between which there
   may be competing business/sociological/political interests.  As a
   result, mechanisms that rely on feedback from routers on the path may
   become brittle or susceptible to spoofing attacks.  This is due to
   the fact that IP packets can be lost due to congestion or packet
   filtering gateways, and that the source addresses of IP packets can
   be forged.  Moreover, IP packets in general can be generated by
   anonymous attackers, e.g., from a rogue node within a third-party
   enterprise that has malicious intent toward a victim.

   Path MTU discovery is an example of a mechanism that relies on ICMP
   feedback from routers on the path, and as such is susceptible to
   these issues.  For IPv4, a common workaround is to disable Path MTU
   Discovery and let fragmentation occur in the network if necessary.
   For IPv6, lack of fragmentation support in the network precludes this
   option such that the mitigation typically recommended is to discard
   ICMP messages that contain insufficient information and/or to operate
   with the minimum IPv6 path MTU.  This example extends also to other
   mechanisms that either rely on or are enhanced by feedback from
   network devices, however attack vectors based on non-ICMP messages
   are also subject for concern.

   The RANGER architecture supports effective mitigations for attacks
   such as distributed denial-of-service, traffic amplification, etc.
   In particular, when VET and SEAL are used, enterprise BGs can use the
   32-bit identification encoded in the SEAL header as well as egress
   filtering to determine if a message has come from a topologically-
   correct enterprise located across the commons.  This allows
   enterprises to employ effective mitigations at their borders without
   the requirement for mutual cooperation from other enterprises.  When
   source address spoofing by on-path attackers located within the
   commons is also subject for concern, additional securing mechanisms
   such as tunnel-mode IPsec between enterprise BGs can also be used.

   BRs can obtain provider-independent prefixes through arrangements
   with a prefix delegation authority.  Thereafter, the BR must have a
   means of proving its ownership when it announces or withdraws the
   prefixes in enterprise routing systems.  This can be accommodated
   through the use of SEcure Neighbor Discovery (SEND) [RFC3971] as well
   as a means for confirming prefix ownership, e.g., through name
   service lookup.  The SEND mechanism is also useful for route
   optimization between lower-tier enterprises across a parent
   enterprise commons.




Templin                   Expires June 22, 2009                [Page 17]

Internet-Draft                   RANGER                    December 2008


   While the RANGER architecture does not in itself address security
   considerations, it proposes an architectural framework for functional
   specifications that do.  Security concerns with tunneling along with
   recommendations that are compatible with the RANGER architecture are
   found in [I-D.ietf-v6ops-tunnel-security-concerns].


7.  Acknowledgements

   This work was inspired through the encouragement of the Boeing DC&NT
   network technology team and through the communications of the IESG.

   Many individuals have contributed to the architectural principles
   that form the basis for RANGER over the course of many years.


8.  References

8.1.  Normative References

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

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

8.2.  Informative References

   [CATENET]  Pouzin, L., "A Proposal for Interconnecting Packet
              Switching Networks", May 1974.

   [I-D.arkko-townsley-coexistence]
              Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-
              Existence Scenarios", draft-arkko-townsley-coexistence-00
              (work in progress), September 2008.

   [I-D.bauer-mext-aero-topology]
              Bauer, C. and S. Ayaz, "ATN Topology Considerations for
              Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00
              (work in progress), July 2008.

   [I-D.farinacci-lisp]
              Farinacci, D., Fuller, V., Oran, D., Meyer, D., and S.
              Brim, "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-10 (work in progress), November 2008.

   [I-D.ietf-v6ops-tunnel-security-concerns]
              Hoagland, J., Krishnan, S., and D. Thaler, "Security



Templin                   Expires June 22, 2009                [Page 18]

Internet-Draft                   RANGER                    December 2008


              Concerns With IP Tunneling",
              draft-ietf-v6ops-tunnel-security-concerns-01 (work in
              progress), October 2008.

   [I-D.jen-apt]
              Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
              L. Zhang, "APT: A Practical Transit Mapping Service",
              draft-jen-apt-01 (work in progress), November 2007.

   [I-D.templin-autoconf-dhcp]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-autoconf-dhcp-24 (work in progress),
              December 2008.

   [I-D.templin-isatapv4]
              Templin, F., "Transmission of IPv4 Packets over ISATAP
              Interfaces", draft-templin-isatapv4-00 (work in progress),
              December 2008.

   [I-D.templin-seal]
              Templin, F., "The Subnetwork Encapsulation and Adaptation
              Layer (SEAL)", draft-templin-seal-23 (work in progress),
              August 2008.

   [I-D.wing-nat-pt-replacement-comparison]
              Wing, D., Ward, D., and A. Durand, "A Comparison of
              Proposals to Replace NAT-PT",
              draft-wing-nat-pt-replacement-comparison-02 (work in
              progress), September 2008.

   [IEN48]    Cerf, V., "The Catenet Model for Internetworking",
              July 1978.

   [RFC1380]  Gross, P. and P. Almquist, "IESG Deliberations on Routing
              and Addressing", RFC 1380, November 1992.

   [RFC1753]  Chiappa, J., "IPng Technical Requirements Of the Nimrod
              Routing and Addressing Architecture", RFC 1753,
              December 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.

   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4



Templin                   Expires June 22, 2009                [Page 19]

Internet-Draft                   RANGER                    December 2008


              Domains without Explicit Tunnels", RFC 2529, March 1999.

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              February 2000.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [RFC4852]  Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
              Green, "IPv6 Enterprise Network Analysis - IP Layer 3
              Focus", RFC 4852, April 2007.

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

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.


Author's Address

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

   Email: fltemplin@acm.org













Templin                   Expires June 22, 2009                [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/