GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5720

Independent Submission F. Templin Request for Comments: 5720 Boeing Phantom Works Category: Informational February 2010 ISSN: 2070-1721

              Routing and Addressing in Networks with
                Global Enterprise Recursion (RANGER)

Abstract

 RANGER is an architectural framework for scalable routing and
 addressing in networks with global enterprise recursion.  The term
 "enterprise network" within this context extends to a wide variety of
 use cases and deployment scenarios, where an "enterprise" can be as
 small as a Small Office, Home Office (SOHO) network, as dynamic as a
 Mobile Ad Hoc Network, as complex as a multi-organizational
 corporation, or as large as the global Internet itself.  Such
 networks will require an architected solution for the coordination of
 routing and addressing plans with accommodations for scalability,
 provider-independence, mobility, multihoming, and security.  These
 considerations are particularly true for existing deployments, but
 the same principles apply even for clean-slate approaches.  The
 RANGER architecture addresses these requirements and provides a
 comprehensive framework for IPv6/IPv4 coexistence.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5720.

Templin Informational [Page 1] RFC 5720 RANGER February 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................4
 3. The RANGER Architecture .........................................7
    3.1. Routing and Addressing .....................................7
    3.2. The Enterprise-within-Enterprise Framework .................9
    3.3. Virtual Enterprise Traversal (VET) ........................12
         3.3.1. RANGER Organizational Principles ...................12
         3.3.2. RANGER End-to-End Addressing Example ...............14
         3.3.3. Dynamic Routing and On-Demand Mapping ..............14
         3.3.4. Support for Legacy RLOC-Based Services .............16
    3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) ......18
    3.5. Mobility Management .......................................18
    3.6. Multihoming ...............................................20
    3.7. Implications for the Internet .............................20
 4. Related Initiatives ............................................21
 5. Security Considerations ........................................22
 6. Acknowledgements ...............................................23
 7. References .....................................................23
    7.1. Normative References ......................................23
    7.2. Informative References ....................................24

Templin Informational [Page 2] RFC 5720 RANGER February 2010

1. Introduction

 RANGER is an architectural framework for scalable routing and
 addressing in networks with global enterprise recursion.  The term
 "enterprise network" within this context extends to a wide variety of
 use cases and deployment scenarios, where an "enterprise" can be as
 small as a SOHO network, as dynamic as a Mobile Ad Hoc Network, as
 complex as a multi-organizational corporation, or as large as the
 global Internet itself.  Such networks will require an architected
 solution for the coordination of routing and addressing plans with
 accommodations for scalability, provider-independence, mobility,
 multihoming, and security.  These considerations are particularly
 true for existing deployments, but the same principles apply even for
 clean-slate approaches.  The RANGER architecture addresses these
 requirements and also provides a comprehensive framework for IPv6/
 IPv4 coexistence [COEXIST].
 RANGER provides a unifying architecture for enterprises that contain
 one or more distinct interior IP routing and addressing domains (or
 "Routing LOCator (RLOC) space"), with each distinct RLOC space
 containing one or more organizational groupings.  Each RLOC space may
 coordinate their own internal addressing plans independently of one
 another, such that limited-scope addresses (e.g., [RFC1918] private-
 use IPv4 addresses) may be reused with impunity to provide unlimited
 scaling through spatial reuse.  Each RLOC space therefore appears as
 an enterprise unto itself, where organizational partitioning of the
 enterprise into one or more "sub-enterprises" (or "sites") is also
 possible and beneficial in many scenarios.  Without an architected
 approach, routing and addressing within such a framework would be
 fragmented due to address/prefix reuse between disjoint enterprises.
 With RANGER, however, multiple enterprises can be linked together to
 provide a multi-hop transit for nodes attached to enterprise edge
 networks that use Endpoint Interface iDentifier (EID) addresses taken
 from an IP addressing range that is distinct from any RLOC space.
 RANGER is recursive in that multiple enterprises can be joined
 together in a nested "enterprise-within-enterprise" fashion, where
 each enterprise also connects edge networks with nodes that configure
 addresses taken from EID space to support edge/core separation.  In
 this way, the same RANGER principles that apply in lower levels of
 recursion can extend upwards to parent enterprises and ultimately to
 the core of the global Internet itself.  Furthermore, it is also
 worth considering whether today's global Internet represents a
 limiting condition for recursion -- in particular, whether other
 internets could be manifested as "parallel universes" and joined
 together at still higher levels of recursion.

Templin Informational [Page 3] RFC 5720 RANGER February 2010

 The RANGER architecture is manifested through composite technologies,
 including Virtual Enterprise Traversal (VET) [VET], the Subnetwork
 Encapsulation and Adaptation Layer (SEAL) [SEAL], and the Intra-Site
 Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214].  Other
 mechanisms such as IPsec [RFC4301] are also in scope for use within
 certain scenarios.
 Noting that combinations with still other technologies are also
 possible, the issues addressed either in full or in part by RANGER
 include:
 o  scalable routing and addressing
 o  provider-independent addressing and its relation to provider-
    aggregated addressing
 o  site mobility and multihoming
 o  address and prefix autoconfiguration
 o  border router discovery
 o  router/host-to-router/host tunneling
 o  neighbor discovery over tunnels
 o  MTU determination for tunnels
 o  IPv6/IPv4 coexistence and transition
 Note that while this document primarily uses the illustrative example
 of IPv6 [RFC2460] as a virtual overlay over IPv4 [RFC0791] networks,
 it is important to note that the same architectural principles apply
 to any combination of IPvX virtual overlays over IPvY networks.

2. Terminology

 Routing Locator (RLOC)
    an IPv4 or IPv6 address assigned to an interface in an enterprise-
    interior routing region.  Note that private-use IP addresses are
    local to each enterprise; hence, the same private-use addresses
    may appear within disjoint enterprises.
 Endpoint Interface iDentifier (EID)
    an IPv4 or IPv6 address assigned to an edge network interface of
    an end system.  Note that EID space must be separate and distinct
    from any RLOC space.

