Network Working Group F. Templin, Ed.
Internet-Draft Boeing Phantom Works
Intended status: Informational October 17, 2008
Expires: April 20, 2009
Routing and Addressing in Next-Generation EnteRprises (RANGER)
draft-templin-ranger-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 20, 2009.
Abstract
Enterprise networks will require support for both Internet protocol
versions (IPv4 and IPv6) for an indeterminant period; perhaps even
indefinitely. This is particularly true for existing enterprise
networks that must introduce IPv6 without disruption of IPv4
services, but the same principles apply also to clean-slate
deployments in new enterprises. Next-generation enterprises
therefore require an architected solution for coordination of their
internal routing and addressing plans for both IPv6 and IPv4. The
RANGER architecture addresses these requirements.
Templin Expires April 20, 2009 [Page 1]
Internet-Draft RANGER October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The RANGER Architecture . . . . . . . . . . . . . . . . . . . 5
3.1. The Enterprise-within-Enterprise Framework . . . . . . . . 5
3.2. Virtual Enterprise Traversal (VET) . . . . . . . . . . . . 8
3.3. Support for IPv4 Services . . . . . . . . . . . . . . . . 10
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 12
4. Initiatives Related to RANGER/VET/SEAL . . . . . . . . . . . . 12
4.1. 6over4 and ISATAP . . . . . . . . . . . . . . . . . . . . 13
4.2. The Locator Identifier Split Protocol (LISP) . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Templin Expires April 20, 2009 [Page 2]
Internet-Draft RANGER October 2008
1. Introduction
Enterprise networks will require support for both Internet protocol
versions (IPv4 and IPv6) for an indeterminant period; perhaps even
indefinitely. This is particularly true for existing enterprise
networks that must introduce IPv6 without disruption of IPv4
services, but the same principles apply also to clean-slate
deployments in new enterprises. Next-generation enterprises
therefore require an architected solution for coordination of their
internal routing and addressing plans for both IPv6 and IPv4. The
RANGER architecture addresses these requirements, and provides a
framework for IPv6/IPv4 coexistence [I-D.arkko-townsley-coexistence].
RANGER is a scalable architecture for routing and addressing in next-
generation enterprise networks that may contain many disjoint
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. These disjoint domains therefore appear as
enterprises unto themselves, such that a model of recursively nested
"enterprises-within-enterprises" is enabled.
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. However, the entire
enterprise can be unified via a virtual overlay architecture
mainfested by automatic tunneling over disjoint domains
interconnected via border routers.
RANGER provides an architecture for operation of virtual overlay
networks within a diverse range of enterprise network scenarios, as
outlined in the following sections. While RANGER discusses the
specific instance of IPv6 as a virtual overlay for connecting
disjoint IPv4 domains, it is important to note that the same
architectural principles apply to any combination of IP virtual
overlays over disjoint IP addressing spaces.
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.
Templin Expires April 20, 2009 [Page 3]
Internet-Draft RANGER October 2008
enterprise
the same as defined in [RFC4852], where the enterprise deploys a
unified IPv4 routing and addressing plan but may internally
contain many disjoint addressing domains and/or organizational
groupings that can be considered as enterprises/sites 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 can therefore
be extended 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, where the site may be less than or equal to an
enterprise in scope. A site may contain many interior
enterprises/sites, which may themselves contain many interior
enterprises/sites in a recursive fashion. At the lowest level of
decomposition, a singleton Border Router can be considered as an
enterprise/site unto itself.
enterprise/site Throughout the remainder of this document, the term
"enterprise" is used to collectively refer to either enterprise or
site, i.e., the RANGER principles apply equally to enterprises and
sites of any size or shape.
Border Router (BR)
an IPv6/IPv4 dual-stack node at the edge of an enterprise and that
is also configured as an IPv6 router in an overlay network. BRs
connect their directly-attached IPv6 networks to the overlay
network, and connect to other IPv6 networks via IPv6-in-IPv4
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
IPv6 routers, and provide forwarding services for accessing IPv6
networks not reachable via a BR within the commons.
Templin Expires April 20, 2009 [Page 4]
Internet-Draft RANGER October 2008
overlay network
a virtual network manifested by IPv6 routing and addressing over
virtual links formed through automatic IPv6-in-IPv4 tunneling. An
IPv6 overlay network may span many underlying IPv4 enterprises/
sites.
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/sites.
ISATAP
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
[RFC5214]; functional specifications and operational practices for
automatic tunneling of unicast IPv6 packets over unicast-only IPv4
enterprises/sites.
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 extra encapsulations such as IPSec,
SEAL, LISP, etc.
SEAL
Subnetwork Encapsulation and Adaptation Layer (SEAL)
[I-D.templin-seal]; a functional specification for robust and
authenticated path MTU assurance over IPv6-in-IPv4 tunnels. Also
provides authentication for other ICMP error messages, and adapts
to subnetworks with diverse link characteristics.
3. The RANGER Architecture
The RANGER architecture enables scalable IPv6 routing and addressing
in next-generation enterprise networks, while sustaining support for
legacy IPv4 networks and services. Key to this approach is a
framework that accommodates interconnection of diverse organizations
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
Templin Expires April 20, 2009 [Page 5]
Internet-Draft RANGER October 2008
(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
enterprise unto itself. This enterprise-within-enterprise (or,
"site-within-site") framework can be extended in an hierarchical
fashion as broadly and as deeply as desired to acheive scaling
factors as well as organizational and/or functional
compartmentalization, 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
Templin Expires April 20, 2009 [Page 6]
Internet-Draft RANGER October 2008
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 IPv4 hosts, routers
and networks (not shown in the diagram) over which IPv4 packets can
be forwarded and IPv6 packets can be tunneled. There may also be
many internal enterprises/sites '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 IPv4 networks/nodes as
well as lower layer enterprises/sites 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 IPv6/IPv4 dual-stack
systems such as those depicted as 'V', 'W' and 'Z' in the diagram.
It is important to note that dual-stack systems such as 'V', 'W' and
'Z' may be simple IPv6/IPv4 hosts, or they may be BRs that attach
arbitrarily-complex IPv6-only edge networks. Such IPv6-only 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 E1 through EN such that
all RANGER architectural principles apply equally within the global
Internet context.
As a specific case in point, the future global Aeronautical
Telecommuncations Network (ATN) under development 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 and be further sub-divided into
enterprises/sites organized as regional, organizational, functional,
etc. compartments. It is important to note that, while ACSPs/ANSPs
within the ATN 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
Templin Expires April 20, 2009 [Page 7]
Internet-Draft RANGER October 2008
Internet itself.
Such an operational framework may indeed be the case for many next-
generation enterprises. In particular, although the inner-workings
of all enterprises will require a mutual level of cooperative active
management at some 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 that uses IPv6 routing and addressing to span an enterprise
via automatic IPv6-in-IPv4 tunneling over a hierarchy of child
enterprises that use enterprise-local-scope IPv4 routing and
addressing internally. These logically and/or physically disjoint
IPv4 child enterprises are "glued together" by IPv6 BRs/BGs, with
each BR requesting an IPv6 prefix delegation from a delegating BG.
Additionally, multihoming is naturally afforded through configuration
of multiple BGs per child enterprise.
Figure 2 below depits a vertical slice (albeit represented
horizontally) from the enterprise-within-enterprise framework shown
in Figure 1, where an IPv6 host 'H' that is deeply nested within
Enterprise 'E1' connects to IPv6 server 'S1' located somewhere on the
IPv6 Internet:
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" 2001:DB8:0:0::/56 *:0::/48 *:0::/40 " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ 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 the RANGER Architecture
Within this vertical slice, Figure 2 depicts each enterprise within
the 'E1' hierarchy as spanned by automatic IPv6-in-IPv4 tunnels
Templin Expires April 20, 2009 [Page 8]
Internet-Draft RANGER October 2008
'vet1' through 'vet3' manifested through Virtual Enterprise Traversal
(VET) [I-D.templin-autoconf-dhcp]. Each 'vet*' interface within this
framework is Non-Broadcast, Multiple Access (NBMA), and connects all
BRs within the same enterprise. Each enterprise within the 'E1'
hierarchy 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. The BR for each 'E1*' enterprise
receives an IPv6 prefix delegation from a delegating BG, depicted
above as sub-delegations of the prefix '2001:DB8::/40'.
Along with the Subnetwork Encapsulation and Adaptation Layer (SEAL -
see: Section 3.4), VET specifies the necessary mechanisms and
operational practices to manifest the RANGER architecture as depicted
in the example above as well as in any such similar example. In
particular, VET allows 'V', 'Y1', 'X2' and 'R2' to configure separate
'vet*' interfaces for each enterprise they connect to, and to
discover BGs through a static name service resolution (or, mapping)
as specified in [I-D.templin-autoconf-dhcp]. After tunnels 'vet1'
through 'vet3' are established and BG's discovered, the BRs connected
to a 'vet*' interface can run an IPv6 routing protocol such as
OSPVFv3 [RFC5340] and form adjacencies between themselves while
treating the 'vet*' interface as an ordinary IPv6 link. This allows
an IPv6 overlay network that spans 'E1' to automatically form and
dynamically adapt to changing conditions within the enterprise.
In the example shown in Figure 2, a simple IPv6 host 'H' is attached
to a shared link with IPv6/IPv4 dual stack node 'V'. 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,
while 'V' sees node 'Y1' as a BG that can be reached via 'vet1' and
that can forward packets toward IPv6 server 'S1'. Similarly, node
'Y1' is a BR for the enterprise spanned by 'vet2' that sees 'X2' as a
BG, and node 'X2' is a BR for 'vet3' that sees 'R2' as a BG that
connects 'E1' to the global IPv6 Internet.
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 April 20, 2009 [Page 9]
Internet-Draft RANGER October 2008
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" 2001:DB8:0:0::/56 *0:0::/48 *0:0::/40 " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ 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:1:0::/56 *1:0::/40 "
" " " " " " " " " " " " " " "" " " " " " " "
<-- Enterprise E1 -->
Figure 3: On-Demand Discovery within the RANGER Architecture
In this scenario, tunnel interfaces 'vet1' through 'vet4' as well as
IPv6 prefix delegations have been established through the enterprise
autoconfiguration procedures specified in
[I-D.templin-autoconf-dhcp]. When IPv6 host 'H' sends IPv6 packets
to server 'J', however, 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, or 'R2' can send an ICMPv6 redirect
message indicating that 'J' can be reached via a more direct route
through 'X7'.
It is specifically worth noting that, in both of the previous
examples, a BR may have potentially many VET interfaces over which it
can connect to the BRs/BGs of potentially many "sibling" enterprises/
sites across the commons.
3.3. Support for IPv4 Services
While the IPv6 overlay network that spans 'E1' provides a fully-
connected routing and addressing capability for IPv6 services, access
to legacy IPv4 services will still be required for an extended (and
Templin Expires April 20, 2009 [Page 10]
Internet-Draft RANGER October 2008
possibly indefinite) period. Figure 4 below depicts the applicable
IPv4 service access models for the RANGER architecture:
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" 2001:DB8:0:0::/56 *:0::/48 *:0::/40 " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ 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 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 4: IPv4 Service Access in the RANGER Architecture
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 IPv6-in-IPv4 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, all routers
'Y1', 'X2' and 'R2' can provide an IPv4 Network Address Translation
(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. As a
second alternative, 'E1' could instead deploy a "Carrier-Grade NAT
(CGN)" at 'R2' (i.e., at the enterprise border with the global
Internet) and E1.1.1 could configure 'Y1' as an IPv4 default router.
'Y1' could then use the "dual-stack-lite" approach in which it uses
IPv4-in-IPv6-in-IPv4 tunneling to convey 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'. As a third alternative,
'K' could be configured as an IPv6-only node and use standard IPv6
routing to reach an IPv6/IPv4 translator located at 'R2'. The
Templin Expires April 20, 2009 [Page 11]
Internet-Draft RANGER October 2008
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, the RANGER architecture currently makes no
provisions for an IPv4 client 'K' to use IPv4-only services to access
an IPv4 server 'M' in a different enterprise within 'E1' that
configures a disjoint addressing domain. Until an architected
approach is devised, 'K' would only be able to access 'M' using IPv6-
only services.
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL)
Whenever the BRs of disjoint enterprises/sites 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. ICMP
messages can therefore be forged by anonymous attackers, e.g., from a
rogue node within an enterprise that has malicious intent toward
another enterprise.
The Subnetwork Encapsulation and Encapsulation Layer (SEAL) provides
effective means for BRs to avoid these shortcomings by accepting only
authenticated feedback from correspondent BRs that can be validated
as Potential Routers within the commons (i.e., the subnetwork) using
the mechanisms of [I-D.templin-autoconf-dhcp]. 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 bandwidth and
MTU size properties, and indeed allows for discovery and eradication
of marginal links.
The advantages of using SEAL within 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.
4. Initiatives Related to RANGER/VET/SEAL
Templin Expires April 20, 2009 [Page 12]
Internet-Draft RANGER October 2008
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 (a unicast-only variant of
6over4) [RFC5214] was specified 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 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). LISP
is in essence a specific manifestation of the RANGER architecture
applied to the global Internetworking use case. All RANGER
architectural principles therefore apply equally to LISP.
5. IANA Considerations
There are no IANA considerations for this document.
6. Security Considerations
Communications between endpoints within different enterprise networks
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.
IP packets can therefore be generated by anonymous attackers, e.g.,
from a rogue node within a third-party enterprise that has malicious
intent toward a victim.
Templin Expires April 20, 2009 [Page 13]
Internet-Draft RANGER October 2008
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 it must. 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 VETand SEAL are is used, enterprise BGs can use
the 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 nodes located within the commons is also
subject for concern, additional securing mechanisms such as tunnel-
mode IPsec between enterprise BGs can also be used.
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. Related Work
The RANGER architecture principles can be traced to the deliberations
of the ROAD group in January 1992 [RFC1380], and likely also to other
early works including Nimrod [RFC1753]. [RFC1955] captures the high-
level architectural aspects of the ROAD group deliberations in a "New
Scheme for Internet Routing and Addressing [ENCAPS] for IPNG".
8. 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.
Templin Expires April 20, 2009 [Page 14]
Internet-Draft RANGER October 2008
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
9.2. Informative References
[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)",
draft-farinacci-lisp-09 (work in progress), October 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.templin-autoconf-dhcp]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-autoconf-dhcp-18 (work in progress),
October 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.
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, November 1992.
Templin Expires April 20, 2009 [Page 15]
Internet-Draft RANGER October 2008
[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.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[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 April 20, 2009 [Page 16]
Internet-Draft RANGER October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Templin Expires April 20, 2009 [Page 17]