Network Working Group S. Russert, Ed.
Internet-Draft E. Fleischman, Ed.
Updates: 3574, 3750, 3904, 4029, F. Templin, Ed.
4057, 4215, 4852 Boeing Research & Technology
(if approved) September 8, 2009
Intended status: Informational
Expires: March 12, 2010
RANGER Scenarios
draft-russert-rangers-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Russert, et al. Expires March 12, 2010 [Page 1]
Internet-Draft RANGERS September 2009
Abstract
Routing and Addressing in Next-Generation EnteRprises (RANGER)
[I-D.templin-RANGER] provides an architectural framework for scalable
routing and addressing. It provides for scalability, provider
independence, mobility, multihoming and security for the next
generation Internet. This document describes a series of use cases
in order to showcase RANGER capabilities. It further shows how the
RANGER architecture restores the network-within-network principles
originally intended for the sustained growth of the Internet.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Global Concerns . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Scaling the Global Interdomain Routing Core . . . . . 11
4.1.2. Supporting Large Corporate Enterprise Networks . . . . 13
4.2. Autonomous System Concerns . . . . . . . . . . . . . . . . 15
4.3. Small Enterprise Concerns . . . . . . . . . . . . . . . . 16
4.4. IPv4/IPv6 Transition and Coexistence . . . . . . . . . . . 18
4.5. Mobility and MANET . . . . . . . . . . . . . . . . . . . . 21
4.5.1. Global Mobility Management . . . . . . . . . . . . . . 21
4.5.2. First-Responder Mobile Ad-Hoc Networks (MANETs) . . . 22
4.5.3. Tactical Military MANETs . . . . . . . . . . . . . . . 24
4.6. Provider Concerns . . . . . . . . . . . . . . . . . . . . 27
4.6.1. ISP Networks . . . . . . . . . . . . . . . . . . . . . 27
4.6.2. Cellular Operator Networks . . . . . . . . . . . . . . 28
4.6.3. Aeronautical Telecommunications Network (ATN) . . . . 28
4.6.4. Unmanaged Networks . . . . . . . . . . . . . . . . . . 31
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Russert, et al. Expires March 12, 2010 [Page 2]
Internet-Draft RANGERS September 2009
1. Introduction
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
[RFC2460] deployment. Routing and Addressing in Next-Generation
EnteRprises (RANGER) [I-D.templin-ranger] describes a method for the
map and encapsulate approach that also facilitates the other two
approaches.
[I-D.templin-ranger] provides an architectural framework for scalable
routing and addressing. It provides for scalability, provider
independence, mobility, multihoming and security for the next
generation Internet. The RANGER architectural principles are not
new. They can be traced to the deliberations of the ROAD group
[RFC1380], and also to still earlier works including NIMROD [RFC1753]
and the Catenet model for internetworking [CATENET][IEN48][RFC2775].
[RFC1955] captures the high-level architectural aspects of the ROAD
group deliberations in a "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG".
The Internet has grown tremendously since these architectural
principles were first developed, and that evolution 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].
The RANGER architecture is built using Virtual Enterprise Traversal
(VET) [I-D.templin-autoconf-dhcp], the Subnetwork Encapsulation and
Adaptation Layer (SEAL) [I-D.templin-seal], Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP)[I-D.templin-isatapv4] [RFC5214],
Russert, et al. Expires March 12, 2010 [Page 3]
Internet-Draft RANGERS September 2009
and other mechanisms including IPsec [RFC4301]. This document
describes use cases and shows how the RANGER mechanisms apply.
Complimentary mechanisms (e.g., DNS, DHCP, NAT, etc.) are included to
show how the various pieces can work together. It expands on the
concepts introduced in IPv6 Enterprise Network Scenarios [RFC4057]
and analysis [RFC4852], and shows how the enterprise network model
generalizes to a broad range of scenarios. These use cases are
included to provide examples, invite criticism and comment, and
explore the potential for creating the next-generation Internet using
the RANGER architecture. Familiarity with RANGER, VET, SEAL, and
ISATAP are assumed.
2. Terminology
Internet Topology Hierarchy
The Internet Protocol (IP) natively supports a topology hierarchy
comprised of increasing aggregations of networked elements.
Network interfaces of devices are grouped into subnetworks and
subnetworks are grouped into larger aggregations. Subnetworks can
be optionally grouped into areas and the areas grouped into an
autonomous system (AS). Alternatively, subnetworks can be
directly grouped into an AS. The foundation of the IP Topology
Hierarchy is the AS, which determines the administrative
boundaries of a network deployment including its routing,
addressing, quality of service, security, and management. Intra-
domain routing occurs within an autonomous system and inter-domain
routing links autonomous systems into a network of networks
(Internet).
Routing Locator (RLOC)
an IPv4 or IPv6 address assigned to an interface in an enterprise-
interior routing region. Note that RLOC space is local to each
enterprise, hence the same RLOC space IP addresses may be reused
between disjoint enterprises.
The IPv4 public address space currently in use today can be
considered as the RLOC space for the global Internet "enterprise".
Endpoint Interface iDentifier (EID)
an IPv4 and IPv6 address assigned to an edge network interface of
an end system. Note that EID space is global in scope, and must
be separate and distinct from any RLOC space.
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. An example of a
Russert, et al. Expires March 12, 2010 [Page 4]
Internet-Draft RANGERS September 2009
commons is the Default Free Zone (DFZ) of the global Internet.
The enterprise-interior routing region within the commons uses an
addressing plan taken from RLOC space.
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
default free zone).
Historically, "Enterprise networks" are associated with large
corporations or academic campuses. However, in RANGER an
"enterprise" may exist at any IP Topology Hierarchy level. The
RANGER architectural principles apply to any networked entity that
has some degree of cooperative active management. This definition
therefore extends to home networks, small office networks, a wide
variety of mobile ad-hoc networks (MANETs), and even to the global
Internet itself.
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 node at the edge of an enterprise that is also configured as a
tunnel endpoint in an overlay network. EBRs connect their
directly-attached networks to the overlay network, and connect to
other networks via IP-in-IP tunneling across the commons to other
EBRs. This definition is intended as an architectural equivalent
of the functional term "EBR" defined in
[I-D.templin-autoconf-dhcp], and is synonymous with the term "xTR"
used in other contexts (e.g., [I-D.farinacci-lisp]).
Russert, et al. Expires March 12, 2010 [Page 5]
Internet-Draft RANGERS September 2009
Enterprise Border Gateway (EBG)
an EBR that also connects the enterprise to provider networks
and/or to the global Internet. EBGs are typically configured as
default routers in the overlay, and provide forwarding services
for accessing IP networks not reachable via an EBR within the
commons. This definition is intended as an architectural
equivalent of the functional term "EBG" defined in
[I-D.templin-autoconf-dhcp], and is synonymous with the term
"default mapper" used in other contexts (e.g., [I-D.jen-apt]).
overlay network
a virtual network manifested by routing and addressing over
virtual links formed through automatic tunneling. An overlay
network may span many underlying enterprises.
6over4
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
[RFC2529]; functional specifications and operational practices for
automatic tunneling of unicast/multicast IPv6 packets over
multicast-capable IPv4 enterprises.
ISATAP
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
[RFC5214][I-D.templin-isatapv4]; functional specifications and
operational practices for automatic tunneling over unicast-only
enterprises.
VET
Virtual Enterprise Traversal (VET) [I-D.templin-autoconf-dhcp];
functional specifications and operational practices that provide a
functional superset of 6over4 and ISATAP. In addition to both
unicast and multicast tunneling, VET also supports address/prefix
autoconfiguration as well as additional encapsulations such as
IPSec, SEAL, LISP/UDP, Teredo/UDP, etc.
SEAL
Subnetwork Encapsulation and Adaptation Layer (SEAL)
[I-D.templin-seal]; a functional specification for robust packet
identification and link MTU adaptation over tunnels. SEAL
supports effective ingress filtering and adapts to subnetworks
configured over links with diverse characteristics.
Within the RANGER architecture context, the SEAL "subnetwork" and
RANGER "enterprise" should be considered as identical
abstractions.
Russert, et al. Expires March 12, 2010 [Page 6]
Internet-Draft RANGERS September 2009
Provider-Independent (PI) prefix
an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.)
that is routable within a limited scope and may also appear in
enterprise mapping tables. PI prefixes that can appear in mapping
tables are typically delegated to a BR by a registry, but are not
aggregated by a provider network. Local-use IPv6 and IPv4
prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of
a PI prefix, but these typically do not appear in mapping tables.
Provider-Aggregated (PA) prefix
an IPv6 or IPv4 EID prefix that is either derived from a PI prefix
or delegated directly to a provider network by a registry.
Although not widely discussed, it bears specific mention that a
prefix taken from a delegating router's PI space becomes a PA
prefix from the perspective of the requesting router.
Customer Premises Equipment (CPE) Router
a residential or small office router that provides IPv4 and/or
IPv6 support. The user or the service provider may manage the
router.
Carrier Grade NAT (CGN)
a special (usually high capacity) IPv4 to IPv4 NAT deployed within
the service provider network that serves multiple subnets.
3. Approach
The RANGER architecture is described in [I-D.templin-ranger]. The
following is a terse summary of some key elements of the
architecture.
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.
RANGER enables a protocol and/or addressing system to be connected in
a virtual overlay across an untrusted transit network, or "commons".
While it does not show all possible uses, Figure 1 illustrates that
RANGER supports the creation of a distributed network across an
intervening commons which could implement a dissimilar IP version,
routing protocol, or addressing system.
Russert, et al. Expires March 12, 2010 [Page 7]
Internet-Draft RANGERS September 2009
.--------------. .--------------. .-------------.
/ \_ _/ \_ _/ \
\ 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
The RANGER concepts can be applied recursively. They can be
implemented at any level within the IP Topology Hierarchy to create
an enterprise-within-enterprise organizational structure extending
traditional AS, area, or subnetwork boundaries. This structure uses
border routers that configure tunnel endpoints to enable
communications between potentially recursively-nested enterprises in
a virtual overlay network that transcends traditional administrative
and organizational boundaries. In its purest form, this overlay
network could therefore span the entire Internet and restore end-to-
end transparency (RFC 2775).
The RANGER architecture applies the best current practice insights
from previous encapsulation systems as they are currently articulated
within the Virtual Enterprise Traversal [I-D.templin-autoconf-dhcp],
and Subnetwork Encapsulation and Adaptation Layer [I-D.templin-seal]
functional specifications. The result is an architecture and
protocol system that can be used to create arbitrarily complex,
scalable IP deployments that support both unicast and multicast
routing and addressing systems.
RANGER supports scalable routing through a recursively-nested
enterprise-within-enterprise network capability. The fundamental
building block is the Enterprise Border Router (EBR) (see Figure 2).
The EBR is the limiting factor for RANGER recursion, and in certain
contexts a singleton EBR can be viewed as an enterprise unto itself.
Traditional network infrastructures can be extended to support
Russert, et al. Expires March 12, 2010 [Page 8]
Internet-Draft RANGERS September 2009
complex structures solely with the addition of EBRs with no other
modification to any networked entity.
An EBR can be a commercial off the shelf router, a tactical military
radio, an aircraft mobile router, etc., but it can also be an end
system (e.g., a laptop computer, a soldiers' handheld device, etc.)
that may or may not enable routing functions such as Internet
connection sharing.
Provider-edge Interfaces
x x x
| | |
+--------------------+---+--------+----------+ E
| | | | | n
| I | | .... | | t
| n +---+---+--------+---+ | e
| t | +--------+ /| | r
| e I x----+ | Host | I /*+------+--< p I
| r n | |Function| n|**| | r n
| n t | +--------+ t|**| | i t
| a e x----+ V e|**+------+--< s e
| l r . | E r|**| . | e r
| f . | T f|**| . | f
| V a . | +--------+ a|**| . | I a
| i c . | | Router | c|**| . | n c
| r e x----+ |Function| e \*+------+--< t e
| t s | +--------+ \| | e s
| u +---+---+--------+---+ | r
| a | | .... | | i
| l | | | | o
+--------------------+---+--------+----------+ r
| | |
x x x
Enterprise-edge Interfaces
Figure 2: Enterprise Border Router (EBR)
EBRs connect networks and end systems to one or more enterprises via
a repertoire of interface types. Enterprise-interior interfaces
attach to a commons. Provider-edge interfaces support traditional
routing relationships up the IP Topology Hierarchy and Enterprise-
edge Interfaces support traditional relationships down the IP
Topology Hierarchy. Internal virtual interfaces are typically
loopback interfaces or VMware-like host-in-host interfaces.
VET interfaces support RANGER recursion and IP-in-IP encapsulation.
VET interfaces are configured over provider-edge, enterprise
interior, or enterprise-edge interfaces to allow recursion
Russert, et al. Expires March 12, 2010 [Page 9]
Internet-Draft RANGERS September 2009
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
[I-D.templin-intarea-vet] Appendix B). One important advantage is
continuous operation across failovers between multiple links attached
to the same enterprise, without any need for readdressing.
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.
The figure shows that the eEBR assigns a Routing LOCator (RLOC)
address on its interface to the Commons' interior IP routing and
address space, while the destination host assigns an Endpoint
interface IDentifier (EID) on its enterprise edge interface. The
iEBR uses a mapping system to discover the RLOC of an eEBR on the
path to the destination EID address. A distinct mapping system is
maintained within each recursively-nested enterprise instance
operating at a specific level of the IP Topology Hierarchy. RANGER
uses the mapping system to join peer enterprises via a virtual
overlay across a commons.
Mapping System RLOC EID
. (BGP, DNS, etc.) . .
.---.------. .----------. . .------.---.
/ . \ / \ . / . \
/ (O) iEBR------/--------------\------eEBR * \
\ / \ Commons / \ /
\_ _ _ _ _ _ / \_ _ _ _ _ _ / \_ _ _ _ _ _/
Figure 3: The RANGER Model
EBRs must configure both RLOC and EID addresses and/or prefixes.
Autoconfiguration is coordinated with Enterprise Border Gateways
(EBGs) that connect to the next-higher layer in the recursive
hierarchy, as specified in VET. Standard mechanisms including DHCP
[RFC2131] [RFC3315] and Stateless Address Autoconfiguration (SLAAC)
[RFC4862] are used for this purpose.
Similarly, EBRs require a means to discover other EBRs and EBGs that
can be used as enterprise exit points. VET specifies mechanisms for
border router discovery using both the global DNS and/or enterprise-
Russert, et al. Expires March 12, 2010 [Page 10]
Internet-Draft RANGERS September 2009
local name services such as LLMNR [RFC4795].
The mapping system is a distributed database that is synchronized
among a limited set of mapping agents. Database synchronization can
be achieved by many different protocol alternatives. The most
commonly used alternatives are either BGP or the domain name system
(DNS; RFC1035). Mapping system databases can be populated by many
different mechanisms including administrative configuration and
automated prefix registrations.
EBRs either forward initial packets for which they have no mapping to
an EBG or consult the mapping system to determine the correct next
hop while delaying or dropping initial packets if necessary. The EBR
then receives a mapping reply that it can use to populate its
Forwarding Information Base (FIB). It then encapsulates each
forwarded packet in an outer IP header for transmission across the
commons to the remote RLOC address of an eEBR. The eEBR in turn
decapsulates the packets and forwards them to the destination EID
address. The Routing Information Base (RIB) within the commons only
needs to maintain state regarding RLOCs and not EIDs. The
synchronized EID-to-RLOC mapping state is not subject to oscillations
due to link state changes within the commons. RANGER supports
scalable addressing by selecting a suitably large EID addressing
range that is distinct from any enterprise-interior RLOC addressing
ranges.
4. Scenarios
4.1. Global Concerns
4.1.1. Scaling the Global Interdomain Routing Core
Growth in the Internet has created challenges in routing and
addressing that have been recognized for more than 15 years. IPv4
[RFC0791] address space is limited, and Regional Internet Registry
(RIR) allocation is passing the "very painful" Host Density (HD)
ratio threshold of 86% (that is, 192M allocated addresses) [RFC3194].
As a result, exhaustion of the IPv4 address pool is predicted within
the next two years [V4pool], [Huston-end]. IPv6 promises to resolve
the address shortage with a much larger address space, but transition
is costly and could exacerbate Border Gateway Protocol (BGP) problems
described below. Richer interconnection, increased multihoming
(especially with Provider-Independent (PI) addresses), and a desire
to support traffic engineering via finer control of routing has led
to super-linear growth of BGP routing tables in the default-free zone
or "DFZ" of the Internet. This growth has been damped because of the
limited number of IPv4 addresses, so the larger address space of IPv6
Russert, et al. Expires March 12, 2010 [Page 11]
Internet-Draft RANGERS September 2009
threatens to make the problem worse.
RANGER allows the coordinated reuse of addresses from Enterprise to
Enterprise by making RLOC address spaces independent of one another.
Figure 4 shows how the RANGER architecture allows the use of separate
address spaces for RLOC and EID addressing in the Internet. This
yields more endpoint address space, especially with the use of IPv6,
and also reduces the load on BGP in the Internet routing core. Note
that Figure 4 could represent variants of RFC 4057 scenarios 1 and 2.
EID RLOC EID
PA Spaces PI
Allocation Registration
.-------------------------------. ^
/ Internet Commons \ |
| .---------------------------. | |
2001:DB8::/40 | / Enterprise A \ | 2001:DB8:10::/56
| |/ 10.1/16 \ | ^
| || .-------------------------. || |
V || / Enterprise A.1 \ || |
2001:DB8::/48 || | 10.1/16 | || 2001:DB8:11::/56
|| \_________________________/ / |
| \ / |
| --------------------------- |
| |
| .---------------------------. |
| / Enterprise B \ |
2001:DB8:100::/40 | | 10.1/16 | | 2001:DB8:12::/56
| \____________________________/ |
\ /
\_______________________________/
Figure 4: Enterprises and the Internet
RLOC address spaces are entirely independent of one another, as they
are used only within an Enterprise (recall that an Enterprise can
exist at any level of the IP Topology Hierarchy). Therefore as
Figure 4 shows, the same RLOC space can be reused freely throughout
different Enterprises regardless of their level of recursion. EID
address space can be Provider-Aggregated (PA) or PI, and taken from
either IPv4, or IPv6. EID addresses (barring use of Network Address
Translation (NAT)) are globally unique, even when routable only
within a more limited scope (e.g., in their own edge networks).
The IRTF routing research group is investigating a Preliminary
Recommendation for a Routing Architecture
[I-D.irtf-rrg-recommendation] that provides a taxonomy for routing
Russert, et al. Expires March 12, 2010 [Page 12]
Internet-Draft RANGERS September 2009
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) [I-D.jen-apt], FIB Suppression with
Virtual Aggregation [I-D.francis-intra-va], LISP [I-D.farinacci-lisp]
and others.
4.1.2. Supporting Large Corporate Enterprise Networks
Each enterprise network operator must be able to manage its internal
networks and use the Internet infrastructure to achieve its
performance and reliability goals. Enterprises that are multihomed
or have mobile components frequently require provider-independent
addressing and the ability to coordinate with multiple providers
without renumbering flag days [RFC4192],
[I-D.carpenter-renum-needs-work]. RANGER provides a way to
coordinate addressing plans and inter-enterprise routing, with full
support for scalability, provider-independence, mobility, multi-
homing and security.
_.--------------------._
_.---'' -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,' ,.X1-.. / \ ,' `. `.
,' ,' `. .' E2 '. X8 Em \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<------------------- Global IPv4 Internet ------------------>
Figure 5: Enterprises on the Internet Commons
Figure 5 depicts enterprises E1 through Em connected to the global
Russert, et al. Expires March 12, 2010 [Page 13]
Internet-Draft RANGERS September 2009
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.
Each enterprise may encompass lower-tier enterprises; for instance,
the singleton EBR "W" in enterprise E2 resides in a lower-tier
enterprise (say E2.1), and (along with any of its attached devices)
may be considered as an enterprise unto itself. W sees Y3 and Y4 as
EBGs, which in turn see X5 and X6 as EBGs that connect to a common
provider network (in this case, the Internet). Each enterprise has
one or more Endpoint identifier (EID) address prefixes used for
addressing nodes on edge networks. RANGER's map-and-encaps approach
separates the mapping of EIDs to RLOCs from the Routing Information
Base (RIB) in the Internet commons that are assigned to EBR router
interfaces. Not only does BGP in the Internet commons only need to
maintain state regarding Routing Locators (RLOCs)in the Internet
commons, it has fewer unique routes to maintain because only routes
to EBRs are needed; traffic engineering can therefore be accommodated
via the mapping database.
In Figure 5, enterprise E2 represents a corporation that has multiple
locations and connections to multiple ISPs. The corporation has
recently merged with another corporation so that its internal network
has two disjoint RLOC address spaces, but neither of the formerly
separate entities can bear the burden of address renumbering.
Enterprise E2 can use a suitably large IPv4 and/or IPv6 EID
addressing range (that is distinct from any enterprise-interior RLOC
addressing range) to support end systems on enterprise edge networks
with no disruption to preexisting address numbering.
As EBRs are deployed to connect enterprises together, ordinary
routers within the enterprise continue to function as-normal and
deliver both ordinary and encapsulated packets across the existing
Internet infrastructure and the enterprise's own RLOC commons.
Legacy IPv4 services that bind to RLOC addresses continue to be
supported even as EID-based services are rolled out. Where legacy IP
client and server are within the same RLOC address space, they simply
communicate by using RLOC-based routing across the enterprise
commons. If client and server are not within the same RLOC address
space, they communicate through some form of network address and/or
Russert, et al. Expires March 12, 2010 [Page 14]
Internet-Draft RANGERS September 2009
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.
As an example, when an end system connected to W in E2.1 has a packet
to send to node Z in enterprise E3, W sends the packet to EBR Y4
which encapsulates the packet in an outer IP packet with its own
source address and the RLOC address of the next-hop EBR as
destination - in this case, X6. X6 decapsulates the packet and looks
up the destination EID prefix, obtaining the RLOC of X7 as next-hop.
X6 then encapsulates the IPv6 packet in a packet with RLOC address X6
as source and X7 as destination. X7 decapsulates the packet on
receipt and forwards it via its enterprise-edge interface to node Z.
This example uses one thread out of many that are possible using
RANGER; see [I-D.templin-ranger] and [I-D.templin-autoconf-dhcp] for
other options and details. Many enterprises that use proxies and
firewalls at their border routers today will wish to maintain that
control over their enterprise borders, and the use of RANGER does not
preclude such configurations (for example, see Section 4.3).
4.2. Autonomous System Concerns
An enterprise such as E2 in Figure 5 above can represent an AS within
the IP Topology Hierarchy. A possible configuration for Enterprise
E2 is for each of its enterprise components to also be recursive 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.
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
Russert, et al. Expires March 12, 2010 [Page 15]
Internet-Draft RANGERS September 2009
administration, and/or functional compartmentalization).
4.3. Small Enterprise Concerns
Global enterprises operating at the autonomous system level of the IP
Topology Hierarchy include multiple geographical regions, multiple
ISPs, and complex internal structures which naturally benefit from
the application of RANGER techniques. However, all other enterprise
network instances (both large and small) can also be served by
RANGER. For example, Small and Home Office (SOHO) networks may
comprise only a few computers on a single network segment or extend
to larger configurations with security islands, internal routers and
switches, etc.
An important concern of the small enterprise is the ability to grow
the network, change ISPs, or expand to more locations without
readdressing the existing network. Consider a small company that has
a single location in California. The ISP connection is via a router
that acts as Network Address Translator and firewall for the company.
Addresses of the few computers ("Wksta") are taken from the [RFC1918]
private address space.
ISP
-------|----- Wksta Wksta
| Firewall |_____________|____________|
| NAT |
-------------
Figure 6: Simple SOHO network
This configuration has been adequate for the few employees performing
software development work, since there is no need to expose services
within the site to the outside world. But now a web presence is
required as product introduction approaches. The network manager
deploys an EBR either as a co-resident function on the existing NAT/
firewall platform as depicted below, or on a separate platform.
The EBR has a provider-edge interface connected to the ISP, the
preexisting workstations, the preexisting enterprise edge interfaces
connecting workstations, and enterprise-edge interfaces connecting
several network segments connected by routers that host web servers,
workstations and other enterprise services. A VET interface is
configured over the new service network to allow the servers to be
addressed from the public Internet.
Russert, et al. Expires March 12, 2010 [Page 16]
Internet-Draft RANGERS September 2009
ISP
|
+------|-----+
| <|--
| VET2 < |
| <|---
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 7: RANGER serving the small company
In this new configuration, the EBR maintains the services within a
"demilitarized zone (DMZ)" that is accessible from the public
Internet without exposing other corporate assets that are still
protected by the preexisting firewall/NAT functions.
Shortly afterward an infusion of venture capital allows acceleration
of the product development and marketing work by adding programmers
in Tokyo and sales offices in New York and London. These new
branches connect via Virtual Private Network (VPN) links across the
Internet, and a new VET interface (VET2) is configured over these
links to form a new sub-enterprise.
ISP
|
+------|-----+
| <|------------London
| VET2 < |
| <|--------------------New York
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 8: RANGER for multiple locations
Russert, et al. Expires March 12, 2010 [Page 17]
Internet-Draft RANGERS September 2009
4.4. IPv4/IPv6 Transition and Coexistence
End systems and networks need to accommodate long-term support for
both IPv4 and IPv6. Requirements for transition include support for
IPv4 applications running over IPv4 protocol stacks, IPv4
applications over IPv6 stacks, IPv4 applications over dual stacks,
IPv6 or IPv4/IPv6 capable applications over both IPv6 and dual
stacks. Both encapsulation and translation will likely be needed to
allow applications, enterprises and providers to incorporate IPv6,
including all intermediate states, without global coordination or a
'flag day'.
The RANGER architecture facilitates the addition of IPv6 addressing
to existing IPv4 end systems and routers (i.e., via dual-stack) as
well as the addition of IPv6 networks to the existing set of IPv4
networks. RANGER, with VET [I-D.templin-autoconf-dhcp] and SEAL
[I-D.templin-seal], makes it possible to carry packets originated in
one protocol across network infrastructure supporting another
protocol or routing system. Figure 1 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.
The RANGER architecture supports end-to-end communications across
arbitrarily-long paths of concatenated enterprises connected by EBRs.
When IPv6 is used as Endpoint interface Identifier (EID) space, each
EBR can provision a globally unique set of IPv6 EID prefixes without
scaling limitations due to the expanded IPv6 address space. For
example, figure 9 shows a pair of end systems 'H' and 'J' separated
by an intervening set of enterprises, where the path between 'H' and
'J' traverses the EBR path 'V->Y1->X2->X7->Z':
Russert, et al. Expires March 12, 2010 [Page 18]
Internet-Draft RANGERS September 2009
+------+
| 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
When each EBR in the path is assigned a unique set of IPv6 EID
prefixes (and registers these prefixes in the appropriate routing/
mapping tables), IPv6 can be used for navigation purposes with each
EBR in the path seen as a waypoint for navigation. This is true even
if IPv4 is used as the enterprise-local Routing LOCator (RLOC)
address space, and there were many IPv4 hops on the path between each
pair of neighboring EBRs.
RANGER further provides a compatible framework for incorporating
supporting mechanisms including protocol translation, application-
layer aspects of IPv4/IPv6 transition discussed in [RFC4038] and DNS
issues for IPv6 from [RFC4472]. For instances where IPv4
applications remain in use, RANGER supports translation via
functional equivalents of "Network Address Translation, Protocol
Translation (NAT-PT)" [RFC2766], and "Bump In the Stack (BIS)"
[RFC2767]. Figure 10 shows the NAT-PT-equivalent translation in the
VET router, and Figure 11 shows the BIS-equivalent translation in end
systems. These examples address scenarios not mentioned in RFC 4852.
Russert, et al. Expires March 12, 2010 [Page 19]
Internet-Draft RANGERS September 2009
IPv4 App A IPv4 App B
_____________ _____________
|_TCP or UDP__| |_TCP or UDP__|
|____IPv4_____| |____IPv4_____|
______|______ _______|_____
/ \ / \
| IPv4-Only | | IPv4-Only |
| Site 1 | | Site 2 |
\_____________/ \_____________/
______|______ ______|_______
|____IPv4_____| _____________ |____IPv4_____|
|NAT-PT-equiv_| / \ |NAT-PT-equiv_|
|_TCP or UDP__| | Internet | |_TCP or UDP__|
|____IPv6_____| | (RANGER) | |____IPv6_____|
|__VET/SEAL___| \_____________/ |__VET/SEAL___|
\_______________/ \___________/
Figure 10: Translation in Routers
In Figure 10, an IPv4 application on end system A operates normally
and the end system sends IPv4 packets on the IPv4-only site network.
The IPv4 packets are received by an Enterprise Border Router (EBR)
that translates them into IPv6 packets by a NAT-PT-equivalent
process. The EBR then encapsulates the packets into IPv4 and sends
them across the RANGER-enabled Internet to Site 2 where they are
received and decapsulated by an EBR for Site 2. The EBR uses NAT-PT-
equivalent translation to translate the resulting IPv6 packet back to
an IPv4 packet that is delivered across the Site 2 IPv4-only network
to an IPv4 application on end system B.
IPv4 App A IPv4 App B
_____________ ______________ _____________
|_TCP or UDP__| / \ |_TCP or UDP__|
|____BIS______| | Internet | |____BIS______|
|____IPv6_____| | (RANGER) | |____IPv6_____|
|__VET/SEAL___| \_____________/ |__VET/SEAL___|
\_______________/ \___________/
Figure 11: BIS-style Translation in Dual-Stack End Systems
Figure 11 shows the simplified approach using a Bump-In the Stack
(BIS) translation process within dual-stack end systems ([RFC2767]).
In this case, the IPv4 application on dual-stack end system A forms
an IPv4 payload which is then transformed into an IPv6 packet within
the end system protocol stack itself. The IPv6 packet can then be
encapsulated and sent across the Internet to be decapsulated and sent
to the dual-stack end system hosting IPv4 application B. The BIS-
equivalent process on end system B reverses the translation, yielding
Russert, et al. Expires March 12, 2010 [Page 20]
Internet-Draft RANGERS September 2009
an IPv4 packet for consumption by the IPv4-only application.
Other issues besides IP protocol translation may arise during IPv4-
IPv6 transition; [RFC4038] points out issues including IPv4/IPv6
capable applications running on IPv4-only protocol stacks, DNS
responses that include addresses of both IP versions, and the
difficulty of supporting multiple application versions. It also
advises that applications be converted to dual support as a preferred
solution. These issues are outside the scope of this document.
4.5. Mobility and MANET
4.5.1. Global Mobility Management
Ubiquitous wireless access enables connection to network
infrastructure nearly anywhere. Vehicles and even persons can host
networks that move around with them. For example, commercial
aircraft networks include requirements for nomadic networks, local
mobility, and global mobility where the connection point between
airplane and ground station 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.
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 ,
[RFC3775]would result in very inefficient paths for one ACSP or the
other. The Aero Enterprise is an overlay that spans both continents
and allows efficient paths by providing multiple entry and exit
points (only one, R2, is shown).
Russert, et al. Expires March 12, 2010 [Page 21]
Internet-Draft RANGERS September 2009
Aircraft - - - - - - ,.- - - - - -.- - ->
. , . . +------+
. , . . | IPv6 |
. , . . |Server|
" ." " " ", "" " " ." " " " " .? " " " " " | S1 |
" . , . . " +--+---+
" . , . . " |
" . ... . . . . . +----+ " |
" . . . . . =+ X3 + " |
" . v +--- + . v . . v +----+ ? |
" . e =+ Y1 + . e . . e . +----+ +--------+
" . t +----+ . t +----+ . t . =+-R2-+==+Internet|
" . 1 . . 2 =+ X2 + . 3 . +----+ +--------+
" . . . +----+ . . " |
" . . . . . . . " +------+
" <ACSP1> <ACSP2> <ANSP> " | IPv4 |
" " |Server|
" - - vet 4 - - " | S2 |
" " " " " " " " " " " " " "" " " " " " " | S2 |
<-- Aero Enterprise --> +------+
Figure 12: Commercial Airplane Mobility
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.
4.5.2. First-Responder Mobile Ad-Hoc Networks (MANETs)
Many emerging network scenarios require autoconfiguration of Mobile
Ad-Hoc Networks (MANETs). Where first responders need networking for
communications and coordination between teams, RANGER allows each
team or agency to quickly stand up a network and then use the
autoconfiguration described in [I-D.templin-autoconf-dhcp] to
Russert, et al. Expires March 12, 2010 [Page 22]
Internet-Draft RANGERS September 2009
coordinate address/prefix autoconfiguration and discover border
routers needed for teams and agencies to interconnect.
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.
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.
Russert, et al. Expires March 12, 2010 [Page 23]
Internet-Draft RANGERS September 2009
+------+
| 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
4.5.3. Tactical Military MANETs
Military networks reflect well-defined policy requirements that
differ in many ways from civilian networks. The military's
information security requirements result in information being labeled
into specific classifications. The Bell-LaPadula model
[Bell-LaPadula] provides a mechanism to extend information security
policy into networked environments. This extension creates
communications security (COMSEC), whose routing and addressing
elements are cleanly supported by RANGER concepts.
Figure 3 on page 10 shows that RANGER supports creation of a VET
Russert, et al. Expires March 12, 2010 [Page 24]
Internet-Draft RANGERS September 2009
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 - [RFC4301]). When this same RANGER
concept is applied to Enterprises operating at the subnetwork level
of the IP Topology Hierarchy then this corresponds to an older form
of COMSEC (Link Layer Encryption). When the same RANGER concept is
applied to Enterprises being singleton EBR nodes (i.e., the interface
level of the IP Topology Hierarchy) then this corresponds to a third
military COMSEC alternative (Link Encryption).
The previous paragraph shows the flexibility of the RANGER
architecture to describe COMSEC approaches in terms of IP Topology
Hierarchy structured relationships. The power of the RANGER
architecture becomes apparent when one recognizes that each of the
entities in Figure 3 may themselves be simple or complex network
structures operating at any specific level of the IP Topology
Hierarchy. (Complex structures refer to architectures that have been
extended by RANGER recursion.) For example, the commons in the
figure may itself be an interface, a subnetwork, an autonomous
system, or an Internet. Enterprise A and Enterprise B can be a
single end system, a subnetwork, an autonomous system or an Internet.
Tactical military MANETs differ from traditional networks in many
ways, the most obvious being the high mobility of tactical
deployments and self-forming-network attributes of MANETs themselves.
Because each networked tactical entity supports a radio/router, the
numbers of routers within military MANETs can be orders of magnitude
more numerous (denser) than traditional civilian networks. This
means that even small deployments have comparatively large router
populations when compared to non-MANET deployments. Larger router
populations directly create greater sensitivity to protocol
scalability issues. Router scalability issues are further
exacerbated because IP protocols react unfavorably to signal
intermittence, which effectively dampens and constrains router
scaling even when mitigation techniques are employed. Signal
intermittence itself is a 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.
RANGER recursion enables MANET networks to be defined into structures
that naturally encourage route aggregation and scaling. For example,
Russert, et al. Expires March 12, 2010 [Page 25]
Internet-Draft RANGERS September 2009
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.
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.
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
Russert, et al. Expires March 12, 2010 [Page 26]
Internet-Draft RANGERS September 2009
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.
4.6. Provider Concerns
Network providers must have a way to support the protocol transitions
and network types mentioned above and still remain reliable and
financially sound. The RANGER architecture provides ways to support
general Internet Service Providers (ISPs), cellular operator
networks, and specialized networks such as the Aeronautical
Telecommunications Network (ATN).
4.6.1. ISP Networks
Internet service provider networks provide a commons for the
connection of Customer Premises Equipment (CPE) routers [I-D.ietf-
v6ops-ipv6-cpe-router] that connect arbitrarily-complex customer
networks. This is true whether the ISP permits direct customer-to-
customer communications, or whether all communications are forwarded
through ISP Provider Edge (PE) equipment.
The ISP commons must potentially support hundreds of thousands of CPE
routers (or more), hence the ISP may be obliged to assign private
IPv4 address allocations (i.e., instead of public) as RLOCs for CPE
routers. This gives rise to a "nested NATs" scenario, which can
increase the overall brittleness brought on by NAT traversal.
To address this brittleness, the ISP can deploy "Carrier Grade NATs"
(CGNs) [I-D.jiang-incremental-cgn] that provide a second level of
RLOC address translation on the path from the CPE to the Internet.
When the CGNs are also configured as EBGs, CPE routers can discover
them as default routers for reaching EID-based services using the EBG
discovery mechanisms specified in VET.
Scenarios and Analysis for Introducing IPv6 into ISP Networks
[RFC4029] discusses both ISP backbone network and customer connection
transition considerations, however this document considers router-to-
router tunneling use cases. Therefore the ISATAP mechanism (which
only supports host-to-router or host-to-host tunneling) is not
mentioned as a candidate technology. Early point solutions (e.g.,
TSP, STEP, etc.) were recommended prior to the publication of RANGER,
VET and SEAL. This document therefore updates RFC4029 to introduce
these new technologies that are widely applicable to managed network
Russert, et al. Expires March 12, 2010 [Page 27]
Internet-Draft RANGERS September 2009
scenarios such as ISP networks.
4.6.2. Cellular Operator Networks
[RFC4215] provides an Analysis on IPv6 Transition in Third Generation
Partnership Project (3GPP) Networks. It envisions an extended period
of support for both IPv4 and IPv6 protocols in the operator network.
User Equipment (UE) uses the Packet Data Protocol (PDP) context to
establish tunnels through the operator network to a Gateway GPRS
Support Node (GGSN). 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.
Other [RFC4215] scenarios examine IPv4-only UEs, IPv6-only UEs, and
various combinations of IPv4 and IPv6 within the operator network.
Also to be considered are scenarios in which the UE is configured as
a router or bridge that connects an end system such as a laptop
computer. In that case, the UE could be the first-hop router/bridge
into the cellular provider network, and the laptop computer could be
configured as an EBR in the RANGER model. Again, the GGSN or a
device reachable through the GGSN could serve as a RANGER EBG.
[RFC4215] was published prior to the development of RANGER, VET and
SEAL. This document therefore updates RFC4215 to introduce these new
technologies that are widely applicable to managed network scenarios
such as cellular operator networks.
4.6.3. Aeronautical Telecommunications Network (ATN)
The 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
Russert, et al. Expires March 12, 2010 [Page 28]
Internet-Draft RANGERS September 2009
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.
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.
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.
_...--------------------------------------..._
/ \
( IPv4 Internet )
-...________________________________________...-
| / | \ |
| / | \ |
_...--------------------------------------..._
/ \
( Aero Overlay )
-...________________________________________...-
. . . . . .
. . . . . .
_...-------.._ _...-------.._ _...-------.._
/ \ / \ / \
( ACSP1 ) ( ANSP ) ( ACSP2 )
-...________...- -...________...- -...________...-
Figure 14: Aeronautical Overlay
Each Aeronautical Communications Service Provider (ACSP), and
Aeronautical Navigation Service Provider (ANSP) constitute an
Russert, et al. Expires March 12, 2010 [Page 29]
Internet-Draft RANGERS September 2009
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.
The ATN is currently an OSI network but is projected to transition to
IPv6 over time. RANGER can bridge OSI networks together across the
IPv4 (or IPv6) Internet, or bridge IPv4 or IPv6 networks across an
OSI network. A pair of EBRs that have IP interfaces on a common
enterprise (whether it is the Internet, the aero enterprise, or
another parent or child enterprise) can support communications
between their attached OSI edge networks by looking up ISO network
service access point (NSAP) addresses [IS8348] instead of IP
addresses for RLOC mappings. OSI ConnectionLess Network Protocol
(CLNP) [IS8473] packets can therefore be encapsulated within IPv4 (or
IPv6) headers for transmission across an Internet Protocol
enterprise. Some OSI networks may transition to IPv6 protocols and
addressing [RFC1888] while applications are adapted by using RFC 2126
[RFC2126] to carry OSI upper layers over TCP/IP, with the resulting
IP packets carried across and between RANGER enterprises in the
normal way. Another approach is to put a protocol translation
function in the EBRs that support OSI protocol edge networks, similar
to the protocol translation approach shown in Figure 10 on page 20.
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
Russert, et al. Expires March 12, 2010 [Page 30]
Internet-Draft RANGERS September 2009
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.
_...--------------------------------------..._
/ (B) (D) \
( Aero Overlay (IPv4) )
-...________________________________________...-
. . .
(A) (C) .
. . .
_...------------------------.._ (E)
/ \ .
/ (F) \ .
( [H] ACSP (IPv6) ) .
\ (G) / .
\...__________________________... .
.
_...------------------------.._
/ \
/ (M) (N) \
( ANSP (IPv6) )
\ [S] /
\...__________________________...
Figure 15: Packet Forwarding for Aeronautical Networks
4.6.4. Unmanaged Networks
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
[RFC3904] considers four cases for support of IPv6-enabled routers
and end systems connected to an ISP network via a gateway:
a. a gateway which does not provide IPv6 at all;
b. a dual-stack gateway connected to a dual-stack ISP;
c. a dual-stack gateway connected to an IPv4-only ISP; and
d. a gateway connected to an IPv6-only ISP.
Case a is typified by the widespread practice of customer networks
using IPv4-only NAT boxes to connect to their service providers.
RANGER does not address this scenario directly, however the TEREDO
mechanism [RFC4380] can provide a sufficient solution in many cases.
Case d is a scenario that has not yet seen widespread adoption. In
Russert, et al. Expires March 12, 2010 [Page 31]
Internet-Draft RANGERS September 2009
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.
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.
5. Summary
The Internet today can be considered as a giant enterprise, with
nodes in the Internet addressed from the public IPv4 address space as
RLOCs. Due to the 32-bit addressing limitations of IPv4, however,
continued expansion is coordinated through the widespread deployment
of IPv4 Network Address Translators (NATs) while IPv6 has yet to see
wide adoption.
In many senses, however, this has resulted in a degenerate
manifestation of the network-of-networks model originally envisaged,
e.g., in the CATENET model. Indeed, these NATed domains have the
external appearance of being a simple host within the global Internet
RLOC space even though they may be proxying for arbitrarily large
networks of end systems. The end result is a loss of transparency in
the end-to-end model; it is no longer true that any node in the
Internet can directly address any other node.
By adopting the principle of using RLOCs as the local addressing
range and EIDs as the global addressing range, RANGER enables a true
network-within-network (or enterprise-within-enterprise) framework.
This is true even across a wide array of deployment scenarios as
documented 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.
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.
Russert, et al. Expires March 12, 2010 [Page 32]
Internet-Draft RANGERS September 2009
6. IANA Considerations
There are no IANA considerations for this document.
7. Security Considerations
Security considerations are addressed in [I-D.templin-ranger],
[I-D.templin-autoconf-dhcp], and [I-D.templin-seal]. While the
RANGER architecture does not in itself address security
considerations, it proposes an architectural framework for functional
specifications that do. Security concerns with tunneling along with
recommendations that are compatible with the RANGER architecture are
found in [I-D.ietf-v6ops-tunnel-security-concerns]. Security
considerations for specific use cases are discussed there.
8. Acknowledgements
This work was inspired by the original architectural principles of
the Internet supplemented with "lessons learned" by many peers from
actual Internet deployments and experience developing encapsulation
protocols. The editors acknowledge that they are furthering work
initiated by many.
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
9.2. Informative References
[Bell-LaPadula]
Bell, D. and L. LaPadula, "Secure Computer Systems:
Mathematical Foundations and Model", October 1974.
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet
Switching Networks", May 1974.
[Huston-end]
Huston, G., "The End of the (IPv4) World is Nigher",
July 2007.
Russert, et al. Expires March 12, 2010 [Page 33]
Internet-Draft RANGERS September 2009
[I-D.carpenter-renum-needs-work]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work", draft-carpenter-renum-needs-work-03
(work in progress), May 2009.
[I-D.farinacci-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12 (work in progress), March 2009.
[I-D.francis-intra-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-francis-intra-va-01 (work in progress), April 2009.
[I-D.ietf-v6ops-tunnel-security-concerns]
Hoagland, J., Krishnan, S., and D. Thaler, "Security
Concerns With IP Tunneling",
draft-ietf-v6ops-tunnel-security-concerns-01 (work in
progress), October 2008.
[I-D.irtf-rrg-recommendation]
Li, T., "Preliminary Recommendation for a Routing
Architecture", draft-irtf-rrg-recommendation-02 (work in
progress), March 2009.
[I-D.jen-apt]
Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
L. Zhang, "APT: A Practical Transit Mapping Service",
draft-jen-apt-01 (work in progress), November 2007.
[I-D.jiang-incremental-cgn]
Jiang, S. and D. Guo, "An Incremental Carrier-Grade NAT
(CGN) for IPv6 Transition", draft-jiang-incremental-cgn-00
(work in progress), March 2009.
[I-D.templin-autoconf-dhcp]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-autoconf-dhcp-38 (work in progress),
April 2009.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-03 (work in progress),
August 2009.
[I-D.templin-isatapv4]
Templin, F., "Transmission of IPv4 Packets over ISATAP
Russert, et al. Expires March 12, 2010 [Page 34]
Internet-Draft RANGERS September 2009
Interfaces", draft-templin-isatapv4-02 (work in progress),
March 2009.
[I-D.templin-ranger]
Templin, F., "Routing and Addressing in Next-Generation
EnteRprises (RANGER)", draft-templin-ranger-07 (work in
progress), February 2009.
[I-D.templin-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-seal-23 (work in progress),
August 2008.
[IEN48] Cerf, V., "The Catenet Model for Internetworking",
July 1978.
[IS8348] International Organization for Standardization,
International Electrotechnical Commission, "Open Systems
Interconnection -- Network service definition", 2002.
[IS8473] International Organization for Standardization,
International Electrotechnical Commission, "Protocol for
providing the connectionless-mode network service:
Protocol specification", 1998.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, November 1992.
[RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod
Routing and Addressing Architecture", RFC 1753,
December 1994.
[RFC1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top
of TCP (ITOT)", RFC 2126, March 1997.
Russert, et al. Expires March 12, 2010 [Page 35]
Internet-Draft RANGERS September 2009
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for
Address Assignment Efficiency An Update on the H ratio",
RFC 3194, November 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
Russert, et al. Expires March 12, 2010 [Page 36]
Internet-Draft RANGERS September 2009
September 2005.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks", RFC 4215,
October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795,
January 2007.
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
Green, "IPv6 Enterprise Network Analysis - IP Layer 3
Focus", RFC 4852, April 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[V4pool] Hain, T., "The IPv4 Address Pool Projection", April 2009.
Russert, et al. Expires March 12, 2010 [Page 37]
Internet-Draft RANGERS September 2009
Authors' Addresses
Steven W. Russert (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: srussert3561@charterinternet.com
Eric W. Fleischman (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: eric.fleischman@boeing.com
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Russert, et al. Expires March 12, 2010 [Page 38]