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

Versions: 00 01 02 03 04 05 RFC 6139

Network Working Group                                    S. Russert, Ed.
Internet-Draft                                        E. Fleischman, Ed.
Updates: 3574, 3750, 3904, 4029,                         F. Templin, Ed.
4057, 4215, 4852                            Boeing Research & Technology
(if approved)                                               May 13, 2009
Intended status: Informational
Expires: November 14, 2009

                            RANGER Scenarios

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 14, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Russert, et al.         Expires November 14, 2009               [Page 1]

Internet-Draft                   RANGERS                        May 2009


   Routing and Addressing in Next-Generation EnteRprises (RANGER)
   [I-D.templin-RANGER] provides an architectural framework for scalable
   routing and addressing.  It provides for scalability, provider
   independence, mobility, multihoming and security for the next
   generation Internet.  This document describes a series of use cases
   in order to showcase RANGER capabilities.  It further shows how the
   RANGER architecture restores the network-within-network principles
   originally intended for the sustained growth of the Internet.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Global Concerns  . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Scaling the Global Interdomain Routing Core  . . . . . 11
       4.1.2.  Supporting Large Corporate Enterprise Networks . . . . 13
     4.2.  Autonomous System Concerns . . . . . . . . . . . . . . . . 15
     4.3.  Small Enterprise Concerns  . . . . . . . . . . . . . . . . 16
     4.4.  IPv4/IPv6 Transition and Coexistence . . . . . . . . . . . 18
     4.5.  Mobility and MANET . . . . . . . . . . . . . . . . . . . . 21
       4.5.1.  Global Mobility Management . . . . . . . . . . . . . . 21
       4.5.2.  First-Responder Mobile Ad-Hoc Networks (MANETs)  . . . 22
       4.5.3.  Tactical Military MANETs . . . . . . . . . . . . . . . 24
     4.6.  Provider Concerns  . . . . . . . . . . . . . . . . . . . . 27
       4.6.1.  ISP Networks . . . . . . . . . . . . . . . . . . . . . 27
       4.6.2.  Cellular Operator Networks . . . . . . . . . . . . . . 28
       4.6.3.  Aeronautical Telecommunications Network (ATN)  . . . . 28
       4.6.4.  Unmanaged Networks . . . . . . . . . . . . . . . . . . 31
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38

Russert, et al.         Expires November 14, 2009               [Page 2]

Internet-Draft                   RANGERS                        May 2009

1.  Introduction

   The Internet today is challenged to support more users, more
   internetwork connections and increasing complexity due to diverse
   policy requirements.  This growth and change strains the
   infrastructure and demands new solutions.  Three complimentary
   approaches to transform Internet technology are being pursued
   concurrently within the IETF: translation (including Network Address
   Translation (NAT)), Tunneling (map and encapsulate), and native IPv6
   [RFC2460] deployment.  Routing and Addressing in Next-Generation
   EnteRprises (RANGER) [I-D.templin-ranger] describes a method for the
   encapsulation approach that also facilitates the other two

   [I-D.templin-ranger] provides an architectural framework for scalable
   routing and addressing.  It provides for scalability, provider
   independence, mobility, multihoming and security for the next
   generation Internet.  The RANGER architectural principles are not
   new.  They can be traced to the deliberations of the ROAD group
   [RFC1380], and also to still earlier works including NIMROD
   [RFC1753], and the Catenet model for internetworking
   [CATENET][IEN48][RFC2775].  [RFC1955] captures the high-level
   architectural aspects of the ROAD group deliberations in a "New
   Scheme for Internet Routing and Addressing (ENCAPS) for IPNG".

   The Internet has grown tremendously since these architectural
   principles were first developed, and that evolution exacerbates the
   need for these capabilities.  The Internet has become a critical
   resource for business, for government, and for everyday people
   throughout the developed world.  RANGER carries forward these
   historic architectural principles, creating a ubiquitous enterprise
   structure that can represent collections of network elements ranging
   from the granularity of a singleton router all the way up to an
   entire Internet.  This enterprise structure uses border routers that
   configure tunnel endpoints to connect potentially recursively-nested
   enterprises, each potentially using completely independent internal
   Routing Locator (RLOC) address spaces, in a virtual overlay network
   connecting edge networks and devices that are addressed with globally
   unique Endpoint Interface iDentifiers (EIDs).  The RANGER virtual
   overlay can transcend traditional administrative and organizational
   boundaries.  In its purest form, this overlay network could therefore
   span the entire Internet and restore the end-to-end transparency
   envisioned in [RFC 2775].

   The RANGER architecture is built using Virtual Enterprise Traversal
   (VET) [I-D.templin-autoconf-dhcp], the Subnetwork Encapsulation and
   Adaptation Layer (SEAL) [I-D.templin-seal], Intra-Site Automatic
   Tunnel Addressing Protocol (ISATAP)[I-D.templin-isatapv4] [RFC5214],

Russert, et al.         Expires November 14, 2009               [Page 3]

Internet-Draft                   RANGERS                        May 2009

   and other mechanisms including IPsec [RFC4301].  This document
   describes use cases and shows how the RANGER mechanisms apply.
   Complimentary mechanisms (e.g., DNS, DHCP, NAT, etc.) are included to
   show how the various pieces can work together.  It expands on the
   concepts introduced in IPv6 Enterprise Network Scenarios [RFC4057]
   and analysis [RFC4852], and shows how the enterprise network model
   generalizes to a broad range of scenarios.  These use cases are
   included to provide examples, invite criticism and comment, and
   explore the potential for creating the next-generation Internet using
   the RANGER architecture.  Familiarity with RANGER, VET, SEAL, and
   ISATAP are assumed.

2.  Terminology

   Internet Topology Hierarchy
      The Internet Protocol (IP) natively supports a topology hierarchy
      comprised of increasing aggregations of networked elements.
      Network interfaces of devices are grouped into subnetworks and
      subnetworks are grouped into larger aggregations.  Subnetworks can
      be optionally grouped into areas and the areas grouped into an
      autonomous system (AS).  Alternatively, subnetworks can be
      directly grouped into an AS.  The foundation of the IP Topology
      Hierarchy is the AS, which determines the administrative
      boundaries of a network deployment including its routing,
      addressing, quality of service, security, and management.  Intra-
      domain routing occurs within an autonomous system and inter-domain
      routing links autonomous systems into a network of networks

   Routing Locator (RLOC)
      an IPv4 or IPv6 address assigned to an interface in an enterprise-
      interior routing region.  Note that RLOC space is local to each
      enterprise, hence the same RLOC space IP addresses may be reused
      between disjoint enterprises.

      The IPv4 public address space currently in use today can be
      considered as the RLOC space for the global Internet "enterprise".

   Endpoint Interface iDentifier (EID)
      an IPv4 and IPv6 address assigned to an edge network interface of
      an end system.  Note that EID space is global in scope, and must
      be separate and distinct from any RLOC space.

      an enterprise-interior routing region that provides a subnetwork
      for cooperative peering between the border routers of diverse
      organizations that may have competing interests.  An example of a

Russert, et al.         Expires November 14, 2009               [Page 4]

Internet-Draft                   RANGERS                        May 2009

      commons is the Default Free Zone (DFZ) of the global Internet.
      The enterprise-interior routing region within the commons uses an
      addressing plan taken from RLOC space.

      the same as defined in [RFC4852], where the enterprise deploys a
      unified RLOC space addressing plan within the commons, but may
      also contain partitions with disjoint RLOC spaces 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).

      Historically, "Enterprise networks" are associated with large
      corporations or academic campuses.  However, in RANGER an
      "enterprise" may exist at any IP Topology Hierarchy level.  The
      RANGER architectural principles apply to any networked entity that
      has some degree of cooperative active management.  This definition
      therefore extends to home networks, small office networks, a wide
      variety of mobile ad-hoc networks (MANETs), and even to the global
      Internet itself.

      a logical and/or physical grouping of interfaces within an
      enterprise commons, 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 recursive decomposition, a singleton
      Enterprise Border Router can be considered as an enterprise unto

   Enterprise Border Router (EBR)
      a node at the edge of an enterprise that is also configured as a
      tunnel endpoint in an overlay network.  EBRs connect their
      directly-attached networks to the overlay network, and connect to
      other networks via IP-in-IP tunneling across the commons to other
      EBRs.  This definition is intended as an architectural equivalent
      of the functional term "EBR" defined in
      [I-D.templin-autoconf-dhcp], and is synonymous with the term "xTR"
      used in other contexts (e.g., [I-D.farinacci-lisp]).

Russert, et al.         Expires November 14, 2009               [Page 5]

Internet-Draft                   RANGERS                        May 2009

   Enterprise Border Gateway (EBG)
      an EBR that also connects the enterprise to provider networks
      and/or to the global Internet.  EBGs are typically configured as
      default routers in the overlay, and provide forwarding services
      for accessing IP networks not reachable via an EBR within the
      commons.  This definition is intended as an architectural
      equivalent of the functional term "EBG" defined in
      [I-D.templin-autoconf-dhcp], and is synonymous with the term
      "default mapper" used in other contexts (e.g., [I-D.jen-apt]).

   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.

      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.

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

      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/UDP, Teredo/UDP, etc.

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

      Within the RANGER architecture context, the SEAL "subnetwork" and
      RANGER "enterprise" should be considered as identical

