Network Working Group                                    F. Templin, Ed.
Internet-Draft                                      Boeing Phantom Works
Intended status: Informational                          October 23,                         November 17, 2008
Expires: April 26, May 21, 2009

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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 April 26, May 21, 2009.

Abstract

   Enterprise networks will require support for both Internet protocol
   versions (IPv4 and IPv6) for an indeterminant period; perhaps even
   indefinitely.  This is particularly true for existing enterprise
   networks that must introduce IPv6 without disruption of IPv4
   services, but the same principles apply also to even for clean-slate
   deployments in new enterprises.  Next-generation enterprises
   therefore require an architected solution for coordination of their
   internal routing and addressing plans for both IPv6 and IPv4.  The
   RANGER architecture addresses these requirements.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  The RANGER Architecture  . . . . . . . . . . . . . . . . . . .  5  6
     3.1.  The Enterprise-within-Enterprise Framework . . . . . . . .  5  6
     3.2.  Virtual Enterprise Traversal (VET) . . . . . . . . . . . .  8
     3.3.  Support for IPv4 Services  . . . . . . . . . . . . . . . . 10 12
     3.4.  Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 12 13
     3.5.  Mobility Management  . . . . . . . . . . . . . . . . . . . 12 14
   4.  Initiatives Related to RANGER/VET/SEAL . . . . . . . . . . . . 13 14
     4.1.  6over4 and ISATAP  . . . . . . . . . . . . . . . . . . . . 13 14
     4.2.  The Locator Identifier Split Protocol (LISP) . . . . . . . 13 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13 15
   7.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9. 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1. 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2. 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 18 19

