One document matched: draft-russert-rangers-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-russert-rangers-01.txt" ipr="trust200811"
updates="3574, 3750, 3904, 4029, 4057, 4215, 4852">
<front>
<title abbrev="RANGERS">RANGER Scenarios</title>
<author fullname="Steven W. Russert" initials="S." role="editor"
surname="Russert">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>srussert3561@charterinternet.com</email>
</address>
</author>
<author fullname="Eric W. Fleischman" initials="E." role="editor"
surname="Fleischman">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>eric.fleischman@boeing.com</email>
</address>
</author>
<author fullname="Fred L. Templin" initials="F." role="editor"
surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="8" month="September" year="2009" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Internet is continually required 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 <xref target="RFC2460"></xref>
deployment. Routing and Addressing in Next-Generation EnteRprises
(RANGER) <xref target="I-D.templin-ranger"></xref> describes a method
for the map and encapsulate approach that also facilitates the other two
approaches.</t>
<t><xref target="I-D.templin-ranger"></xref> 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
<xref target="RFC1380"></xref>, and also to still earlier works
including NIMROD <xref target="RFC1753"></xref> and the Catenet model
for internetworking <xref target="CATENET"></xref><xref
target="IEN48"></xref><xref target="RFC2775"></xref>. <xref
target="RFC1955"></xref> captures the high-level architectural aspects
of the ROAD group deliberations in a "New Scheme for Internet Routing
and Addressing (ENCAPS) for IPNG".</t>
<t>The Internet has grown tremendously since these architectural
principles were first developed, and that evolution increases the need
for these capabilities. The Internet has become a critical resource for
business, for government, and for individual users 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 enterprise
may use completely independent internal Routing Locator (RLOC) address
spaces, supporting 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].</t>
<t>The RANGER architecture is built using Virtual Enterprise Traversal
(VET) <xref target="I-D.templin-autoconf-dhcp"></xref>, the Subnetwork
Encapsulation and Adaptation Layer (SEAL) <xref
target="I-D.templin-seal"></xref>, Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)<xref target="I-D.templin-isatapv4"> </xref>
<xref target="RFC5214"></xref>, and other mechanisms including IPsec
<xref target="RFC4301"></xref>. 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 <xref target="RFC4057"></xref> and analysis <xref
target="RFC4852"></xref>, 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.</t>
</section>
<section anchor="terminology" title="Terminology">
<t><list style="hanging">
<t hangText="Internet Topology Hierarchy"><vspace />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 (Internet).</t>
<t hangText="Routing Locator (RLOC)"><vspace />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.</t>
<t hangText="">The IPv4 public address space currently in use today
can be considered as the RLOC space for the global Internet
“enterprise”.</t>
<t hangText="Endpoint Interface iDentifier (EID)"><vspace />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.</t>
<t hangText="commons"><vspace />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 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.</t>
<t hangText="enterprise"><vspace />the same as defined in <xref
target="RFC4852"></xref>, 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).</t>
<t>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.</t>
<t hangText="site"><vspace />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.</t>
<t>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.</t>
<t hangText="Enterprise Border Router (EBR)"><vspace />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 <xref target="I-D.templin-autoconf-dhcp"></xref>, and is
synonymous with the term "xTR" used in other contexts (e.g., <xref
target="I-D.farinacci-lisp"></xref>).</t>
<t hangText="Enterprise Border Gateway (EBG)"><vspace />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 <xref
target="I-D.templin-autoconf-dhcp"></xref>, and is synonymous with
the term "default mapper" used in other contexts (e.g., <xref
target="I-D.jen-apt"></xref>).</t>
<t hangText="overlay network"><vspace />a virtual network manifested
by routing and addressing over virtual links formed through
automatic tunneling. An overlay network may span many underlying
enterprises.</t>
<t hangText="6over4"><vspace />Transmission of IPv6 over IPv4
Domains without Explicit Tunnels <xref target="RFC2529"></xref>;
functional specifications and operational practices for automatic
tunneling of unicast/multicast IPv6 packets over multicast-capable
IPv4 enterprises.</t>
<t hangText="ISATAP"><vspace />Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP) <xref target="RFC5214"></xref><xref
target="I-D.templin-isatapv4"></xref>; functional specifications and
operational practices for automatic tunneling over unicast-only
enterprises.</t>
<t hangText="VET"><vspace />Virtual Enterprise Traversal (VET) <xref
target="I-D.templin-autoconf-dhcp"></xref>; 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.</t>
<t hangText="SEAL"><vspace />Subnetwork Encapsulation and Adaptation
Layer (SEAL) <xref target="I-D.templin-seal"></xref>; 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.</t>
<t hangText="">Within the RANGER architecture context, the SEAL
“subnetwork” and RANGER “enterprise” should
be considered as identical abstractions.</t>
<t hangText="Provider-Independent (PI) prefix"><vspace />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.</t>
<t hangText="Provider-Aggregated (PA) prefix"><vspace />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.</t>
<t hangText="Customer Premises Equipment (CPE) Router"><vspace />a
residential or small office router that provides IPv4 and/or IPv6
support. The user or the service provider may manage the router.</t>
<t hangText="Carrier Grade NAT (CGN)"><vspace />a special (usually
high capacity) IPv4 to IPv4 NAT deployed within the service provider
network that serves multiple subnets.</t>
</list></t>
<t></t>
</section>
<section anchor="app" title="Approach">
<t>The RANGER architecture is described in <xref
target="I-D.templin-ranger"></xref>. The following is a terse summary of
some key elements of the architecture.</t>
<t>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 addressing.</t>
<t>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.</t>
<figure>
<artwork>
.--------------. .--------------. .-------------.
/ \_ _/ \_ _/ \
\ Enterprise A / \ Commons / \ Enterprise B /
\_ _ _ _ _ _ _ / \_ _ _ _ _ _ _ / \_ _ _ _ _ _ _/
Domains
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</artwork>
</figure>
<t>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).</t>
<t>The RANGER architecture applies the best current practice insights
from previous encapsulation systems as they are currently articulated
within the Virtual Enterprise Traversal <xref
target="I-D.templin-autoconf-dhcp"></xref>, and Subnetwork Encapsulation
and Adaptation Layer <xref target="I-D.templin-seal"></xref> 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.</t>
<t>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 complex structures
solely with the addition of EBRs with no other modification to any
networked entity.</t>
<t>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.</t>
<figure>
<artwork>
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)</artwork>
</figure>
<t>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.</t>
<t>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 horizontally or
vertically within the IP Topology Hierarchy. A VET interface may be
configured over several underlying interfaces that all connect to the
same enterprise. This creates a link-layer multiplexing capability that
can provide several advantages (see <xref
target="I-D.templin-intarea-vet"></xref> Appendix B). One important
advantage is continuous operation across failovers between multiple
links attached to the same enterprise, without any need for
readdressing.</t>
<t>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 enterprise.</t>
<t>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.</t>
<figure>
<artwork>
Mapping System RLOC EID
. (BGP, DNS, etc.) . .
.---.------. .----------. . .------.---.
/ . \ / \ . / . \
/ (O) iEBR------/--------------\------eEBR * \
\ / \ Commons / \ /
\_ _ _ _ _ _ / \_ _ _ _ _ _ / \_ _ _ _ _ _/
Figure 3: The RANGER Model</artwork>
</figure>
<t>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 <xref
target="RFC2131"></xref> <xref target="RFC3315"></xref> and Stateless
Address Autoconfiguration (SLAAC) <xref target="RFC4862"></xref> are
used for this purpose.</t>
<t>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 <xref
target="RFC4795"></xref>.</t>
<t>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 (DNS; RFC1035).
Mapping system databases can be populated by many different mechanisms
including administrative configuration and automated prefix
registrations.</t>
<t>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 ranges.</t>
</section>
<section anchor="scenarios" title="Scenarios">
<section anchor="global" title="Global Concerns">
<t></t>
<section title="Scaling the Global Interdomain Routing Core">
<t>Growth in the Internet has created challenges in routing and
addressing that have been recognized for more than 15 years. IPv4
<xref target="RFC0791"></xref> 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) <xref target="RFC3194"></xref>.
As a result, exhaustion of the IPv4 address pool is predicted within
the next two years <xref target="V4pool"></xref>, <xref
target="Huston-end"></xref>. 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.</t>
<t>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 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.</t>
<figure>
<artwork>
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</artwork>
</figure>
<t>RLOC address spaces are entirely independent of one another, as
they are used only within an Enterprise (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).</t>
<t>The IRTF routing research group is investigating a Preliminary
Recommendation for a Routing Architecture <xref
target="I-D.irtf-rrg-recommendation"></xref> 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 Transit Mapping Service (APT) <xref
target="I-D.jen-apt"></xref>, FIB Suppression with Virtual
Aggregation <xref target="I-D.francis-intra-va"></xref>, LISP <xref
target="I-D.farinacci-lisp"></xref> and others.</t>
</section>
<section title="Supporting Large Corporate Enterprise Networks">
<t>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 <xref target="RFC4192"></xref>, <xref
target="I-D.carpenter-renum-needs-work"></xref>. RANGER provides a
way to coordinate addressing plans and inter-enterprise routing,
with full support for scalability, provider-independence, mobility,
multi-homing and security.</t>
<figure>
<artwork>
_.--------------------._
_.---'' -.
,--'' ,---. `---.
,-' 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</artwork>
</figure>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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
prefix.</t>
<t>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.</t>
<t>This example uses one thread out of many that are possible using
RANGER; see <xref target="I-D.templin-ranger"></xref> and <xref
target="I-D.templin-autoconf-dhcp"></xref> 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).</t>
</section>
</section>
<section title="Autonomous System Concerns">
<t>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 ASs 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 support an internal instance of the Border
Gateway Protocol (BGP) linking many corporate-internal ASs and
independent from the BGP instance which maintains the RIB within the
global Internet Default Free Zone (DFZ). Such configurations are often
motivated by scaling or administrative requirements.</t>
<t>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).</t>
</section>
<section title="Small Enterprise Concerns">
<t>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.</t>
<t>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 <xref
target="RFC1918"></xref> private address space.</t>
<figure>
<artwork>
ISP
-------|----- Wksta Wksta
| Firewall |_____________|____________|
| NAT |
-------------
Figure 6: Simple SOHO network</artwork>
</figure>
<t>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.</t>
<t>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.</t>
<figure>
<artwork>
ISP
|
+------|-----+
| <|--
| VET2 < |
| <|---
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 7: RANGER serving the small company</artwork>
</figure>
<t>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.</t>
<t>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.</t>
<figure>
<artwork>
ISP
|
+------|-----+
| <|------------London
| VET2 < |
| <|--------------------New York
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 8: RANGER for multiple locations</artwork>
</figure>
</section>
<section anchor="trans" title="IPv4/IPv6 Transition and Coexistence">
<t>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’.</t>
<t>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 <xref
target="I-D.templin-autoconf-dhcp"></xref> and SEAL <xref
target="I-D.templin-seal"></xref>, makes it possible to carry packets
originated in one protocol across network infrastructure supporting
another protocol or routing system. Figure 1 on page 8 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.</t>
<t>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’:</t>
<figure>
<artwork>
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | 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</artwork>
</figure>
<t>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.</t>
<t>RANGER further provides a compatible framework for incorporating
supporting mechanisms including protocol translation,
application-layer aspects of IPv4/IPv6 transition discussed in <xref
target="RFC4038"></xref> and DNS issues for IPv6 from <xref
target="RFC4472"></xref>. For instances where IPv4 applications remain
in use, RANGER supports translation via functional equivalents of
“Network Address Translation, Protocol Translation
(NAT-PT)” <xref target="RFC2766"></xref>, and “Bump In the
Stack (BIS)” <xref target="RFC2767"></xref>. 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.</t>
<figure>
<artwork>
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_| / \ |NAT-PT-equiv_|
|_TCP or UDP__| | Internet | |_TCP or UDP__|
|____IPv6_____| | (RANGER) | |____IPv6_____|
|__VET/SEAL___| \_____________/ |__VET/SEAL___|
\_______________/ \___________/
Figure 10: Translation in Routers</artwork>
</figure>
<t>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.</t>
<figure>
<artwork>
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</artwork>
</figure>
<t>Figure 11 shows the simplified approach using a Bump-In the Stack
(BIS) translation process within dual-stack end systems (<xref
target="RFC2767"></xref>). 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 an IPv4 packet for consumption by
the IPv4-only application.</t>
<t>Other issues besides IP protocol translation may arise during
IPv4-IPv6 transition; <xref target="RFC4038"></xref> 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.</t>
</section>
<section title="Mobility and MANET">
<t></t>
<section title="Global Mobility Management">
<t>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 can move 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.</t>
<t>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 , <xref
target="RFC3775"></xref>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).</t>
<figure>
<artwork>
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</artwork>
</figure>
<t>When the plane moves between ground stations that are located
within the ACSP1 enterprise, no routing or mapping changes need be
made outside ACSP1. Moreover, if link-layer multiplexing (as
mentioned in section 3 above) is used then the VET interface network
layer is unaware of the movement. 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.</t>
</section>
<section title="First-Responder Mobile Ad-Hoc Networks (MANETs)">
<t>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 <xref
target="I-D.templin-autoconf-dhcp"></xref> to coordinate
address/prefix autoconfiguration and discover border routers needed
for teams and agencies to interconnect.</t>
<t>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. In this example,
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
vet2.</t>
<t>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
there.</t>
<figure>
<artwork>
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | 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</artwork>
</figure>
</section>
<section title="Tactical Military MANETs">
<t>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 <xref
target="Bell-LaPadula"></xref> 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.</t>
<t>Figure 3 on page 10 shows that RANGER supports creation of a VET
interface 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 (IPsec - <xref target="RFC4301"></xref>).
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).</t>
<t>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.</t>
<t>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 characteristic of mobility and the radio
signal propagation attributes of local deployment environments
(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 reduce radio
signal propagation, further increasing the probability of signal
intermittence.</t>
<t>RANGER recursion enables MANET networks to be defined into
structures that naturally encourage route aggregation and scaling.
For example, a MANET autonomous system may benefit from RANGER
recursion by being physically comprised of enterprises that are
autonomous systems themselves. This relationship can be recursively
extended vertically as deep as required in order to create route
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 routing protocols similar to 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 ASs 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.</t>
<t>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 their 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. 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.</t>
<t>Another key distinctive of Tactical Military networks is that,
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 are
manifested in several dimensions. It is important to recognize,
however, that just as RANGER recursion was used vertically to create
IP Topology enterprise-within-enterprise structures in order to
improve routing aggregation and scaling of the peer enterprises, so
RANGER recursion can be used horizontally (within the same IP
Topology Hierarchy level) 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 limitations.</t>
</section>
</section>
<section title="Provider Concerns">
<t>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).</t>
<section title="ISP Networks">
<t>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.</t>
<t>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.</t>
<t>To address this brittleness, the ISP can deploy “Carrier
Grade NATs” (CGNs) <xref
target="I-D.jiang-incremental-cgn"></xref> 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.</t>
<t>Scenarios and Analysis for Introducing IPv6 into ISP Networks
<xref target="RFC4029"></xref> 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 scenarios such as ISP networks.</t>
</section>
<section title="Cellular Operator Networks">
<t><xref target="RFC4215"></xref> 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). RANGER could
be used in 3GPP transition; 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 tunneling.</t>
<t>Other <xref target="RFC4215"></xref> 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.</t>
<t><xref target="RFC4215"></xref> 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.</t>
</section>
<section title="Aeronautical Telecommunications Network (ATN)">
<t>The Aeronautical Telecommunications Network (ATN) is currently
based on the OSI and IPv4 protocols and is deployed only in limited
areas. The future ATN under consideration within the civil aviation
industry will be IPv6-based. 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 on page 13. 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, enterprises may have competing business, social, or
political interests which require that components be distinct ASs.
The RANGER principles therefore support collaborative objectives
while allowing very diverse local policy distinctions. In this
manner entities that do not trust each other can create
collaborative infrastructures to achieve common goals.</t>
<t>Operational associations like this will characterize many
next-generation deployments, including the US Department of
Defense's Global Information 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. This will require different enterprises within that
association to be separated into distinct ASs that are linked within
their own functional Internet relationship.</t>
<t>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 ACSP, ANSP, or AOC edge networks that travel between
VET interfaces on EBRs see their passage across the Internet as only
one hop.</t>
<figure>
<artwork>
_...--------------------------------------..._
/ \
( IPv4 Internet )
-...________________________________________...-
| / | \ |
| / | \ |
_...--------------------------------------..._
/ \
( Aero Overlay )
-...________________________________________...-
. . . . . .
. . . . . .
_...-------.._ _...-------.._ _...-------.._
/ \ / \ / \
( ACSP1 ) ( ANSP ) ( ACSP2 )
-...________...- -...________...- -...________...-
Figure 14: Aeronautical Overlay</artwork>
</figure>
<t>Each Aeronautical Communications Service Provider (ACSP), and
Aeronautical Navigation Service Provider (ANSP) constitute an
enterprise recursively nested below the aero overlay. Relationships
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 across which ACSP and
ANSP EBRs can route traffic 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.</t>
<t>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 <xref
target="IS8348"></xref> instead of IP addresses for RLOC mappings.
OSI ConnectionLess Network Protocol (CLNP) <xref
target="IS8473"></xref> 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 <xref target="RFC1888"></xref> while applications are
adapted by using RFC 2126 <xref target="RFC2126"></xref> 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 on page 20.</t>
<t>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) 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.</t>
<figure>
<artwork>
_...--------------------------------------..._
/ (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</artwork>
</figure>
</section>
<section title="Unmanaged Networks">
<t>Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
<xref target="RFC3904"></xref> considers four cases for support of
IPv6-enabled routers and end systems connected to an ISP network via
a gateway:</t>
<t><list style="letters">
<t hangText="A)">a gateway which does not provide IPv6 at
all;</t>
<t hangText="B)">a dual-stack gateway connected to a dual-stack
ISP;</t>
<t hangText="C)">a dual-stack gateway connected to an IPv4-only
ISP; and</t>
<t hangText="D)">a gateway connected to an IPv6-only ISP.</t>
</list>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 <xref target="RFC4380"></xref> can provide a
sufficient solution in many cases.</t>
<t>Case d is a scenario that has not yet seen widespread adoption.
In this scenario, the customer network could be configured as IPv6
only 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.</t>
<t>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 the same as 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.</t>
</section>
</section>
</section>
<section title="Summary">
<t>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.</t>
<t>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; it is no longer true that any node in the Internet can
directly address any other node.</t>
<t>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
here, 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.</t>
<t>By restoring the original CATENET vision to the Internet, the next
generation Internet can be arbitrarily scalable while simultaneously
supporting provider independence, mobility, multihoming and
security.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.</t>
</section>
<section anchor="secure" title="Security Considerations">
<t>Security considerations are addressed in <xref
target="I-D.templin-ranger"></xref>, <xref
target="I-D.templin-autoconf-dhcp"></xref>, and <xref
target="I-D.templin-seal"></xref>. 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 <xref
target="I-D.ietf-v6ops-tunnel-security-concerns"></xref>. Security
considerations for specific use cases are discussed there.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2460"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.carpenter-renum-needs-work'?>
<?rfc include='reference.I-D.farinacci-lisp'?>
<?rfc include='reference.I-D.francis-intra-va'?>
<?rfc include="reference.I-D.ietf-v6ops-tunnel-security-concerns"?>
<?rfc include='reference.I-D.irtf-rrg-recommendation'?>
<?rfc include='reference.I-D.jiang-incremental-cgn'?>
<?rfc include='reference.I-D.jen-apt'?>
<?rfc include="reference.I-D.templin-autoconf-dhcp"?>
<?rfc include="reference.I-D.templin-intarea-vet"?>
<?rfc include="reference.I-D.templin-isatapv4"?>
<?rfc include="reference.I-D.templin-ranger"?>
<?rfc include="reference.I-D.templin-seal"?>
<?rfc include='reference.RFC.1035'?>
<?rfc include="reference.RFC.1380"?>
<?rfc include="reference.RFC.1753"?>
<?rfc include='reference.RFC.1888'?>
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.1955"?>
<?rfc include='reference.RFC.2126'?>
<?rfc include='reference.RFC.2131'?>
<?rfc include="reference.RFC.2529"?>
<?rfc include='reference.RFC.2766'?>
<?rfc include='reference.RFC.2767'?>
<?rfc include="reference.RFC.2775"?>
<?rfc include='reference.RFC.3194'?>
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.RFC.3344'?>
<?rfc include="reference.RFC.3775"?>
<?rfc include='reference.RFC.3904'?>
<?rfc include='reference.RFC.4029'?>
<?rfc include='reference.RFC.4038'?>
<?rfc include='reference.RFC.4057'?>
<?rfc include='reference.RFC.4192'?>
<?rfc include='reference.RFC.4215'?>
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.4309"?>
<?rfc include='reference.RFC.4380'?>
<?rfc include='reference.RFC.4472'?>
<?rfc include='reference.RFC.4795'?>
<?rfc include="reference.RFC.4852"?>
<?rfc include='reference.RFC.4862'?>
<?rfc include="reference.RFC.5214"?>
<reference anchor="Bell-LaPadula">
<front>
<title>Secure Computer Systems: Mathematical Foundations and
Model</title>
<author fullname="D. Bell" initials="D." surname="Bell">
<organization></organization>
</author>
<author fullname="L. LaPadula" initials="L." surname="LaPadula">
<organization>The Mitre Corporation</organization>
</author>
<date month="October" year="1974" />
</front>
</reference>
<reference anchor="CATENET">
<front>
<title>A Proposal for Interconnecting Packet Switching
Networks</title>
<author fullname="L. Pouzin" initials="L." surname="Pouzin">
<organization></organization>
</author>
<date month="May" year="1974" />
</front>
</reference>
<reference anchor="Huston-end">
<front>
<title>The End of the (IPv4) World is Nigher</title>
<author fullname="Geoff Huston" initials="G" surname="Huston">
<organization></organization>
</author>
<date month="July" year="2007" />
</front>
</reference>
<reference anchor="IEN48">
<front>
<title>The Catenet Model for Internetworking</title>
<author fullname="Vinton Cerf" initials="V" surname="Cerf">
<organization></organization>
</author>
<date month="July" year="1978" />
</front>
</reference>
<reference anchor="IS8348">
<front>
<title>Open Systems Interconnection -- Network service
definition</title>
<author>
<organization>International Organization for Standardization,
International Electrotechnical Commission</organization>
</author>
<date year="2002" />
</front>
</reference>
<reference anchor="IS8473">
<front>
<title>Protocol for providing the connectionless-mode network
service: Protocol specification</title>
<author>
<organization abbrev="ISO/IEC">International Organization for
Standardization, International Electrotechnical
Commission</organization>
</author>
<date year="1998" />
</front>
</reference>
<reference anchor="V4pool">
<front>
<title>The IPv4 Address Pool Projection</title>
<author fullname="Tony Hain" initials="T" surname="Hain">
<organization></organization>
</author>
<date day="30" month="April" year="2009" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:21:08 |