Russert, et al.         Expires November 14, 2009               [Page 6]

Internet-Draft                   RANGERS                        May 2009

   Provider-Independent (PI) prefix
      an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.)
      that is routable within a limited scope and may also appear in
      enterprise mapping tables.  PI prefixes that can appear in mapping
      tables are typically delegated to a BR by a registry, but are not
      aggregated by a provider network.  Local-use IPv6 and IPv4
      prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of
      a PI prefix, but these typically do not appear in mapping tables.

   Provider-Aggregated (PA) prefix
      an IPv6 or IPv4 EID prefix that is either derived from a PI prefix
      or delegated directly to a provider network by a registry.
      Although not widely discussed, it bears specific mention that a
      prefix taken from a delegating router's PI space becomes a PA
      prefix from the perspective of the requesting router.

   Customer Premises Equipment (CPE) Router
      a residential or small office router that provides IPv4 and/or
      IPv6 support.  The user or the service provider may manage the

   Carrier Grade NAT (CGN)
      a special (usually high capacity) IPv4 to IPv4 NAT deployed within
      the service provider network that serves multiple subnets.

3.  Approach

   The RANGER architecture is described in [I-D.templin-ranger].  The
   following is a terse summary of some key elements of the

   The RANGER "enterprise" is a cooperative networked collective sharing
   a common (business, social, political, etc.) goal.  An enterprise can
   be simple or complex in composition and can operate at any IP
   Topology Hierarchy level.  Although RANGER focuses on encapsulation,
   it is also compatible with both native and translated routing and

   RANGER enables a protocol and/or addressing system to be connected in
   a virtual overlay across an untrusted transit network, or "commons".
   While it does not show all possible uses, Figure 1 illustrates that
   RANGER supports the creation of a distributed network across an
   intervening commons which could implement a dissimilar IP version,
   routing protocol, or addressing system.

Russert, et al.         Expires November 14, 2009               [Page 7]

Internet-Draft                   RANGERS                        May 2009

              .--------------.     .--------------.     .-------------.
             /                \_ _/                \_ _/               \
             \ Enterprise A   /   \    Commons     /   \  Enterprise B /
              \_ _ _ _ _ _ _ /     \_ _ _ _ _ _ _ /     \_ _ _ _ _ _ _/

  Network    /        IPvx              IPvy               IPvz
  Protocol   \        IPv6              IPv4               IPv6

  IP Security        secured          unsecured          secured

  Mgmt Domain      Entity A              ISP              Entity B

             | Public Addresses   Private Addresses   Public Addresses
  Addressing |Private Addresses    Public Addresses   Private Addresses
             |   PA Addresses        PI Addresses         PA Addresses
              \   PI Addresses       PA Addresses         PI Addresses

             Figure 1:  Ranger links Distributed Enterprises

   The RANGER concepts can be applied recursively.  They can be
   implemented at any level within the IP Topology Hierarchy to create
   an enterprise-within-enterprise organizational structure extending
   traditional AS, area, or subnetwork boundaries.  This structure uses
   border routers that configure tunnel endpoints to enable
   communications between potentially recursively-nested enterprises in
   a virtual overlay network that transcends traditional administrative
   and organizational boundaries.  In its purest form, this overlay
   network could therefore span the entire Internet and restore end-to-
   end transparency (RFC 2775).

   The RANGER architecture applies the best current practice insights
   from previous encapsulation systems as they are currently articulated
   within the Virtual Enterprise Traversal [I-D.templin-autoconf-dhcp],
   and Subnetwork Encapsulation and Adaptation Layer [I-D.templin-seal]
   functional specifications.  The result is an architecture and
   protocol system that can be used to create arbitrarily complex,
   scalable IP deployments that support both unicast and multicast
   routing and addressing systems.

   RANGER supports scalable routing through a recursively-nested
   enterprise-within-enterprise network capability.  The fundamental
   building block is the Enterprise Border Router (EBR) (see Figure 2).
   The EBR is the limiting factor for RANGER recursion, and in certain
   contexts a singleton EBR can be viewed as an enterprise unto itself.
   Traditional network infrastructures can be extended to support

Russert, et al.         Expires November 14, 2009               [Page 8]

