Internet Research Task Force F. Templin, Ed.
(IRTF) Boeing Research & Technology
Internet-Draft August 6, 2010
Intended status: Informational
Expires: February 7, 2011
The Internet Routing Overlay Network (IRON)
draft-templin-iron-09.txt
Abstract
Since the Internet must continue to support escalating growth due to
increasing demand, it is clear that current routing architectures and
operational practices must be updated. This document proposes an
Internet Routing Overlay Network for supporting sustainable growth
through Provider Independent addressing while requiring no changes to
end systems and no changes to the existing routing system. This
document is a product of the IRTF Routing Research Group (RRG).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 7, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Templin Expires February 7, 2011 [Page 1]
Internet-Draft IRON August 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5
3.1. IR[CE] - IRON Customer Edge Router . . . . . . . . . . . . 7
3.2. IR[VE] - IRON Virtual Prefix Company Edge Router . . . . . 7
3.3. IR[VC] - IRON Virtual Prefix Company Core Router . . . . . 8
3.4. IR[VP] - IRON Virtual Prefix Company Combined Router . . . 9
4. IRON Organizational Principles . . . . . . . . . . . . . . . . 10
5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 12
5.1. IR[VC] Initialization . . . . . . . . . . . . . . . . . . 12
5.2. IR[VE] Initialization . . . . . . . . . . . . . . . . . . 12
5.3. IR[CE] Initialization . . . . . . . . . . . . . . . . . . 13
6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. IR[CE] Operation . . . . . . . . . . . . . . . . . . . . . 14
6.2. IR[VE] Operation . . . . . . . . . . . . . . . . . . . . . 16
6.3. IR(VC) Operation . . . . . . . . . . . . . . . . . . . . . 17
6.4. IRON Reference Operating Scenarios . . . . . . . . . . . . 17
6.4.1. Both Hosts Within IRON EUNs . . . . . . . . . . . . . 18
6.4.2. Mixed IRON and Non-IRON Hosts . . . . . . . . . . . . 24
6.5. Mobility, Multihoming and Traffic Engineering
Considerations . . . . . . . . . . . . . . . . . . . . . . 27
6.5.1. Mobility Management . . . . . . . . . . . . . . . . . 27
6.5.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 28
6.5.3. Inbound Traffic Engineering . . . . . . . . . . . . . 28
6.5.4. Outbound Traffic Engineering . . . . . . . . . . . . . 28
6.6. Renumbering Considerations . . . . . . . . . . . . . . . . 28
6.7. NAT Traversal Considerations . . . . . . . . . . . . . . . 29
6.8. Nested EUN Considerations . . . . . . . . . . . . . . . . 29
6.8.1. Host A Sends Packets to Host Z . . . . . . . . . . . . 30
6.8.2. Host Z Sends Packets to Host A . . . . . . . . . . . . 32
7. Additional Considerations . . . . . . . . . . . . . . . . . . 33
8. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IRON VPs Over Non-Native Internetworks . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Templin Expires February 7, 2011 [Page 2]
Internet-Draft IRON August 2010
1. Introduction
Growth in the number of entries carried in the Internet routing
system has led to concerns for unsustainable routing scaling
[I-D.narten-radir-problem-statement]. Operational practices such as
increased use of multihoming with IPv4 Provider-Independent (PI)
addressing are resulting in more and more fine-grained prefixes
injected into the routing system from more and more end user
networks. Furthermore, the forthcoming depletion of the public IPv4
address space has raised concerns for both increased deaggregation
(leading to yet further routing table entries) and an impending
address space run-out scenario. At the same time, the IPv6 routing
system is beginning to see growth in IPv6 Provider-Aggregated (PA)
prefixes [BGPMON] which must be managed in order to avoid the same
routing scaling issues the IPv4 Internet now faces. Since the
Internet must continue to scale to accommodate increasing demand, it
is clear that new routing methodologies and operational practices are
needed.
Several related works have investigated routing scaling issues and
proposed solutions. Virtual Aggregation (VA) [I-D.ietf-grow-va] and
Aggregation in Increasing Scopes (AIS) [I-D.zhang-evolution] are
global routing proposals that introduce routing overlays with Virtual
Prefixes (VPs) to reduce the number of entries required in each
router's Forwarding Information Base (FIB) and Routing Information
Base (RIB). Routing and Addressing in Networks with Global
Enterprise Recursion (RANGER) [RFC5720] examines recursive
arrangements of enterprise networks that can apply to a very broad
set of use case scenarios [I-D.russert-rangers]. In particular,
RANGER supports encapsulation and secure redirection by treating each
layer in the recursive hierarchy as a virtual non-broadcast, multiple
access (NBMA) "link". RANGER is an architectural framework that
includes Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet]
and the Subnetwork Adaptation and Encapsulation Layer (SEAL)
(including the SEAL Control Message Protocol (SCMP))
[I-D.templin-intarea-seal] as its functional building blocks.
This document proposes an Internet Routing Overlay Network (IRON)
with goals of supporting sustainable growth while requiring no
changes to the existing routing system. IRON borrows concepts from
VA, AIS and RANGER, and further borrows concepts from the Internet
Vastly Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture
proposal along with its associated Translating Tunnel Router (TTR)
mobility extensions [TTRMOB]. Indeed, the TTR model to a great
degree inspired the IRON mobility architecture design discussed in
this document. The Network Address Translator (NAT) traversal
techniques adapted for IRON were inspired by the Simple Address
Mapping for Premises Legacy Equipment (SAMPLE) proposal
Templin Expires February 7, 2011 [Page 3]
Internet-Draft IRON August 2010
[I-D.carpenter-softwire-sample].
IRON specifically seeks to provide scalable PI addressing without
changing the current BGP [RFC4271] routing system. IRON observes the
Internet Protocol standards [RFC0791][RFC2460]. Other network layer
protocols that can be encapsulated within IP packets (e.g., OSI/CLNP
[RFC1070], etc.) are also within scope.
The IRON is a global overlay network routing system comprising
Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes
(VPs) from which End User Network (EUN) PI prefixes (EPs) are
delegated to customer sites. The IRON is motivated by a growing
customer demand for multihoming, mobility management and traffic
engineering while using stable PI addressing to avoid network
renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and
IPv6 global Internet routing systems as virtual links for tunneling
inner network protocol packets within outer IPv4 or IPv6 headers
(see: Section 3). The IRON requires deployment of a small number of
new routers that can often be simple commodity hardware platforms.
No modifications to hosts, and no modifications to most routers are
required.
Note: This document is offered in compliance with Internet Research
Task Force (IRTF) document stream procedures [RFC5743]; it is not an
IETF product and is not a standard. The views in this document were
considered controversial by the IRTF Routing Research Group (RRG) but
the RG reached a consensus that the document should still be
published. The document will undergo a period of review within the
RRG and through selected expert reviewers prior to publication. The
following sections discuss details of the IRON architecture.
2. Terminology
This document makes use of the following terms:
End User Network (EUN)
an edge network that connects an organization's devices (e.g.,
computers, routers, printers, etc.) to the Internet and possibly
also the IRON.
Internet Service Provider (ISP)
a service provider which physically connects customer EUNs to the
Internet.
Templin Expires February 7, 2011 [Page 4]
Internet-Draft IRON August 2010
Provider Aggregated (PA) prefix
a network layer address prefix delegated to an EUN by a service
provider.
Provider Independent (PI) prefix
a network layer address prefix delegated to an EUN by a third
party independently of the EUN's ISP arrangements.
Virtual Prefix (VP)
a highly-aggregated PI prefix block (e.g., an IPv4 /16, an IPv6
/20, an OSI NSAP prefix, etc.) that is owned and managed by a
Virtual Prefix Company (VPC).
Virtual Prefix Company (VPC)
a company that owns and manages a set of VPs from which it
delegates End User Network PI Prefixes (EPs) to EUNs
Master Virtual Prefix database (MVPd)
a distributed database that maintains VP-to-locator mappings for
all VPs in the IRON.
End User Network PI prefix (EP)
a more-specific PI prefix derived from a VP (e.g., an IPv4 /28, an
IPv6 /56, etc.) and delegated to an EUN by a VPC.
EP Address (EPA)
a network layer address taken from an EP address range and
assigned to the interface of an end system in an EUN.
locator
an IP address assigned to the interface of a router or end system
within a public or private network. Locators taken from public IP
address spaces are routable within the global Internet while
locators taken from private IP address spaces are routable only
within the network where the private IP addressing plan is
deployed.
Internet Routing Overlay Network (IRON)
an overlay network configured over the global Internet. The IRON
supports routing through encapsulation of inner packets with EPA
addresses within outer headers that use locator addresses.
3. The Internet Routing Overlay Network (IRON)
The Internet Routing Overlay Network (IRON) consists of IRON Routers
(IRs) that automatically tunnel the packets of end-to-end
communication sessions within encapsulating headers used for
Templin Expires February 7, 2011 [Page 5]
Internet-Draft IRON August 2010
Internetwork routing. IRs use Virtual Enterprise Traversal (VET)
[I-D.templin-intarea-vet] in conjunction with the Subnetwork
Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal]
to encapsulate inner network layer packets within outer headers as
shown in Figure 1:
+-------------------------+
| Outer headers with |
~ locator addresses ~
| (IPv4 or IPv6) |
+-------------------------+
| SEAL Header |
+-------------------------+ +-------------------------+
| Inner Packet Header | --> | Inner Packet Header |
~ with EP addresses ~ --> ~ with EP addresses ~
| (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) |
+-------------------------+ +-------------------------+
| | --> | |
~ Inner Packet Body ~ --> ~ Inner Packet Body ~
| | --> | |
+-------------------------+ +-------------------------+
Inner packet before Outer packet after
before encapsulation after encapsulation
Figure 1: Encapsulation of Inner Packets Within Outer IP Headers
VET specifies the automatic tunneling mechanisms used for
encapsulation, while SEAL specifies the format and usage of the SEAL
header as well as a set of control messages. Most notably, IRs use
SEAL to deterministically exchange and authenticate control messages
such as indications of Path Maximum Transmission Unit (PMTU)
limitations.
The IRON is manifested through a business model in which Virtual
Prefix Companies (VPCs) own and manage a set of IRs that are
distributed throughout the Internet and serve highly-aggregated
Virtual Prefixes (VPs). VPCs delegate sub-prefixes from their VPs
which they lease to customers as End User Network PI prefixes (EPs).
The customers in turn assign the EPs to their customer edge IRs which
connect their End User Networks (EUNs) to the IRON. VPCs may have no
affiliation with the ISP networks from which customers obtain their
basic connectivity. Therefore, VPCs can open for business and begin
serving their customers immediately without the need to coordinate
their activities with ISPs or with other VPCs.
The IRON requires no changes to end systems and no changes to most
routers in the Internet. Instead, the IRON comprises IRs that are
Templin Expires February 7, 2011 [Page 6]
Internet-Draft IRON August 2010
deployed either as new platforms or as modifications to existing
platforms. IRs may be deployed incrementally without disturbing the
existing Internet routing system, and act as waypoints (or "cairns")
for navigating the IRON. The functional roles for IRs are described
in the following sections.
3.1. IR[CE] - IRON Customer Edge Router
An "IR[CE]" is a Customer Edge router (or host with embedded gateway
function) that logically connects the customer's EUNs and their
associated EPs to the IRON via tunnels. IR[CE]s obtain EPs from VPCs
and use them to number subnets and interfaces within their EUNs. An
IR[CE] can be deployed on the same physical platform that also
connects the customer's EUNs to its ISPs, but it may also be a
separate router or even a singleton end system located within the
EUN. (This model applies even if the EUN connects to the ISP via a
Network Address Translator (NAT) - see Section 6.7). An IR[CE]
connects its EUNs to the IRON via tunnels as shown in Figure 2:
.-.
,-( _)-.
+--------+ .-(_ (_ )-.
| IR[CE] |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::::::::::::)-.
+--------+ (:::: The IRON ::::)
`-(::::::::::::)-'
`-(::::::)-'
Figure 2: IR[CE] Connecting EUN to the IRON
3.2. IR[VE] - IRON Virtual Prefix Company Edge Router
An "IR[VE]" is a VPC's overlay network edge router that provides
forwarding and mapping services for the EPs owned by customer
IR[CE]s. In typical deployments, a VPC will deploy many IR[VE]s
around the IRON in a globally-distributed fashion (e.g., as depicted
in Figure 3) so that IR[CE] clients can discover those that are
nearby.
Templin Expires February 7, 2011 [Page 7]
Internet-Draft IRON August 2010
+--------+ +--------+
| IR[VE] | | IR[VE] |
| Boston | | Tokyo |
+--+-----+ ++-------+
+--------+ \ /
| IR[VE] | \ ___ /
| Seattle| \ (:::)-. +--------+
+------+-+ .-(::::::::)------+ IR[VE] |
\.-(::::::::::::)-. | Paris |
(:::: The IRON ::::) +--------+
`-(::::::::::::)-'
+--------+ / `-(::::::)-' \ +--------+
| IR[VE] + | \--- + IR[VE] |
| Moscow | +----+---+ | Sydney |
+--------+ | IR[VE] | +--------+
| Cairo |
+--------+
Figure 3: IR[VE] Global Distribution Example
An IR[VE] is a customer-facing tunnel endpoint router that IR[CE]s
form bidirectional tunnels with over the IRON. Each IR[VE]
associates with the VPC's Internet-facing IR[VC]s that can forward
packets from the IRON out to the native public Internet and vice-
versa as discussed in the next section.
3.3. IR[VC] - IRON Virtual Prefix Company Core Router
An "IR[VC]" is a VPC's overlay network core router that acts as a
gateway between the IRON and the native public Internet. Each VPC
configures one or more IR[VC]s which advertise the company's VPs into
the IPv4 and/or IPv6 global Internet BGP routing systems. Each
IR[VC] associates with all of the VPC's overlay network edge routers,
either via tunnels over the IRON or via a direct interconnect (e.g.,
via an Ethernet cable, etc. ). The IR[VC] role is depicted in
Figure 4:
Templin Expires February 7, 2011 [Page 8]
Internet-Draft IRON August 2010
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-'
|
+----+---+
| IR[VC] |
+----+---+
_|_
(:::)-.
.-(::::::::)
+--------+ .-(::::::::::::)-. +--------+
| IR[VE] | (:::: The IRON ::::) | IR[VE] |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
+--------+
| IR[VE] |
+--------+
Figure 4: IR[VC] Connecting IRON to Native Internet
3.4. IR[VP] - IRON Virtual Prefix Company Combined Router
An "IR[VP]" is a VPC's overlay network router that combines the
functions of both the IR[VE] and IR[VC]. In that case, the IR[VE]
and IR[VC] functions can be thought of as "half-gateway" functions
that together comprise a unified IR[VP]. The IR[VE] and IR[VC]
functions can therefore be discussed separately even when both
functions reside within the same physical IR[VP] router as shown in
Figure 5:
Templin Expires February 7, 2011 [Page 9]
Internet-Draft IRON August 2010
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-'
|
+----------+----------+
| IR[VC] half-gateway |
+---------------------+
| IR[VE] half-gateway |
+----------+----------+
<- IR[VP] Unified Gateway ->
_|_
(:::)-.
.-(::::::::)
.-(::::::::::::)-.
(:::: The IRON ::::)
`-(::::::::::::)-'
`-(::::::)-'
Figure 5: IR[VP] Combining IR[VE] and IR[VC] Functions
4. IRON Organizational Principles
The IRON consists of the union of all VPC overlay networks worldwide.
Each such overlay network represents a distinct "patch" on the
Internet "quilt", where the patches are stitched together by tunnels
over the links, routers, bridges, etc that connect the public
Internet. When a new VPC overlay network is deployed, it becomes yet
another patch on the quilt. The IRON is therefore a composite
overlay network consisting of multiple individual patches, where each
patch can be discussed independently of all others. In particular,
each patch (i.e., each VP overlay network) can operate independently
of the other patches. (NB: each patch needs to be aware of the VPs
assigned to all other patches.)
Each VPC in the IRON maintains a set of IR[VC]s that connect its
overlay network directly to the public IPv4 and/or IPv6 Internets.
In particular, if the VPC serves IPv4 VPs the IR[VC]s must configure
locator addresses on the public IPv4 Internet, and if the VPC serves
IPv6 VPs the IR[VC]s must configure locator addresses on the public
IPv6 Internet. Each IR[VC] advertises the VPC's IPv4 VPs into the
IPv4 BGP routing system and advertises the VPC's IPv6 VPs into the
IPv6 BGP routing system. IR[VC]s will therefore receive packets with
EPA destination addresses sent by end systems in the Internet then
(re)encapsulate and forward them to the correct EPA-addressed end
systems connected to the VPC overlay network.
Templin Expires February 7, 2011 [Page 10]
Internet-Draft IRON August 2010
Each VPC also manages a set of IR[VE]s that connect its overlay
network directly to the public IPv4 and/or IPv6 Internets the same as
for IR[VC]s, except that IR[VE]s need not be BGP routers and can
often be simple commodity hardware platforms. As such, the IR[VE]
and IR[VC] functions can be deployed together on the same physical
platform as an IR[VP], or they may be deployed on separate platforms
(e.g., for load balancing purposes). Each IR[VE] maintains a working
set of IR[CE]s for which it caches EP-to-IR[CE] mappings in its
Forwarding Information Base (FIB). Each IR[VE] also in turn
propagates the list of EPs in its working set to each of the VPC's
IR[VC]s, e.g., via a dynamic routing protocol. Each IR[VE] will
therefore commonly track only the EPs for its current working set of
IR[CE]s, while each IR[VC] will maintain a full EP-to-IR[VE] mapping
table that represents reachability information for all EPs in the VPC
overlay network.
Customers establish IR[CE]s to connect their EUNs to the VPC overlay
network. Each EUN can connect to the overlay network via one or
multiple IR[CE]s as long as the multiple IR[CE]s coordinate with one
another, e.g., to mitigate EUN partitions. Unlike IR[VC]s and
IR[VE]s, IR[CE]s may use private addresses behind one or several
layers of NATs. The IR[CE] initially discovers a list of nearby
IR[VE]s through an exchange with its VPC, then forms tunnels with one
or more of the IR[VE]s through initial exchanges followed by periodic
keepalives. The IR[CE] then adds each such IR[VE] to its default
router list.
The IR[CE] forwards outbound packets from its EUNs by tunneling them
to an IR[VC]/IR[VE] that can forward them further toward their final
destination. When the IR[CE] configures a locator with the same
protocol version of its EPs, it tunnels packets with EPA destination
addresses to an IR[VC]/IR[VE] within the VPC overlay network that
manages the EUN of the final destination without involving one of the
IR[VE]s in its default router list. When the IR[CE] configures a
locator of a different protocol version than its EPs, or when it
forwards packets with non-EPA destination addresses, it instead
tunnels the packets to one of the IR[VE]s in its default router list.
If a flow of packets uses an EPA destination address, the IR[CE]/
IR[VE] tunnels the initial packets of the flow by encapsulating them
within an outer header that also uses the EPA as a destination
address. It then forwards the encapsulated packets into the public
Internet where they will be routed to an IR[VC] that owns a VP that
covers destination. Thereafter, the IR[VE]/IR[CE] may receive
redirects from the IR[VC] informing it of a more direct route via an
IR[VE] that manages the EUN. If a flow of packets uses a non-EPA
address, however, the IR[CE] tunnels them to a IR[VE] in its default
router list which will then forward them into the public Internet.
Templin Expires February 7, 2011 [Page 11]
Internet-Draft IRON August 2010
These arrangements are necessary to avoid ingress filtering issues
and to allow for generally shortest path routes.
The IRON can also be used to support VPs of network layer protocols
that cannot be routed natively in the underlying Internetwork (e.g.,
OSI/CLNP within the public Internet, IPv6 within in IPv4-only
Internetworks, IPv4 within IPv6-only Internetworks, etc.). In that
case, however, the native routing capabilities of the Internetwork
cannot be leveraged such that a more rigid structure that depends on
a globally-distributed mapping database is required. Further details
for support of IRON VPs over non-native Internetworks are discussed
in Appendix A.
5. IRON Initialization
IRON initialization entails the startup actions of IRs within the VPC
overlay network and customer EUNs. The following sections discuss
these startups procedures.
5.1. IR[VC] Initialization
Before its first operational use, each IR[VC] in a VPC overlay
network is pre-provisioned with the list of VPs that it will serve as
well as the locators for all IR[VE]s that belong to the same overlay
network. The IR[VC] is also provisioned with BGP peerings the same
as for any BGP router.
Upon startup, the IR[VC] engages in BGP routing exchanges with its
peers in the IPv4 and/or IPv6 Internets the same as for any BGP
router. It then connects to all of the IR[VE]s that service its VPs
(e.g., via a TCP connection over a two-way tunnel, via a route
reflector, etc.) for the purpose of discovering EP->IR[VE] mappings.
After the IR[VC] has thus fully populated its EP->IR[VE] mapping
information database, it is said to be "synchronized" wrt its VPs.
The IR[VC] then advertises its VPs into the IPv4 and/or IPv6 Internet
BGP routing systems and engages in ordinary packet forwarding
operations.
5.2. IR[VE] Initialization
Before its first operational use, each IR[VE] in a VPC overlay
network is pre-provisioned with the locators for all IR[VC]s that
serve the overlay network's VPs. In order to support route
optimization, the IR[VE] must also be pre-provisioned with the list
of all VPs in the IRON (i.e., and not just the VPs of it own overlay
network) so that it can discern EPA and non-EPA addresses.
Templin Expires February 7, 2011 [Page 12]
Internet-Draft IRON August 2010
Upon startup, the IR[VE] connects to all of the IR[VC]s in the
overlay network for the purpose of reporting its EP->IR[VE] mappings.
The IR[VE] then actively listens for IR[CE] customers which will
create a two-way tunnel while registering its EP prefixes. When a
new IR[CE] registers its EP prefixes, the IR[VE] informs all IR[VC]s
of the new EP additions; when an existing IR[CE] unregisters its EP
prefixes, the IR[VE] informs all IR[VC]s of the deletions.
5.3. IR[CE] Initialization
Before its first operational use, each IR[CE] must obtain one or more
EPs from a VPC along with a certificate and a public/private key pair
from the VPC that it can later use to prove ownership of its EPs.
This implies that each VPC must run its own key infrastructure to be
used only for the purpose of verifying a customer's claimed right to
use an EP. Hence, the VPC need not coordinate its key infrastructure
with any other organizations. In order to support route
optimization, the IR[CE] must also be pre-provisioned with the list
of all VPs in the IRON (i.e., and not just the VPs of this VPC) so
that it can discern EPA and non-EPA addresses.
Upon startup, the IR[CE] sends a router discovery message using an
implicit anycast procedure (see Section 6.1) to discover the nearest
IR[VC]. The IR[VC] will in turn return a list of locators of the
company's nearby IR[VE]s. (This list is analogous to the ISATAP
Potential Router List (PRL) [RFC5214].) The IR[CE] then selects a
subset of IR[VE]s from this list and tests them to determine those
that offer the best performance (see: Section 6.1). The IR[CE] then
registers its EP prefixes with one or more IR[VE]s and adds them to
its default router list.
6. IRON Operation
Following this IRON initialization, IRs engage in the steady-state
process of receiving and forwarding packets. All IRs forward
encapsulated packets over the IRON using the mechanisms of VET
[I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal], while
IR[VC]s and IR[VE]s additionally forward packets to and from the
native IPv6 and IPv4 Internets. IRs also use the SEAL Control
Message Protocol (SCMP) to coordinate with other IRs, including the
process of sending and receiving redirect messages for route
optimization. Each IR operates as specified in the following sub-
sections.
Templin Expires February 7, 2011 [Page 13]
Internet-Draft IRON August 2010
6.1. IR[CE] Operation
During its initialization phase, the IR[CE] first sends a SEAL
Control Message Protocol (SCMP) Router Solicitation (SRS) message
using an implicit anycast addressing scheme to determine the closest
IR[VC] in its VPC overlay network. In this procedure, the IR[CE]
sets the "Router Alert" bit in the SEAL header to alert the nearest
IR[VC] that this SRS message must be processed locally and not
forwarded. The IR[CE] then sets the source address of the SRS
message to one of its locator addresses and sets the destination
address of the message to one of its own EPA addresses. (If the EPA
address is of a different protocol version than the underlying
Internetwork routing system, however, the IR[CE] sets the destination
address to any EPA address of the Internetwork protocol version that
is covered by a VP owned by the VPC overlay network.) Normal
Internet routing will then convey the SRS message to the nearest
IR[VC] that advertises a VP that covers the EPA. When the IR[VC]
receives the SRS message, it notices that the Router Alert bit is set
and sends back an SCMP Router Advertisement (SRA) message that lists
the locator addresses of one or more nearby IR[VE] routers.
After the IR[CE] receives an SRS message from the nearby IR[VC]
listing the locator addresses of nearby IR[VE]s, it sends SRS test
messages to one or more of the locator addresses to elicit SRA
messages. The IR[VE] that configures the locator will include the
header of the soliciting SRS message in its SRA message so that the
IR[CE] can determine the number of hops along the forward path. The
IR[VE] also includes a metric in its SRA messages indicating its
current load average so that the IR[CE] can avoid selecting IR[VE]s
that are overloaded. The IR[VE] also includes a challenge/response
puzzle that the IR[CE] must answer if it wishes to enlist this
IR[VE]'s services.
When the IR[CE] receives these SRA messages, it can measure the round
trip time between sending the SRS and receiving the SRA as an
indication of round-trip delay. If the IR[CE] wishes the enlist the
services of a specific IR[VE] (e.g., based on the measured
performance), it then calculates the answer to the puzzle using its
keying information and sends the answer back to the IR[VE] in a new
SRS message that also contains all of the IR[CE]'s EP prefixes for
which it claims ownership. If the IR[CE] answered the puzzle
correctly, the IR[VE] will send back a new SRA message that includes
a non-zero default router lifetime and that signifies the
establishment of a two-way tunnel. (A zero default router lifetime
on the other hand signifies that the IR[VE] is currently unable to
establish a two-way tunnel, e.g., due to heavy load, due to
challenge/response failure, etc.)
Templin Expires February 7, 2011 [Page 14]
Internet-Draft IRON August 2010
Note that in the above procedure it is essential that the IR[CE]
select one and only one IR[VE]. This is to allow the VPC overlay
network mapping system to have one and only one active EP-to-IR[VE]
mapping at any point in time which shares fate with the IR[VE]
itself. If this IR[VE] fails, the IR[CE] will quickly select a new
one which will automatically update the VPC overlay network mapping
system with a new EP-to-IR[VE] mapping.
After selecting its serving IR[VE], the IR[CE] should register each
of its ISP connections with the IR[VE] in order to establish multiple
two-way tunnels for multihoming purposes. To do so, it sends
periodic SRS messages via each of its ISPs to establish additional
two-way tunnels and to keep each two-way tunnel alive. These
messages need not include challenge/response mechanisms since prefix
proof of ownership was already established in the initial exchange
and the SEAL ID in the SEAL header can be used to confirm that the
SRS message was sent by the correct IR[CE]. This implies that a
single SEAL_ID is used to represent the set of all two-way tunnels
between the IR[CE] and the IR[VE]. Therefore, there are multiple
two-way tunnels and the SEAL_ID names this "bundle" of tunnels.
If the IR[CE] ceases to receive SRA messages from its serving IR[VE]
via a specific ISP connection, it marks the IR[VE] as unreachable
from that address and therefore over that ISP connection. (The
IR[CE] must also inform its serving IR[VE] of this outage via one of
its working ISP connections.) If the IR[CE] ceases to receive SRA
messages from its serving IR[VE] via multiple ISP connections, it
marks the IR[VE] as unusable and quickly attempts to establish a
connection with a new IR[VE]. The act of establishing the connection
with a new serving IR[VE] will automatically purge the stale mapping
state associated with the old serving IR[VE].
When an end system in an EUN has a packet to send, the packet is
forwarded through the EUN via normal routing until it reaches the
IR[CE], which then tunnels the packet either to its serving IR[VE]s
or to an IR[VC]/IR[VE] associated with the packet's destination. In
particular, if the IR[CE] does not configure a locator of the same
protocol version as the packet's destination or if the destination
address is a non-EPA address, the IR[CE] encapsulates the packet in
an outer header with its locator as the source address and the
locator of its serving IR[VE]s as the destination address.
Otherwise, the IR[CE] encapsulates the packet in an outer header with
its locator as the source address and the destination address of the
inner packet copied into the destination address of the outer packet.
The IR[CE] then forwards the encapsulated packet via one of its ISP
connections, where normal Internet routing will convey it to the
correct tunnel far end.
Templin Expires February 7, 2011 [Page 15]
Internet-Draft IRON August 2010
The IR[CE] uses the mechanisms specified in VET and SEAL to
encapsulate each forwarded packet. The IR[CE] further uses the SCMP
protocol to coordinate with other IRs, including accepting redirect
messages that indicate a better next hop. When the IR[CE] receives
an SCMP redirect, it checks the identification field of the
encapsulated message to verify that the redirect corresponds to a
packet that it had previously sent and accepts the redirect if there
is a match. Thereafter, subsequent packets forwarded by the source
IR[CE] will follow a route-optimized path.
6.2. IR[VE] Operation
After an IR[VE] is initialized, it responds to SRSs from IR[CE]s by
sending SRAs as described in Section 6.1. When the IR[VE] receives
an SRS message from a potential IR[CE], it sends back an SRA message
with a challenge/response puzzle. The IR[CE] in turn sends an SRS
message with an answer to the puzzle. If this authentication fails,
the IR[VE] discards the message. Otherwise, it creates tunnel state
for this new IR[CE], records the EPs in its FIB, and records the
locator address from the SCMP message as the link-layer address of
the next hop. The IR[VE] next sends an SRA message back to the
IR[CE] to complete the tunnel establishment.
When the IR[VE] receives an encapsulated packet from one of its
IR[CE] tunnel endpoints, it decapsulates the packet and examines the
inner destination address. If the inner destination address is an
EPA, the IR[VE] re-encapsulates the packet, sets the outer source
address of the packet to one of its own locator address, sets the
outer destination address of the packet to the inner destination
address then forwards the encapsulated packet into the Internet via a
default or more-specific route. If the inner destination address is
not an EPA, however, the IR[VE] either forwards it unencapsulated
into the Internet if it is able to do so without loss due to ingress
filtering or tunnels the packet over the IRON to an IR[VC] within its
VPC overlay network which will then decapsulate the packet and
forward it into the Internet.
When the IR[VE] receives an encapsulated packet from the Internet, if
the inner destination address matches an EP in its FIB the IR[VE] 'A'
re-encapsulates the packet using VET/SEAL and forwards it to its
client IR[CE] 'B' which in turn decapsulates the packet and forwards
it to the correct end system in the EUN. If 'B' has left notice with
'A' that it has moved to a new IR[VE] 'C', however, 'A' will instead
forward the re-encapsulated packet to 'C' and also send an SCMP
redirect message back to the source of the packet. In this way,
IR[CE]s can change between IR[VE]s (e.g., due to mobility events)
without exposing packets to loss.
Templin Expires February 7, 2011 [Page 16]
Internet-Draft IRON August 2010
6.3. IR(VC) Operation
After an IR[VC] has synchronized its VPs (see: Section 5.1) it
advertises the full set of the company's VP's into the IPv4 and/or
IPv6 Internet BGP routing systems. The VPs will be represented as
ordinary routing information in the BGP, and any packets originating
from the IPv4 or IPv6 Internet destined to an EPA covered by one of
the VPs will be forwarded into the VPC's overlay network by an
IR[VC].
When an IR[VC] receives a packet from the Internet destined to an EPA
covered by one of its VPs, it looks in its FIB for a matching EP to
discover the locator of the serving IR[VE], then examines the packet
format.
If the packet is not a SEAL-encapsulated packet, the IR[VC] simply
encapsulates the packet with its own locator as the outer source
address and the locator of the IR[VE] as the outer destination
address and forwards the packet to the IR[VE].
If the packet is a SEAL-encapsulated packet, however, the IR[VC]
examines the "Router Alert" flag in the SEAL header. If the Router
Alert flag is set, and the packet encodes an SRS message, the IR[VC]
sends an SRA message back to the source listing the locator addresses
of nearby IR[VE] routers. In all cases when the Route Alert flag is
set, the IR[VC] next discards the packet.
For all other SEAL-encapsulated packets, the IR[VC] sends an SCMP
redirect message back to the source of the packet with the locator of
the serving IR[VE] as the redirected target. The source and
destination addresses of the SCMP redirect message use the outer
destination and source addresses of the original packet,
respectively. This arrangement is necessary to allow the redirect
messages to flow through any NATs on the path.
After sending a redirect message, the IR[VC] then rewrites the outer
source address of the packet to one of its own locators, rewrites the
outer destination address of the packet to the locator of the IR[VE]
and forwards the (re)encapsulated packet to the IR[VE]. In this way,
the IR[VC] "bends" the initial encapsulated packets of a flow in
flight to deflect them toward a correct IR[VE], while subsequent
packets in the flow will be sent directly to the IR[VE] after the
source receives a redirect.
6.4. IRON Reference Operating Scenarios
The IRON is used to support communications when one or both hosts are
located within EP-addressed EUNs regardless of whether the EPs are
Templin Expires February 7, 2011 [Page 17]
Internet-Draft IRON August 2010
provisioned by the same VPC or by different VPCs . When both hosts
are within IRON EUNs, route optimizations that eliminate unnecessary
IR[VC]s from the path are possible. When only one host is within an
IRON EUN, however, route optimization cannot be used.
The following sections discuss the two scenarios. Note that it is
sufficient to discuss the scenarios in a unidirectional fashion,
i.e., by tracing packet flows only in the forward direction from the
source host to destination host. The reverse direction can be
considered separately, and incurs the same considerations as for the
forward direction.
6.4.1. Both Hosts Within IRON EUNs
When both hosts are within EP-addressed EUNs, the initial packets of
the flow may need to involve an IR[VC] of the destination host but
route optimization can eliminate the IR[VC] from the path for
subsequent packets. The two sub-scenarios that exist occur based on
whether or not the IR[CE] of the source host configures a locator of
the same version as the packet. The sub-cases are discussed in the
following sections.
6.4.1.1. IR[CE] of Source Host Configures a Locator of the Same
Protocol Version as the EPA
Figure 6 shows the flow of initial packets from host A to host B
within two EP-addressed EUNs when the IR[CE] of the source host A
configures a locator of the same protocol version as the inner
packet:
Templin Expires February 7, 2011 [Page 18]
Internet-Draft IRON August 2010
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +=================+ _ +========+ )-.
.( // (_|| Internet|| _) || ).
.( // ||-(______)|| vv ).
.( // || || +------------+ ).
( // vv || | IR[VE](B) |====+ )
( // +------------+ +------------+ \\ )
( // .-. | IR[VC](B) | .-. \\ )
( //,-( _)-. +------------+ ,-( _)-\\ )
( .||_ (_ )-. / .-(_ (_ ||. )
( _|| ISP A .) / (redirect) (__ ISP B ||_))
( ||-(______)-' / `-(______)|| )
( || | / | vv )
( +-----+-----+ <=/ +-----+-----+ )
| IR[CE](A) | | IR[CE](B) |
+-----+-----+ The IRON +-----+-----+
| ( (Overlaid on the native Internet) ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 6: EPA/Locator Matching Scenario Before Redirects
In this scenario, host A sends its packets with destination address B
on its network interface connected to EUN A. (This interface could be
a physical interface such as an Ethernet NIC, an ISATAP tunnel
virtual interface with IR[CE](A) as a PRL router, etc.) Routing with
EUN A will direct the packets to IR[CE](A) as a default router for
the EUN which then uses VET and SEAL to encapsulate them in outer
headers with its locator address as the outer source address and B as
the outer destination address (i.e., the inner and outer destination
address will be the same). IR[CE](A) then simply releases the
encapsulated packets into its ISP network connection that provided
its locator. The ISP will release the packet into the Internet
without filtering since the (outer) source address is topologically
correct. Once the packets have been released into the Internet,
routing will direct them to the nearest IR[VC] that advertises
reachability to a VP that covers destination address B (namely,
IR[VC](B)).
Templin Expires February 7, 2011 [Page 19]
Internet-Draft IRON August 2010
IR[VC](B) will receive the encapsulated packets from IR[CE](A) then
check its FIB to discover an entry that covers destination address B
with IR[VE](B) as the next hop. IR[VC](B) will then issue SCMP
redirect messages to inform IR[CE](A) that IR[VE](B) is a better next
hop (*). IR[VC](B) then rewrites the outer source address of the
encapsulated packets to its own locator address and rewrites the
destination address of the encapsulated packets to the locator
address of IR[VE](B). IR[VC](B) then releases these (re)encapsulated
packets into the native Internet, where routing will direct them to
IR[VE](B).
IR[VE](B) will receive the encapsulated packets from IR[VC](B) then
check its FIB to discover an entry that covers destination address B
with IR[CE](B) as the next hop. IR[VE](B) then rewrites the outer
source address of the packets to its own locator address and rewrites
the outer destination address to the locator address of IR[CE](B).
(If IR[CE](B) is located behind a NAT, IR[VE](B) also rewrites the
UDP destination port number in the encapsulating header in order to
support NAT traversal.) IR[VE](B) then tunnels these
(re)encapsulated packets to IR[CE](B), which will in turn decapsulate
the packets and forward the inner packets to host B via EUN B.
(*) Note that after the initial flow of packets, IR[CE](A) will have
received one or more SCMP redirect messages from IR[VC](B) informing
it of IR[VE](B) as a better next hop. Thereafter, IR[CE](A) will
forward its encapsulated packets directly to the locator address of
IR[VE](B) without involving IR[VC](B) as shown in Figure 7:
Templin Expires February 7, 2011 [Page 20]
Internet-Draft IRON August 2010
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +=============> .-(_ (_ )-.======+ )-.
.( // (__ Internet _) || ).
.( // `-(______)-' vv ).
.( // +------------+ ).
( // | IR[VE](B) |====+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
( _|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ The IRON +-----+-----+ )
| IR[CE](A) | (Overlaid on the native Internet) | IR[CE](B) |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 7: EPA/Locator Matching Scenario After Redirects
6.4.1.2. IR[CE] of Source Host Configures a Locator of a Different
Protocol Version than the EPA
Figure 8 shows the flow of initial packets from host A to host B
within two EP-addressed EUNs when the IR[CE] of source host A cannot
configure a locator of the same protocol version as the inner network
layer protocol. For example, if the IR[CE] configures only an IPv4
locator, but EUN A uses IPv6 natively, IR[CE] is obliged to forward
its packets through its serving IR[VE].
Templin Expires February 7, 2011 [Page 21]
Internet-Draft IRON August 2010
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +========+(_ (_ +=====+ )-.
.( || (_|| Internet ||_) || ).
.( || ||-(______)-|| vv ).
.( +--------++--+ || || +------------+ ).
( +==>| IR[VE](A) | vv || | IR[VE](B) |====+ )
( // +------------+ +--++----++--+ +------------+ \\ )
( // .-. | IR[VC](B) | .-. \\ )
( //,-( _)-. +------------+ ,-( _)-\\ )
( .||_ (_ )-. / .-(_ (_ ||. )
( _|| ISP A .) / (redirect) (__ ISP B ||_))
( ||-(______)-' / `-(______)|| )
( || | / | vv )
( +-----+-----+ <=/ +-----+-----+ )
| IR[CE](A) | | IR[CE](B) |
+-----+-----+ The IRON +-----+-----+
| ( (Overlaid on the native Internet) ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 8: EPA/Locator Mis-matching Scenario Before Redirects
In this scenario, host A sends its packets with destination address B
on its network interface connected to EUN A. (This interface could be
a physical interface such as an Ethernet NIC, an ISATAP tunnel
virtual interface with IR[CE](A) as a PRL router, etc.) Routing with
EUN A will direct the packets to IR[CE](A) as a default router for
the EUN which then uses VET and SEAL to encapsulate them in outer
headers with its locator address as the outer source address and the
locator address of its serving IR[VE](A) as the outer destination
address. IR[CE](A) then simply releases the encapsulated packets
into its ISP network connection that provided its locator. The ISP
will release the packets into the Internet without filtering since
the (outer) source address is topologically correct. Once the
packets have been released into the Internet, routing will direct
them to IR[VE](A).
IR[VE](A) receives the encapsulated packets from IR[CE](A) then
rewrites the outer source address to its own locator address and
Templin Expires February 7, 2011 [Page 22]
Internet-Draft IRON August 2010
rewrites the outer destination address to B (i.e., the inner and
outer destination address will be the same). IR[VE](A) then releases
the (re)encapsulated packets into the Internet where routing will
direct them to IR[VC](B) which advertises the VP that covers B.
IR[VC](B) will receive the encapsulated packets from IR[VE](A) then
check its FIB to discover an entry that covers destination address B
with IR[VE](B) as the next hop. IR[VC](B) will then issue SCMP
redirect messages to inform IR[VE](A) that IR[VE](B) is a better next
hop (*). IR[VC](B) then rewrites the outer source address of the
encapsulated packets to its own locator address and rewrites the
outer destination address to the locator address of IR[VE](B).
IR[VC](B) then releases these (re)encapsulated packets into the
Internet, where routing will direct them to IR[VE](B).
IR[VE](B) will receive the encapsulated packets from IR[VC](B) then
check its FIB to discover an entry that covers destination address B
with IR[CE](B) as the next hop. IR[VE](B) then rewrites the outer
source address of the packets to its own locator address and rewrites
the outer destination address to the locator address of IR[CE](B).
(If IR[CE](B) is located behind a NAT, then IR[VE](B) also rewrites
the UDP destination port number in the encapsulating header in order
to support NAT traversal.) IR[VE](B) then releases these
(re)encapsulated packets into the Internet, where routing will direct
them to IR[CE](B). IR[CE](B) will in turn decapsulate the packets
and forward the inner packets to host B via EUN B.
(*) Note that after the initial flow of packets, IR[VE](A) will have
received one or more SCMP redirect messages from IR[VC](B) informing
it of IR[VE](B) as a better next hop. Thereafter, IR[VE](A) will
forward its encapsulated packets directly to the locator address of
IR[VE](B) without involving IR[VC](B) as shown in Figure 9:
Templin Expires February 7, 2011 [Page 23]
Internet-Draft IRON August 2010
________________________________________
.-( .-. )-.
.-( ,-( _)-. )-.
.-( +====> .-(_ (_ )-.======+ )-.
.( || (__ Internet _) || ).
.( || `-(______)-' vv ).
.( +--------++--+ +------------+ ).
( +==>| IR[VE](A) | | IR[VE](B) |====+ )
( // +------------+ +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
( _|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ The IRON +-----+-----+ )
| IR[CE](A) | (Overlaid on the native Internet) | IR[CE](B) |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ IRON EUN B )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 9: EPA/Locator Mis-matching Scenario After Redirects
6.4.2. Mixed IRON and Non-IRON Hosts
When one host is within an IRON EUN and the other is in a non-IRON
EUN (i.e., one that connects to the native Internet instead of the
IRON), the IR elements involved depend on the packet flow directions.
The cases are described in the following sections:
6.4.2.1. From IRON Host A to Non-IRON Host B
Figure 10 depicts the IRON reference operating scenario for packets
flowing from Host A in an IRON EUN to Host B in a non-IRON EUN:
Templin Expires February 7, 2011 [Page 24]
Internet-Draft IRON August 2010
_________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | IR[VC](A) |--------------+ )-.
.( +------------+ \ ).
.( +=======>| IR[VE](A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( || | )-. v | )
( +-----+ ----+ )-. +-----+-----+ )
| IR[CE](A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ non-IRON EUN )
`-(______)-' `-(___B___)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 10: From IRON Host A to Non-IRON Host B
In this scenario, host A sends its packets with destination address B
on its network interface connected to IRON EUN A. (This interface
could be a physical interface such as an Ethernet NIC, an ISATAP
tunnel virtual interface with IR[CE](A) as a PRL router, etc.)
Routing with EUN A will direct the packets to IR[CE](A) as a default
router for the EUN which then uses VET and SEAL to encapsulate them
in outer headers with its locator address as the outer source address
and the locator address of a serving IR[VE] (i.e., IR[VE](A) as the
outer destination address. The ISP will pass the packets without
filtering since the (outer) source address is topologically correct.
Once the packets have been released into the native Internet, routing
will direct them to IR[VE](A).
IR[VE](A) receives the encapsulated packets from IR[CE](A) then
forwards them to IR[VC](A) which simply decapsulates them and
releases the unencapsulated packets into the Internet. Once the
packets are released into the Internet, routing will direct them to
Templin Expires February 7, 2011 [Page 25]
Internet-Draft IRON August 2010
the final destination B. (Note that in this diagram IR[VE](A) and
IR[VC](A) are depicted as two halves of a unified IR[VP](A). In that
case, the "forwarding" between IR[VE](A) and IR[VC](A) is a zero-
instruction imaginary operation.)
Note that this scenario always involves an IR[VC](A) owned by the VPC
that provides service to IRON EUN A. This scenario therefore imparts
a cost that would need to be borne by either the VPC or its
customers.
6.4.2.2. From Non-IRON Host B to IRON Host A
Figure 10 depicts the IRON reference operating scenario for packets
flowing from Host B in an Non-IRON EUN to Host A in an IRON EUN:
_______________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | IR[VC](A) |<-------------+ )-.
.( +------------+ \ ).
.( +========| IR[VE](A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // The IRON ) \ )
( // .-. ) \ .-. )
( //,-( _)-. ) \ ,-( _)-. )
( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. )
( _|| ISP A ) ) (_ | ISP B ))
( ||-(______)-' ) |-(______)-' )
( vv | )-. | | )
( +-----+ ----+ )-. +-----+-----+ )
| IR[CE](A) |)-. | Router B |
+-----+-----+ +-----+-----+
| ( ) |
.-. .-(____________________________________)-. .-.
,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN A ) (_ non-IRON EUN )
`-(______)-' `-(___B___)-'
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 11: From Non-IRON Host B to IRON Host A
In this scenario, host B sends its unencapsulated packets with
destination address A on its network interface connected to non-IRON
Templin Expires February 7, 2011 [Page 26]
Internet-Draft IRON August 2010
EUN B. Routing will direct the packets to IR[VC](A) which then
forwards them to IR[VE](A) using encapsulation if necessary. (Note
that in this diagram IR[VE](A) and IR[VC](A) are depicted as two
halves of a unified IR[VP](A). In that case, the "forwarding"
between IR[VE](A) and IR[VC](A) is a zero-instruction imaginary
operation.)
IR[VE](A) will then check its FIB to discover an entry that covers
destination address A with IR[CE](A) as the next hop. IR[VE](A) then
encapsulates the packets using its own locator address as the outer
source address and the locator address of IR[CE](A) as the outer
destination address. IR[VE](A) then releases these (re)encapsulated
packets into the Internet, where routing will direct them to
IR[CE](A). IR[CE](A) will in turn decapsulate the packets and
forward the inner packets to host A via its network interface
connected to IRON EUN A. (This interface could be a physical
interface such as an Ethernet NIC, an ISATAP tunnel virtual interface
with Host A as the next-hop neighbor, etc.).
Note that this scenario always involves an IR[VC](A) owned by the VPC
that provides service to IRON EUN A. This scenario therefore imparts
a cost that would need to be borne by either the VPC or its
customers.
6.5. Mobility, Multihoming and Traffic Engineering Considerations
While IR[VE]s and IR[VC]s can be considered as fixed infrastructure,
IR[CE]s may need to move between different network points of
attachment, connect to multiple ISPs, or explicitly manage their
traffic flows. The following sections discuss mobility, multi-homing
and traffic engineering considerations for IR[CE]s.
6.5.1. Mobility Management
When an IR[CE] changes its network point of attachment (e.g., due to
a mobility event), it configures one or more new locators. If the
IR[CE] has not moved far away from its previous network point of
attachment, it simply informs its serving IR[VE] of any locator
additions or deletions. This operation is performance-sensitive, and
should be conducted immediately to avoid packet loss.
If the IR[CE] has moved far away from its previous network point of
attachment, however, it re-issues the implicit anycast discovery
procedure described in Section 6.1 to discover whether its candidate
set of serving IR[VE]s has changed. If the IR[CE]'s current serving
IR[VE] is also included in the new list received from the VPC, this
serves as indication that the IR[CE] has not moved far enough to
warrant changing to a new serving IR[VE]. Otherwise, the IR[CE] may
Templin Expires February 7, 2011 [Page 27]
Internet-Draft IRON August 2010
wish to move to a new serving IR[VE] in order to maintain optimal
routing. This operation is not performance-critical, and therefore
can be conducted over a matter of seconds/minutes instead of
milliseconds/microseconds.
To move to a new IR[VE], the IR[CE] first engages in the EP
registration process with the new IR[VE] and maintains the
registrations through periodic SRS/SRA exchanges the same as
described in Section 6.1. The IR[CE] then informs its former IR[VE]
that it has moved by providing it with the locator address of the new
IR[VE]. The IR[CE] then discontinues the SRS/SRA keepalive process
with the former IR[VE], which will garbage-collect the stale FIB
entries when their lifetime expires. This will allow the former
IR[VE] to redirect existing correspondents to the new IR[VE] so that
no packets are lost.
6.5.2. Multihoming
An IR[CE] may register multiple locators with its serving IR[VE]. It
can assign metrics with its registrations to inform its IR[VE] of
preferred locators, and can select outgoing locators according to its
local preferences. Multihoming is therefore naturally supported.
6.5.3. Inbound Traffic Engineering
An IR[CE] can dynamically adjust the priorities of its prefix
registrations with its serving IR[VE] in order to influence inbound
traffic flows. It can also change between serving IR[VE]s when
multiple IR[VE]s are available, but should strive for stability in
its IR[VE] selection in order to limit routing churn.
6.5.4. Outbound Traffic Engineering
An IR[CE] can select outgoing locators, e.g., based on current QoS
considerations.
6.6. Renumbering Considerations
As better link layer technologies and service plans emerge, customers
will be motivated to select their service providers through healthy
competition between ISPs. If a customer's EUN addresses are tied to
a specific ISP, however, the customer may be forced to undergo a
painstaking EUN renumbering process if it wishes to changes to a
different ISP [RFC4192][RFC5887].
When a customer obtains EP prefixes from a VPC, it can change between
ISPs seamlessly and without need to renumber. If the VPC itself
applies unreasonable costing structures for use of the EPs, however,
Templin Expires February 7, 2011 [Page 28]
Internet-Draft IRON August 2010
the customer may be compelled to seek a different VPC and would again
be required to confront a renumbering scenario. The IRON approach to
renumbering avoidance therefore depends on VPCs conducting ethical
business practices with reasonable rates.
6.7. NAT Traversal Considerations
The Internet today consists of a global public IPv4 routing and
addressing system with non-IRON EUNs that use either public or
private IPv4 addressing. The latter class of EUNs connect to the
public IPv4 Internet via Network Address Translators (NATs). When an
IR[CE] is located behind a NAT, its selects IR[VE]s using the same
procedures as for IR[CE]s with public addresses, i.e., it will send
SRS messages to IR[VE]s in order to get SRA messages in return. The
only requirement is that the IR[CE] must configure its SEAL
encapsulation to use a transport protocol that supports NAT
traversal, namely UDP.
Since the IR[VE] maintains state about its IR[CE] customers, it can
discover locator information for each IR[CE] by examining the UDP
port number and IPv4 address in the outer headers of SRS messages.
When there is a NAT in the path, the UDP port number and IPv4 address
in the SRS message will correspond to state in the NAT box and might
not correspond to the actual values assigned to the IR[CE]. The
IR[VE] can then encapsulate packets destined to hosts serviced by the
IR[CE] within outer headers that use this IPv4 address and UDP port
number. The NAT box will receive the packets, translate the values
in the outer headers to match those assigned to the IR[CE], then
forward the packets to the IR[CE].
6.8. Nested EUN Considerations
Each IR[CE] configures a locator that may be taken from an ordinary
non-EPA address assigned by an ISP or from an EPA address taken from
an EP assigned to another IR[CE]. In that case, the IR[CE] is said
to be "nested" within the EUN of another IR[CE].
For example, assume a configuration in which IR[CE](A) configures a
locator EPA(B) taken from the EP assigned to EUN(B). IR[CE](B) in
turn configures a locator EPA(C) taken from the EP assigned to
EUN(C). Finally, IR[CE](C) assigns a locator ISP(D) taken from a
non-EPA address delegated by an ordinary ISP(D). Using this example,
the "nested-IRON" case must be examined in which a host A which
configures the address EPA(A) within EUN(A) exchanges packets with
host Z located elsewhere in the Internet. The example configuration
is depicted in Figure 12:
Templin Expires February 7, 2011 [Page 29]
Internet-Draft IRON August 2010
.-.
EPA(D) ,-( _)-.
+-----------+ .-(_ (_ )-.
| IR[CE](C) |--(_ ISP(D) )
+-----+-----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN(C) ) e `-(______)- +--------+
`-(______)-' l ___ | Host Z |
| EPA(C) s => (:::)-. +--------+
+-----+-----+ .-(::::::::)
| IR[CE](B) | .-(::::::::::::)-.
+-----+-----+ (:::: The IRON ::::)
| `-(::::::::::::)-'
.-. `-(::::::)-'
,-( _)-.
.-(_ (_ )-. +-----------------+
(_ EUN(B) ) | IR[VP/VC/VE]'s] |
`-(______)-' +-----------------+
| EPA(B)
+-----+-----+
| IR[CE](A) |
+-----------+
|
.-.
,-( _)-. EPA(A)
.-(_ (_ )-. +--------+
(_ EUN(A) )---| Host A |
`-(______)-' +--------+
Figure 12: Nested EUN Example
The two cases of host A sending packets to host Z, and host Z sending
packets to host A, must be considered separately as described below:
6.8.1. Host A Sends Packets to Host Z
There are two distinct cases of Host A sending packets to Host Z
which are dependent upon whether Z is an EPA or non-EPA address. The
two cases are discussed below:
6.8.1.1. Nested IRON Example When Z Configures an EPA Address
Host A first forwards a packet with source address EPA(A) and
destination address EPA(Z) into EUN(A). Routing within EUN(A) will
direct the packet to IR[CE](A), which encapsulates it in an outer
Templin Expires February 7, 2011 [Page 30]
Internet-Draft IRON August 2010
header with EPA(B) as the outer source address and EPA(Z) as the
outer destination address then forwards the encapsulated packet into
EUN(B). Routing within EUN[B] will direct the packet to IR[CE](B),
which encapsulates it in an outer header with EPA(C) as the outer
source address and EPA(Z) as the outer destination address then
forwards the encapsulated packet into EUN(C). Routing within EUN(C)
will direct the packet to IR[CE](C), which encapsulates it in an
outer header with ISP(D) as the outer source address and EPA(Z) as
the outer destination address. IR[CE](C) then sends this "triple-
encapsulated" packet into the ISP(D) network, where it will be routed
into the Internet to an IR[VC](Z) that advertises a VP that covers
destination address EPA(Z).
When IR[VC](Z) receives the "triple-encapsulated" packet, it consults
its FIB to determine that IR[VE](Z) is the serving router for EP(Z).
It then (re)encapsulates the packet by changing the outer source
address to its own locator address and the outer destination address
to the locator address for IR[VE](Z). It also sends a redirect
message back to IR[CE](C) as normal. When IR[VE](Z) receives the
"triple-encapsulated" packet, it strips off all outer layers of
encapsulation and (re)encapsulates the inner packet using its own
locator address as the source address and the locator address of
IR[CE](Z) as the destination address. IR[VE](Z) then tunnels the
packet to IR[CE](Z), which decapsulates the packet and forwards it to
host Z.
The key architectural requirement derived from this case is that each
IR[VE] must iteratively decapsulate each layer of a multi-
encapsulated packet when the outer destination address matches an EPA
assigned to one of its IR[CE] customers. When the final such layer
of encapsulation is reached, the IR[VE] must (re)encapsulate the
packet and forward it to the correct customer IR[CE]. This class of
packets can be considered as "inbound" wrt the IR[VE]'s client
customer EUNs.
6.8.1.2. Nested IRON Example when Z Configures a non-EPA Address
Host A first forwards a packet with source address EPA(A) and
destination address Z into EUN(A). Routing within EUN(A) will direct
the packet to IR[CE](A), which encapsulates it in an outer header
with EPA(B) as the outer source address and IR[VE](A) as the outer
destination address then forwards the encapsulated packet into
EUN(B). (Note that IR[CE](A) must forward this packet via its
serving IR[VE](A) for reasons explained in Section 6.4.2). Routing
within EUN[B] will direct the packet to IR[CE](B), which encapsulates
it in an outer header with EPA(C) as the outer source address and
IR[VE](B) as the outer destination address then forwards the
encapsulated packet into EUN(C). Routing within EUN(C) will direct
Templin Expires February 7, 2011 [Page 31]
Internet-Draft IRON August 2010
the packet to IR[CE](C), which encapsulates it in an outer header
with ISP(D) as the outer source address and IR[VE](C) as the outer
destination address. IR[CE](C) then sends this "triple-encapsulated"
packet into its ISP network, where it will be routed to IR[VE](C).
To ease in discussion of this case, now consider that each IR[VE]
named above is half of a unified IR[VP] that combines both the IR[VC]
and IR[VE] functions. With this simplification in mind, when
IR[VP](C) receives the "triple-encapsulated" packet, it removes the
outermost layer of encapsulation and forwards the packet into the
Internet where Internet routing will direct it to IR[VP](B).
IR[VP](B) in turn removes the next layer of encapsulation and
forwards the packet into the Internet where Internet routing will
direct it to IR[VP](A). IR[VP](A) will finally remove the final
layer of encapsulation and forward the packet into the Internet where
Internet routing will direct it to host Z.
The key architectural requirement derived from this case is that each
IR[VP] must iteratively decapsulate each layer of a multi-
encapsulated packet when the outer destination address is one of its
own locator addresses. When the final such layer of encapsulation is
reached, the IR[VP] forwards the packet into the Internet. This
class of packets can be considered as "outbound" wrt the IR[VP]'s
client customer EUNs.
6.8.2. Host Z Sends Packets to Host A
Whether or not host Z configures an EPA address, its packets destined
to Host A will eventually reach IR[VE](A). IR[VE](A) will have a
mapping that lists IR[CE](A) as the next hop toward EPA(A).
IR[VE](A) will then encapsulate the packet with EPA(B) as the outer
destination address and forward the packet into the Internet.
Internet routing will convey this once-encapsulated packet to
IR[VE](B) which will have a mapping that lists IR[CE](B) as the next
hop toward EPA(B). IR[VE](B) will then encapsulate the packet with
EPA(C) as the outer destination address and forward the packet into
the Internet. Internet routing will then convey this twice-
encapsulated packet to IR[VE](C) which will have a mapping that lists
IR[CE](C) as the next hop toward EPA(C). IR[VE](C) will then
encapsulate the packet with ISP(D) as the outer destination address
and forward the packet into the Internet. Internet routing will then
convey this triple-encapsulated packet to IR[CE](C).
When the triple-encapsulated packet arrives at IR[CE](C), it strips
the outer layer of encapsulation and forwards the twice-encapsulated
packet to EPA(C) which is the locator address of IR[CE](B). When
IR[CE](B) receives the twice-encapsulated packet, it strips the outer
layer of encapsulation and forwards the once-encapsulated packet to
Templin Expires February 7, 2011 [Page 32]
Internet-Draft IRON August 2010
EPA(B) which is the locator address of IR[CE](A). When IR[CE](A)
receives the once-encapsulated packet, it strips the outer layer of
encapsulation and forwards the unencapsulated packet to EPA(A) which
is the host address of host A.
The key architectural requirement derived from this case is that each
IR[CE] must decapsulate only the outermost layer of a multi-
encapsulated packet when the outer destination address matches an EPA
assigned to a device in its EUN. This class of packets can be
considered as "inbound" wrt the IR[CE]'s EUNs. The outbound cases
are discussed in Section 6.8.1
7. Additional Considerations
Considerations for the scalability of Internet Routing due to
multihoming, traffic engineering and provider-independent addressing
are discussed in [I-D.narten-radir-problem-statement]. Route
optimization considerations for mobile networks are found in
[RFC5522].
8. Related Initiatives
IRON builds upon the concepts RANGER architecture [RFC5720], and
therefore inherits the same set of related initiatives.
Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in
Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for
the Virtual Prefix concepts.
Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has
contributed valuable insights, including the use of real-time
mapping. The use of IR[VE]s as mobility anchor points is directly
influenced by Ivip's associated TTR mobility extensions [TTRMOB].
Numerous publications have proposed NAT traversal techniques. The
NAT traversal techniques adapted for IRON were inspired by the Simple
Address Mapping for Premises Legacy Equipment (SAMPLE) proposal
[I-D.carpenter-softwire-sample].
9. IANA Considerations
There are no IANA considerations for this document.
Templin Expires February 7, 2011 [Page 33]
Internet-Draft IRON August 2010
10. Security Considerations
Security considerations that apply to tunneling in general are
discussed in [I-D.ietf-v6ops-tunnel-security-concerns]. Additional
considerations that apply also to IRON are discussed in RANGER
[RFC5720], VET [I-D.templin-intarea-vet] and SEAL
[I-D.templin-intarea-seal].
IR[CE]s require a means for securely registering their EP-to-locator
bindings with their VPC. Each VPC provides its customer IR[CE]s with
a secure means for registering and re-registering their mappings.
11. Acknowledgements
This ideas behind this work have benefited greatly from discussions
with colleagues; some of which appear on the RRG and other IRTF/IETF
mailing lists. Mohamed Boucadair, Wesley Eddy, Dae Young Kim and
Robin Whittle provided review input. Eric Fleischman pointed out the
opportunity to leverage anycast for discovering topologically-close
serving IR[VE]s.
12. References
12.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.
12.2. Informative References
[BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes,
http://bgpmon.net/stat.php", June 2010.
[I-D.carpenter-softwire-sample]
Carpenter, B. and S. Jiang, "Legacy NAT Traversal for
IPv6: Simple Address Mapping for Premises Legacy Equipment
(SAMPLE)", draft-carpenter-softwire-sample-00 (work in
progress), June 2010.
[I-D.ietf-grow-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-ietf-grow-va-02 (work in progress), March 2010.
Templin Expires February 7, 2011 [Page 34]
Internet-Draft IRON August 2010
[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-02 (work in
progress), March 2010.
[I-D.narten-radir-problem-statement]
Narten, T., "On the Scalability of Internet Routing",
draft-narten-radir-problem-statement-05 (work in
progress), February 2010.
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-05 (work in progress),
July 2010.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-16 (work in
progress), July 2010.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-16 (work in progress),
July 2010.
[I-D.whittle-ivip-arch]
Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
Architecture", draft-whittle-ivip-arch-04 (work in
progress), March 2010.
[I-D.zhang-evolution]
Zhang, B. and L. Zhang, "Evolution Towards Global Routing
Scalability", draft-zhang-evolution-02 (work in progress),
October 2009.
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as
a subnetwork for experimentation with the OSI network
layer", RFC 1070, February 1989.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Templin Expires February 7, 2011 [Page 35]
Internet-Draft IRON August 2010
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code
Point (ICP) Assignments for NSAP Addresses", RFC 4548,
May 2006.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
Route Optimization Requirements for Operational Use in
Aeronautics and Space Exploration Mobile Networks",
RFC 5522, October 2009.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC5743] Falk, A., "Definition of an Internet Research Task Force
(IRTF) Document Stream", RFC 5743, December 2009.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for
Core-Edge Separation Solutions to the Internet's Routing
Scaling Problem,
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf",
August 2008.
Appendix A. IRON VPs Over Non-Native Internetworks
The IRON architecture leverages the native Internet routing system by
providing generally shortest-path routing when EPAs are taken from
VPs that are routable. When the VPs are not routable within the
native underlying Internetwork, however (e.g., when OSI/NSAP
[RFC4548] VPs are used within a private IPv4 Internetwork) packets
with EPA addresses covered by the VPs must be carried solely via
tunnels within the IRON. In such an environment, the IR[VC] role is
deprecated since there is no native underlying Internetwork to
support VP routing. This restricted model therefore entails only
IR[CE]s and IR[VE]s.
Templin Expires February 7, 2011 [Page 36]
Internet-Draft IRON August 2010
When IRON VPs are carried over a non-native Internetwork, a global
mapping database is required to allow IR[VE]s to map VPs to locators
which are assigned to the interfaces of other IR[VE]s. Each such
non-routable VP in the IRON must therefore be represented in a
globally distributed Master VP database (MVPd). The MVPd is
maintained by a globally-managed assigned numbers authority in the
same manner as the Internet Assigned Numbers Authority (IANA)
currently maintains the master list of all top-level IPv4 and IPv6
delegations. The database can be replicated across multiple servers
for load balancing much in the same way that FTP mirror sites are
used to manage software distributions.
Each VP in the MVPd is encoded as the tuple: "{address family,
prefix, prefix-length, FQDN}", where:
o "address family" is one of IPv4, IPv6, OSI/CLNP, etc.
o "prefix" is the VP, e.g. - 2001:DB8::/32 (IPv6) [RFC3849],
192.2/16 (IPv4) [RFC5737], etc.
o "prefix-length" is the length (in bits) of the associated VP
o FQDN is a DNS Fully-Qualified Domain Name
For each VP entry in the MVPd, the VPC maintains a FQDN in the DNS to
map the VP to a list of IR[VE]s that serve it. Other IR[VE]s
discover the mappings by resolving the FQDN into a list of resource
records. Each resource record corresponds to an individual IR[VE],
and encodes the tuple : "{address family, locator, WGS 84
coordinates}" where "address family" is the address family of the
locator, "locator" is the routing locator assigned to an IR[VE]
interface, and "WGS 84 coordinates" identify the physical location of
the IR[VE].
Upon startup, each IR[VE] managed by the VPC discovers the full set
of VPs for the IRON by reading the MVPd. Each IR[VE] reads the MVPd
from a nearby server upon startup time, and periodically checks the
server for deltas since the database was last read. Upon reading the
MVPd, each IR[VE] resolves the FQDN corresponding to each VP into a
list of locators. Each locator is an address that is routable within
the underlying Internetwork and assigned to an interface of an IR[VE]
that serves the VP.
For each VP, each IR[VE] sorts the list of locators to determine a
priority ranking (e.g., based on distance from the locator) and
inserts each "VP->locator" mapping into its FIB in order of priority.
The FIB entries must be configured such that packets with destination
addresses covered by the VP are forwarded to the corresponding
Templin Expires February 7, 2011 [Page 37]
Internet-Draft IRON August 2010
locator using encapsulation of the inner network layer packet in an
outer header of a network layer protocol that is routable within the
Internetwork. This is accomplished by configuring the routing table
entry to use the locator addresses as the L2 address corresponding to
an imaginary L3 next-hop address.
Note that the VP and locator may be of different address families;
hence, possible encapsulations include IPv6-in-IPv4, IPv4-in-IPv6,
IPv6-in-IPv6, IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.
After each IR[VE] reads in the list of VPs and sorts the information
accordingly, it is said to be "synchronized with the IRON". Each
IR[VE] next installs all EPs derived from its VPs into its FIB based
on the mapping information received from the IR[CE]s each of its EUN
customers.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
entire. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires February 7, 2011 [Page 38]