1.  Introduction

   Enterprise networks will require support for both Internet protocol
   versions (IPv4 and IPv6) for an indeterminant period; perhaps even
   indefinitely.  This is particularly true for existing enterprise
   networks that must introduce IPv6 without disruption of IPv4
   services, but the same principles apply also to even for clean-slate
   deployments in new enterprises.  Next-generation enterprises
   therefore require an architected solution for coordination of their
   internal routing and addressing plans for both IPv6 and IPv4.  The
   RANGER architecture addresses these requirements, and provides a
   framework for IPv6/IPv4 coexistence [I-D.arkko-townsley-coexistence].

   RANGER is a scalable architecture for routing and addressing in next-
   generation enterprise networks that may either comprise a single
   interior IPv4 addressing domain or contain many multiple disjoint interior
   IPv4 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.  These disjoint domains  Each addressing domain therefore appear appears as
   enterprises an
   enterprise unto themselves, 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.  However, the entire 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, as
   outlined in the following sections.  While RANGER discusses the
   specific instance of IPv6 as a virtual overlay for connecting
   disjoint over or IPv4 domains, networks,
   it is important to note that the same architectural principles apply
   to any combination of IP IP* within IP* virtual
   overlays over disjoint IP addressing spaces. overlays.

   The RANGER architecture uses many mechanisms already documented or
   proposed in the IRTF and IETF.  Technical details of the composite
   technologies that make up the architecture are found in the Virtual
   Enterprise Traversal (VET) specification [I-D.templin-autoconf-dhcp].

   The RANGER architectural principles can be either directly or
   indirectly 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] [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 IPv4 routing and addressing plan within the commons, but
      may internally contain many disjoint interior addressing domains and/or
      organizational groupings that can be considered as enterprises/sites 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
      IPv4 addressing region of an enterprise, where the topology of the
      site may be less than or equal to an
      enterprise in scope. is a proper subset of the topology of the enterprise.  A site
      may contain many interior
      enterprises/sites, sites, which may themselves contain many
      interior
      enterprises/sites sites in a recursive fashion.  At the lowest level of
      decomposition, a singleton Border Router can be considered as an
      enterprise/site unto itself.

   enterprise/site

      Throughout the remainder of this document, the term "enterprise" is used to collectively refer
      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
      be considered as an enterprise unto itself.

   Border Router (BR)
      an IPv6/IPv4 dual-stack node at the edge of an enterprise and that
      is also configured as an IPv6 router in an overlay network.  BRs
      connect their directly-attached IPv6 networks to the overlay
      network, and connect to other IPv6 networks via IPv6-in-IPv4
      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
      IPv6 routers, and provide forwarding services for accessing IPv6
      networks not reachable via a BR within the commons.

   overlay network
      a virtual network manifested by IPv6 routing and addressing over
      virtual links formed through automatic IPv6-in-IPv4 tunneling.  An
      IPv6 overlay network may span many underlying IPv4 enterprises/
      sites. 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/sites. enterprises.

   ISATAP
      Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
      [RFC5214]; functional specifications and operational practices for
      automatic tunneling of unicast IPv6 packets over unicast-only IPv4
      enterprises/sites.
      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 extra additional encapsulations such as
      IPSec, SEAL, LISP, etc.

   SEAL
      Subnetwork Encapsulation and Adaptation Layer (SEAL)
      [I-D.templin-seal]; a functional specification for robust and
      authenticated path MTU assurance over IPv6-in-IPv4 tunnels.  Also
      provides authentication for other ICMP error messages, and adapts
      to subnetworks configured over links with diverse link characteristics.

3.  The RANGER Architecture

   The RANGER architecture enables scalable IPv6 routing and addressing
   in next-generation enterprise networks, while sustaining support for
   legacy IPv4 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
   enterprise unto itself.  This enterprise-within-enterprise (or,
   "site-within-site") framework
   can be extended in an hierarchical fashion as broadly and as deeply
   as desired to acheive scaling factors as well as organizational
   and/or functional compartmentalization, as shown in Figure 1.

                               ,---------------.
                            ,-'     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 IPv4 hosts, routers
   and networks (not shown in the diagram) over which IPv4 packets can
   be forwarded and IPv6 packets can be tunneled.  There may also be
   many internal enterprises/sites 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 IPv4 networks/nodes as
   well as lower layer enterprises/sites 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 IPv6/IPv4 dual-stack systems such
   as those depicted as 'V', 'W' and 'Z' in the diagram.

   It is important to note that dual-stack systems such as 'V', 'W' and
   'Z' may be simple IPv6/IPv4 hosts, or they may be BRs that attach
   arbitrarily-complex IPv6-only edge networks.  Such IPv6-only 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 E1 through EN such that
   all RANGER architectural principles apply equally within the global
   Internet context.

   As a specific case in point, the future global Aeronautical
   Telecommuncations Network (ATN) under development 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 and be further sub-divided into
   enterprises/sites
   enterprises organized as regional, organizational, functional, etc.
   compartments.  It is important to note that, while ACSPs/ANSPs within
   the ATN 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 inner-workings
   of all enterprises will require a mutual level of cooperative active
   management at some 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 that manifested through Virtual Enterprise Traversal (VET)
   [I-D.templin-autoconf-dhcp].  The approach uses IPv6 routing and addressing to span an enterprise
   via automatic IPv6-in-IPv4 IPv6-in-
   IPv4 tunneling over within a hierarchy of child enterprises that are
   either configured within the same addressing region of a larger
   enterprise or use enterprise-local-scope their own enterprise-local IPv4 routing and
   addressing internally.  These logically and/or physically disjoint
   IPv4
   child enterprises are "glued together" by IPv6 BRs/BGs, with each BR
   requesting an IPv6 prefix delegation from a delegating BG.
   Additionally, fault tolerance and multihoming is naturally afforded
   through configuration of multiple BGs per child enterprise.

   Figure 2 below depits a vertical slice (albeit represented
   horizontally) from the enterprise-within-enterprise framework shown
   in Figure 1, where an IPv6 host 'H' that is deeply nested within
   Enterprise 'E1' connects to IPv6 server 'S1' located somewhere on the
   IPv6 Internet:
                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "  2001:DB8:0:0::/56    *:0::/48     *:0::/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 within the RANGER Architecture

   Within this vertical slice, Figure 2 depicts each enterprise within
   the 'E1' hierarchy as spanned by automatic IPv6-in-IPv4 tunnels
   'vet1' through 'vet3' manifested through Virtual Enterprise Traversal
   (VET) [I-D.templin-autoconf-dhcp].  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'.

   Along with the Subnetwork Encapsulation and Adaptation Layer (SEAL -
   see: Section 3.4), '2001:
   DB8::/40'.

   VET specifies the necessary mechanisms and operational practices to
   manifest the RANGER architecture in a wide range of use cases such as depicted
   in the example above as well as above.  The use of VET in any such similar example.  In
   particular, conjunction with the
   Subnetwork Encapsulation and Adaptation Layer (SEAL - see:

   Section 3.4) may also be essential in certain deployments to avoid
   issues related to ICMP spoofing and tunnel encapsulation overhead.

   VET allows 'V', 'Y1', 'X2' and 'R2' to configure separate 'vet*'
   interfaces for each enterprise they connect to, and to discover BGs
   through a static name service resolution (or, mapping) as specified
   in [I-D.templin-autoconf-dhcp].  After tunnels 'vet1' through 'vet3'
   are established and BG's discovered, the BRs connected to a 'vet*'
   interface can run an IPv6 routing protocol such as OSPVFv3 [RFC5340]
   and form adjacencies between themselves in an on-demand fashion while
   treating the 'vet*' interface as an ordinary IPv6 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 IPv6 overlay network that
   spans 'E1' to automatically form and dynamically adapt to changing conditions within the
   enterprise.

   In the example shown in Figure 2, 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 for the enterprise spanned by 'vet2' that sees 'X2' as a
   BG, and node 'X2' is a BR for 'vet3' that sees 'R2' as a BG that
   connects 'E1' to the global IPv6 Internet.

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

                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "  2001:DB8:0:0::/56   *0:0::/48    *0:0::/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:0::/56     *1:0::/40   "
        " " " " " " " " " " " " " " "" " " " " " " "
                     <-- Enterprise E1 -->

       Figure 3: On-Demand Discovery within the RANGER Architecture

   In this scenario, tunnel interfaces 'vet1' through 'vet4' as well as
   IPv6 prefix delegations have been established through the enterprise
   autoconfiguration procedures specified in
   [I-D.templin-autoconf-dhcp].  When IPv6 host 'H' sends IPv6 packets
   to server 'J', however, 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, or perform
   an on-demand mapping lookup by consulting the enterprise name service
   as specified in[I-D.templin-autoconf-dhcp].  Alternatively, 'X2' can
   send the packet to default router 'R2', and 'R2' can send return an ICMPv6
   redirect message indicating that 'J' can be reached via a more direct
   route through 'X7'.

   It is specifically worth noting that, in both of the previous
   examples, a BR may have potentially many VET interfaces over which it
   can connect to the BRs/BGs of potentially many "sibling" enterprises/
   sites neighboring
   enterprises across the commons.

3.3.  Support for IPv4 Services

   While the IPv6 overlay network that spans 'E1' provides a fully-
   connected routing and addressing capability for IPv6 services, access
   to legacy IPv4 services will still be required for an extended (and
   possibly indefinite) period.  Figure 4 below depicts the applicable
   IPv4 service access models for the RANGER architecture:

                                                            +------+
                                                            | IPv6 |
                                                            |Server|
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "  2001:DB8:0:0::/56    *:0::/48     *:0::/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 |
      "      10/8             10/8         10/8                                              "      |Server|
        " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                     <-- Enterprise E1 -->                  +------+

         Figure 4: IPv4 Service Access in the RANGER Architecture

   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 IPv6-in-IPv4 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 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 Network Address Translation
   (NAT) capability,
   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.  As a
   second alternative,  Instead, 'E1'
   could instead deploy a "Carrier-Grade NAT (CGN)" at 'R2' (i.e., at the
   enterprise border with the global Internet) and E1.1.1 could configure discover
   'Y1' as an IPv4 default router.  'Y1' could then use the "dual-stack-lite" "dual-stack-
   lite" approach in which it uses IPv4-in-IPv6-in-IPv4 tunneling to
   convey 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'.  As a third alternative,  Finally, 'K' could be configured as an IPv6-only
   node and use standard IPv6 routing to reach an IPv6/IPv4 translator
   located at 'R2'. 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, the RANGER architecture currently makes no
   provisions for an IPv4 client 'K' to use IPv4-only services to can access an IPv4 server 'M' in
   a different enterprise within 'E1' that
   configures a E1 as long as both enterprises are
   configured over the same underlying IPv4 routing region.  If the
   enterprises are configured over disjoint addressing domain.  Until an architected
   approach is devised, 'K' IPv4 routing regions,
   however, to K' would only be able to access 'M' using IPv6-
   only IPv6-only
   services.

3.4.  Subnetwork Encapsulation and Adaptation Layer (SEAL)

   Whenever the BRs of disjoint enterprises/sites 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.  ICMP messages
   can therefore be forged by anonymous attackers, e.g., from a rogue
   node within an enterprise that has malicious intent toward another
   enterprise.

   The Subnetwork Encapsulation and Encapsulation Layer (SEAL) provides
   effective means for BRs to avoid these shortcomings by accepting only
   authenticated feedback from correspondent BRs that can be validated
   as Potential Routers topologically-correct routers within the commons (i.e., the
   subnetwork) using the Potential Router List (PRL) discovery
   mechanisms of [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 bandwidth and MTU size
   properties, and indeed allows for discovery and eradication of
   marginal links.

   The advantages of using SEAL within 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 cooperation but with competing
   interests or objectives.

3.5.  Mobility Management

   When a mobile IPv6 node within an enterprise network moves to a new
   IPv6 link, it can use mobility management mechanisms such as Mobile
   IPv6 [RFC3775] or HIP [RFC4423] to maintain a stable identifier even
   as it moves between foreign links.

   When a mobile BR moves to a new enterprise, it can renumber its IPv4
   address(es) (i.e., its locators) and communicate these changes to
   peers using a mechanism such as MobIKE [RFC4555]. [RFC4555], dynaic updates to
   the DNS, etc.  In that case, it can still retain its IPv6 addresses
   and/or prefixes without need for renumbering.  This approach is
   especially useful for maintaining continuity for the provider-
   independent IPv6 prefixes owned by the BR.

4.  Initiatives Related to RANGER/VET/SEAL

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 (a unicast-only variant of
   6over4) [RFC5214] was specified 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).  LISP
   is

   LISP, and a number of other proposals being discussed in essence the Routing
   Research Group, share a specific manifestation number of properties with the RANGER architecture
   applied to solution
   proposed here.  They may therefore be architecturally consistent with
   the global Internetworking use case.  All RANGER
   architectural principles therefore apply equally to LISP. architecture.

5.  IANA Considerations

   There are no IANA considerations for this document.

6.  Security Considerations

   Communications between endpoints within different enterprise networks within 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.  IP packets can therefore 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 it must.  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 VETand SEAL are is used, enterprise BGs can use
   the identification encoded in the SEAL header as well as ingress
   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 nodes located within the commons is also
   subject for concern, additional securing mechanisms such as tunnel-
   mode IPsec between enterprise BGs can also be used.

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

   The RANGER architecture principles can be traced to the deliberations
   of the ROAD group in January 1992 [RFC1380], and likely also to other
   early works including Nimrod [RFC1753].  [RFC1955] captures the high-
   level architectural aspects of the ROAD group deliberations in a "New
   Scheme for Internet Routing and Addressing [ENCAPS] for IPNG".

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

9.

8.  References

9.1.

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.

9.2.

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-09 (work in progress), October 2008.

   [I-D.ietf-v6ops-tunnel-security-concerns]
              Hoagland, J., Krishnan, S., and D. Thaler, "Security
              Concerns With IP Tunneling",
              draft-ietf-v6ops-tunnel-security-concerns-01 (work in
              progress), October 2008.

   [I-D.templin-autoconf-dhcp]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-autoconf-dhcp-18
              draft-templin-autoconf-dhcp-20 (work in progress),
              October 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
              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.

   [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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.