Templin Informational [Page 4] RFC 5720 RANGER February 2010

 commons
    an enterprise-interior routing region that provides a subnetwork
    for cooperative peering between the border routers of diverse
    organizations that may have competing interests.  A prime example
    of a commons is the Default-Free Zone (DFZ) of the global
    Internet.  The enterprise-interior routing region within the
    commons uses an addressing plan taken from RLOC space.
 enterprise
    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 DFZ).
    Enterprise networks are typically associated with large
    corporations or academic campuses; however, the RANGER
    architectural principles apply to any network that has some degree
    of cooperative active management.  This definition therefore
    extends to home networks, small office networks, ISP networks, a
    wide variety of Mobile Ad Hoc Networks (MANETs), and even to the
    global Internet itself.
 site
    a logical and/or physical grouping of interfaces within 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
    itself.
 Enterprise Border Router (EBR)
    a router 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 [VET].

Templin Informational [Page 5] RFC 5720 RANGER February 2010

 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 [VET], and is synonymous with the
    term "default mapper" used in other contexts (e.g., [JEN]).
 Ingress Tunnel Endpoint (ITE)
    a host or router interface that encapsulates inner IP packets
    within an outer IP header for transmission over an enterprise-
    interior routing region to the RLOC address of an Egress Tunnel
    Endpoint (ETE).
 Egress Tunnel Endpoint (ETE)
    a host or router interface that receives encapsulated packets sent
    to its RLOC address, decapsulates the inner IP packets, then
    delivers them to the EID address of the final destination.
 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.
 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 Border Router (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.
 Additionally, RANGER provides an informative consideration of
 functional specifications and operational practices outlined in other
 documents.  These documents include:

Templin Informational [Page 6] RFC 5720 RANGER February 2010

 6over4
    Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
    [RFC2529]; functional specifications and operational practices for
    automatic tunneling of unicast/multicast IPv6 packets over
    multicast-capable IPv4 enterprises.
 ISATAP
    Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
    [RFC5214]; functional specifications and operational practices for
    automatic tunneling of unicast IPv6 packets over unicast-only IPv4
    enterprises.
 VET
    Virtual Enterprise Traversal (VET) [VET]; functional
    specifications and operational practices for automatic tunneling
    of both unicast and multicast IP packets with provisions for
    address/prefix autoconfiguration, provider-independent addressing,
    mobility, multihoming, and security.  VET is descended from both
    6over4 and ISATAP and is also known as "ISATAP version 2
    (ISATAPv2)".
 SEAL
    Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL]; an
    encapsulation sublayer that provides an extended IP Identification
    field and mechanisms for link MTU adaptation over tunnels.

3. The RANGER Architecture

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

3.1. Routing and Addressing

 The Internet today is facing "growing pains", with indications that
 core Routing Information Base (RIB) scaling may not be sustainable
 over the long term and that the remaining space for IPv4 address
 allocations may be depleted in the near future.  Therefore, there is
 an emerging need for scalable routing and addressing solutions.  It
 must further be noted that the same solutions selected to address
 global Internet routing and addressing scaling can apply equally for
 large enterprises -- or for any enterprise that would benefit from a
 separation of core and edge addressing domains.

Templin Informational [Page 7] RFC 5720 RANGER February 2010

 RANGER supports scalable routing through an approach that parallels
 the "New Scheme for Internet Routing and Addressing" described in
 [RFC1955].  This approach is also commonly known as "map-and-encaps".
 In this approach, an Ingress Tunnel Endpoint (ITE) that must forward
 an IP packet first consults a mapping system to discover a mapping
 for the destination Endpoint Interface iDentifier (EID) to a Routing
 LOCator (RLOC) assigned to an Egress Tunnel Endpoint (ETE).  The
 mapping system is typically maintained as a per-enterprise
 distributed database that is synchronized among a limited set of
 mapping agents.  Distributed database management alternatives include
 a routing protocol instance maintained by Enterprise Border Gateways
 (EBGs), a DNS reverse zone distributed among a restricted set of
 caching servers, etc.  Mapping entries are inserted into the mapping
 system through administrative configuration, automated prefix
 registrations, etc.
 RANGER allows for an ITE to either consult the mapping system itself
 (while delaying or dropping initial IP packets) or forward initial
 packets to an EBG acting as a "default mapper".  In either case, the
 ITE receives a mapping reply that it can use to populate its
 Forwarding Information Base (FIB).  The choice of mapping approaches
 must be considered with respect to the individual enterprise network
 scenario, e.g., forwarding to an EBG may be more appropriate in some
 scenarios while ITE self-discovery may be more appropriate in others.
 Use of other mapping mechanisms is also possible according to the
 specific enterprise scenario.
 After discovering the mapping, the ITE encapsulates inner IP packets
 in an outer IP header for transmission across the commons to the RLOC
 address of an ETE.  The ETE in turn decapsulates the packets and
 forwards them over the next hop toward the EID address of the final
 destination.  Therefore, the Routing Information Base (RIB) within
 the commons only needs to maintain state regarding RLOCs and not
 EIDs, while the synchronized EID-to-RLOC mapping state is maintained
 by a smaller number of nodes and is not subject to oscillations due
 to link state changes within the commons.  Finally, EIDs are routable
 only within a limited scope within edge networks (which may be as
 small as node-local scope in the limiting case).
 RANGER supports scalable addressing by selecting a suitably large EID
 addressing range that is distinct and kept separate from any
 enterprise-interior RLOC addressing ranges.  It should therefore come
 as no surprise that taking EID space from the IPv6 addressing
 architecture should lead to a viable, scalable addressing
 alternative, while taking EID space from the (already exhausted) IPv4
 addressing architecture may not.

Templin Informational [Page 8] RFC 5720 RANGER February 2010

3.2. The Enterprise-within-Enterprise Framework

 Enterprise networks traditionally distribute routing information via
 Interior Gateway Protocols (IGPs) such as Open Shortest Path First
 (OSPF), while large enterprises may even use an Exterior Gateway
 Protocol (EGP) internally in place of an IGP.  Thus, it is becoming
 increasingly commonplace for large enterprises to use the Border
 Gateway Protocol (BGP) internally and independently from the BGP
 instance that maintains the RIB within the global Internet DFZ.
 As such, large enterprises may run an internal instance of BGP across
 many internal Autonomous Systems (ASs).  Such a large enterprise can
 therefore appear as an internet unto itself, albeit with default
 routes leading to the true global Internet.  Additionally, each
 internal AS within such an enterprise may itself run BGP internally
 in place of an IGP, and can therefore also appear as an independent,
 lower-tier enterprise unto itself.  This enterprise-within-enterprise
 framework can be extended in a recursive fashion as broadly and as
 deeply as desired to achieve scaling factors as well as
 organizational and/or functional compartmentalization, e.g., as shown
 in Figure 1.