Internet-Draft                   RANGERS                        May 2009

   complex structures solely with the addition of EBRs with no other
   modification to any networked entity.

   An EBR can be a commercial off the shelf router, a tactical military
   radio, an aircraft mobile router, etc., but it can also be an end
   system (e.g., a laptop computer, a soldiers' handheld device, etc.)
   that may or may not enable routing functions such as Internet
   connection sharing.

                                Provider-edge Interfaces
                                     x   x        x
                                     |   |        |
                +--------------------+---+--------+----------+    E
                |                    |   |        |          |    n
                |    I               |   |  ....  |          |    t
                |    n           +---+---+--------+---+      |    e
                |    t           |   +--------+      /|      |    r
                |    e  I   x----+   |  Host  |   I /*+------+--< p  I
                |    r  n        |   |Function|   n|**|      |    r  n
                |    n  t        |   +--------+   t|**|      |    i  t
                |    a  e   x----+              V e|**+------+--< s  e
                |    l  r      . |              E r|**|  .   |    e  r
                |       f      . |              T f|**|  .   |       f
                |    V  a      . |   +--------+   a|**|  .   |    I  a
                |    i  c      . |   | Router |   c|**|  .   |    n  c
                |    r  e   x----+   |Function|   e \*+------+--< t  e
                |    t  s        |   +--------+      \|      |    e  s
                |    u           +---+---+--------+---+      |    r
                |    a               |   |  ....  |          |    i
                |    l               |   |        |          |    o
                +--------------------+---+--------+----------+    r
                                     |   |        |
                                     x   x        x
                              Enterprise-edge Interfaces

                  Figure 2: Enterprise Border Router (EBR)

   EBRs connect networks and end systems to one or more enterprises via
   a repertoire of interface types.  Enterprise-interior interfaces
   attach to a commons.  Provider-edge interfaces support traditional
   routing relationships up the IP Topology Hierarchy and Enterprise-
   edge Interfaces support traditional relationships down the IP
   Topology Hierarchy.  Internal virtual interfaces are typically
   loopback interfaces or VMware-like host-in-host interfaces.

   VET interfaces support RANGER recursion and IP-in-IP encapsulation.
   VET interfaces are configured over provider-edge, enterprise
   interior, or enterprise-edge interfaces to allow recursion

Russert, et al.         Expires November 14, 2009               [Page 9]

Internet-Draft                   RANGERS                        May 2009

   horizontally or vertically within the IP Topology Hierarchy.

   Figure 3 shows two enterprises (each with their own internal
   addressing and routing systems) that communicate over a virtual
   overlay network across a commons.  The virtual overlay is manifested
   by tunneling, which links enterprises separated by geographical
   remoteness, protocol incompatibility, or both.  An ingress EBR (iEBR)
   within the left enterprise seeks to forward encapsulated packets
   across the commons to the egress EBR (eEBR) within the right

   The figure shows that the eEBR assigns a Routing LOCator (RLOC)
   address on its interface to the Commons' interior IP routing and
   address space, while the destination host assigns an Endpoint
   interface IDentifier (EID) on its enterprise edge interface.  The
   iEBR uses a mapping system to discover the RLOC of an eEBR on the
   path to the destination EID address.  A distinct mapping system is
   maintained within each recursively-nested enterprise instance
   operating at a specific level of the IP Topology Hierarchy.  RANGER
   uses the mapping system to join peer enterprises via a virtual
   overlay across a commons.

                Mapping System                   RLOC       EID
                . (BGP, DNS, etc.)                 .         .
          .---.------.          .----------.       .  .------.---.
         /  .         \        /            \      . /       .    \
        /  (O)      iEBR------/--------------\------eEBR     *     \
        \              /      \   Commons    /       \             /
         \_ _ _ _ _ _ /        \_ _ _ _ _ _ /         \_ _ _ _ _ _/

                Figure 3: The RANGER Model

   EBRs must configure both RLOC and EID addresses and/or prefixes.
   Autoconfiguration is coordinated with Enterprise Border Gateways
   (EBGs) that connect to the next-higher layer in the recursive
   hierarchy, as specified in VET.  Standard mechanisms including DHCP
   [RFC2131] [RFC3315] and Stateless Address Autoconfiguration (SLAAC)
   [RFC4862] are used for this purpose.

   Similarly, EBRs require a means to discover other EBRs and EBGs that
   can be used as enterprise exit points.  VET specifies mechanisms for
   border router discovery using both the global DNS and/or enterprise-
   local name services such as LLMNR [RFC4795].

   The mapping system is a distributed database that is synchronized
   among a limited set of mapping agents.  Database synchronization can
   be achieved by many different protocol alternatives.  The most
   commonly used alternatives are either BGP or the domain name system

Russert, et al.         Expires November 14, 2009              [Page 10]

Internet-Draft                   RANGERS                        May 2009

   (DNS; RFC1035).  Mapping system databases can be populated by many
   different mechanisms including administrative configuration and
   automated prefix registrations.

   EBRs either forward initial packets for which they have no mapping to
   an EBG or consult the mapping system to determine the correct next
   hop while delaying or dropping initial packets if necessary.  The EBR
   then receives a mapping reply that it can use to populate its
   Forwarding Information Base (FIB).  It then encapsulates each
   forwarded packet in an outer IP header for transmission across the
   commons to the remote RLOC address of an eEBR.  The eEBR in turn
   decapsulates the packets and forwards them to the destination EID
   address.  The Routing Information Base (RIB) within the commons only
   needs to maintain state regarding RLOCs and not EIDs.  The
   synchronized EID-to-RLOC mapping state is not subject to oscillations
   due to link state changes within the commons.  RANGER supports
   scalable addressing by selecting a suitably large EID addressing
   range that is distinct from any enterprise-interior RLOC addressing

4.  Scenarios

4.1.  Global Concerns

4.1.1.  Scaling the Global Interdomain Routing Core

   Growth in the Internet has created challenges in routing and
   addressing that have been recognized for more than 15 years.  IPv4
   [RFC0791]address space is limited, and Regional Internet Registry
   (RIR) allocation is passing the "very painful" Host Density (HD)
   ratio threshold of 86% (that is, 192M allocated addresses) [RFC3194].
   As a result, exhaustion of the IPv4 address pool is predicted within
   the next two years [V4pool], [Huston-end].  IPv6 promises to resolve
   the address shortage with a much larger address space, but transition
   is costly and could exacerbate Border Gateway Protocol (BGP) problems
   described below.  Richer interconnection, increased multihoming
   (especially with Provider-Independent (PI) addresses), and a desire
   to support traffic engineering via finer control of routing has led
   to super-linear growth of BGP routing tables in the default-free zone
   or "DFZ" of the Internet.  This growth has been damped because of the
   limited number of IPv4 addresses, so the larger address space of IPv6
   threatens to make the problem worse.

   RANGER allows the coordinated reuse of addresses from Enterprise to
   Enterprise by making RLOC address spaces independent of one another.
   Figure 4 shows how the RANGER architecture allows the use of separate
   address spaces for RLOC and EID addressing in the Internet.  This

Russert, et al.         Expires November 14, 2009              [Page 11]

Internet-Draft                   RANGERS                        May 2009

   yields more endpoint address space, especially with the use of IPv6,
   and also reduces the load on BGP in the Internet routing core.  Note
   that Figure 4 could represent variants of RFC 4057 scenarios 1 and 2.

      EID                          RLOC                       EID
       PA                         Spaces                       PI
   Allocation                                             Registration
                    .-------------------------------.          ^
                   /           Internet Commons      \         |
                   |  .---------------------------.   |        |
  2001:DB8::/40    | /         Enterprise A        \  | 2001:DB8:10::/56
        |          |/              10.1/16          \ |        ^
        |          ||  .-------------------------.   ||        |
        V          || /         Enterprise A.1    \  ||        |
  2001:DB8::/48    || |            10.1/16        |  || 2001:DB8:11::/56
                   ||  \_________________________/  / |
                   | \                             /  |
                   |   ---------------------------    |
                   |                                  |
                   |  .---------------------------.   |
                   | /         Enterprise B        \  |
 2001:DB8:100::/40 | |            10.1/16           | | 2001:DB8:12::/56
                   |  \____________________________/  |
                    \                                 /

              Figure 4: Enterprises and the Internet

   RLOC address spaces are entirely independent of one another, as they
   are used only within an Enterprise (Please recall that an Enterprise
   can exist at any level of the IP Topology Hierarchy).  Therefore as
   Figure 4 shows, the same RLOC space can be reused freely throughout
   different Enterprises regardless of their level of recursion.  EID
   address space can be Provider-Aggregated (PA) or PI, and taken from
   either IPv4, or IPv6.  EID addresses (barring use of Network Address
   Translation (NAT)) are globally unique, even when routable only
   within a more limited scope (e.g., in their own edge networks).

   The IRTF routing research group is investigating a Preliminary
   Recommendation for a Routing Architecture
   [I-D.irtf-rrg-recommendation] that provides a taxonomy for routing
   scaling solutions for the global Internet interdomain routing core.
   RANGER is a locator/identifier separation architecture within this
   taxonomy that uniquely shows applicability from the core all the way
   out to edge networks via its recursive enterprise-within-enterprise
   framework.  RANGER is further compatible with a number of schemes
   intending to address routing scaling issues, including A Practical

Russert, et al.         Expires November 14, 2009              [Page 12]

Internet-Draft                   RANGERS                        May 2009

   Transit Mapping Service (APT) [I-D.jen-apt], FIB Suppression with
   Virtual Aggregation [I-D.francis-intra-va], LISP [I-D.farinacci-lisp]
   and others.

4.1.2.  Supporting Large Corporate Enterprise Networks

   Each enterprise network operator must be able to manage its internal
   networks and use the Internet infrastructure to achieve its
   performance and reliability goals.  Enterprises that are multihomed
   or have mobile components frequently require provider-independent
   addressing and the ability to coordinate with multiple providers
   without renumbering flag days [RFC4192],
   [I-D.carpenter-renum-needs-work].  RANGER provides a way to
   coordinate addressing plans and inter-enterprise routing, with full
   support for scalability, provider-independence, mobility, multi-
   homing and security.

                       _.---''                         -.
                  ,--''           ,---.                 `---.
               ,-'              X5     X6            .---..  `-.
             ,'  ,.X1-..       /         \        ,'       `.   `.
           ,'  ,'       `.    .'  E2     '.     X8    Em     \    `.
          /   /           \   |   ,--.    |     / _,.._       \     \
         /   /   E1        \  | Y3    `.  |    | /     Y7      |     \
        ;   |    ___        | |  ` W  Y4  |... | `Y6  ,'       |      :
        |   | ,-'   `.     X2 |   `--'    |    |   `''         |      |
        :   | |  V  Y2      | \    _      /    |               |      ;
         \  | `-Y1,,'       |  \ .' Y5   /      \    ,-Y8'`-  /      /
          \  \             /    \ \_'  /        X9   `.    ,'/      /
           `. \          X3      `.__,,'          `._  Y9'','     ,'
             ` `._     _,'      ___.......X7_        `---'      ,'
               `  `---'      ,-'             `-.              -'
                  `---.      `.    E3     Z   _'        _.--'
                       `-----. \---.......---'   _.---''

          <------------------- Global IPv4 Internet ------------------>

                Figure 5: Enterprises on the Internet Commons

   Figure 5 depicts enterprises E1 through Em connected to the global
   IPv4 Internet via Enterprise Border Routers (EBRs) X1 through X9.
   This same set of border nodes also act as Enterprise Border Gateways
   (EBGs) that provide default routing services for nodes within their
   respective enterprises.  The global Internet forms a commons across
   which the various enterprises connect as cooperating yet potentially
   competing entities.  Within each enterprise there may be arbitrarily

Russert, et al.         Expires November 14, 2009              [Page 13]

Internet-Draft                   RANGERS                        May 2009

   many hosts, routers and networks (not shown in the diagram) that use
   addresses taken from that enterprise's RLOC space and over which both
   encapsulated IP packets with (global-scoped) EID addresses and
   unencapsulated IP packets with (enterprise-local) RLOC addresses can
   be forwarded.

   Each enterprise may encompass lower-tier enterprises; for instance,
   the singleton EBR "W" in enterprise E2 resides in a lower-tier
   enterprise (say E2.1), and (along with any of its attached devices)
   may be considered as an enterprise unto itself.  W sees Y3 and Y4 as
   EBGs, which in turn see X5 and X6 as EBGs that connect to a common
   provider network (in this case, the Internet).  Each enterprise has
   one or more Endpoint identifier (EID) address prefixes used for
   addressing nodes on edge networks.  RANGER's map-and-encaps approach
   separates the mapping of EIDs to RLOCs from the Routing Information
   Base (RIB) in the Internet commons that are assigned to EBR router
   interfaces.  Not only does BGP in the Internet commons only need to
   maintain state regarding Routing Locators (RLOCs)in the Internet
   commons, it has fewer unique routes to maintain because only routes
   to EBRs are needed; traffic engineering can therefore be accommodated
   via the mapping database.

   In Figure 5, enterprise E2 represents a corporation that has multiple
   locations and connections to multiple ISPs.  The corporation has
   recently merged with another corporation so that its internal network
   has two disjoint RLOC address spaces, but neither of the formerly
   separate entities can bear the burden of address renumbering.
   Enterprise E2 can use a suitably large IPv4 and/or IPv6 EID
   addressing range (that is distinct from any enterprise-interior RLOC
   addressing range) to support end systems on enterprise edge networks
   with no disruption to preexisting address numbering.

   As EBRs are deployed to connect enterprises together, ordinary
   routers within the enterprise continue to function as-normal and
   deliver both ordinary and encapsulated packets across the existing
   Internet infrastructure and the enterprise's own RLOC commons.
   Legacy IPv4 services that bind to RLOC addresses continue to be
   supported even as EID-based services are rolled out.  Where legacy IP
   client and server are within the same RLOC address space, they simply
   communicate by using RLOC-based routing across the enterprise
   commons.  If client and server are not within the same RLOC address
   space, they communicate through some form of network address and/or
   protocol translation (see [I-D.templin-RANGER] Section 3.3.4 for
   details).  EBRs from the various enterprises publish their EID
   prefixes to an enterprise-specific mapping system, so that other EBRs
   from the various enterprises can consult the mapping system to
   receive the RLOC address of one or more EBRs that serve the EID

Russert, et al.         Expires November 14, 2009              [Page 14]

Internet-Draft                   RANGERS                        May 2009

   As an example, when an end system connected to W in E2.1 has a packet
   to send to node Z in enterprise E3, W sends the packet to EBR Y4
   which encapsulates the packet in an outer IP packet with its own
   source address and the RLOC address of the next-hop EBR as
   destination - in this case, X6.  X6 decapsulates the packet and looks
   up the destination EID prefix, obtaining the RLOC of X7 as next-hop.
   X6 then encapsulates the IPv6 packet in a packet with RLOC address X6
   as source and X7 as destination.  X7 decapsulates the packet on
   receipt and forwards it via its enterprise-edge interface to node Z.

   This example uses one thread out of many that are possible using
   RANGER; see [I-D.templin-ranger] and [I-D.templin-autoconf-dhcp] for
   other options and details.  Many enterprises that use proxies and
   firewalls at their border routers today will wish to maintain that
   control over their enterprise borders, and the use of RANGER does not
   preclude such configurations (for example, see Section 4.3).

4.2.  Autonomous System Concerns

   An enterprise such as E2 in Figure 5 above can represent an AS within
   the IP Topology Hierarchy.  A possible configuration for Enterprise
   E2 is for each of its enterprise components to also be recursive ASes
   linked together using the RANGER constructs.  Such a configuration is
   increasingly commonplace today for the networks of very large
   corporations (e.g., Boeing's corporate enterprise network).  These
   networks internally use the Border Gateway Protocol (BGP)
   independently from a different BGP instance from that which maintains
   the RIB within the global Internet Default Free Zone (DFZ).  Such
   configurations are often motivated by scaling or administrative

   Large corporations may therefore support an internal instance of BGP
   linking many corporate-internal ASs.  Such a corporate entity is
   internally an Internet unto itself, albeit with separate default
   routes leading to the true global Internet.  The enterprise E2
   therefore appears to the rest of the Internet as if it were a
   traditional IP Topology Hierarchy AS.  Since RANGER supports
   recursion, each AS within such an enterprise may itself use BGP
   internally in place of an IGP, and can therefore also internally be
   composed of a locally-internal Internet in a recursive fashion.  This
   enterprise-within-enterprise framework can recursively be extended as
   broadly and as deeply as required in order to achieve the specific
   requirements of the deployment (e.g., scaling, unique administration,
   and/or functional compartmentalization).

Russert, et al.         Expires November 14, 2009              [Page 15]

Internet-Draft                   RANGERS                        May 2009

4.3.  Small Enterprise Concerns

   Global enterprises operating at the autonomous system level of the IP
   Topology Hierarchy include multiple geographical regions, multiple
   ISPs, and complex internal structures which naturally benefit from
   the application of RANGER techniques.  However, all other enterprise
   network instances (both large and small) can also be served by
   RANGER.  For example, Small and Home Office (SOHO) networks may
   comprise only a few computers on a single network segment or extend
   to larger configurations with security islands, internal routers and
   switches, etc.

   An important concern of the small enterprise is the ability to grow
   the network, change ISPs, or expand to more locations without
   readdressing the existing network.  Consider a small company that has
   a single location in California.  The ISP connection is via a router
   that acts as Network Address Translator and firewall for the company.
   Addresses of the few computers ("Wksta") are taken from the [RFC1918]
   private address space.

                      -------|-----            Wksta        Wksta
                      |  Firewall  |_____________|____________|
                      |    NAT     |

                     Figure 6: Simple SOHO network

   This configuration has been adequate for the few employees performing
   software development work, since there is no need to expose services
   within the site to the outside world.  But now a web presence is
   required as product introduction approaches.  The network manager
   deploys an EBR either as a co-resident function on the existing NAT/
   firewall platform as depicted below, or on a separate platform.

   The EBR has a provider-edge interface connected to the ISP, the
   preexisting workstations, the preexisting enterprise edge interfaces
   connecting workstations, and enterprise-edge interfaces connecting
   several network segments connected by routers that host web servers,
   workstations and other enterprise services.  A VET interface is
   configured over the new service network to allow the servers to be
   addressed from the public Internet.

Russert, et al.         Expires November 14, 2009              [Page 16]

Internet-Draft                   RANGERS                        May 2009

                         |           <|--
                         |     VET2 < |
                         |           <|---
                         |            |
                         |            |      Server     Server
                         |      VET1 <|--------|-----------|-------
                         |            |
                         | +--------+ |           Wksta        Wksta
                         | |Firewall| |_____________|____________|
                         | |   NAT  | |
                         | +--------+ |

                     Figure 7: RANGER serving the small company

   In this new configuration, the EBR maintains the services within a
   "demilitarized zone (DMZ)" that is accessible from the public
   Internet without exposing other corporate assets that are still
   protected by the preexisting firewall/NAT functions.

   Shortly afterward an infusion of venture capital allows acceleration
   of the product development and marketing work by adding programmers
   in Tokyo and sales offices in New York and London.  These new
   branches connect via Virtual Private Network (VPN) links across the
   Internet, and a new VET interface (VET2) is configured over these
   links to form a new sub-enterprise.

                         |           <|------------London
                         |     VET2 < |
                         |           <|--------------------New York
                         |            |
                         |            |      Server     Server
                         |     VET1  <|--------|-----------|-------
                         |            |
                         | +--------+ |          Wksta        Wksta
                         | |Firewall| |_____________|____________|
                         | |   NAT  | |
                         | +--------+ |

                     Figure 8: RANGER for multiple locations

Russert, et al.         Expires November 14, 2009              [Page 17]

Internet-Draft                   RANGERS                        May 2009

4.4.  IPv4/IPv6 Transition and Coexistence

   End systems and networks need to accommodate long-term support for
   both IPv4 and IPv6.  Requirements for transition include support for
   IPv4 applications running over IPv4 protocol stacks, IPv4
   applications over IPv6 stacks, IPv4 applications over dual stacks,
   IPv6 or IPv4/IPv6 capable applications over both IPv6 and dual
   stacks.  Both encapsulation and translation will likely be needed to
   allow applications, enterprises and providers to incorporate IPv6,
   including all intermediate states, without global coordination or a
   'flag day'.

   The RANGER architecture facilitates the addition of IPv6 addressing
   to existing IPv4 end systems and routers (i.e., via dual-stack) as
   well as the addition of IPv6 networks to the existing set of IPv4
   networks.  RANGER, with VET [I-D.templin-autoconf-dhcp] and SEAL
   [I-D.templin-seal], makes it possible to carry packets originated in
   one protocol across network infrastructure supporting another
   protocol or routing system.  Figure 1 shows how RANGER supports
   various combinations of edge (EID) and core (RLOC commons)
   technologies, going beyond IP version differences to include mixed
   security, management, and addressing as well.

   The RANGER architecture supports end-to-end communications across
   arbitrarily-long paths of concatenated enterprises connected by EBRs.
   When IPv6 is used as Endpoint interface Identifier (EID) space, each
   EBR can provision a globally unique set of IPv6 EID prefixes without
   scaling limitations due to the expanded IPv6 address space.  For
   example, figure 9 shows a pair of end systems 'H' and 'J' separated
   by an intervening set of enterprises, where the path between 'H' and
   'J' traverses the EBR path 'V->Y1->X2->X7->Z':

Russert, et al.         Expires November 14, 2009              [Page 18]

Internet-Draft                   RANGERS                        May 2009

                                                            | IPv6 |
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "                                               "      +--+---+
   "     . . . . . . .       . . . .      . . . .     "        |
   "   .               .    .       .    .       .    "        |
   "   .  +----+   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         .      . . . .     "
    "                 . . . . . . .                   "
      "                                              "
        " " " " " " " " " " " " " " "" " " " " " " "

             Figure 9: EBR Waypoint Navigation using IPv6

   When each EBR in the path is assigned a unique set of IPv6 EID
   prefixes (and registers these prefixes in the appropriate routing/
   mapping tables), IPv6 can be used for navigation purposes with each
   EBR in the path seen as a waypoint for navigation.  This is true even
   if IPv4 is used as the enterprise-local Routing LOCator (RLOC)
   address space, and there were many IPv4 hops on the path between each
   pair of neighboring EBRs.

   RANGER further provides a compatible framework for incorporating
   supporting mechanisms including protocol translation, application-
   layer aspects of IPv4/IPv6 transition discussed in [RFC4038] and DNS
   issues for IPv6 from [RFC4472].  For instances where IPv4
   applications remain in use, RANGER supports translation via
   functional equivalents of "Network Address Translation, Protocol
   Translation (NAT-PT)" [RFC2766], and "Bump In the Stack (BIS)"
   [RFC2767].  Figure 10 shows the NAT-PT-equivalent translation in the
   VET router, and Figure 11 shows the BIS-equivalent translation in end
   systems.  These examples address scenarios not mentioned in RFC 4852.

Russert, et al.         Expires November 14, 2009              [Page 19]

Internet-Draft                   RANGERS                        May 2009

              IPv4 App A                               IPv4 App B
            _____________                            _____________
           |_TCP or UDP__|                          |_TCP or UDP__|
           |____IPv4_____|                          |____IPv4_____|
            ______|______                           _______|_____
           /             \                         /             \
           |  IPv4-Only   |                        |  IPv4-Only   |
           |   Site 1     |                        |   Site 2     |
           \_____________/                         \_____________/
            ______|______        _____________       ______|_______
           |____IPv4_____|      /             \     |____IPv4_____|
           |NAT-PT-equiv_|      |   Internet   |    |NAT-PT-equiv_|
           |_TCP or UDP__|      |              |    |_TCP or UDP__|
           |____IPv6_____|      |   (RANGER)   |    |____IPv6_____|
           |__VET/SEAL___|      \_____________/     |__VET/SEAL___|
                  \_______________/         \___________/

                Figure 10:  Translation in Routers

   In Figure 10, an IPv4 application on end system A operates normally
   and the end system sends IPv4 packets on the IPv4-only site network.
   The IPv4 packets are received by an Enterprise Border Router (EBR)
   that translates them into IPv6 packets by a NAT-PT-equivalent
   process.  The EBR then encapsulates the packets into IPv4 and sends
   them across the RANGER-enabled Internet to Site 2 where they are
   received and decapsulated by an EBR for Site 2.  The EBR uses NAT-PT-
   equivalent translation to translate the resulting IPv6 packet back to
   an IPv4 packet that is delivered across the Site 2 IPv4-only network
   to an IPv4 application on end system B.

           IPv4 App A                               IPv4 App B
         _____________        ______________      _____________
        |_TCP or UDP__|      /              \    |_TCP or UDP__|
        |____BIS______|      |   Internet   |    |____BIS______|
        |____IPv6_____|      |   (RANGER)   |    |____IPv6_____|
        |__VET/SEAL___|      \_____________/     |__VET/SEAL___|
               \_______________/         \___________/

             Figure 11:  BIS-style Translation in Dual-Stack End Systems

   Figure 11 shows the simplified approach using Bump-In the Stack (BIS)
   translation process within dual-stack end systems ([RFC2767]).  In
   this case, the IPv4 application on dual-stack end system A forms an
   IPv4 payload which is then transformed into an IPv6 packet within the
   end system protocol stack itself.  The IPv6 packet can then be
   encapsulated and sent across the Internet to be decapsulated and sent
   to the dual-stack end system hosting IPv4 application B. The BIS-
   equivalent process on end system B reverses the translation, yielding

Russert, et al.         Expires November 14, 2009              [Page 20]

Internet-Draft                   RANGERS                        May 2009

   an IPv4 packet for consumption by the IPv4-only application.

   Other issues besides IP protocol translation may arise during IPv4-
   IPv6 transition; [RFC4038] points out issues including IPv4/IPv6
   capable applications running on IPv4-only protocol stacks, DNS
   responses that include addresses of both IP versions, and the
   difficulty of supporting multiple application versions.  It also
   advises that applications be converted to dual support as a preferred
   solution.  These issues are outside the scope of this document.

4.5.  Mobility and MANET

4.5.1.  Global Mobility Management

   Ubiquitous wireless access enables connection to network
   infrastructure nearly anywhere.  Vehicles and even persons can host
   networks that move around with them.  For example, commercial
   aircraft networks include requirements for nomadic networks, local
   mobility, and global mobility where the connection point between
   airplane and ground station moves from one continent to another.
   Mobile networks need to be able to use Provider-Independent (PI) as
   well as Provider-aggregated (PA) address prefixes.  Some applications
   such as voice require rapid or seamless connection handoffs - also
   known as session survivability.  Internet routing should not be
   unduly disrupted by mobility, so movement of mobile nodes or edge
   networks should not cause large ripples of routing protocol traffic,
   especially in the DFZ.

   When a RANGER enterprise is overlaid on the Internet, mobile nodes or
   mobile routers (that connect arbitrarily complex edge networks or
   enterprises) can move between different points of attachment while
   remaining reachable and without creating excessive routing churn.  In
   a commercial airline scenario, an aircraft with a mobile router would
   move between ground station points of attachment (that may be on
   different continents) without readdressing of its onboard networks.
   Figure 12 shows an aircraft transiting between four different access
   points; two that are part of Air Communications Service Provider
   (ACSP) 1, one in ACSP2 and the last directly to the Air Navigation
   Service Provider (ANSP).  ACSP1 and ACSP2 in this example might be on
   different continents, so a traditional Mobile IP Home Agent scheme
   would result in very inefficient paths for one ACSP or the other.
   The Aero Enterprise is an overlay that spans both continents and
   allows efficient paths by providing multiple entry and exit points
   (only one, R2, is shown).

Russert, et al.         Expires November 14, 2009              [Page 21]

Internet-Draft                   RANGERS                        May 2009

  Aircraft - - - - - - ,.- - - - - -.- - ->
        .             ,  .           .                        +------+
         .           ,    .           .                       | IPv6 |
          .         ,      .           .                      |Server|
         " ." " " ", "" " " ." " "  " " .? " " " " "          |  S1  |
       "    .     ,          .           .            "       +--+---+
     "       .   ,            .           .            "         |
     "     . ...            . . .         . . +----+    "        |
     "   .       .        .      .      .    =+ X3 +    "        |
     "   .   v  +--- +   . v      .     .  v  +----+    ?        |
     "   .   e =+ Y1 +   . e      .     .  e  .       +----+  +--------+
     "   .   t  +----+   . t    +----+  .  t  .      =+-R2-+==+Internet|
     "   .   1   .       . 2   =+ X2 +  .  3  .       +----+  +--------+
     "    .     .         .     +----+   .   .          "        |
     "      . .             . . .         . .           "     +------+
      "    <ACSP1>       <ACSP2>        <ANSP>          "     | IPv4 |
        "                                              "      |Server|
          "                - - vet 4 - -              "       |  S2  |
            " " " " " " " " " " " " " "" " " " " " "          |  S2  |
                       <-- Aero Enterprise -->                +------+

               Figure 12: Commercial Airplane Mobility

   Where the ground stations are located within the ACSP1 enterprise, no
   routing or mapping changes need be made outside ACSP1.  When the
   point of access moves to ACSP2, no changes are made outside the aero
   Enterprise.  When the aircraft moves between ground stations of the
   same parent enterprise (as indicated by the two different links from
   the aircraft to ACSP1 in Figure 12), the aircraft announces its PI
   prefixes at its new point of attachment and withdraws them from the
   old.  The worldwide Internet sees no change, and mapping system churn
   is confined to ACSP1, since the prefixes need not be announced or
   withdrawn within the parent aero Enterprise, i.e., the churn is
   isolated to lower tiers of the recursive hierarchy.  This can be
   contrasted with the mobility solution previously fielded by
   Connexion, which propagated BGP changes into the Internet routing
   system to support mobile onboard networks.

4.5.2.  First-Responder Mobile Ad-Hoc Networks (MANETs)

   Many emerging network scenarios require autoconfiguration of Mobile
   Ad-Hoc Networks (MANETs).  Where first responders need networking for
   communications and coordination between teams, RANGER allows each
   team or agency to quickly stand up a network and then use the
   autoconfiguration described in [I-D.templin-autoconf-dhcp] to
   coordinate address/prefix autoconfiguration and discover border
   routers needed for teams and agencies to interconnect.

Russert, et al.         Expires November 14, 2009              [Page 22]

Internet-Draft                   RANGERS                        May 2009

   For example, Figure 13 shows how police units arriving on a scene
   with no network infrastructure can create a wireless network using
   vehicle-mounted 802.11 hotspots with one or more cellular, 802.16, or
   satellite links in order to reach the Internet.  The California
   Highway Patrol sets up an incident management center with a satellite
   link to the Internet and vet1 serving Enterprise L1.  The Los Angeles
   County Sheriff team sets up Enterprise L1.1 at their field
   headquarters and the Altadena police force creates the L1.2
   enterprise with their mobile units.  R2 is the Enterprise router that
   serves as an EBG for border routers X3 and X4, which connect
   enterprise L1.2 and L1.1 respectively.  X3 serves vet3 and X4 serves

   In like manner, the Angeles National Forest creates Enterprise F1,
   with the San Gabriel Ranger District setting up Enterprise F1.1 and
   the Fire Response Team Enterprise F1.2.  R1 and R2 discover one
   another and become peer EBRs across the Internet by means of manual
   configuration.  In Enterprise L1, individual PI address prefixes are
   announced from L1.2 and L1.1 to L1 and R2 advertises them to the
   satellite ISP.  R1 receives a PA prefix from its WiMAX provider and
   delegates parts of the prefix to X1 and X2.  R2 also runs an IGP with
   R1, advertising the PI prefixes to R1 and learning the PA prefixes

Russert, et al.         Expires November 14, 2009              [Page 23]

Internet-Draft                   RANGERS                        May 2009

                                                            | IPv6 |
       " " " " " " " "" " " " " " " " " " " " " " " "       |  S1  |
     "          Law Enforcement Enterprise           "      +--+---+
    "    2001:DB8:10::/56 (PI)  ---------------->     "        |
   "      . . . . . . . +--- +            . . . .     "        |
   "    .              =+ X3 +===========.       .    "  +-----+-------+
   "   .  +----+   v    +--- +           .   v   +----+  |             +
   "   .  | V  +=  e    .      . .       .   e  =+ R2 +==+             |
   "   .  +-+--+   t    .    .      +----+   t   +----+  |             |
   "   .    |      3   .    . vet2  + X4 +=  1   .    "  |             |
   "    .   H1        .     .       +----+       .    "  |             |
   "      . . . . . .        . . . .      . . . .     "  |             |
    "       <L1.2>           <L1.1>        <L1>       "  |             |
      "      10/8             10/8         10/8      "   |             |
        " " " " " " " " " " " " " " "" " " " " " " "     |   Internet  |
                                                         |             |
       " " " " " " " "" " " " " " " " " " " " " " " "    |             |
     "        USDA Forest Service Enterprise         "   |             |
    "         <----------------- 2001:DB8::/40 (PA)  "   |             |
   "      . . . . . . . +--- +            . . . .     "  |             |
   "    .              =+ X1 +===========.       .    "  |             |
   "   .  +----+   v    +--- +           .   v   +----+  |             |
   "   .  | J  +=  e    .      . .       .   e  =+ R1 +==+             |
   "   .  +-+--+   t    .    .      +----+   t   +----+  |             |
   "   .    |      6   .    . vet5  + X2 +=  4   .    "  +-----+-------+
   "    .   H2        .     .       +----+       .    "        |
   "      . . . . . .        . . . .      . . . .     "     +--+---+
    "       <F1.2>           <F1.1>        <F1>       "     | IPv4 |
      "      10/8             10/8         10/8      "      |Server|
        " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |

                  Figure 13: First-Responder MANET

4.5.3.  Tactical Military MANETs

   Military networks reflect well-defined policy requirements that
   differ in many ways from civilian networks.  The military's
   information security requirements result in information being labeled
   into specific classifications.  The Bell-LaPadula model
   [Bell-LaPadula] provides a mechanism to extend information security
   policy into networked environments.  This extension creates
   communications security (COMSEC), whose routing and addressing
   elements are cleanly supported by RANGER concepts.

   Figure 3 shows that RANGER supports creation of a VET interface

Russert, et al.         Expires November 14, 2009              [Page 24]

Internet-Draft                   RANGERS                        May 2009

   between the Enterprise Interior (network) Interface of two Enterprise
   Border Routers (EBR) located within separate enterprises, A and B.
   When this concept is applied to Enterprises operating above the
   subnetwork level of the IP Topology Hierarchy, then this VET
   interface uses IP-in-IP encapsulation.  This corresponds with a
   popular COMSEC approach.  When this same RANGER concept is applied to
   Enterprises operating at the subnetwork level of the IP Topology
   Hierarchy then this corresponds to an older form of COMSEC (Link
   Layer Encryption).  When the same RANGER concept is applied to
   Enterprises being singleton EBR nodes (i.e., the interface level of
   the IP Topology Hierarchy) then this corresponds to a third military
   COMSEC alternative (Link Encryption).

   The previous paragraph shows the flexibility of the RANGER
   architecture to describe COMSEC approaches in terms of IP Topology
   Hierarchy structured relationships.  The power of the RANGER
   architecture becomes apparent when one recognizes that each of the
   entities in Figure 3 may themselves be simple or complex network
   structures operating at any specific level of the IP Topology
   Hierarchy.  (Complex structures refer to architectures that have been
   extended by RANGER recursion.)  For example, the commons in the
   figure may itself be an interface, a subnetwork, an autonomous
   system, or an Internet.  Enterprise A and Enterprise B can be a
   single end system, a subnetwork, an autonomous system or an Internet.

   Tactical military MANETs differ from traditional networks in many
   ways, the most obvious being the high mobility of tactical
   deployments and self-forming-network attributes of MANETs themselves.
   Because each networked tactical entity supports a radio/router, the
   numbers of routers within military MANETs can be orders of magnitude
   more numerous (denser) than traditional civilian networks.  This
   means that even small deployments have comparatively large router
   populations when compared to non-MANET deployments.  Larger router
   populations directly create greater sensitivity to protocol
   scalability issues.  Router scalability issues are further
   exacerbated because IP protocols react unfavorably to signal
   intermittence, which effectively dampens and constrains router
   scaling even when mitigation techniques are employed.  Signal
   intermittence itself is a partial function of the impact of mobility
   upon the radio signal propagation attributes of the local deployment
   environment (e.g., issues as terrain, foliage, buildings, weather,
   distance, etc.).  War fighting also encourages war fighters to locate
   into more defensible terrain features, many of which naturally impact
   radio signal propagation, further increasing the probability of
   signal intermittence.

   RANGER recursion enables MANET networks to be defined into structures
   that naturally encourage route aggregation and scaling.  For example,

Russert, et al.         Expires November 14, 2009              [Page 25]

Internet-Draft                   RANGERS                        May 2009

   a MANET autonomous system may benefit from RANGER recursion by being
   physically comprised of enterprises who themselves are autonomous
   systems.  This relationship can be recursively extended vertically as
   deep as required in order to create router aggregation between
   entities having common mission assignments at differing levels of
   abstraction.  Since MANET routing is an active research topic, it is
   helpful to realize that these structures may or may not use similar
   routing protocols as their civilian IP Topology Hierarchy peers.  For
   example, because of the behavior of BGP within highly mobile
   environments, the Exterior Gateway Protocol (EGP) used to link ASes
   may or may not be BGP and, if it is BGP, it may have unusual timer
   settings.  However, whatever IGP and EGP is used, RANGER constructs
   can increase route aggregation between entities sharing common
   mission assignments to enable route scaling.

   Tactical Military MANETs often have requirements to communicate with
   stationary infrastructures.  By localizing mobility into an
   enterprise then the specific mobility-friendly protocols can be
   localized and its aggregation results presented to the stationary
   network using a protocol supported by the stable network.  This also
   reduces the impact of mobility upon routing and addressing systems as
   reported to the stationary infrastructure.  Mobility induced route
   fluctuations (e.g., routing flaps) can still occur but their impact
   can be dampened if RANGER constructs are used to localize them in
   lower tiers of the IP Topology Hierarchy.  For example, Enterprise A
   in Figure 3 can be a military MANET and Enterprise B may be a
   stationary military entity.  Please recall that Enterprise A and B
   interface at a specific IP Topology Hierarchy level but they may be
   physically extended by RANGER mechanisms.  For example, Enterprise A
   can be a MANET enterprise that is physically a network-of-networks
   Internet that interfaces to Enterprise B as if it were an Autonomous
   System.  This gives Enterprise B a more stable and aggregated view of
   the Enterprise A Internet than would be the case if it were directly
   aware of Enterprise A's various sub-enterprise components.

   Another key distinctive of Tactical Military networks is because
   radio networks operate at a different classification level than the
   data they convey, tactical military networks have several orders of
   magnitude more COMSEC devices than do equivalently sized stationary
   military deployments (i.e., the number of COMSEC devices is a
   function of the number of mobile war-fighting entities).  This can
   create significant scalability issues within the overlay COMSEC
   network relationships themselves.  COMSEC scaling problems become
   manifested in several dimensions.  It is important to recognize,
   however, that just as RANGER recursion was vertically used to create
   IP Topology enterprise-within-enterprise structures in order to
   improve routing aggregation and scaling of the peer enterprises, so
   RANGER recursion can horizontally (within the same IP Topology

Russert, et al.         Expires November 14, 2009              [Page 26]

Internet-Draft                   RANGERS                        May 2009

   Hierarchy level) be used to improve COMSEC aggregation and scaling of
   the network overlay system.  The RANGER use of VET also combines with
   the Subnetwork Encapsulation and Adaptation Layer (SEAL) to provide
   robust packet identification and maximum transmission unit (MTU) link
   adaptation services over tunnels.  These capabilities protect against
   both source address spoofing and black holes caused by MTU

4.6.  Provider Concerns

   Network providers must have a way to support the protocol transitions
   and network types mentioned above and still remain reliable and
   financially sound.  The RANGER architecture provides ways to support
   general Internet Service Providers (ISPs), cellular operator
   networks, and specialized networks such as the Aeronautical
   Telecommunications Network (ATN).

4.6.1.  ISP Networks

   Internet service provider networks provide a commons for the
   connection of Customer Premises Equipment (CPE) routers [I-D.ietf-
   v6ops-ipv6-cpe-router] that connect arbitrarily-complex customer
   networks.  This is true whether the ISP permits direct customer-to-
   customer communications, or whether all communications are forwarded
   through ISP Provider Edge (PE) equipment.

   The ISP commons must potentially support hundreds of thousands of CPE
   routers (or more), hence the ISP may be obliged to assign private
   IPv4 address allocations (i.e., instead of public) as RLOCs for CPE
   routers.  This gives rise to a "nested NATs" scenario, which can
   increase the overall brittleness brought on by NAT traversal.

   To address this brittleness, the ISP can deploy "Carrier Grade NATs"
   (CGNs) [I-D.jiang-incremental-cgn] that provide a second level of
   RLOC address translation on the path from the CPE to the Internet.
   When the CGNs are also configured as EBGs, CPE routers can discover
   them as default routers for reaching EID-based services using the EBG
   discovery mechanisms specified in VET.

   Scenarios and Analysis for Introducing IPv6 into ISP Networks
   [RFC4029] discusses both ISP backbone network and customer connection
   transition considerations, however this document considers router-to-
   router tunneling use cases.  Therefore the ISATAP mechanism (which
   only supports host-to-router or host-to-host tunneling) is not
   mentioned as a candidate technology.  Early point solutions (e.g.,
   TSP, STEP, etc.) were recommended prior to the publication of RANGER,
   VET and SEAL.  This document therefore updates RFC4029 to introduce
   these new technologies that are widely applicable to managed network

Russert, et al.         Expires November 14, 2009              [Page 27]

Internet-Draft                   RANGERS                        May 2009

   scenarios such as ISP networks.

4.6.2.  Cellular Operator Networks

   [RFC4215] provides an Analysis on IPv6 Transition in Third Generation
   Partnership Project (3GPP) Networks.  It envisions an extended period
   of support for both IPv4 and IPv6 protocols in the operator network.
   User Equipment (UE) uses the Packet Data Protocol (PDP) context to
   establish tunnels through the operator network to a Gateway GPRS
   Support Node (GGSN).  When the UE uses IPv6, and the PDP context is
   established across an IPv4 provider network, the UE can configure
   itself as an EBR and contact the GGSN (as a RANGER EBG) through VET

   Other scenarios examine IPv4-only UEs, IPv6-only UEs, and various
   combinations of IPv4 and IPv6 within the operator network.  Also to
   be considered are scenarios in which the UE is configured as a router
   or bridge that connects an end system such as a laptop computer.  In
   that case, the UE could be the first-hop router/bridge into the
   cellular provider network, and the laptop computer could be
   configured as an EBR in the RANGER model.  Again, the GGSN or a
   device reachable through the GGSN could serve as a RANGER EBG.

   [RFC4215] was published prior to the development of RANGER, VET and
   SEAL.  This document therefore updates RFC4215 to introduce these new
   technologies that are widely applicable to managed network scenarios
   such as cellular operator networks.

4.6.3.  Aeronautical Telecommunications Network (ATN)

   The future global Aeronautical Telecommunications Network (ATN) is
   currently under consideration within the civil aviation industry.
   The IP variant of ATN is expected to take the form of a worldwide
   enterprise that internally comprises an aeronautical-only Internet
   which has additional external interfaces to the global Internet.
   Within the ATN, there may be many Air Communications Service Provider
   (ACSP) and Air Navigation Service Provider (ANSP) networks that are
   internally organized either as autonomous systems or internets within
   the ATN, i.e., as depicted in figure 5.  Each of these entities may
   themselves be further internally sub-divided into lower-tier
   enterprises organized as regional, organizational, or functional
   compartments.  It is important to note that while ACSPs and ANSPs
   within the ATN will share a common objective of safety-of-flight for
   civil aviation services, there potentially also may exist competing
   business, social, or political interests between Enterprises which
   require that components be distinct ASs.  The RANGER principles
   therefore support collaborative objectives while supporting
   potentially very diverse local policy distinctions.  In this manner

Russert, et al.         Expires November 14, 2009              [Page 28]

Internet-Draft                   RANGERS                        May 2009

   entities that do not trust each other can create collaborative
   infrastructures to achieve common goals.

   Operational associations like this will characterize many next-
   generation deployments, including the US Department of Defense's
   Global Informatino Grid (GIG).  In particular, although the routing
   and addressing arrangements of all enterprises require a mutual level
   of cooperative active management at a certain level, scaling issues,
   security policy differences, free market forces, organizational
   differences, political distinctions, or other factors may create
   internal competition among entities that otherwise share common
   goals, which will require different enterprises within that
   association to be separated into distinct ASes that are linked within
   their own functional Internet relationship.

   The ATN illustrates transition from OSI protocols to IPv6.  It must
   support mobility (see Section 4.5.1) and it serves many government
   and private entities which cooperate to provide safe and efficient
   air travel while often competing with one another.  One possible way
   to meet these needs with RANGER is to create an overlay using IP in
   IP tunneling across the Internet, as illustrated in Figure 14.  The
   aero overlay forms an enterprise, so that inner packets from edge
   networks from ACSP, ANSP, or AOC that travel between VET interfaces
   on EBRs see their passage across the Internet as only one hop.

              /                                              \
             (                  IPv4 Internet                 )
                    |         /       |       \       |
                    |        /        |        \      |
              /                                              \
             (                  Aero Overlay                  )
               .  .         .          .            .   .
              .   .           .       .             .    .
       _...-------.._       _...-------.._      _...-------.._
      /              \     /              \    /              \
     (      ACSP1     )   (      ANSP      )  (     ACSP2      )
      -...________...-     -...________...-    -...________...-

                     Figure 14: Aeronautical Overlay

   Each Aeronautical Communications Service Provider (ACSP), and
   Aeronautical Navigation Service Provider (ANSP) constitute an
   enterprise recursively nested below the aero overlay.  Relationships

Russert, et al.         Expires November 14, 2009              [Page 29]

Internet-Draft                   RANGERS                        May 2009

   between the various enterprises can vary from slight to tight
   integration.  In the example, the ACSP and ANSP might choose to
   exchange full routing information for their edge networks using a
   coordinated global-scope RLOC address space in which ACSP and ANSP
   EBRs can route traffic across without further mapping lookups or re-
   encapsulation at intermediate EBRs.  Other enterprises that have the
   aero enterprise as a common parent may not have any knowledge of each
   other's interior routing but will merely forward packets on a default
   route up to the aero overlay.

   The ATN is currently an OSI network but is projected to transition to
   IPv6 over time.  RANGER can bridge OSI networks together across the
   IPv4 (or IPv6) Internet, or bridge IPv4 or IPv6 networks across an
   OSI network.  A pair of EBRs that have IP interfaces on a common
   enterprise (whether it is the Internet, the aero enterprise, or
   another parent or child enterprise) can support communications
   between their attached OSI edge networks by looking up ISO network
   service access point (NSAP) addresses [IS8348] instead of IP
   addresses for RLOC mappings.  OSI ConnectionLess Network Protocol
   (CLNP) [IS8473] packets can therefore be encapsulated within IPv4 (or
   IPv6) headers for transmission across an Internet Protocol
   enterprise.  Some OSI networks may transition to IPv6 protocols and
   addressing [RFC1888] while applications are adapted by using RFC 2126
   [RFC2126] to carry OSI upper layers over TCP/IP, with the resulting
   IP packets carried across and between RANGER enterprises in the
   normal way.  Another approach is to put a protocol translation
   function in the EBRs that support OSI protocol edge networks, similar
   to the protocol translation approach shown in Figure 10.

   Figure 15 depicts an ACSP and ANSP connected via an IPv4 aero
   overlay.  Host H represents a system onboard an aircraft that has a
   wireless link to the ACSP, connected via an enterprise-edge network
   interface on EBR F within the ACSP enterprise.  H resides on an IPv6
   edge network, and its EID is taken from the ACSP IPv6 prefix.  H
   needs to send a query to server S in the ANSP enterprise.  H starts
   by sending a DNS query to the server at G and in return it receives
   the EID of server S. H then creates an IPv6 packet with source EID(H)
   and destination EID(S) and forwards it to its default router, F. F
   consults G for a mapping from EID(S) to the appropriate RLOC.  In
   this case, EBR F encapsulates the IPv6 packet in an IPv6 outer packet
   and forwards the packet to its default EBG, A. A decapsulates the
   packet and looks up the destination EID(S) by querying the DNS server
   at EBR B. B returns a mapping with the RLOC of EBR E. A encapsulates
   the IPv6 inner packet in an IPv4 outer packet with source RLOC(A) and
   destination RLOC(E).  The packet is forwarded via EBRs C and D in the
   aero overlay until it reaches E, where it is decapsulated.  E
   consults its cache of EID/RLOC mappings and finds that the EBR for S
   is N. E encapsulates the packet in an IPv6 packet with source RLOC(E)

Russert, et al.         Expires November 14, 2009              [Page 30]

Internet-Draft                   RANGERS                        May 2009

   and destination RLOC(N).  When the packet reaches N, it is
   decapsulated and the inner IPv6 packet is forwarded on the edge
   network to the server, S.

            /           (B)                   (D)          \
           (                  Aero Overlay (IPv4)           )
                 .                  .            .
               (A)                (C)            .
               .                  .              .
      _...------------------------.._           (E)
     /                               \           .
    /      (F)                        \          .
   (     [H]       ACSP (IPv6)         )         .
    \                      (G)        /          .
     \...__________________________...           .
                                     /                               \
                                    /     (M)                (N)      \
                                   (               ANSP (IPv6)         )
                                    \                          [S]    /

                 Figure 15: Packet Forwarding for Aeronautical Networks

4.6.4.  Unmanaged Networks

   Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
   [RFC3904] considers four cases for support of IPv6-enabled routers
   and end systems connected to an ISP network via a gateway:

   a.  a gateway which does not provide IPv6 at all;

   b.  a dual-stack gateway connected to a dual-stack ISP;

   c.  a dual-stack gateway connected to an IPv4-only ISP; and

   d.  a gateway connected to an IPv6-only ISP.

   Case a is typified by the widespread practice of customer networks
   using IPv4-only NAT boxes to connect to their service providers.
   RANGER does not address this scenario directly, however the TEREDO
   mechanism [RFC4380] can provide a sufficient solution in many cases.

   Case d is a scenario that has not yet seen widespread adoption.  In
   this scenario, the customer network could be configured as IPv6 only

Russert, et al.         Expires November 14, 2009              [Page 31]

Internet-Draft                   RANGERS                        May 2009

   and the deployment could be considered as an IPv6-only extension to a
   RANGER enterprise-edge network.  End systems in this scenario would
   still require support for legacy IPv4-only applications, and if the
   customer network contained IPv4-only routers and end systems the
   RANGER encapsulation mechanisms would still apply.

   Cases b and c correspond to the scenario of the customer gateway to
   the ISP becoming an IPv6 router.  In that case, the gateway could
   become a RANGER EBR, and the scenario becomes one and the same with
   the SOHO network use cases discussed in Section 4.3.  In particular,
   when traditional home network IPv4 NAT boxes are updated to also
   support IPv6 routing, the NAT box becomes a RANGER EBR.

5.  Summary

   The Internet today can be considered as a giant enterprise, with
   nodes in the Internet addressed from the public IPv4 address space as
   RLOCs.  Due to the 32-bit addressing limitations of IPv4, however,
   continued expansion is coordinated through the widespread deployment
   of IPv4 Network Address Translators (NATs) while IPv6 has yet to see
   wide adoption.

   In many senses, however, this has resulted in a degenerate
   manifestation of the network-of-networks model originally envisaged,
   e.g., in the CATENET model.  Indeed, these NATed domains have the
   external appearance of being a simple host within the global Internet
   RLOC space even though they may be proxying for arbitrarily large
   networks of end systems.  The end result is a loss of transparency in
   the end-to-end model, e.g., it is no longer true that any node in the
   Internet can directly address any other node.

   By adopting the principle of using RLOCs as the local addressing
   range and EIDs as the global addressing range, RANGER enables a true
   network-within-network (or, enterprise-within-enterprise) framework.
   This is true even across a wide array of deployment scenarios as
   documented herein, and even for networks-within-networks that may be
   recursively nested to an arbitrary depth.  RANGER therefore brings a
   unifying architecture applied consistently across all layers of
   recursion, rather than a mixed bag of point solutions that may or may
   not be mutually compatible.

   By restoring the original CATENET vision to the Internet, the next
   generation Internet would become arbitrarily scalable while
   simultaneously supporting provider independence, mobility,
   multihoming, and security.

Russert, et al.         Expires November 14, 2009              [Page 32]

Internet-Draft                   RANGERS                        May 2009

6.  IANA Considerations

   There are no IANA considerations for this document.

7.  Security Considerations

   Security considerations are addressed in [I-D.templin-ranger],
   [I-D.templin-autoconf-dhcp], and [I-D.templin-seal].  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].  Security
   considerations for specific use cases are discussed there.

8.  Acknowledgements

   This work was inspired by the original architectural principles of
   the Internet supplemented with "lessons learned" by many peers from
   actual Internet deployments and experience developing encapsulation
   protocols.  The editors acknowledge that they are furthering work
   initiated by many.

9.  References

9.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.  Informative References

              Bell, D. and L. LaPadula, "Secure Computer Systems:
              Mathematical Foundations and Model", October 1974.

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

              Huston, G., "The End of the (IPv4) World is Nigher",
              July 2007.

Russert, et al.         Expires November 14, 2009              [Page 33]

Internet-Draft                   RANGERS                        May 2009

              Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              still needs work", draft-carpenter-renum-needs-work-03
              (work in progress), May 2009.

              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12 (work in progress), March 2009.

              Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
              L. Zhang, "FIB Suppression with Virtual Aggregation",
              draft-francis-intra-va-01 (work in progress), April 2009.

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

              Li, T., "Preliminary Recommendation for a Routing
              Architecture", draft-irtf-rrg-recommendation-02 (work in
              progress), March 2009.

              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.

              Jiang, S. and D. Guo, "An Incremental Carrier-Grade NAT
              (CGN) for IPv6 Transition", draft-jiang-incremental-cgn-00
              (work in progress), March 2009.

              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-autoconf-dhcp-38 (work in progress),
              April 2009.

              Templin, F., "Transmission of IPv4 Packets over ISATAP
              Interfaces", draft-templin-isatapv4-02 (work in progress),
              March 2009.

              Templin, F., "Routing and Addressing in Next-Generation

Russert, et al.         Expires November 14, 2009              [Page 34]

Internet-Draft                   RANGERS                        May 2009

              EnteRprises (RANGER)", draft-templin-ranger-07 (work in
              progress), February 2009.

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

              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.

   [IS8348]   ISO/IEC, I., "Open Systems Interconnection -- Network
              service definition", 2002.

   [IS8473]   ISO/IEC, I., "Protocol for providing the connectionless-
              mode network service: Protocol specification", 1998.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

   [RFC1888]  Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
              and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.

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

   [RFC2126]  Pouffary, Y. and A. Young, "ISO Transport Service on top
              of TCP (ITOT)", RFC 2126, March 1997.

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

Russert, et al.         Expires November 14, 2009              [Page 35]

Internet-Draft                   RANGERS                        May 2009

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

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC2767]  Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
              Hosts using the "Bump-In-the-Stack" Technique (BIS)",
              RFC 2767, February 2000.

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

   [RFC3194]  Durand, A. and C. Huitema, "The H-Density Ratio for
              Address Assignment Efficiency An Update on the H ratio",
              RFC 3194, November 2001.

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

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

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

   [RFC3904]  Huitema, C., Austein, R., Satapati, S., and R. van der
              Pol, "Evaluation of IPv6 Transition Mechanisms for
              Unmanaged Networks", RFC 3904, September 2004.

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

   [RFC4029]  Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
              Savola, "Scenarios and Analysis for Introducing IPv6 into
              ISP Networks", RFC 4029, March 2005.

   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
              Castro, "Application Aspects of IPv6 Transition",
              RFC 4038, March 2005.

   [RFC4057]  Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
              June 2005.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for

Russert, et al.         Expires November 14, 2009              [Page 36]

Internet-Draft                   RANGERS                        May 2009

              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4215]  Wiljakka, J., "Analysis on IPv6 Transition in Third
              Generation Partnership Project (3GPP) Networks", RFC 4215,
              October 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

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

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472,
              April 2006.

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

   [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
              Multicast Name Resolution (LLMNR)", RFC 4795,
              January 2007.

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

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

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              September 2007.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 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

Russert, et al.         Expires November 14, 2009              [Page 37]

Internet-Draft                   RANGERS                        May 2009

              for IPv6", RFC 5340, July 2008.

   [V4pool]   Hain, T., "The IPv4 Address Pool Projection", April 2009.

Authors' Addresses

   Steven W. Russert (editor)
   Boeing Research & Technology
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124

   Email: steven.w.russert@boeing.com

   Eric W. Fleischman (editor)
   Boeing Research & Technology
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124

   Email: eric.fleischman@boeing.com

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

   Email: fltemplin@acm.org

Russert, et al.         Expires November 14, 2009              [Page 38]

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