Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Intended status: Informational January 19, 2009
Expires: July 23, 2009
Routing and Addressing in Next-Generation EnteRprises (RANGER)
draft-templin-ranger-06.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 July 23, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
Next-generation enterprise networks including the global Internet
itself will require an architected solution for the coordination of
Templin Expires July 23, 2009 [Page 1]
Internet-Draft RANGER January 2009
internal routing and addressing plans and with accommodations for
Provider-Independent (PI) addressing, scalability, mobility, multi-
homing and security. Additionally, next-generation networks will
require support for both Internet protocol versions (IPv4 and IPv6)
for an indeterminant period; perhaps even indefinitely. These
considerations are particularly true for existing deployments, but
the same principles apply even for clean-slate approaches. The
RANGER architecture addresses these requirements, and provides a
comprehensive framework for IPv6/IPv4 coexistence.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The RANGER Architecture . . . . . . . . . . . . . . . . . . . 6
3.1. The Enterprise-within-Enterprise Framework . . . . . . . . 6
3.2. Virtual Enterprise Traversal (VET) . . . . . . . . . . . . 8
3.2.1. Organizational Principles . . . . . . . . . . . . . . 9
3.2.2. Dynamic Routing and On-Demand Mapping . . . . . . . . 11
3.2.3. Support for Legacy Services . . . . . . . . . . . . . 13
3.3. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 14
3.4. Mobility Management . . . . . . . . . . . . . . . . . . . 15
3.5. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 16
4. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 17
4.1. 6over4 and ISATAP . . . . . . . . . . . . . . . . . . . . 17
4.2. The Locator Identifier Split Protocol (LISP) . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Templin Expires July 23, 2009 [Page 2]
Internet-Draft RANGER January 2009
1. Introduction
Next-generation enterprise networks including the global Internet
itself will require an architected solution for the coordination of
internal routing and addressing plans with accommodations for
Provider-Independent (PI) addressing, routing scalability, mobility,
multi-homing and security. Additionally, next-generation networks
will require support for both Internet protocol versions (IPv4 and
IPv6) for an indeterminant period; perhaps even indefinitely. These
considerations are particularly true for existing deployments, but
the same principles apply even for clean-slate approaches. The
RANGER architecture addresses these requirements, and provides a
comprehensive framework for IPv6/IPv4 coexistence
[I-D.arkko-townsley-coexistence].
RANGER is a scalable architecture for routing and addressing in next-
generation enterprises that contain one or more distinct interior
addressing domains. Each of these domains may coordinate their own
internal addressing plans independently of one another such that
limited-scope addresses (e.g., [RFC1918] private-use IPv4 addresses)
may be reused with impunity to provide unlimited scaling through
spatial reuse. Each addressing domain therefore appears as an
enterprise unto itself, such that a model of recursively nested
"enterprises-within-enterprises" is enabled. Logical or physical
partitioning of an enterprise into multiple sites is also possible
and beneficial in many scenarios.
Without an architected approach, routing and addressing within such a
framework would be fragmented due to limited-scope address/prefix
reuse between disjoint addressing domains. With RANGER, however, the
enterprise can be unified via a virtual overlay architecture
mainfested by automatic tunneling over disjoint domains
interconnected via border routers.
The RANGER architecture provides for operation of virtual overlay
networks within a diverse range of enterprise network scenarios.
Moreover, RANGER gracefully supports modes of operation that have
heretofore challenged the classic IP networking model. While this
document discusses the specific example of IPv6 as a virtual overlay
over or IPv4 networks, it is important to note that the same
architectural principles apply to any combination of IP* virtual
overlays over IP* networks.
The RANGER architecture builds on mechanisms documented in the IRTF
and IETF communities, with composite technologies including Virtual
Enterprise Traversal (VET) [I-D.templin-autoconf-dhcp], the
Subnetwork Encapsulation and Adaptation Layer (SEAL)
[I-D.templin-seal] and the Intra-Site Automatic Tunnel Addressing
Templin Expires July 23, 2009 [Page 3]
Internet-Draft RANGER January 2009
Protocol (ISATAP) [RFC5214][I-D.templin-isatapv4]. Other mechanisms
such as IPsec [RFC4301] are also in scope for use within certain
deployments.
The RANGER architectural principles can be traced to the
deliberations of the ROAD group in January 1992 [RFC1380], and also
to still earlier works including NIMROD [RFC1753], the Catenet model
for internetworking [CATENET][IEN48] [RFC2775], and many others.
[RFC1955] captures the high-level architectural aspects of the ROAD
group deliberations in a "New Scheme for Internet Routing and
Addressing [ENCAPS] for IPNG".
2. Terminology
commons
a routing region within an enterprise that provides a subnetwork
for cooperative peering between the border routers of diverse
organizations that may have competing interests. A prime example
of a commons is the Default Free Zone (DFZ) of the global
Internet.
enterprise
the same as defined in [RFC4852], where the enterprise deploys a
unified routing and addressing plan within the commons, but may
contain many disjoint interior addressing domains 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).
Enterprise networks are typically associated with large
corporations or academic campuses, however the RANGER
architectural principles apply to any network that has some degree
of cooperative active management. This definition therefore
extends to home networks, small office networks, a wide variety of
mobile ad-hoc networks (MANETs), and even to the global Internet
itself.
site
a logical and/or physical grouping of interfaces within a unified
addressing region of an enterprise, 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.
Templin Expires July 23, 2009 [Page 4]
Internet-Draft RANGER January 2009
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 Border
Router can be considered as an enterprise unto itself.
Border Router (BR)
a node at the edge of an enterprise that is also configured as a
router in an overlay network. BRs connect their directly-attached
networks to the overlay network, and connect to other networks via
IP-in-IP tunneling across the commons to other BRs.
Border Gateway (BG)
a BR that also connects the enterprise to provider networks and/or
to the global Internet. BGs are typically configured as default
routers in the overlay, and provide forwarding services for
accessing IP networks not reachable via a BR within the commons.
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, etc.
SEAL
Subnetwork Encapsulation and Adaptation Layer (SEAL)
[I-D.templin-seal]; a functional specification for robust packet
identification and link adaptation over tunnels. SEAL supports
effective ingress filtering and adapts to subnetworks configured
Templin Expires July 23, 2009 [Page 5]
Internet-Draft RANGER January 2009
over links with diverse characteristics.
Provider-Independent (PI) prefix
an IPv6 or IPv4 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 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 an IPv6
prefix taken from delegating router's PI space becomes a PA prefix
from the perspective of the requesting router.
3. The RANGER Architecture
The RANGER architecture enables scalable routing and addressing in
next-generation enterprise networks with sustaining support for
legacy networks and services. Key to this approach is a framework
that accommodates interconnection of diverse organizations within the
enterprise with a mutual spirit of cooperation, but with the
potential for competing interests. The following sections outline
the RANGER architecture within the context of anticipated use cases:
3.1. The Enterprise-within-Enterprise Framework
Enterprise networks traditionally distribute routing information via
Interior Gateway Protocols (IGPs) such as Open Shortest Path First
(OSPF), while large enterprises may even use an Exterior Gateway
Protocol (EGP) internally in place of an IGP. In particular, it is
becoming increasingly commonplace for large enterprises to use the
Border Gateway Protocol (BGP) internally and independently from the
BGP instance that maintains the routing information base within the
global Internet Default Free Zone (DFZ).
As such, large enterprises may run an internal instance of BGP across
many internal Autonomous Systems (ASs). Such a large enterprise can
therefore appear as an Internet unto itself, albeit with default
routes leading to the true global Internet. Additionally, each
internal AS within such an enterprise may itself run BGP internally
in place of an IGP, and can therefore also appear as an independent
lower-tier enterprise unto itself. This enterprise-within-enterprise
framework can be extended in a hierarchical fashion as broadly and as
Templin Expires July 23, 2009 [Page 6]
Internet-Draft RANGER January 2009
deeply as desired to acheive scaling factors as well as
organizational and/or functional compartmentalization, e.g., as shown
in Figure 1.
,---------------.
,-' Global `-. <--------+
( IPv6/IPv4 ) ,----|-----.
`-. Internet ,-' ( Enterprises)
`+--+..+--+ ...+--+ ( E2 thru EN )
_.-|R1|--|R2+----|Rn|-._ `.---------/
_.---'' +--+ +--+ ...+--+ -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,' ,.X1-.. / \ ,' `. `.
,' ,' `. .' E1.2 '. X8 E1.m \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1.1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E1.3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<---------------- Enterprise E1 ---------------->
Figure 1: Enterprise-within-Enterprise Framework
Figure 1 depicts an enterprise 'E1' connected to the global IPv6/IPv4
Internet via routers 'R1' through 'Rn' and additional enterprises
'E2' through 'EN' that also connect to the global Internet. Within
the 'E1' commons, there may be arbitrarily-many hosts, routers and
networks (not shown in the diagram) over which both unencapsulated IP
packets and IP-in-IP encapsulated packets can be forwarded. There
may also be many lower-tier enterprises 'E1.1' through 'E1.m' (shown
in the diagram) that interconnect within the 'E1' commons via Border
Routers (BRs) depicted as 'X1' through 'X9' (where 'X1' through 'X9'
see 'R1' through 'Rn' as Border Gateways (BGs)). Within each 'E1.*'
enterprise, there may also be arbitrarily-many lower-tier enterprises
that interconnect within the 'E1.*' commons via BRs depicted as 'Y1'
through 'Y9' in the diagram (where 'Y1' through 'Y9' see 'X1' through
'X9' as BGs). This hierarchical decomposition can be recursively
nested as deeply as desired, and ultimately terminates at singleton
nodes such as those depicted as 'V', 'W' and 'Z' in the diagram.
Templin Expires July 23, 2009 [Page 7]
Internet-Draft RANGER January 2009
It is important to note that nodes such as 'V', 'W' and 'Z' may be
simple hosts, or they may be BRs that attach arbitrarily-complex edge
networks. Such edge networks could be as simple as a home network
behind a residential gateway or as complex as a major corporate/
academic campus, a large service provider network, etc.
Again, this enterprise-within-enterprise framework can be recursively
nested as broadly and deeply as desired. From the ultimate level of
the hierarchy, consider now that the global Internet itself can be
viewed as an "enterprise" that interconnects lower-tier enterprises
E1 through EN such that all RANGER architectural principles apply
equally within that context.
As a specific case in point, the future global Aeronautical
Telecommuncations Network (ATN) under consideration within the civil
aviation industry [I-D.bauer-mext-aero-topology] will take the form
of a large enterprise network that appears as an Internet unto
itself, i.e., exactly as depicted for 'E1' in Figure 1. Within the
ATN, there will be many Air Communications Service Provider (ACSP)
and Air Navigation Service Provider (ANSP) networks organized as
autonomous systems internal to the ATN, i.e., exactly as depicted for
'E1.*' in the diagram. The ACSP/ANSP network BGs will participate in
a BGP instance internal to the ATN, and may themselves run
independent BGP instances internally that are further sub-divided
into lower-tier enterprises organized as regional, organizational,
functional, etc. compartments. It is important to note that, while
ACSPs/ANSPs within the ATN will share a common objective of safety-
of-flight for civil aviation services, there may be competing
business/social/political interests between them such that the ATN is
not necessarily "one big happy family". Therefore, the model
parallels that of the global Internet itself.
Such an operational framework may indeed be the case for many next-
generation enterprises. In particular, although the routing and
addressing arrangements of all enterprises will require a mutual
level of cooperative active management at a certain level, free
market forces, business objectives, political alliances, etc. may
drive internal competition.
3.2. Virtual Enterprise Traversal (VET)
Within the enterprise-within-enterprise framework outlined in
Section 3.1, the RANGER architecture is based on an overlay network
approach manifested through Virtual Enterprise Traversal (VET)
[I-D.templin-autoconf-dhcp] [RFC5214][I-D.templin-isatapv4]. The
approach uses automatic IP-in-IP tunneling within a hierarchy of
lower-tier enterprises that are either configured within the same
addressing region of a parent enterprise or use their own enterprise-
Templin Expires July 23, 2009 [Page 8]
Internet-Draft RANGER January 2009
local routing and addressing internally.
VET and its related works specify the necessary mechanisms and
operational practices to manifest the RANGER architecture. The use
of VET in conjunction with SEAL Section 3.3 is essential in certain
deployments to avoid issues related to source address spoofing and
black holing due to path Maximum Transmission Unit (MTU) limitations.
(The use of VET in conjunction with IPsec [RFC4301] can also be
beneficial in some enterprise network scenarios.) The following
sections discuss operational considerations and use cases within the
VET approach:
3.2.1. Organizational Principles
In the VET approach, logically and/or physically disjoint lower-tier
enterprises are connected by BGs that appear as BRs within a parent
enterprise. In turn, BRs within the parent enterprise coordinate
their IP prefixes with BGs that connect to upper-tier enterprises.
The prefixes could be either Provider-Independent (PI) prefixes owned
by the BR or Provider-Aggregated (PA) prefixes delegated by the BG,
but the prefixes are linked with mapping and routing over the virtual
topology in both cases. Additionally, fault tolerance and
multihoming is naturally afforded through configuration of multiple
BGs per enterprise.
Figure 2 below depits a vertical slice (albeit represented
horizontally) from the enterprise-within-enterprise framework shown
in Figure 1. In this example, an IPv6 host 'H' that is deeply nested
within Enterprise 'E1' connects to IPv6 server 'S1' located somewhere
on the IPv6 Internet. Again, while this and other examples speak of
the specific instance of IPv6-in-IPv4 encapsulation, the same
principles apply to any IP-in-IP encapsulation:
Templin Expires July 23, 2009 [Page 9]
Internet-Draft RANGER January 2009
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" <----------------- 2001:DB8::/40 (PA) " +--+---+
" 2001:DB8:10::/56 (PI) ----------------> " |
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . H . . . . . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 2: Virutal Enterprise Traversal
Within this vertical slice, Figure 2 depicts each enterprise within
the 'E1' hierarchy as spanned by automatic IPv6-in-IPv4 tunnels
'vet1' through 'vet3'. Each 'vet*' interface within this framework
is a Non-Broadcast, Multiple Access (NBMA) interface that connects
all BRs within the same enterprise. Each enterprise within the 'E1'
hierarchy may comprise a smaller topological region within a larger
IPv4 routing region, or they may configure an independent routing and
addressing plan from a common (but spatially reused) limited-scope
IPv4 prefix, e.g., depicted as '10/8' in the diagram.
When PA addressing is used, the BR for each 'E1*' enterprise receives
an IPv6 prefix delegation from a delegating BG in a parent
enterprise. In this example, when 'R2' is a delegating router for
the prefix '2001:DB8::/40, it may delegate '2001:DB8::/48' to X2,
whichin turn delegates '2001:DB8::/52' to Y1, which in turn delegates
2001:DB8::/56' to V. When PI addressing is used, individual BRs
(e.g., V) register their PI prefixes (e.g., 2001:DB1:10::/56) with
their BGs which in turn register them with their parent BGs, etc.
This registration results in updates to the mapping system, which can
later be used to populate a BR's Forwarding Information Base (FIB).
In the example in Figure 2, a simple IPv6 host 'H' is attached to a
shared link with IPv6/IPv4 dual stack router 'V', which advertises
the IPv6 prefixes '2001:DB8:0:0::/64' and '2001:DB8:10:0::/64. IPv6
host 'H' uses standard IPv6 neighbor discovery mechanisms to discover
'V' as a default IPv6 router that can forward its packets off the
local link, and configures addresses from both of the advertised
Templin Expires July 23, 2009 [Page 10]
Internet-Draft RANGER January 2009
prefixes. 'V' in turn sees node 'Y1' as a BG that can be reached via
VET interface ''vet1' and that can forward packets toward IPv6 server
'S1'. Similarly, node 'Y1' is a BR on the enterprise spanned by
'vet2' that sees 'X2' as a BG, and node 'X2' is a BR on 'vet3' that
sees 'R2' as a BG. Ultimately, 'R2' is a BR that connects 'E1' to
the global Internet.
In this and other examples, it is specifically worth noting that a BR
may have potentially many VET interfaces over which it can connect to
the BRs/BGs of neighboring enterprises.
3.2.2. Dynamic Routing and On-Demand Mapping
In the example shown in Figure 2, 'V', 'Y1', 'X2' and 'R2' configure
separate 'vet*' interfaces for each enterprise they connect to and to
discover BRs/BGs through a dynamic routing protocol and/or mapping
database lookups. After tunnels 'vet1' through 'vet3' are
established and BG's discovered, the BRs connected to a 'vet*'
interface can run a dynamic routing protocol such as OSPVFv3
[RFC5340] and form adjacencies between themselves in an on-demand
fashion while treating the 'vet*' interface as an ordinary link. It
is important to note that adjacencies can be formed on-demand and
allowed to expire after idle periods such that a full mesh of links
need not be maintained. This allows an overlay network that spans
'E1' to dynamically adapt to changing conditions within the
enterprise.
In a second example, Figure 3 depicts an instance of on-demand
discovery of more-specific routes in which an IPv6 host 'H' connects
to an IPv6 server 'J' located in a different organizational entity
within 'E1':
Templin Expires July 23, 2009 [Page 11]
Internet-Draft RANGER January 2009
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" <----------------- 2001:DB8::/40 (PA) " +--+---+
" 2001:DB8:10::/56 (PI) ----------------> " |
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +----+ v +----+ +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ +----+ +-----+-------+
" . | 1 . . 2 . . . " |
" . H . . . . v . " |
" . . . . . . . . . . . e . " +--+---+
" . t . " | IPv4 |
" . . . . . . , . 3 . " |Server|
" . +----+ v +----+ . " | S2 |
" . | Z += e =+ X7 += . " +------+
" . +-+--+ t +----+ . "
" . | 4 . . . "
" . J . . . . . "
" . . . . . . . "
" 2001:DB8:20::/56 (PI) --------> "
" " " " " " " " " " " " " " "" " " " " " " "
<-- Enterprise E1 -->
Figure 3: On-Demand Discovery
In this example, tunnel interfaces 'vet1' through 'vet4' as well as
IPv6 PI prefix registrations have been established through VET
enterprise autoconfiguration procedures [I-D.templin-autoconf-dhcp].
When host 'H' with IPv6 address '2001:DB8:10::1' sends packets to
server 'J' with IPv6 address '2001:DB8:20::1', unless IPv6 routing
information is available BR 'X2' must determine that 'J' can be
reached using a more direct route via 'X7' across the 'E1' commons.
To do so, 'X2' can perform an on-demand mapping lookup by consulting
the enterprise mapping service (e.g., an enterprise name service).
Alternatively, 'X2' can send the packet to a default router 'R2', and
'R2' can return an ICMPv6 redirect message indicating that 'J' can be
reached via a more direct route through 'X7'. When 'X2' receives a
redirect from 'R2', it can send an IPv6 Router Advertisement (RA)
message using SEcure Neighbor Discovery (SEND) [RFC3971] to 'X7' then
forward subsequent packets directly via the route-optimized path to
'X7'.
In some enterprise scenarions, dynamic routing and on-demand mapping
can be combined as complementary functions. In other scenarios, it
may be sufficient to use on-demand mapping alone.
Templin Expires July 23, 2009 [Page 12]
Internet-Draft RANGER January 2009
3.2.3. Support for Legacy Services
While the overlay network that spans 'E1' provides a fully-connected
routing and addressing capability for IP overlay services, access to
legacy services will still be required for an extended (and possibly
indefinite) period. For example, Figure 4 below depicts the
applicable IPv4 service access models for the RANGER architecture
when IPv6 is used as the overlay:
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" <----------------- 2001:DB8::/40 (PA) " +--+---+
" 2001:DB8:10::/56 (PI) -----------------> " |
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +----+ t +----+ t +----+ t +----+ +-----+-------+
" . 1 . . 2 . . 3 . " |
" . K L . . . . M . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 4: Legacy IPv4 Service Support
In a first instance, an IPv4 client 'K' within enterprise 'E1.1.1'
can access IPv4 service 'L' within the same enterprise as-normal and
without the need for any encapsulation. Instead, a "mapping" is done
through a simple name lookup within the enterprise-local name service
deployed in 'E1.1.1', and enterprise-local native IPv4 services are
used. In many instances, this may indeed be the preferred service
access model even when IPv6 services are widely deployed due to
factors such as inability to replace legacy IPv4 applications, IPv6
header overhead avoidance, etc.
In a second instance, IPv4 client 'K' can access IPv4 server 'S2' on
the global IPv4 Internet in a number of ways. First, if the
recursively nested enterprises are all configured within the same
IPv4 routing region within E1, 'K' can simply forward its packets
toward 'R2' that then acts as an IPv4 Network Address Translator
(NAT) and/or an ordinary IPv4 enterprise border router. Secondly, if
the recursively nested enterprises are configured within disjoint
IPv4 routing regions, all routers 'Y1', 'X2' and 'R2' can provide an
Templin Expires July 23, 2009 [Page 13]
Internet-Draft RANGER January 2009
IPv4 NAT capability however this approach requires multiple instances
of stateful NAT devices on the path which can lead to an overall
degree of brittleness and intolerance to routing changes. Instead,
'E1' could deploy a "Carrier-Grade NAT (CGN)" at 'R2' (i.e., at the
enterprise border with the global Internet) and E1.1.1 could discover
'Y1' as an IPv4 default router. 'Y1' could then use the "dual-stack-
lite" approach in which IPv4-in-IPv6-in-IPv4 tunneling conveys the
IPv4 packets from 'K' to the CGN at 'R2', which then decapsulates and
translates the inner IPv4 packets before sending them on to 'S2'.
Finally, 'K' could be configured as an IPv6-only node and use
standard IPv6 routing to reach an IPv6/IPv4 translator located at an
IPv6 BR for the enterprise in which 'S2' resides'. The translator
would then use IPv6-to-IPv4 translation before sending packets
onwards toward 'S2'. These and other alternatives are discussed in
[I-D.wing-nat-pt-replacement-comparison].
In a final instance, IPv4 client 'K' can access an IPv4 server 'M' in
a different enterprise within E1 as long as both enterprises are
configured over the same underlying IPv4 routing region. If the
enterprises are configured over disjoint IPv4 routing regions,
however, 'K' would still be able to access 'M' using IPv6-only
services, or by using IPv4 services if an IPv4 overlay were
configured in parallel with the IPv6 overlay [I-D.templin-isatapv4].
3.3. Subnetwork Encapsulation and Adaptation Layer (SEAL)
Whenever the BRs of disjoint enterprises are joined across a commons,
mechanisms that rely on ICMP feedback from routers within the network
may become brittle or susceptible to spoofing attacks. This is due
to the fact that ICMP messages can be lost due to congestion or
packet filtering gateways, and that network middleboxes are
essentially "anonymous" and may include insufficient information in
ICMPs that can be used to authenticate their source. Of even greater
concern is the fact that a rogue node from a different enterprise
could send spoofed packets of any kind, e.g., for the purpose of
mounting denial-of-service and/or traffic amplification attacks
targeting underprivileged links.
The Subnetwork Encapsulation and Encapsulation Layer (SEAL) provides
effective mitigations by only accepting packets from correspondent
BRs that can be validated as topologically-correct routers within the
commons (i.e., the subnetwork) using the VET Potential Router List
(PRL) and ingress filtering [I-D.templin-autoconf-dhcp] in
conjunction with the 32-bit SEAL_ID in the pacekt. Moreover, SEAL
does not require reliable delivery of all ICMPs, but rather supports
continued operation even if some/many ICMPs are lost. Finally, SEAL
adapts to subnetworks that contain links with diverse MTUs
properties, and can use probing to identifiy links in the path that
Templin Expires July 23, 2009 [Page 14]
Internet-Draft RANGER January 2009
configure marginal MTUs.
The advantages of using SEAL in conjunction with the RANGER
enterprise-within-enterprise framework are tangible, and compare
favorably with the alternative of deploying an all-IPv6
infrastructure even for clean-slate deployments. This is especially
true within enterprises that provide a commons for joining
organizational/political/functional entities with a spirit of mutual
cooperation but with competing interests or objectives.
3.4. Mobility Management
Mobility management use cases must be considered along several
different vectors:
o nomadic devices may be satisfied by client-only basic connectivity
and can tolerate address renumbering events as they move between
enterprise network attachment points.
o mobile routers with PI prefixes may be satisfied by updates to the
mapping system as long as they do not impart unacceptable churn.
o mobile routers and end systems with PA addresses/prefixes may
require additional supporting mechanisms that can accomodate
address/prefix renumbering.
Nomadic device mobility is already satisfied by currently deployed
technologies. For example, transporting a laptop computer from a
wireless access hot spot to a home network LAN would allow the
nomadic device to regain client-only basic network connectivity at
the expense of address renumbering resulting in terminated
communication sessions.
Mobile routers that use VET and SEAL can move freely between
enterprises as long as they withdraw their PI prefixes from the
mapping/routing systems of departed enterprises and inject them into
the mapping/routing systems of new enterprises. In many cases, a
more localized event mobility may result in no changes to mapping/
routing in parent enterprises. For enterprises that require in-the-
network confidentiality, MobIKE [RFC4555] may also be useful within
this context.
Mobile routers and end systems that move quickly between disparate
enterprise edge network attachment points may impart unacceptable
mapping/routing churn and packet loss in service networks that cannot
easily support a well-structure enterprise-within-enterprise
framework. Devices that connect to such networks should use PA
addresses/prefixes that can be coordinated via a rendezvous service
Templin Expires July 23, 2009 [Page 15]
Internet-Draft RANGER January 2009
in a home enterprise when the device moves to a visited enterprise.
Mobility management mechanisms such as Mobile IPv6 [RFC3775] and HIP
[RFC4423] can be used to maintain a stable identifier for fast moving
devices even as they move quickly between visited enterprise edge
network attachment points.
As a use case in point, consider an aircraft with a mobile router
moving between ground station points of attachment. If the ground
stations are located within the same enterprise, or within lower-tier
sites of the same parent enterprise, it should suffice for the
aircraft to announce its PI prefixes at its new point of attachment
and withdraw them from the old. This would avoid excessive routing/
mapping system churn, since the prefixes need not be announced/
withdrawn within the parent enterprise, i.e., the churn is isolated
to lower layers of the recursive hierarchy. Note also that such
movement would not entail an aircraft-wide readdressing event.
As a second example, consider a wireless handset moving between
service coverage areas maintained by independent providers with
peering arrangements. Since the coverage range of terrestrial
cellular wireless technologies is limited, mobility events may occur
on a much more aggressive timescale than some other examples. In
this case, the handset may expect to incur a readdressing event for
its access interface at least, and may be obliged to arrange for a
rendezvous linkage with its home network.
It should specifically be noted that the contingency of mobility
management solutions is not necessarily mutually exclusive, and must
be considered in relation to specific use cases. The RANGER
architecture is therefore naturally inclusive in this regard.
3.5. Multihoming
As with mobility management, multi-homing use cases must be
considered along multiple vectors. Within an enterprise, BRs can
discover multiple BGs and use them in a fault tolerant and load-
balancing fashion as long as they register their PI prefixes with
each such BG. At the enterprise edge, a true location/identity split
approach such as HIP may be necessary for supporting true multihoming
across multiple physical links with diverse properties.
As a first case in point, consider the enterprise network of a major
corporation that obtains services from a number of ISPs. The
corporation should be able to register its PI prefixes with all of
its ISPs, and use any of the ISPs for its Internet access services.
As a second use case, consider an aircraft with a diverse set of
wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.). The
aircraft should be able to select and utilize the most appropriate
Templin Expires July 23, 2009 [Page 16]
Internet-Draft RANGER January 2009
link(s) based on phase of flight, and change seamlessly between links
as necessary. Other examples include a nomadic laptop with both
802.11 and Ethernet links, a wireless handset with both CDMA wireless
and 802.11, etc.
As with mobilitiy management, the contintingency of solutions is not
necessarily mutually exclusive and can combine to suit use cases
within the scope of the RANGER architecture.
4. Related Initiatives
4.1. 6over4 and ISATAP
Long before the RANGER architecture and VET/SEAL specifications were
published, 6over4 [RFC2529] specified a means for automatic tunneling
of unicast/multicast IPv6 packets over multicast-capable IPv4
enterprises, however it was unable to function in enterprises that
did not support a full deployment of IPv4 multicast services.
To address these shortcomings, ISATAP [RFC5214][I-D.templin-isatapv4]
was specified as a unicast-only variant of 6over4 and widely
implemented among major software and equipment vendor products.
ISATAP provides unicast-only neighbor discovery mechanisms and also
adds a means for determining whether a node on an ISATAP interface is
authorized to act as an IPv6 router; namely, the Potential Router
List (PRL).
VET provides a functional superset of the 6over4 and ISATAP
mechanisms; VET further combines with SEAL, IPSec, etc. to provide
the functional elements of the RANGER architecture.
4.2. The Locator Identifier Split Protocol (LISP)
The Locator-Identifier Split Protocol (LISP) [I-D.farinacci-lisp]
proposes a map-and-encaps architecture for scalable routing and
addressing within the global Internet Default Free Zone (DFZ).
Several companion documents (e.g., LISP-ALT, LISP-CONS, LISP-EMACS,
LISP-NERD) propose mapping function solutions. A related mapping
function solution proposal is found in [I-D.jen-apt].
LISP, and a number of related proposals being discussed in the
Routing Research Group, share common properties with the solution
proposed here. They may therefore be architecturally consistent with
the RANGER architecture.
Templin Expires July 23, 2009 [Page 17]
Internet-Draft RANGER January 2009
5. IANA Considerations
There are no IANA considerations for this document.
6. Security Considerations
Communications between endpoints within different sites inside an
enterprise are carried across a commons that joins organizational
entities with a mutual spirit of cooperation, but between which there
may be competing business/sociological/political interests. As a
result, mechanisms that rely on feedback from routers on the path may
become brittle or susceptible to spoofing attacks. This is due to
the fact that IP packets can be lost due to congestion or packet
filtering gateways, and that the source addresses of IP packets can
be forged. Moreover, IP packets in general can be generated by
anonymous attackers, e.g., from a rogue node within a third-party
enterprise that has malicious intent toward a victim.
Path MTU discovery is an example of a mechanism that relies on ICMP
feedback from routers on the path, and as such is susceptible to
these issues. For IPv4, a common workaround is to disable Path MTU
Discovery and let fragmentation occur in the network if necessary.
For IPv6, lack of fragmentation support in the network precludes this
option such that the mitigation typically recommended is to discard
ICMP messages that contain insufficient information and/or to operate
with the minimum IPv6 path MTU. This example extends also to other
mechanisms that either rely on or are enhanced by feedback from
network devices, however attack vectors based on non-ICMP messages
are also subject for concern.
The RANGER architecture supports effective mitigations for attacks
such as distributed denial-of-service, traffic amplification, etc.
In particular, when VET and SEAL are used, enterprise BGs can use the
32-bit identification encoded in the SEAL header as well as ingress
filtering to determine if a message has come from a topologically-
correct enterprise located across the commons. This allows
enterprises to employ effective mitigations at their borders without
the requirement for mutual cooperation from other enterprises. When
source address spoofing by on-path attackers located within the
commons is also subject for concern, additional securing mechanisms
such as tunnel-mode IPsec between enterprise BGs can also be used.
BRs can obtain PI prefixes through arrangements with a prefix
delegation authority. Thereafter, the BR must have a means of
proving its ownership when it announces or withdraws the prefixes in
enterprise routing systems. This can be accommodated through the use
of SEcure Neighbor Discovery (SEND) [RFC3971] as well as a means for
Templin Expires July 23, 2009 [Page 18]
Internet-Draft RANGER January 2009
confirming prefix ownership, e.g., through name service lookup. The
SEND mechanism is also useful for route optimization between lower-
tier enterprises across a parent enterprise commons.
While the RANGER architecture does not in itself address security
considerations, it proposes an architectural framework for functional
specifications that do. Security concerns with tunneling along with
recommendations that are compatible with the RANGER architecture are
found in [I-D.ietf-v6ops-tunnel-security-concerns].
7. Acknowledgements
This work was inspired through the encouragement of the Boeing DC&NT
network technology team and through the communications of the IESG.
Many individuals have contributed to the architectural principles
that form the basis for RANGER over the course of many years.
8. References
8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
8.2. Informative References
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet
Switching Networks", May 1974.
[I-D.arkko-townsley-coexistence]
Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-
Existence Scenarios", draft-arkko-townsley-coexistence-00
(work in progress), September 2008.
[I-D.bauer-mext-aero-topology]
Bauer, C. and S. Ayaz, "ATN Topology Considerations for
Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00
(work in progress), July 2008.
[I-D.farinacci-lisp]
Farinacci, D., Fuller, V., Oran, D., Meyer, D., and S.
Brim, "Locator/ID Separation Protocol (LISP)",
Templin Expires July 23, 2009 [Page 19]
Internet-Draft RANGER January 2009
draft-farinacci-lisp-11 (work in progress), December 2008.
[I-D.ietf-v6ops-tunnel-security-concerns]
Hoagland, J., Krishnan, S., and D. Thaler, "Security
Concerns With IP Tunneling",
draft-ietf-v6ops-tunnel-security-concerns-01 (work in
progress), October 2008.
[I-D.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.templin-autoconf-dhcp]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-autoconf-dhcp-27 (work in progress),
January 2009.
[I-D.templin-isatapv4]
Templin, F., "Transmission of IPv4 Packets over ISATAP
Interfaces", draft-templin-isatapv4-00 (work in progress),
December 2008.
[I-D.templin-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-seal-23 (work in progress),
August 2008.
[I-D.wing-nat-pt-replacement-comparison]
Wing, D., Ward, D., and A. Durand, "A Comparison of
Proposals to Replace NAT-PT",
draft-wing-nat-pt-replacement-comparison-02 (work in
progress), September 2008.
[IEN48] Cerf, V., "The Catenet Model for Internetworking",
July 1978.
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, November 1992.
[RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod
Routing and Addressing Architecture", RFC 1753,
December 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
Templin Expires July 23, 2009 [Page 20]
Internet-Draft RANGER January 2009
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
Green, "IPv6 Enterprise Network Analysis - IP Layer 3
Focus", RFC 4852, April 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
Author's Address
Fred L. Templin (editor)
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires July 23, 2009 [Page 21]