Templin Informational [Page 9] RFC 5720 RANGER February 2010

                             ,---------------.
                          ,-'     Global      `-.  <--------+
                         (       IPv6/IPv4       )     ,----|-----.
                          `-.    Internet     ,-'     ( Enterprises)
                             `+--+..+--+ ...+--+      ( E2 thru EN )
                           _.-|R1|--|R2+----|Rn|-._    `.---------/
                    _.---''   +--+  +--+ ...+--+   -.
               ,--''           ,---.                 `---.
            ,-'              X5     X6            .---..  `-.
          ,'  ,.X1-..       /         \        ,'       `.   `.
        ,'  ,'       `.    .'  E1.2   '.     X8    E1.m   \    `.
       /   /           \   |   ,--.    |     / _,.._       \     \
      /   /   E1.1      \  | Y3    `.  |    | /     Y7       |     \
     ;   |    ___        | |  ` W  Y4  |... | `Y6  ,'       |      :
     |   | ,-'   `.     X2 |   `--'    |    |   `''         |      |
     :   | |  V  Y2      | \    _      /    |               |      ;
      \  | `-Y1,,'       |  \ .' Y5   /      \    ,-Y8'`-   /      /
       \  \             /    \ \_'  /        X9   `.    ,'/      /
        `. \          X3      `.__,,'          `._  Y9'','     ,'
          ` `._     _,'      ___.......X7_        `---'      ,'
            `  `---'      ,-'             `-.              -'
               `---.      `.    E1.3   Z   _'        _.--'
                    `-----. \---.......---'   _.---''
                           `----------------''
         <----------------   Enterprise E1  ---------------->
           Figure 1: Enterprise-within-Enterprise Framework
 Figure 1 depicts an enterprise 'E1' connected to the global IPv6/IPv4
 Internet via routers 'R1' through 'Rn' and additional enterprises
 'E2' through 'EN' that also connect to the global Internet.  Within
 the 'E1' commons, there may be arbitrarily many hosts, routers, and
 networks (not shown in the diagram) that use addresses taken from
 RLOC space and over which both encapsulated and unencapsulated IP
 packets can be forwarded.  There may also be many lower-tier
 enterprises, 'E1.1' through 'E1.m' (shown in the diagram), that
 interconnect within the 'E1' commons via Enterprise Border Routers
 (EBRs), depicted as 'X1' through 'X9' (where 'X1' through 'X9' see
 'R1' through 'Rn' as EBGs).  Within each 'E1.*' enterprise, there may
 also be arbitrarily many lower-tier enterprises that interconnect
 within the 'E1.*' commons via EBRs, depicted as 'Y1' through 'Y9' in
 the diagram (where 'Y1' through 'Y9' see 'X1' through 'X9' as EBGs).
 This recursive decomposition can be nested as deeply as desired and
 ultimately terminates at singleton nodes such as those depicted as
 'V', 'W', and 'Z' in the diagram.

Templin Informational [Page 10] RFC 5720 RANGER February 2010

 It is important to note that nodes such as 'V', 'W', and 'Z' may be
 simple hosts or they may be EBRs that attach arbitrarily complex edge
 networks with addresses taken from EID space.  Such edge networks
 could be as simple as a home network behind a residential gateway or
 as complex as a major corporate/academic campus, a large service
 provider network, etc.
 Again, this enterprise-within-enterprise framework can be recursively
 nested as broadly and deeply as desired.  From the highest level of
 the recursion, consider now that the global Internet itself can be
 viewed as an "enterprise" that interconnects lower-tier enterprises
 E1 through EN such that all RANGER architectural principles apply
 equally within that context.  Furthermore, the RANGER architecture
 recognizes that the global Internet need not represent a limiting
 condition for recursion, but rather allows that other internets could
 be manifested as "parallel universes" and joined together at still
 higher levels of recursion.
 As a specific case in point, the future global Aeronautical
 Telecommunications Network (ATN), under consideration within the
 civil aviation industry [BAUER], will take the form of a large
 enterprise network that appears as an internet unto itself, i.e.,
 exactly as depicted for 'E1' in Figure 1.  Within the ATN, there will
 be many Air Communications Service Provider (ACSP) and Air Navigation
 Service Provider (ANSP) networks organized as autonomous systems
 internal to the ATN, i.e., exactly as depicted for 'E1.*' in the
 diagram.  The ACSP/ANSP network EBGs will participate in a BGP
 instance internal to the ATN, and may themselves run independent BGP
 instances internally that are further sub-divided into lower-tier
 enterprises organized as regional, organizational, functional, etc.
 compartments.  It is important to note that, while ACSPs/ANSPs within
 the ATN will share a common objective of safety-of-flight for civil
 aviation services, there may be competing business/social/political
 interests between them, such that the ATN is not necessarily "one big
 happy family".  Therefore, the model parallels that of the global
 Internet itself.
 Such an operational framework may indeed be the case for many next-
 generation enterprises.  In particular, although the routing and
 addressing arrangements of all enterprises will require a mutual
 level of cooperative active management at a certain level, free
 market forces, business objectives, political alliances, etc. may
 drive internal competition.

Templin Informational [Page 11] RFC 5720 RANGER February 2010

3.3. Virtual Enterprise Traversal (VET)

 Within the enterprise-within-enterprise framework outlined in Section
 3.2, the RANGER architecture is based on overlay networks manifested
 through Virtual Enterprise Traversal (VET) ([VET], [RFC5214]).  The
 VET approach uses automatic IP-in-IP tunneling in which ITEs
 encapsulate EID-based inner IP packets within RLOC-based, outer IP
 headers for transmission across the commons to ETEs.
 For each enterprise they connect to, EBRs that use VET configure a
 Non-Broadcast, Multiple Access (NBMA) interface known as a "VET
 interface" that sees all other EBRs within the enterprise as
 potential single-hop neighbors from the perspective of the inner IP
 protocol.  This means that, for many enterprise scenarios, standard
 neighbor discovery mechanisms (e.g., router advertisements,
 redirects, etc.) can be used between EBR pairs.  This gives rise to a
 data-driven model in which neighbor relationships are formed based on
 traffic demand in the data plane, which in many cases can relax the
 requirement for dynamic routing exchanges across the overlay in the
 control plane.
 When multiple VET interfaces are linked together, end-to-end
 traversal is seen as multiple VET hops from the perspective of the
 inner IP protocol.  In that case, transition between VET interfaces
 entails a "re-encapsulation" approach in which a packet that exits
 VET interface 'i' is decapsulated then re-encapsulated before it is
 forwarded into VET interface 'i+1'.  For example, if an end-to-end
 path between two EID-based peers crosses N distinct VET interfaces, a
 traceroute would show N inner IP forwarding hops corresponding to the
 portions of the path that traverse the VET interfaces.
 VET and its related works specify necessary mechanisms and
 operational practices to manifest the RANGER architecture.  The use
 of VET in conjunction with SEAL (see Section 3.4) is essential in
 certain deployments to avoid issues related to source address
 spoofing and black holing due to path Maximum Transmission Unit (MTU)
 limitations.  (The use of VET in conjunction with IPsec [RFC4301] may
 also be necessary in some enterprise network scenarios.)  The
 following sections discuss operational considerations and use cases
 within the VET approach.

3.3.1. RANGER Organizational Principles

 Figure 2 below depicts a vertical slice (albeit represented
 horizontally) from the enterprise-within-enterprise framework shown
 in Figure 1:

Templin Informational [Page 12] RFC 5720 RANGER February 2010

                                                          +------+
                                                          | IPv6 |
     " " " " " " " "" " " " " " " " " " " " " " " "       |Server|
   "         <----------------- 2001:DB8::/40 (PA) "      |  S1  |
 "    2001:DB8:10::/56 (PI)  ---------------->      "     +--+---+
 "     . . . . . . .       . . . .      . . . .     "        |
 "   .               .    .       .    .       .    "        |
 "   .  +----+   v    +--- +   v  +----+   v   +----+  +-----+-------+
 "   .  | V  +=  e   =+ Y1 +=  e =+ X2 +=  e  =+ R2 +==+   Internet  |
 "   .  +-+--+   t    +----+   t  +----+   t   +----+  +-----+-------+
 "   .    |      1   .    .    2  .    .   3   .    "        |
 "    .   H         .     .       .    .       .    "        |
 "      . . . . . .        . . . .      . . . .     "     +--+---+
  "       <E1.1.1>         <E1.1>        <E1>       "     | IPv4 |
    "      10/8             10/8         10/8      "      |Server|
      " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                   <-- Enterprise E1 -->                  +------+
          Figure 2: Virtual Enterprise Traversal
 Within this vertical slice, each enterprise within the 'E1' recursive
 hierarchy is spanned by VET interfaces, represented as 'vet1' through
 'vet3'.  Each VET interface within this framework is a Non-Broadcast,
 Multiple Access (NBMA) interface that connects all EBRs within the
 same enterprise.  Each enterprise within the 'E1' hierarchy may
 comprise a smaller topological region within a larger RLOC space, or
 they may configure an independent RLOC space from a common (but
 spatially reused) limited-scope prefix, e.g., depicted as multiple
 disjoint instances of '10/8' in the diagram.
 In the RANGER approach, EBRs within lower-tier enterprises coordinate
 their EID prefixes with EBGs that connect to an upper-tier
 enterprise.  EID prefixes could be either provider-independent (PI)
 prefixes owned by the EBR or provider-aggregated (PA) prefixes
 delegated by the EBG.  In either case, EID prefixes must be
 coordinated with the enterprise routing/mapping systems.
 When PA EID prefixes are used, the EBR for each 'E1*' enterprise
 receives an EID prefix delegation from a delegating EBG in a parent
 enterprise.  In this example, when 'R2' is a delegating router for
 the prefix '2001:DB8::/40', it may delegate '2001:DB8::/48' to 'X2',
 which in turn delegates '2001:DB8::/52' to 'Y1', which in turn
 delegates '2001:DB8::/56' to 'V'.  The preferred mechanism for this
 recursive PA prefix sub-delegation is DHCP Prefix Delegation
 [RFC3633], which also arranges for publication of the prefixes in the
 enterprise routing system.

Templin Informational [Page 13] RFC 5720 RANGER February 2010

 When PI EID prefixes are used, individual EBRs (e.g., 'V') register
 their PI prefixes (e.g., '2001:DB1:10::/56') by sending Router
 Advertisement (RA) messages to EBGs within the enterprise to assert
 prefix ownership.  When stronger authentication is necessary, the
 EBRs can digitally sign the messages using the mechanisms specified
 for SEcure Neighbor Discovery (SEND) [RFC3971].  EBGs that receive
 the RAs (e.g., 'Y1') first verify the sender's credentials, then
 register the prefixes in the enterprise mapping system.  Next, they
 forward a proxied version of the RA to EBGs within their parent
 enterprises (e.g., 'X2').  This proxying process continues up the
 recursive hierarchy until a default-free commons is reached.  (In
 this case, the proxying process ends at 'R2').  After the initial
 registration, the EBR that owns the PI prefixes must periodically
 send additional RAs to update prefix expiration timers.

3.3.2. RANGER End-to-End Addressing Example

 In Figure 2, an IPv6 host 'H' that is deeply nested within Enterprise
 'E1' connects to IPv6 server 'S1', located somewhere on the IPv6
 Internet.  'H' is attached to a shared link with IPv6/IPv4 dual-stack
 router 'V', which advertises the IPv6 prefixes '2001:DB8:0:0::/64'
 and '2001:DB8:10:0::/64'.  'H' uses standard IPv6 neighbor discovery
 mechanisms to discover 'V' as a default IPv6 router that can forward
 its packets off the local link, and configures addresses from both of
 the advertised prefixes.  'V' in turn sees node 'Y1' as an EBG that
 is reachable via VET interface 'vet1' and that can forward packets
 toward IPv6 server 'S1'.  Similarly, node 'Y1' is an EBR on the
 enterprise spanned by 'vet2' that sees 'X2' as an EBG, and node 'X2'
 is an EBR on 'vet3' that sees 'R2' as an EBG.  Ultimately, 'R2' is an
 EBR that connects 'E1' to the global Internet.

3.3.3. Dynamic Routing and On-Demand Mapping

 In the example shown in Figure 2, 'V', 'Y1', 'X2', and 'R2' configure
 separate VET interfaces for each enterprise they connect to in order
 to discover routes through a dynamic routing protocol and/or mapping
 database lookups.  After tunnels 'vet1' through 'vet3' are
 established, the EBRs connected to a VET interface can run a dynamic
 routing protocol such as OSPVFv3 [RFC5340] and exchange topology
 information over the VET interface using the NBMA interface model.
 In this way, each EBR can discover other EBRs on the link via routing
 protocol control message exchanges.
 In a second example, Figure 3 depicts an instance of on-demand
 discovery of more specific routes in which an IPv6 end system 'H'
 connects to a peer end system 'J', located in a different
 organizational entity within 'E1':

Templin Informational [Page 14] RFC 5720 RANGER February 2010

                                                          +------+
                                                          | IPv6 |
     " " " " " " " "" " " " " " " " " " " " " " " "       |Server|
   "         <----------------- 2001:DB8::/40 (PA) "      |  S1  |
 "    2001:DB8:10::/56 (PI)  ---------------->      "     +--+---+
 "     . . . . . . .       . . . .      . . . .     "        |
 "   .               .    .       .    .       .    "        |
 "   .  +----+   v   +----+   v   +----+       +----+  +-----+-------+
 "   .  | V  +=  e  =+ Y1 +=  e  =+ X2 +=     =+ R2 +==+   Internet  |
 "   .  +-+--+   t   +----+   t   +----+       +----+  +-----+-------+
 "   .    |      1   .    .   2   .    .       .    "        |
 "    .   H         .     .       .    .   v   .    "        |
 "      . . . . . .        . . . .     .   e   .    "     +--+---+
 "                                     .   t   .    "     | IPv4 |
 "                  . . . . . . ,      .   3   .    "     |Server|
 "                .  +----+   v   +----+       .    "     |  S2  |
 "                .  | Z  +=  e  =+ X7 +=      .    "     +------+
 "                .  +-+--+   t   +----+       .    "
 "                .    |      4   .    .       .    "
 "                .    J         .      . . . .     "
  "                 . . . . . . .                   "
    "           2001:DB8:20::/56 (PI) -------->    "
      " " " " " " " " " " " " " " "" " " " " " " "
                   <-- Enterprise E1 -->
              Figure 3: On-Demand Discovery
 In this example, tunnel interfaces 'vet1' through 'vet4' as well as
 IPv6 PI prefix registrations have been established through VET
 enterprise autoconfiguration procedures.  When IPv6 end system 'H'
 with IPv6 address '2001:DB8:10::1' sends packets to a peer end system
 'J' with IPv6 address '2001:DB8:20::1', the packets will be conveyed
 through 'V', 'Y1', and finally to 'X2' via default routes.  Then,
 unless 'X2' has an IPv6 FIB entry matching 'J', it must discover that
 'J' can be reached using a more direct route via 'X7' as the next-hop
 across the 'E1' commons.
 In particular, when 'X2' receives a packet on the 'vet2' interface
 with inner destination address 'J', it can perform an on-demand
 mapping lookup by consulting the enterprise mapping service, e.g., by
 consulting the DNS reverse zone.  Alternatively, 'X2' can send the
 packet to a default router (e.g., 'R2'), which in turn can forward
 the packet to 'X7' and return an ICMPv6 redirect message.  When 'X2'
 receives the redirect, it can send an RA message to 'X7' to prove
 that it is authorized to produce packets with a prefix that matches
 source address 'J'.  'X2' can then forward subsequent packets
 directly to 'X7' without involving 'R2'.

Templin Informational [Page 15] RFC 5720 RANGER February 2010

 In some enterprise scenarios, dynamic routing and on-demand mapping
 can be combined as complementary functions.  In other scenarios, it
 may be preferable to use either dynamic routing only or on-demand
 mapping only.

3.3.4. Support for Legacy RLOC-Based Services

 Legacy hosts, routers, and networks that were already present in pre-
 RANGER deployments and have already numbered their interfaces with
 RLOC addresses must see continued support for RLOC-based services for
 the long term, even as EID-based services are rolled out in new
 deployments.  For example, a legacy IPv4-only node behind an IPv4
 Network Address Translator (NAT) must still be able to reach legacy
 IPv4-only Internet services (e.g., "http://example.com") long after
 the RANGER architecture and EID-based services are widely deployed.
 Returning to the example diagrams, while virtual enterprise traversal
 across 'E1' provides a fully connected routing and addressing
 capability for EID-based services, legacy nodes will still require
 access to RLOC-based services within connected or disjoint RLOC
 spaces for an extended (and possibly indefinite) period.  For
 example, Figure 4 below depicts the applicable RLOC-based IPv4
 service-access scenarios for the RANGER architecture when VET
 interfaces are used to link recursively nested enterprises together:
                                                          +------+
                                                          | IPv6 |
     " " " " " " " "" " " " " " " " " " " " " " " "       |Server|
   "         <----------------- 2001:DB8::/40 (PA) "      |  S1  |
 "    2001:DB8:10::/56 (PI)  ----------------->     "     +--+---+
 "     . . . . . . .       . . . .      . . . .     "        |
 "   .               .    .       .    .       .    "        |
 "   .  +----+   v   +--- +   v   +----+   v   +----+  +-----+-------+
 "   .  | V  +=  e  =+ Y1 +=  e  =+ X2 +=  e  =+ R2 +==+   Internet  |
 "   .  +-+--+   t   +----+   t   +----+   t   +----+  +-----+-------+
 "   .    |      1   .    .   2   .    .   3   .    "        |
 "    .   K   L     .     .       .    . M     .    "        |
 "      . . . . . .        . . . .      . . . .     "     +--+---+
  "       <E1.1.1>         <E1.1>        <E1>       "     | IPv4 |
    "                                              "      |Server|
      " " " " " " " " " " " " " " "" " " " " " " "        |  S2  |
                   <-- Enterprise E1 -->                  +------+
      Figure 4: Support for Legacy RLOC-Based Services
 In a first instance, a legacy RLOC-based IPv4 client 'K' within
 enterprise 'E1.1.1' can access RLOC-based IPv4 service 'L' within the
 same enterprise as normal and without the need for any encapsulation.

Templin Informational [Page 16] RFC 5720 RANGER February 2010

 Instead, 'K' discovers a "mapping" for 'L' through a simple lookup
 within the 'E1.1.1' enterprise-local name service, and conveys
 packets to 'L' through unencapsulated RLOC-based IPv4 routing and
 addressing within the 'E1.1.1' commons.  In many instances, this may
 indeed be the preferred service-access model, even when EID-based
 IPv6 services are widely deployed due to factors such as inability to
 replace legacy IPv4 applications, IPv6 header overhead avoidance,
 etc.
 In a second instance, RLOC-based IPv4 client 'K' can access RLOC-
 based IPv4 server 'S2' on the legacy global IPv4 Internet in a number
 of ways, based on the way the recursively nested 'E1.*' enterprises
 are provisioned:
 o  if all of the recursively nested 'E1.*' enterprises are configured
    within the same IPv4 RLOC space, normal IPv4 forwarding will
    convey unencapsulated IPv4 packets from 'K' toward 'R2', which
    then acts as an IPv4 Network Address Translator (NAT) and/or an
    ordinary IPv4 Enterprise Border Router.
 o  if the recursively nested 'E1.*' enterprises are configured within
    disjoint RLOC spaces, all EBGs 'Y1', 'X2', and 'R2' can be
    configured to provide an IPv4 NAT capability (i.e., a recursive
    nesting of NATs within NATs).  However, this approach places
    multiple instances of stateful NAT devices on the path, which can
    lead to an overall degree of brittleness and intolerance to
    routing changes.  Instead, 'R2' can act as a "Carrier-Grade NAT
    (CGN)", and 'V' can convey packets from 'K' to the CGN using
    IPv4-in-IPv6-in-IPv4 tunneling.  The CGN can then decapsulate the
    inner, RLOC-based IPv4 packets and translate the IPv4 source
    addresses into global IPv4 source addresses before sending the
    packets on to 'S2'.
 o  'K' could be configured as an EID-based, IPv6-capable node and use
    standard IPv6 routing to reach an IPv6/IPv4 translator located at
    an EBR for the enterprise in which 'S2' resides.  The translator
    would then use IPv6-to-IPv4 translation before sending packets
    onwards toward 'S2'.  These and other alternatives are discussed
    in [WING].
 In a final instance, RLOC-based IPv4 client 'K' can access an RLOC-
 based IPv4 server 'M' in a different enterprise within E1 as long as
 both enterprises are configured over the same IPv4 RLOC space.  If
 the enterprises are configured over disjoint IPv4 RLOC spaces,
 however, 'K' would still be able to access 'M' by using EID-based
 IPv6 services, by using EID-based IPv4 services if an EID-based IPv4
 overlay were deployed, or by using some form of RLOC-based IPv4 NAT
 traversal.  'K' could also access server 'M' if both 'V' and 'X2'

Templin Informational [Page 17] RFC 5720 RANGER February 2010

 implemented an IPv6/IPv4 protocol translation capability.  Finally,
 'K' and/or 'M' could implement a bump-in-the-wire or bump-in-the-api
 IPv6/IPv4 protocol translation capability.

3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL)

 Tunnel endpoints that depend on ICMP feedback from routers within the
 enterprise commons may be susceptible to undetected black holes due
 to ICMP filtering gateways and/or off-path ICMP spoofing attacks from
 a node pretending to be a router.  Furthermore, rogue nodes within
 enterprises that do not correctly implement ingress filtering can
 send spoofed packets of any kind, e.g., for the purpose of mounting
 denial-of-service and/or traffic amplification attacks targeting
 underprivileged links.
 The Subnetwork Encapsulation and Adaptation Layer (SEAL) provisions
 each encapsulated packet with a monotonically incrementing, extended
 Identification field (i.e., the 32-bit SEAL_ID) that tunnel endpoints
 can use as a nonce to detect off-path spoofing.  Moreover, tunnel
 endpoints that use SEAL can continue to operate correctly even if
 some/many ICMPs are lost.  Finally, tunnel endpoints that use SEAL
 can adapt to subnetworks containing links with diverse MTUs
 properties.

3.5. Mobility Management

 Enterprise mobility use cases must be considered along several
 different vectors:
 o  nomadic enterprises and end systems may be satisfied to incur
    address renumbering events as they move between new enterprise
    network attachment points.
 o  mobile enterprises with PI prefixes may be satisfied by dynamic
    updates to the mapping system as long as they do not impart
    unacceptable churn.
 o  mobile enterprises and end systems with PA addresses/prefixes may
    require additional supporting mechanisms that can accommodate
    address/prefix renumbering.
 Nomadic enterprise mobility is already satisfied by currently
 deployed technologies.  For example, transporting a laptop computer
 from a wireless-access hot spot to a home network LAN would allow the
 nomadic device to re-establish connectivity at the expense of address
 renumbering.  Such renumbering may be acceptable, especially for

Templin Informational [Page 18] RFC 5720 RANGER February 2010

 devices that do not require session persistence across mobility
 events and do not configure servers with addresses published in the
 global DNS.
 Mobile enterprises with PI prefixes that use VET and SEAL can move
 between parent enterprise attachment points as long as they withdraw
 the prefixes from the mapping systems of departed enterprises and
 inject them into the mapping systems of new enterprises.  When moving
 between the lower recursive tiers of a common parent enterprise, such
 a localized event mobility may result in no changes to the parent
 enterprise's mapping system.  Hence, the organizational structure of
 a carefully arranged enterprise-within-enterprise framework may be
 able to dampen mobility-related churn.  For enterprises that require
 in-the-network confidentiality, IKEv2 Mobility and Multihoming
 (MOBIKE) [RFC4555] may also be useful within this context.
 Mobile enterprises and end systems that move quickly between
 disparate parent enterprise attachment points should not use PI
 prefixes if withdrawing and announcing the prefixes would impart
 unacceptable mapping/routing churn and packet loss.  They should
 instead use PA addresses/prefixes that can be coordinated via a
 rendezvous service.  Mobility management mechanisms such as Mobile
 IPv6 [RFC3775] and the Host Identity Protocol (HIP) [RFC4423] can be
 used to maintain a stable identifier for fast moving devices even as
 they move quickly between visited enterprise attachment points.
 As a use case in point, consider an aircraft with a mobile router
 moving between ground station points of attachment.  If the ground
 stations are located within the same enterprise, or within lower-tier
 sites of the same parent enterprise, it should suffice for the
 aircraft to announce its PI prefixes at its new point of attachment
 and withdraw them from the old.  This would avoid excessive mapping
 system churn, since the prefixes need not be announced/withdrawn
 within the parent enterprise, i.e., the churn is isolated to lower
 layers of the recursive hierarchy.  Note also that such movement
 would not entail an aircraft-wide readdressing event.
 As a second example, consider a wireless handset moving between
 service coverage areas maintained by independent providers with
 peering arrangements.  Since the coverage range of terrestrial
 cellular wireless technologies is limited, mobility events may occur
 on a much more aggressive timescale than some other examples.  In
 this case, the handset may expect to incur a readdressing event for
 its access interface at least, and may be obliged to arrange for a
 rendezvous service linkage.

Templin Informational [Page 19] RFC 5720 RANGER February 2010

 It should specifically be noted that the contingency of mobility
 management solutions is not necessarily mutually exclusive and must
 be considered in relation to specific use cases.  The RANGER
 architecture is therefore naturally inclusive in this regard.  In
 particular, RANGER could benefit from mechanisms that could support
 rapid dynamic updates of PI prefix mappings without causing excessive
 churn.

3.6. Multihoming

 As with mobility management, multihoming use cases must be considered
 along multiple vectors.  Within an enterprise, EBRs can discover
 multiple EBGs and use them in a fault-tolerant and load-balancing
 fashion as long as they register their PI prefixes with each such
 EBG, as described in Section 3.3.1.  These registrations are created
 through the transmission of Router Advertisement messages that
 percolate up through the recursive enterprise-within-enterprise
 hierarchy.
 As a first case in point, consider the enterprise network of a major
 corporation that obtains services from a number of ISPs.  The
 corporation should be able to register its PI prefixes with all of
 its ISPs, and use any of the ISPs for its Internet access services.
 As a second use case, consider an aircraft with a diverse set of
 wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.).  The
 aircraft should be able to select and utilize the most appropriate
 link(s) based on the phase of flight and to change seamlessly between
 links as necessary.  Other examples include a nomadic laptop with
 both 802.11 and Ethernet links, a wireless handset with both CDMA
 wireless and 802.11, etc.
 As with mobility management, the contingency of solutions is not
 necessarily mutually exclusive and can combine to suit use cases
 within the scope of the RANGER architecture.

3.7. Implications for the Internet

 Selection of mapping alternatives may have significant implications
 for applications, server selection, route determination, security,
 etc.  In particular, applications that expect all packets (including
 initial ones) to experience similar delays may be adversely affected
 by a scheme that imposes non-negligible delays when initial packets
 are queued while a look-aside mapping table is consulted.  Still
 other applications may experience significant startup delays when its
 initial packets are dropped during a mapping lookup event.  These

Templin Informational [Page 20] RFC 5720 RANGER February 2010

 factors would seem to favor a scheme that is able to forward initial
 packets along a path with sub-optimal delay while a mapping lookup is
 performed in parallel, e.g., such as when a "default mapper" is used.
 Generally speaking, proactive mapping-maintenance mechanisms may have
 scaling issues with the amount of updates they generate, while
 reactive mechanisms may involve effects to the delay of initial
 packets before the cached state is updated.  Also to be considered
 are attacks against the mapping mechanism, which may result in denial
 of service of the mapping cache.
 Encapsulation of packets in automatically created tunnels involves a
 number of issues as well.  There are obvious interactions between
 encapsulation overhead and the effective tunnel MTU, which can be
 addressed by SEAL and (when necessary) careful operational link
 arrangements.  Moreover, it is important to minimize the impact to
 the global routing table without at the same time impacting the
 ability of legacy Internet networks to connect to those employing
 RANGER.  As long as other nodes in the Internet need to connect to
 networks implementing RANGER, EID routes need to appear both in the
 mapping system and the global BGP routing tables.  This can be
 accommodated by keeping the number of prefixes aggregated by RANGER
 to the bare minimum through efficient aggregation (e.g., one or a few
 [PREF]::/4 IPv6 prefixes instead of millions of [PREF]::/32
 prefixes).

4. Related Initiatives

 The origins of the RANGER architectural principles can be traced to
 the "Catenet model for internetworking" ([CATENET], [IEN48],
 [RFC2775]) beginning as early as the mid-1970's.  Subsequently,
 deliberations of the ROAD group [RFC1380] and related efforts such as
 NIMROD [RFC1753] provided a sustained evolution of the concepts.
 [RFC1955], "New Scheme for Internet Routing and Addressing (ENCAPS)
 for IPNG", captures the high-level architectural aspects of the ROAD
 group deliberations.
 These foundational works significantly influenced more recent
 developments, including the X-Bone initiative [XBONE], which explored
 virtual topologies manifested through tunneling.  Various tunneling
 approaches including IP-in-IP ([RFC2003], [RFC4213]), 6over4
 [RFC2529], and ISATAP [RFC5214] have evolved from the mid-1990's
 until the present day and are used in common, operational practice.
 Tunnel-mode IPsec [RFC4301] is also commonly used for separation of
 security domains within enterprises.

Templin Informational [Page 21] RFC 5720 RANGER February 2010

 Currently, initiatives with similar properties to RANGER are under
 development within the IRTF Routing Research Group (RRG) and within
 IETF working groups such as LISP, SOFTWIRE, V6OPS, and others.
 Numerous proposals have been offered within the RRG, including the
 Locator-Identifier Split Protocol (LISP) [LISP], Six-One [VOGT], ILNP
 [ILNP], Internet vastly improved plumbing (Ivip) [WHITTLE], A
 Practical Transit-Mapping Service (APT) [JEN], and Virtual
 Aggregation [VA].  Still other similar initiatives almost certainly
 exist.
 While RANGER shares many properties with these earlier works, it
 uniquely provides a top-to-bottom articulation of how the various
 pieces fit together within a recursively nested "enterprise-within-
 enterprise" (or "network-of-networks") framework.  In this way, it
 bears striking resemblance to the network-of-networks model
 envisioned by CATENET.  RANGER further provides a detailed
 consideration of challenging issues such as autoconfiguration,
 provider-independent addressing, border router discovery, tunnel MTU,
 multihoming, etc. that many other approaches have either overlooked
 or left for future work.  A detailed analysis of RANGER applicability
 in various use case scenarios is provided in "RANGER Scenarios
 (RANGERS)" [RUSSERT].

5. Security Considerations

 Communications between endpoints within different sites inside an
 enterprise are carried across a commons that joins organizational
 entities with a mutual spirit of cooperation, but between which there
 may be competing business/sociological/political interests.  As a
 result, mechanisms that rely on feedback from routers on the path may
 become brittle or susceptible to spoofing attacks.  This is due to
 the fact that IP packets can be lost due to congestion or packet-
 filtering gateways and that the source addresses of IP packets can be
 forged.  Moreover, IP packets in general can be generated by
 anonymous attackers, e.g., from a rogue node within a third-party
 enterprise that has malicious intent toward a victim.
 Path MTU Discovery is an example of a mechanism that relies on ICMP
 feedback from routers on the path and, as such, is susceptible to
 these issues.  For IPv4, a common workaround is to disable Path MTU
 Discovery and let fragmentation occur in the network if necessary.
 For IPv6, lack of fragmentation support in the network precludes this
 option such that the mitigation typically recommended is to discard
 ICMP messages that contain insufficient information and/or to operate
 with the minimum IPv6 path MTU.  This example extends also to other
 mechanisms that either rely on or are enhanced by feedback from
 network devices; however, attack vectors based on non-ICMP messages
 are also subject for concern.

Templin Informational [Page 22] RFC 5720 RANGER February 2010

 The RANGER architecture supports effective mitigations for attacks
 such as distributed denial-of-service, traffic amplification, etc.
 In particular, when VET and SEAL are used, EBGs can use the 32-bit
 identification encoded in the SEAL header as well as ingress
 filtering to determine if a message has come from a topologically
 correct enterprise located across the commons.  This allows
 enterprises to employ effective mitigations at their borders without
 the requirement for mutual cooperation from other enterprises.  When
 source address spoofing by on-path attackers located within the
 commons is also subject for concern, additional securing mechanisms
 such as tunnel-mode IPsec between enterprise EBGs can also be used.
 EBRs can obtain PI prefixes through arrangements with a prefix
 delegation authority.  Thereafter, the EBR can announce and/or
 withdraw the prefixes within an enterprise by sending IPv6 Router
 Advertisements (RAs).  In environments where additional
 authenticating mechanisms are necessary, the EBR can sign its RAs
 using SEcure Neighbor Discovery (SEND) [RFC3971].
 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 [HOAGLAND].

6. Acknowledgements

 This work was inspired through the encouragement of the Boeing DC&NT
 network technology team and through the communications of the IESG.
 Many individuals have contributed to the architectural principles
 that form the basis for RANGER over the course of many years.  The
 following individuals have given specific feedback on the RANGER
 document itself: Jari Arkko, Brian Carpenter, Eric Fleischman, Joel
 Halpern, Thomas Henderson, Steven Russert, Dallas Thomas, Robin
 Whittle.

7. References

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

Templin Informational [Page 23] RFC 5720 RANGER February 2010

7.2. Informative References

 [CATENET]  Pouzin, L., "A Proposal for Interconnecting Packet
            Switching Networks", Proceedings of EUROCOMP, Bronel
            University, p. 1023-1036, May 1974.
 [COEXIST]  Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-
            Existence Scenarios", Work in Progress, July 2009.
 [BAUER]    Bauer, C. and S. Ayaz, "ATN Topology Considerations for
            Aeronautical NEMO RO", Work in Progress, September 2009.
 [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
            "Locator/ID Separation Protocol (LISP)", Work in Progress,
            September 2009.
 [HOAGLAND] Hoagland, J., Krishnan, S., and D. Thaler, "Security
            Concerns With IP Tunneling", Work in Progress, October
            2008.
 [JEN]      Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
            L. Zhang, "APT: A Practical Transit Mapping Service", Work
            in Progress, November 2007.
 [RUSSERT]  Russert, S., Fleischman, E., and F. Templin, "RANGER
            Scenarios", Work in Progress, September 2009.
 [SEAL]     Templin, F., Ed., "The Subnetwork Encapsulation and
            Adaptation Layer (SEAL)", RFC 5320, February 2010.
 [VET]      Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
            RFC 5558, February 2010.
 [WING]     Wing, D., Ward, D., and A. Durand, "A Comparison of
            Proposals to Replace NAT-PT", Work in Progress, September
            2008.
 [IEN48]    Cerf, V., "The Catenet Model for Internetworking", July
            1978.
 [ILNP]     Atkinson, R., "ILNP Concept of Operations", Work in
            Progress, December 2008.
 [RFC1380]  Gross, P. and P. Almquist, "IESG Deliberations on Routing
            and Addressing", RFC 1380, November 1992.

Templin Informational [Page 24] RFC 5720 RANGER February 2010

 [RFC1753]  Chiappa, N., "IPng Technical Requirements Of the Nimrod
            Routing and Addressing Architecture", RFC 1753, December
            1994.
 [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de 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.
 [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
            October 1996.
 [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
            Domains without Explicit Tunnels", RFC 2529, March 1999.
 [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775, February
            2000.
 [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.
 [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
            "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
 [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
            for IPv6 Hosts and Routers", RFC 4213, October 2005.
 [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
            Internet Protocol", RFC 4301, December 2005.
 [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
            (HIP) Architecture", RFC 4423, May 2006.
 [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
            (MOBIKE)", RFC 4555, June 2006.
 [RFC4852]  Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
            Green, "IPv6 Enterprise Network Analysis - IP Layer 3
            Focus", RFC 4852, April 2007.

Templin Informational [Page 25] RFC 5720 RANGER February 2010

 [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
            Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
            March 2008.
 [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
            for IPv6", RFC 5340, July 2008.
 [VA]       Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
            L. Zhang, "FIB Suppression with Virtual Aggregation", Work
            in Progress, October 2009.
 [VOGT]     Vogt, C., "Six/One: A Solution for Routing and Addressing
            in IPv6", Work in Progress, October 2009.
 [WHITTLE]  Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
            Architecture", Work in Progress, August 2008.
 [XBONE]    Touch, J., "The X-Bone", March 1997,
            http://www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf

Author's Address

 Fred L. Templin
 Boeing Phantom Works
 P.O. Box 3707 MC 7L-49
 Seattle, WA  98124
 USA
 EMail: fltemplin@acm.org

Templin Informational [Page 26]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5720.txt · Last modified: 2010/02/22 23:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki