One document matched: draft-templin-ironbis-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='no'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-ironbis-01.txt" ipr="trust200902">
<front>
<title abbrev="IRON">The Internet Routing Overlay Network (IRON)</title>
<author fullname="Fred L. Templin" initials="F." role="editor"
surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="05" month="August" year="2011" />
<workgroup>Network Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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 (IRON) architecture that supports
sustainable growth while requiring no changes to end systems and no
changes to the existing routing system. IRON further addresses other
important issues including routing scaling, mobility management,
multihoming, traffic engineering and NAT traversal. While business
considerations are an important determining factor for widespread
adoption, they are out of scope for this document.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Growth in the number of entries instantiated in the Internet routing
system has led to concerns regarding unsustainable routing scaling <xref
target="RADIR"></xref>. Operational practices such as the increased use
of multihoming with Provider-Independent (PI) addressing are resulting
in more and more fine-grained prefixes being injected into the routing
system from more and more end user networks. Furthermore, depletion of
the public IPv4 address space has raised concerns for both increased
address space fragmentation (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 <xref
target="BGPMON"></xref> 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.</t>
<t>Several related works have investigated routing scaling issues.
Virtual Aggregation (VA) <xref target="GROW-VA"></xref> and Aggregation
in Increasing Scopes (AIS) <xref target="EVOLUTION"></xref> 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) <xref target="RFC5720"></xref> examines recursive arrangements
of enterprise networks that can apply to a very broad set of use-case
scenarios <xref target="RFC6139"></xref>. IRON specifically adopts the
RANGER Non-Broadcast, Multiple Access (NBMA) tunnel virtual-interface
model, and uses Virtual Enterprise Traversal (VET) <xref
target="INTAREA-VET"></xref> and the Subnetwork Adaptation and
Encapsulation Layer (SEAL) <xref target="INTAREA-SEAL"></xref> as its
functional building blocks.</t>
<t>This document proposes an Internet Routing Overlay Network (IRON)
architecture with goals of supporting sustainable growth while requiring
no changes to the existing routing system. IRON borrows concepts from VA
and AIS, and further borrows concepts from the Internet Vastly Improved
Plumbing (Ivip) <xref target="IVIP-ARCH"></xref> architecture proposal
along with its associated Translating Tunnel Router (TTR) mobility
extensions <xref target="TTRMOB"></xref>. 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 <xref
target="SAMPLE"></xref>.</t>
<t>IRON supports scalable addressing without changing the current BGP
<xref target="RFC4271"></xref> routing system. IRON observes the
Internet Protocol standards <xref target="RFC0791"></xref><xref
target="RFC2460"></xref>, while other network-layer protocols that can
be encapsulated within IP packets (e.g., OSI/CLNP (Connectionless
Network Protocol) <xref target="RFC1070"></xref>, etc.) are also within
scope.</t>
<t>IRON is a global routing system comprising Virtual Service Provider
(VSP) overlay networks that service Virtual Prefixes (VPs) from which
End User Network (EUN) prefixes (EPs) are delegated to customer sites.
IRON is motivated by a growing customer demand for multihoming, mobility
management, and traffic engineering while using stable addressing to
minimize dependence on network renumbering <xref
target="RFC4192"></xref><xref target="RFC5887"></xref>. IRON VSP overlay
network instances use the existing IPv4 and IPv6 global Internet routing
systems as virtual NBMA links for tunneling inner network protocol
packets within outer IPv4 or IPv6 headers (see Section 3). Each IRON
instance requires deployment of a small number of new BGP core routers
and supporting servers, as well as IRON-aware clients that connect
customer EUNs. No modifications to hosts, and no modifications to most
routers, are required. The following sections discuss details of the
IRON architecture.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:</t>
<t><list style="hanging">
<t hangText="End User Network (EUN):"><vspace />an edge network that
connects an organization's devices (e.g., computers, routers,
printers, etc.) to the Internet.</t>
<t hangText="End User Network Prefix (EP):"><vspace />a more
specific inner network-layer prefix (e.g., an IPv4 /28, an IPv6 /56,
etc.) derived from an aggregated Virtual Prefix (VP)and delegated to
an EUN by a Virtual Service Provider (VSP).</t>
<t hangText="End User Network Prefix Address (EPA):"><vspace />a
network-layer address belonging to an EP and assigned to the
interface of an end system in an EUN.</t>
<t hangText="Forwarding Information Base (FIB):"><vspace />a data
structure containing network prefixes to next-hop mappings; usually
maintained in a router's fast-path processing lookup tables.</t>
<t hangText="Internet Routing Overlay Network (IRON):"><vspace />the
union of all VSP overlay network instances. Each such IRON instance
supports routing within the overlay through encapsulation of inner
packets with EPA addresses within outer headers that use locator
addresses. Each IRON instance connects to the global Internet the
same as for any autonomous system.</t>
<t
hangText="IRON Client Router/Host ("Client"):"><vspace />a
customer's router or host that logically connects the customer's
EUNs and their associated EPs to an IRON instance via an NBMA tunnel
virtual interface.</t>
<t hangText="IRON Serving Router ("Server"):"><vspace />a
VSP's IRON instance router that provides forwarding and mapping
services for the EPs owned by customer Clients.</t>
<t hangText="IRON Relay Router ("Relay"):"><vspace />a
VSP's IRON instance router that acts as a relay between the IRON and
the native Internet.</t>
<t hangText="IRON Agent (IA):"><vspace />generically refers to any
of an IRON Client/Server/Relay.</t>
<t hangText="Internet Service Provider (ISP):"><vspace />a service
provider that connects customer EUNs to the underlying Internetwork.
In other words, an ISP is responsible for providing basic Internet
connectivity for customer EUNs.</t>
<t hangText="Locator"><vspace />an IP address assigned to the
interface of a router or end system within a public or private
network. Locators taken from public IP prefixes are routable on a
global basis, while locators taken from private IP prefixes are made
public via Network Address Translation (NAT).</t>
<t
hangText="Routing and Addressing in Networks with Global Enterprise Recursion (RANGER):"><vspace />
an architectural examination of virtual overlay networks applied to
enterprise network scenarios, with implications for a wider variety
of use cases.</t>
<t
hangText="Subnetwork Encapsulation and Adaptation Layer (SEAL):"><vspace />an
encapsulation sublayer that provides extended packet identification
and a Control Message Protocol to ensure deterministic network-layer
feedback.</t>
<t hangText="Virtual Enterprise Traversal (VET):"><vspace />a method
for discovering border routers and forming dynamic tunnel-neighbor
relationships over enterprise networks (or sites) with varying
properties.</t>
<t hangText="Virtual Prefix (VP):"><vspace />a prefix block (e.g.,
an IPv4 /16, an IPv6 /20, an OSI Network Service Access Protocol
(NSAP) prefix, etc.) that is owned and managed by a Virtual Service
Provider (VSP).</t>
<t hangText="Virtual Service Provider (VSP):"><vspace />a company
that owns and manages a set of VPs from which it delegates EPs to
EUNs.</t>
<t hangText="VSP Overlay Network:"><vspace />a specialized set of
routers deployed by a VSP to service customer EUNs through an IRON
instance configured over an underlying Internetwork (e.g., the
global Internet).</t>
</list></t>
</section>
<section anchor="iron" title="The Internet Routing Overlay Network">
<t>The Internet Routing Overlay Network (IRON) is a union of Virtual
Service Provider (VSP) overlay network instances connected to a common
Internetwork. While the principles presented in this document are
discussed within the context of the public global Internet, they can
also be applied to any autonomous Internetwork. The rest of this
document therefore refers to the terms "Internet" and "Internetwork"
interchangeably except in cases where specific distinctions must be
made.</t>
<t>Each IRON instance consists of IRON Agents (IAs) that automatically
tunnel the packets of end-to-end communication sessions within
encapsulating headers used for Internet routing. IAs use the Virtual
Enterprise Traversal (VET) <xref target="INTAREA-VET"></xref> virtual
NBMA link model in conjunction with the Subnetwork Encapsulation and
Adaptation Layer (SEAL) <xref target="INTAREA-SEAL"></xref> to
encapsulate inner network-layer packets within outer headers, as shown
in <xref target="encaps"></xref>.</t>
<t><figure anchor="encaps"
title="Encapsulation of Inner Packets within Outer IP Headers">
<artwork><![CDATA[ +-------------------------+
| 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
encapsulation encapsulation]]></artwork>
</figure></t>
<t>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, IAs use the
SEAL Control Message Protocol (SCMP) to deterministically exchange and
authenticate control messages such as route redirections, indications of
Path Maximum Transmission Unit (PMTU) limitations, destination
unreachables, etc. IAs appear as neighbors on an NBMA virtual link, and
form bidirectional and/or unidirectional tunnel-neighbor
relationships.</t>
<t>Each IRON instance comprises a set of IAs distributed throughout the
Internet to serve highly aggregated Virtual Prefixes (VPs). VSPs
delegate sub-prefixes from their VPs, which they lease to customers as
End User Network Prefixes (EPs). In turn, the customers assign the EPs
to their customer edge IAs, which connect their End User Networks (EUNs)
to the VSP IRON instance.</t>
<t>VSPs may have no affiliation with the ISP networks from which
customers obtain their basic Internet connectivity. Therefore, a
customer could procure its summary network services either through a
common provider or through separate entities. In that case, the VSP can
open for business and begin serving its customers immediately without
the need to coordinate its activities with ISPs or other VSPs. Further
details on business considerations are out of scope for this
document.</t>
<t>IRON requires no changes to end systems or to most routers in the
Internet. Instead, IAs are deployed either as new platforms or as
modifications to existing platforms. IAs may be deployed incrementally
without disturbing the existing Internet routing system, and act as
waypoints (or "cairns") for navigating VSP overly networks. The
functional roles for IAs are described in the following sections.</t>
<section title="IRON Client">
<t>An IRON client (or, simply, "Client") is a customer's router or
host that logically connects the customer's EUNs and their associated
EPs to its VSP's IRON instance via tunnels, as shown in <xref
target="IREP"></xref>. Client routers obtain EPs from their VSPs and
use them to number subnets and interfaces within their EUNs. A Client
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 standalone server 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). Finally, a Client may also be a
simple end system that connects a singleton EUN and exhibits the
outward appearance of a host.</t>
<figure anchor="IREP"
title="IRON Client Router Connecting EUN to IRON Instance">
<artwork><![CDATA[ .-.
,-( _)-.
+--------+ .-(_ (_ )-.
| Client |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::: IRON :::)-.
+--------+ (:::: Instance ::::)
`-(::::::::::::)-'
`-(::::::)-']]></artwork>
</figure>
<t></t>
</section>
<section title="IRON Serving Router">
<t>An IRON serving router (or, simply, "Server") is a VSP's router
that provides forwarding and mapping services within the IRON instance
for the EPs owned by customer Client routers. In typical deployments,
a VSP will deploy many Servers around the IRON instance in a globally
distributed fashion (e.g., as depicted in <xref target="IRVE"></xref>)
so that Clients can discover those that are nearby.</t>
<t><figure anchor="IRVE"
title="IRON Serving Router Global Distribution Example">
<artwork><![CDATA[ +--------+ +--------+
| Boston | | Tokyo |
| Server | | Server |
+--+-----+ ++-------+
+--------+ \ /
| Seattle| \ ___ /
| Server | \ (:::)-. +--------+
+------+-+ .-(::::::::)------+ Paris |
\.-(::: IRON :::)-. | Server |
(:::: Instance ::::) +--------+
`-(::::::::::::)-'
+--------+ / `-(::::::)-' \ +--------+
| Moscow + | \--- + Sydney |
| Server | +----+---+ | Server |
+--------+ | Cairo | +--------+
| Server |
+--------+]]></artwork>
</figure>Each Server acts as a tunnel-endpoint router that forms
bidirectional tunnel-neighbor relationships with each of its Client
customers and also serves as the tunnel egress of dynamically
discovered unidirectional tunnel-neighbors. Each Server also
associates with a set of Relays that can forward packets from the IRON
out to the native Internet and vice versa, as discussed in the next
section.</t>
</section>
<section title="IRON Relay Router">
<t>An IRON Relay Router (or, simply, "Relay") is a router that acts as
a relay between the VSP's IRON instance and the native Internet.
Therefore, it also serves as an Autonomous System Border Router (ASBR)
that is owned and managed by the VSP.</t>
<t>Each VSP configures one or more Relays that advertise the company's
VPs into the IPv4 and IPv6 global Internet BGP routing systems. Each
Relay associates with all of the VSP's IRON instance Servers, e.g.,
via tunnels over the IRON instance, via a direct interconnect such as
an Ethernet cable, etc. The Relay role is depicted in <xref
target="IRGW"></xref>.</t>
<t><figure anchor="IRGW"
title="IRON Relay Router Connecting IRON Instance to Native Internet ">
<artwork><![CDATA[
.-.
,-( _)-.
.-(_ (_ )-.
(_ Internet )
`-(______)-' | +--------+
| |--| Server |
+----+---+ | +--------+
| Relay |----| +--------+
+--------+ |--| Server |
_|| | +--------+
(:::)-. (Ethernet)
.-(::::::::)
+--------+ .-(::: IRON :::)-. +--------+
| Server |=(:::: Instance ::::)=| Server |
+--------+ `-(::::::::::::)-' +--------+
`-(::::::)-'
|| (Tunnels)
+--------+
| Server |
+--------+]]></artwork>
</figure></t>
</section>
</section>
<section anchor="IBM" title="IRON Organizational Principles">
<t>The IRON consists of the union of all VSP overlay networks configured
over a common Internetwork (e.g., the public Internet). Each such IRON
instance represents a distinct "patch" on the Internet "quilt", where
the patches are stitched together by standard Internet routing. When a
new IRON instance is deployed, it becomes yet another patch on the quilt
and coordinates its internal routing system independently of all other
patches.</t>
<t>Each IRON instance maintains a set of Relays and Servers that provide
services to Client customers. In order to ensure adequate customer
service levels, the VSP should conduct a traffic scaling analysis and
distribute sufficient Relays and Servers for the IRON instance globally
throughout the Internet. <xref target="VON"></xref> depicts the logical
arrangement of Relays, Servers, and Clients in an IRON instance.</t>
<t><figure anchor="VON" title="IRON Organization">
<artwork><![CDATA[ .-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::::::::: IRON Instance :::::::::::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<------------ Servers ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<----------- Clients and EUNs ----------->]]></artwork>
</figure>Each Relay connects the IRON instance directly to the IPv4
and IPv6 Internets. It also advertises the VSP's IPv4 VPs into the IPv4
BGP routing system and advertises the VSP's IPv6 VPs into the IPv6 BGP
routing system. Relays will therefore receive packets with EPA
destination addresses sent by end systems in the Internet and forward
them via tunnels toward EPA-addressed end systems connected to the VSP's
IRON instance.</t>
<t>Each VSP also manages a set of Servers that connect their Clients and
associated EUNs to the IRON instance and to the IPv6 and IPv4 Internets
via their associations with Relays. IRON Servers therefore need not be
BGP routers themselves; they can be simple commodity hardware platforms.
The Server and Relay functions can further be deployed together on the
same physical platform as a unified gateway, or they may be deployed on
separate platforms (e.g., for load balancing purposes).</t>
<t>Each Server maintains a working set of bidirectional tunnel-neighbor
Clients for which it caches EP-to-Client mappings in its Forwarding
Information Base (FIB). Each Server also, in turn, propagates the list
of EPs in its working set to each of the Relays in the IRON instance via
a dynamic routing protocol (e.g., an internal BGP instance that carries
only the EP-to-Server mappings and does not interact with the external
BGP routing system). Therefore, each Server only needs to track the EPs
for its current working set of Clients, while each Relay will maintain a
full EP-to-Server routing information base that represents reachability
information for all EPs in the IRON instance.</t>
<t>Customers establish Clients that obtain their basic Internet
connectivity from ISPs and connect to Servers to attach their EUNs to
the IRON instance. Each EUN can further connect to the IRON instance via
multiple Clients as long as the Clients coordinate with one another,
e.g., to mitigate EUN partitions. Unlike Relays and Servers, Clients may
use private addresses behind one or several layers of NATs. Each Client
initially discovers a list of nearby Servers then forms a bidirectional
tunnel-neighbor relationship with one of the Servers through an initial
exchange followed by periodic keepalives.</t>
<t>After the Client selects a Server, it forwards initial outbound
packets from its EUNs by tunneling them to the Server, which may, in
turn, forward them to the nearest Relay within the IRON instance. The
Client may subsequently receive redirect messages informing it of a more
direct route through a different Server within the IRON instance that
serves the final destination EUN. This Server in turn provides a
unidirectional tunnel-neighbor egress for route optimization
purposes,.</t>
<t>The IRON can also be used to support VPs of network-layer address
families that cannot be routed natively in the underlying Internetwork
(e.g., OSI/CLNP over the public Internet, IPv6 over IPv4-only
Internetworks, IPv4 over IPv6-only Internetworks, etc.). Further details
for the support of IRON VPs of one address family over Internetworks
based on other address families are discussed in Appendix A.</t>
</section>
<section anchor="initialization" title="IRON Initialization">
<t>Each IRON instance is initialized through the startup actions of IAs
and customer EUNs. The following sub-sections discuss these startup
procedures.</t>
<section title="IRON Relay Router Initialization">
<t>Each IRON Relay is provisioned with the list of VPs that it will
serve, as well as the locators for all Servers within the IRON
instance. The Relay is also provisioned with external BGP
interconnections -- the same as for any BGP router.</t>
<t>Upon startup, the Relay 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 Servers in the IRON instance
(e.g., via a secured TCP connection over a bidirectional tunnel, via
an Internal BGP (IBGP) route reflector, etc.) for the purpose of
discovering EP-to-Server mappings. After the Relay has fully populated
its EP-to-Server mapping information database, it is said to be
"synchronized" with respect to its VPs.</t>
<t>After this initial synchronization procedure, the Relay then
advertises the VPs externally. In particular, the Relay advertises the
IPv6 VPs into the IPv6 BGP routing system and advertises the IPv4 VPs
into the IPv4 BGP routing system. The Relay then engages in ordinary
packet-forwarding operations.</t>
</section>
<section title="IRON Serving Router Initialization">
<t>Each IRON Server is provisioned with the locators for all Relays
within the IRON instance. Upon startup, each Server must connect to
all of the Relays within the IRON instance (e.g., via a secured TCP
connection, via an IBGP route reflector, etc.) for the purpose of
reporting the list of EPs it is currently serving. The Server then
actively listens for Client customers that register their EP prefixes
as part of establishing a bidirectional tunnel-neighbor relationship.
When a new Client connects, the Server announces the new EP routes to
all Relays; when an existing Client disconnects, the Server withdraws
its announcements.</t>
</section>
<section anchor="EUN" title="IRON Client Initialization">
<t>Each Client obtains one or more EPs in an initial secured exchange
with the VSP, e.g., as part of the initial customer signup agreement.
Upon startup, the Client connects to a location broker (e.g., a well
known website run by the VSP) to discover a list of nearby
Servers.</t>
<t>After the Client obtains a list of nearby Servers, it initiates a
short transaction with one or more Servers (e.g., via a secured TCP
connection) in order to establish a bidirectional tunnel-neighbor
relationship. During the transaction, each Server provides the Client
with a tunnel-neighbor identifier ("NBR_ID") and a Shared Secret that
the Client will use to sign and authenticate certain control messages.
The protocol details of the transaction are specific to the VSP, and
hence out of scope for this document.</t>
</section>
</section>
<section anchor="operation" title="IRON Operation">
<t>Following the initialization operations detailed in Section 5, IAs
engage in the cooperative process of receiving and forwarding packets.
All IAs forward encapsulated packets over the IRON instance using the
mechanisms of VET <xref target="INTAREA-VET"></xref> and SEAL <xref
target="INTAREA-SEAL"></xref>, while Relays additionally forward packets
to and from the native IPv6 and IPv4 Internets. IAs also use SCMP to
coordinate with other IAs, including the process of sending and
receiving redirect messages, error messages, etc. Each IA operates as
specified in the following sub-sections.</t>
<section title="IRON Client Operation">
<t>After selecting Servers as specified in Section 5.3, the Client
registers one or more active ISP connections with each Server. To do
so, it sends periodic beacons (e.g., cryptographically signed SRS
messages) to the Server via each ISP connection to maintain
tunnel-neighbor address mapping state. The beacons should be sent at
no more than 60 second intervals (subject to a small random delay) so
that state in NATs on the path as well as on the Server itself is
refreshed regularly. Although the Client may connect via multiple
ISPs, a single NBR_ID is used to represent the set of all ISP paths
the Client has registered with this Server. The NBR_ID therefore names
this "bundle" of tunnel-neighbor ISP connections.</t>
<t>If the Client ceases to receive acknowledgements from a Server via
a specific ISP connection, it marks the Server as unreachable from
that ISP. (The Client should also inform the Server of this outage via
one of its working ISP connections.) If the Client ceases to receive
acknowledgements from the Server via multiple ISP connections, it
withdraws its registration with this server and registers with a new
nearby Server. The act of withdrawing from the old server and
registering with the new server will soon propagate the appropriate
routing information among the IRON instance's Relay Routers.</t>
<t>When an end system in an EUN sends a flow of packets to a
correspondent, the packets are forwarded through the EUN via normal
routing until they reach the Client, which then tunnels the initial
packets to a Server as the next hop. In particular, the Client
encapsulates each packet in an outer header with its locator as the
source address and the locator of the Server as the destination
address. After sending the initial packets of a flow, the Client may
receive important control messages, such as indications of PMTU
limitations, redirect messages that indicate a better tunnel-neighbor
next hop, etc.</t>
<t>The Client uses the mechanisms specified in VET and SEAL to
encapsulate each packet to be forwarded. The Client further uses the
SCMP protocol to coordinate with Servers, including accepting
redirects and other control messages.</t>
</section>
<section title="IRON Serving Router Operation">
<t>After the Server is initialized, it accepts Client connections and
authenticates the SRS messages it receives from its connected
tunnel-neighbor Clients. The Server discards any SRS messages that
failed authentication, and responds to authentic SRS messages by
returning signed SRAs.</t>
<t>When the Server receives a SEAL-encapsulated data packet from one
of its bidirectional tunnel-neighbor Clients, it uses normal
longest-prefix-match rules to locate a FIB entry that matches the
packet's inner destination address. If the matching FIB entry is
more-specific than default, the next hop is another of the Server's
tunnel-neighbor Clients; otherwise, the next-hop is a Relay which
serves as a default router. The Server then re-encapsulates the packet
(i.e., it removes the outer header and replaces it with a new outer
header of the same address family), sets the outer destination address
to the locator address of the next hop and tunnels the packet to the
next hop.</t>
<t>When the Server receives a SEAL-encapsulated data packet from
either a Relay or from a unidirectional tunnel-neighbor Client, it
again locates a FIB entry that matches the packet's inner destination
address. If the matching FIB entry is more-specific than default, the
Server re-encapsulates the packet and forwards it to the correct
bidirectional tunnel-neighbor Client. If the Client has recently moved
to a different Server, however, the Server also returns an SCMP
redirect message listing a NULL next hop to inform the previous hop
that the Client has moved.</t>
<t>Note that Server-to-Server tunneling is not permitted, since this
could result in sustained routing loops in which Server A has a route
to Server B, and Server B has a route to Server A. This implies that a
Server must never accept and process a redirect message, but must
instead relay the redirect message to the appropriate bidirectional
Client. The permissible data flow paths for tunneled packets that flow
through a Server are therefore:</t>
<t><list style="symbols">
<t>From a bidirectional Client customer to another bidirectional
Client customer (i.e., a hairpin route)</t>
<t>From a bidirectional Client customer to a default Relay
router</t>
<t>From a default Relay router to a bidirectional Client
customer</t>
<t>From a unidirectional foreign Client to a bidirectional Client
customer</t>
</list></t>
</section>
<section title="IRON Relay Router Operation">
<t>After each Relay has synchronized its VPs (see Section 5.1) it
advertises them in the IPv4 and IPv6 Internet BGP routing systems.
These prefixes will be represented as ordinary routing information in
the BGP, and any packets originating from the IPv4 or IPv6 Internet
destined to an address covered by one of the prefixes will be
forwarded to one of the VSP's Relays.</t>
<t>When a Relay receives a packet from the Internet destined to an EPA
covered by one of its VPs, it behaves as an ordinary IP router. In
particular, the Relay looks in its FIB to discover a locator of a
Server that serves the EP covering the destination address. The Relay
then simply encapsulates the packet with its own locator as the outer
source address and the locator of the Server as the outer destination
address and forwards the packet to the Server.</t>
</section>
<section title="IRON Reference Operating Scenarios">
<t>IRON supports communications when one or both hosts are located
within EP-addressed EUNs. The following sections discuss the reference
operating scenarios.</t>
<section title="Both Hosts within Same IRON Instance">
<t>When both hosts are within EUNs served by the same IRON instance,
it is sufficient to consider the scenario in a unidirectional
fashion, i.e., by tracing packet flows only in the forward direction
from source host to destination host. The reverse direction can be
considered separately and incurs the same considerations as for the
forward direction. The simplest case occurs when the EUNs that
service the source and destination hosts are connected to the same
server, while the general case occurs when the EUNs are connected to
different Servers. The two cases are discussed in the following
sections.</t>
<section title="EUNs Served by Same Server">
<t>In this scenario, the packet flow from the source host is
forwarded through the EUN to the source's Client. The Client then
tunnels the packets to the Server, which simply relays the
tunneled packets to the destination's Client. The destination's
Client then removes the packets from the tunnel and forwards them
over the EUN to the destination. <xref target="example0"></xref>
depicts the sustained flow of packets from Host A to Host B within
EUNs serviced by the same Server(S) via a "hairpinned" route:</t>
<t><figure anchor="example0"
title="Sustained Packet Flow via Hairpinned Route">
<artwork><![CDATA[ ________________________________________
.-( )-.
.-( )-.
.-( )-.
.( ).
.( ).
.( +------------+ ).
( +===================>| Server(S) |=====================+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
((_|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ +-----+-----+ )
| Client(A) | | Client(B) |
+-----+-----+ VSP IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+]]></artwork>
</figure>With reference to <xref target="example0"></xref>, Host
A sends packets destined to Host B via its network interface
connected to EUN A. Routing within EUN A will direct the
packets to Client(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, the locator address
of Server(S) as the outer destination address, and the NBR_ID
parameters associated with its tunnel-neighbor state as the
identity. Client(A) then simply forwards the encapsulated packets
into its ISP network connection that provided its locator. The ISP
will forward the encapsulated packets into the Internet without
filtering since the (outer) source address is topologically
correct. Once the packets have been forwarded into the Internet,
routing will direct them to Server(S).</t>
<t>Server(S) will receive the encapsulated packets from Client(A)
then check its FIB to discover an entry that covers destination
address B with Client(B) as the next hop. Server(S) then
re-encapsulates the packets in a new outer header that uses the
source address, destination address, and NBR_ID parameters
associated with the tunnel-neighbor state for Client(B). Server(S)
then forwards these re-encapsulated packets into the Internet,
where routing will direct them to Client(B). Client(B) will, in
turn, decapsulate the packets and forward the inner packets to
Host B via EUN B.</t>
<t>In this scenario, no further route optimization is supported
within the IRON framework, since IRON does not make provisions for
Client-to-Client binding updates. Each Client therefore need only
coordinate its locator to EP mappings with its Server(s), and does
not update bindings with any of its recent correspondents.</t>
</section>
<section title="EUNs Served by Different Servers">
<t>In this scenario, the initial packets of a flow produced by a
source host within an EUN connected to the IRON instance by a
Client must flow through both the Server of the source host and a
nearby Relay, but route optimization can eliminate these elements
from the path for subsequent packets in the flow. <xref
target="example1"></xref> shows the flow of initial packets from
Host A to Host B within EUNs of the same IRON instance:</t>
<t><figure anchor="example1"
title="Initial Packet Flow Before Redirects">
<artwork><![CDATA[ ________________________________________
.-( )-.
.-( +------------+ )-.
.-( +======>| Relay(R) |=======+ )-.
.( || +*-----------+ || ).
.( || * vv ).
.( +--------++--+* +--++--------+ ).
( +==>| Server(A) *| | Server(B) |====+ )
( // +----------*-+ +------------+ \\ )
( // .-. * .-. \\ )
( //,-( _)-. * ,-( _)-\\ )
( .||_ (_ )-. * .-(_ (_ ||. )
((_|| ISP A .) * (__ ISP B ||_))
( ||-(______)-' * `-(______)|| )
( || | * | vv )
( +-----+-----+ * +-----+-----+ )
| Client(A) |<* | Client(B) |
+-----+-----+ VSP IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ ***** == Redirect +--------+]]></artwork>
</figure>With reference to <xref target="example1"></xref>, Host
A sends packets destined to Host B via its network interface
connected to EUN A. Routing within EUN A will direct the
packets to Client(A) as a default router for the EUN, which then
encapsulates them in outer headers and forwards the encapsulated
packets into the ISP network connection that provided its locator.
The ISP will forward the encapsulated packets into the Internet,
where routing will direct them to Server(A).</t>
<t>Server(A) receives the encapsulated packets from Client(A) then
rewrites the outer source address to one of its own locator
addresses and rewrites the outer destination address to the
address of a nearby Relay(R). Server(A) then forwards the revised
encapsulated packets into the Internet, where routing will direct
them to Relay(R).</t>
<t>Relay(R) receives the encapsulated packets from Server(A) then
checks its FIB to discover an entry that covers inner destination
address B with Server(B) as the next hop. Relay(R) then returns
SCMP redirect messages to Server(A), rewrites the outer
destination address of the encapsulated packets to the locator
address of Server(B), and forwards these revised packets to
Server(B).</t>
<t>Server(B) receives the encapsulated packets from Relay(R) then
checks its FIB to discover an entry that covers destination
address B with Client(B) as the next hop. Server(B) then
re-encapsulates the packets in a new outer header that uses the
source address, destination address, and NBR_ID parameters
associated with the tunnel-neighbor state for Client(B). Server(B)
then forwards these re-encapsulated packets into the Internet,
where routing will direct them to Client(B). Client(B) will, in
turn, decapsulate the packets and forward the inner packets to
Host B via EUN B.</t>
<t>Note that after the initial flow of packets, Server(A) will
have received one or more SCMP redirect messages from Relay(R)
listing Server(B) as a better next hop. Server(A) will, in turn,
proxy the redirects to Client(A), which will establish
unidirectional tunnel-neighbor state listing Server(B) as the next
hop toward the EP that covers Host B. Client(A) thereafter
forwards its encapsulated packets directly to the locator address
of Server(B) without involving either Server(A) or Relay(B), as
shown in <xref target="example2"></xref>.</t>
<t><figure anchor="example2"
title="Sustained Packet Flow After Redirects">
<artwork><![CDATA[ ________________________________________
.-( )-.
.-( )-.
.-( )-.
.( ).
.( ).
.( +------------+ ).
( +====================================>| Server(B) |====+ )
( // +------------+ \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
((_|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( || | | vv )
( +-----+-----+ +-----+-----+ )
| Client(A) | | Client(B) |
+-----+-----+ IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+]]></artwork>
</figure></t>
</section>
</section>
<section title="Mixed IRON and Non-IRON Hosts">
<t>The cases in which 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) are described in the following
sub-sections.</t>
<section title="From IRON Host A to Non-IRON Host B">
<t><xref target="example5"></xref> depicts the IRON reference
operating scenario for packets flowing from Host A in an IRON EUN
to Host B in a non-IRON EUN.</t>
<t><figure anchor="example5"
title="From IRON Host A to Non-IRON Host B">
<artwork><![CDATA[ _________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |--------------------------+ )-.
.( +------------+ \ ).
.( +=======>| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // IRON ) \ )
( // .-. Instance ) .-. \ )
( //,-( _)-. ) ,-( _)-. \ )
( .||_ (_ )-. ) The Native Internet .- _ (_ )-| )
( _|| ISP A ) ) (_ ISP B |))
( ||-(______)-' ) `-(______)-' | )
( || | )-. | v )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router(B) |
+-----+-----+ +-----+-----+
^ | ( ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+-| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+]]></artwork>
</figure></t>
<t>In this scenario, Host A sends packets destined to Host B via
its network interface connected to IRON EUN A. Routing
within EUN A will direct the packets to Client(A) as a default
router for the EUN, which then encapsulates them and sends them
into the ISP network. 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, the Internet routing system will direct them to
Server(A).</t>
<t>Server(A) receives the encapsulated packets from Client(A) then
re-encapsulates and forwards them to Relay(A), which simply
decapsulates them and forwards the unencapsulated packets into the
Internet. Once the packets are released into the Internet, routing
will direct them to the final destination B. (Note that Server(A)
and Relay(A) are depicted in <xref target="example5"></xref> as
two halves of a unified gateway. In that case, the "forwarding"
between Server(A) and Relay(A) is a zero-instruction imaginary
operation within the gateway.)</t>
</section>
<section title="From Non-IRON Host B to IRON Host A">
<t><xref target="example6"></xref> depicts the IRON reference
operating scenario for packets flowing from Host B in an Non-IRON
EUN to Host A in an IRON EUN.</t>
<t><figure anchor="example6"
title="From Non-IRON Host B to IRON Host A">
<artwork><![CDATA[ _________________________________________
.-( )-. )-.
.-( +-------)----+ )-.
.-( | Relay(A) |<-------------------------+ )-.
.( +------------+ \ ).
.( +========| Server(A) | \ ).
.( // +--------)---+ \ ).
( // ) \ )
( // IRON ) \ )
( // .-. Instance ) .-. \ )
( //,-( _)-. ) ,-( _)-. \ )
( .||_ (_ )-. ) The Native Internet .- _ (_ )-| )
( _|| ISP A ) ) (_ ISP B |))
( ||-(______)-' ) `-(______)-' | )
( vv | )-. | | )
( +-----+ ----+ )-. +-----+-----+ )
| Client(A) |)-. | Router(B) |
+-----+-----+ +-----+-----+
| | ( ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+>| Host A | <===> == Tunnel | Host B |-+
+--------+ +--------+]]></artwork>
</figure></t>
<t>In this scenario, Host B sends packets destined to Host A via
its network interface connected to non-IRON EUN B. Internet
routing will direct the packets to Relay(A), which then forwards
them to Server(A) using encapsulation if necessary.</t>
<t>Server(A) will then check its FIB to discover an entry that
covers destination address A with Client(A) as the next hop.
Server(A) then (re-)encapsulates the packets in an outer header
that uses the source address, destination address, and NBR_ID
parameters associated with the tunnel-neighbor state for
Client(A). Next, Server(A) forwards these (re-)encapsulated
packets into the Internet, where routing will direct them to
Client(A). Client(A) will, in turn, decapsulate the packets and
forward the inner packets to Host A via its network interface
connected to IRON EUN A.</t>
</section>
</section>
<section title="Hosts within Different IRON Instances ">
<t><xref target="example7"></xref> depicts the IRON reference
operating scenario for packets flowing between Host A in an IRON
instance A and Host B in a different IRON instance B. In that case,
forwarding between hosts A and B always involves the Servers and
Relays of both IRON instances, i.e., the scenario is no different
than if one of the hosts was serviced by an IRON EUN and the other
was serviced by a non-IRON EUN. <figure anchor="example7"
title="Hosts within Different IRON Instances">
<artwork><![CDATA[ _________________________________________
.-( )-. .-( )-.
.-( +-------)----+ +---(--------+ )-.
.-( | Relay(A) | <---> | Relay(B) | )-.
.( +------------+ +------------+ ).
.( +=======>| Server(A) | | Server(B) |<======+ ).
.( // +--------)---+ +---(--------+ \\ ).
( // ) ( \\ )
( // IRON ) ( IRON \\ )
( // .-. Instance A ) ( Instance B .-. \\ )
( //,-( _)-. ) ( ,-( _). || )
( .||_ (_ )-. ) ( .-'_ (_ )|| )
( _|| ISP A ) ) ( (_ ISP B ||))
( ||-(______)-' ) ( '-(______)-|| )
( vv | )-. .-( | vv )
( +-----+ ----+ )-. .-( +-----+-----+ )
| Client(A) |)-. .-(| Client(B) |
+-----+-----+ The Native Internet +-----+-----+
^ | ( ) | ^
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| IRON EUN A ) (_ IRON EUN B|)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+>| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+]]></artwork>
</figure></t>
</section>
</section>
<section title="Mobility, Multiple Interfaces, Multihoming, and Traffic Engineering Considerations">
<t>While IRON Servers and Relays can be considered as fixed
infrastructure, Clients 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,
multihoming, and traffic engineering considerations for IRON Client
routers.</t>
<section title="Mobility Management">
<t>When a Client changes its network point of attachment (e.g., due
to a mobility event), it configures one or more new locators. If the
Client has not moved far away from its previous network point of
attachment, it simply informs its Server of any locator additions or
deletions. This operation is performance sensitive and should be
conducted immediately to avoid packet loss.</t>
<t>If the Client has moved far away from its previous network point
of attachment, however, it re-issues the Server discovery procedure
described in Section 5.3 to discover whether its candidate set of
Servers has changed. If the Client's current Server is also included
in the new list received from the VSP, this provides indication that
the Client has not moved far enough to warrant changing to a new
Server. Otherwise, the Client may wish to move to a new Server in
order to reduce routing stretch. This operation is not performance
critical, and therefore can be conducted over a matter of
seconds/minutes instead of milliseconds/microseconds.</t>
<t>To move to a new Server, the Client first engages in the EP
registration process with the new Server, as described in Section
5.3. The Client then informs its former Server that it has departed;
again, via a VSP-specific secured reliable transport connection. The
former Server will then withdraw its EP advertisements from the VSP
routing system and retain the (stale) FIB entries until their
lifetime expires. In the interim, the Server continues to deliver
packets to the Client's last-known locator addresses for the short
term while informing any unidirectional tunnel-neighbors that the
Client has moved.</t>
</section>
<section title="Multiple Interfaces and Multihoming">
<t>A Client may register multiple ISP connections with each Server.
It can assign metrics with its registrations to inform the Server of
preferred ISP connections, and it can select outgoing ISP
connections according to its outbound traffic requirements.
Therefore, multiple interfaces are naturally supported.</t>
<t>A Client may further register with multiple Servers for fault
tolerance and reduced routing stretch. In that case, the Client
should register each of its ISP connections with each of its Servers
unless it has a way of carefully coordinating its ISP-to-Server
mappings. (However, unpredictable performance may result if the
Client registers only preferred ISP connections with Server A and
backup ISP connections with Server B.)</t>
<t>Client registration with multiple Servers results in
"pseudo-multihoming", in which the multiple homes are within the
same VSP IRON instance. True multihoming would only apply if the
Client were to connect to multiple IRON instances and receive a
different set of EPs from each instance.</t>
</section>
<section title="Inbound Traffic Engineering">
<t>A Client can dynamically adjust the priorities of its locator
registrations with its Server in order to influence inbound traffic
flows. It can also change between Servers when multiple Servers are
available, but should strive for stability in its Server selection
in order to limit VSP network routing churn.</t>
</section>
<section title="Outbound Traffic Engineering">
<t>A Client can select outgoing locators, e.g., based on current
Quality-of-Service (QoS) considerations such as minimizing delay or
variance.</t>
</section>
</section>
<section title="Renumbering Considerations">
<t>As new link-layer technologies and/or service models 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 change to a
different ISP <xref target="RFC4192"></xref><xref
target="RFC5887"></xref>.</t>
<t>When a customer obtains EP prefixes from a VSP, it can change
between ISPs seamlessly and without need to renumber. If the VSP
itself applies unreasonable costing structures for use of the EPs,
however, the customer may be compelled to seek a different VSP and
would again be required to confront a renumbering scenario.</t>
</section>
<section title="NAT Traversal Considerations">
<t>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
Internet via Network Address Translators (NATs). When a Client is
located behind a NAT, it selects Servers using the same procedures as
for Clients with public addresses and can then send SRS messages to
Servers in order to get SRA messages in return. The only requirement
is that the Client must configure its SEAL encapsulation to use a
transport protocol that supports NAT traversal, e.g., UDP, TCP, SSL,
etc.</t>
<t>Since the Server maintains state about its Client customers, it can
discover locator information for each Client by examining the UDP port
number and IP address in the outer headers of the Client's
encapsulated SRS packets. When there is a NAT in the path, the
transport port number and IP address in each encapsulated packet will
correspond to state in the NAT box and might not correspond to the
actual values assigned to the Client. The Server can then encapsulate
packets destined to hosts in the Client's EUN within outer headers
that use this IP address and UDP port number. The NAT box will receive
the packets, translate the values in the outer headers, then forward
the packets to the Client. In this sense, the Server's "locator" for
the Client consists of the concatenation of the IP address and
transport port number.</t>
<t>IRON does not introduce any new issues to complications raised for
NAT traversal or for applications embedding address referrals in their
payload.</t>
</section>
<section title="Multicast Considerations">
<t>IRON Servers and Relays are topologically positioned to provide
Internet Group Management Protocol (IGMP) / Multicast Listener
Discovery (MLD) proxying for their Clients <xref
target="RFC4605"></xref>. Further multicast considerations for IRON
(e.g., interactions with multicast routing protocols, traffic scaling,
etc.) will be discussed in a separate document.</t>
</section>
<section title="Nested EUN Considerations">
<t>Each Client 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 Client. In that case, the Client is said to
be "nested" within the EUN of another Client, and recursive nestings
of multiple layers of encapsulations may be necessary.</t>
<t>For example, in the network scenario depicted in <xref
target="nest"></xref>, Client(A) configures a locator EPA(B) taken
from the EP assigned to EUN(B). Client(B) in turn configures a locator
EPA(C) taken from the EP assigned to EUN(C). Finally, Client(C)
configures 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.</t>
<t><figure anchor="nest" title="Nested EUN Example">
<artwork><![CDATA[ .-.
ISP(D) ,-( _)-.
+-----------+ .-(_ (_ )-.
| Client(C) |--(_ ISP(D) )
+-----+-----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN(C) ) e `-(______)-'
`-(______)-' l ___
| EPA(C) s => (:::)-.
+-----+-----+ .-(::::::::)
| Client(B) | .-(::: IRON :::)-. +-----------+
+-----+-----+ (:::: Instance ::::) | Relay(Z) |
| `-(::::::::::::)-' +-----------+
.-. `-(::::::)-' +-----------+
,-( _)-. | Server(Z) |
.-(_ (_ )-. +-----------+ +-----------+
(_ EUN(B) ) | Server(C) | +-----------+
`-(______)-' +-----------+ | Client(Z) |
| EPA(B) +-----------+ +-----------+
+-----+-----+ | Server(B) | +--------+
| Client(A) | +-----------+ | Host Z |
+-----------+ +-----------+ +--------+
| | Server(A) |
.-. +-----------+
,-( _)-. EPA(A)
.-(_ (_ )-. +--------+
(_ EUN(A) )---| Host A |
`-(______)-' +--------+]]></artwork>
</figure></t>
<t>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.</t>
<section title="Host A Sends Packets to Host Z">
<t>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 Client(A), which encapsulates it in an outer header
with EPA(B) as the outer source address and Server(A) as the outer
destination address then forwards the once-encapsulated packet into
EUN(B). Routing within EUN(B) will direct the packet to Client(B),
which encapsulates it in an outer header with EPA(C) as the outer
source address and Server(B) as the outer destination address then
forwards the twice-encapsulated packet into EUN(C). Routing within
EUN(C) will direct the packet to Client(C), which encapsulates it in
an outer header with ISP(D) as the outer source address and
Server(C) as the outer destination address. Client(C) then sends
this triple-encapsulated packet into the ISP(D) network, where it
will be routed into the Internet to Server(C).</t>
<t>When Server(C) receives the triple-encapsulated packet, it
removes the outer layer of encapsulation and forwards the resulting
twice-encapsulated packet into the Internet to Server(B). Next,
Server(B) removes the outer layer of encapsulation and forwards the
resulting once-encapsulated packet into the Internet to Server(A).
Next, Server(A) checks the address type of the inner address 'Z'. If
Z is a non-EPA address, Server(A) simply decapsulates the packet and
forwards it into the Internet. Otherwise, Server(A) rewrites the
outer source and destination addresses of the once-encapsulated
packet and forwards it to Relay(Z). Relay(Z), in turn, rewrites the
outer destination address of the packet to the locator for
Server(Z), then forwards the packet and sends a redirect to
Server(A) (which forwards the redirect to Client(A)). Server(Z) then
re-encapsulates the packet and forwards it to Client(Z), which
decapsulates it and forwards the inner packet to Host Z.
Subsequent packets from Client(A) will then use Server(Z) as the
next hop toward Host Z, which eliminates Server(A) and Relay(Z) from
the path.</t>
</section>
<section title="Host Z Sends Packets to Host A">
<t>Whether or not Host Z configures an EPA address, its packets
destined to Host A will eventually reach Server(A). Server(A) will
have a mapping that lists Client(A) as the next hop toward EPA(A).
Server(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
Server(B), which will have a mapping that lists Client(B) as the
next hop toward EPA(B). Server(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 Server(C), which will have a mapping
that lists Client(C) as the next hop toward EPA(C). Server(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 Client(C).</t>
<t>When the triple-encapsulated packet arrives at Client(C), it
strips the outer layer of encapsulation and forwards the
twice-encapsulated packet to EPA(C), which is the locator address of
Client(B). When Client(B) receives the twice-encapsulated packet, it
strips the outer layer of encapsulation and forwards the
once-encapsulated packet to EPA(B), which is the locator address of
Client(A). When Client(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.</t>
</section>
</section>
</section>
<section title="Implications for the Internet">
<t>The IRON architecture envisions a hybrid routing/mapping system that
benefits from both the shortest-path routing afforded by pure dynamic
routing systems and the routing-scaling suppression afforded by pure
mapping systems. Therefore, IRON targets the elusive "sweet spot" that
pure routing and pure mapping systems alone cannot satisfy.</t>
<t>The IRON system requires a VSP deployment of new routers/servers
throughout the Internet to maintain well-balanced virtual overlay
networks. These routers/servers can be deployed incrementally without
disruption to existing Internet infrastructure and appropriately managed
to provide acceptable service levels to customers.</t>
<t>End-to-end traffic that traverses an IRON instance may experience
delay variance between the initial packets and subsequent packets of a
flow. This is due to the IRON system allowing a longer path stretch for
initial packets followed by timely route optimizations to utilize better
next hop routers/servers for subsequent packets.</t>
<t>IRON instances also work seamlessly with existing and emerging
services within the native Internet. In particular, customers serviced
by an IRON instance will receive the same service enjoyed by customers
serviced by non-IRON service providers. Internet services already
deployed within the native Internet also need not make any changes to
accommodate VSP customers.</t>
<t>The IRON system operates between routers within provider networks and
end user networks. Within these networks, the underlying paths traversed
by the virtual overlay networks may comprise links that accommodate
varying MTUs. While the IRON system imposes an additional per-packet
overhead that may cause the size of packets to become slightly larger
than the underlying path can accommodate, IRON routers have a method for
naturally detecting and tuning out instances of path MTU underruns. In
some cases, these MTU underruns may need to be reported back to the
original hosts; however, the system will also allow for MTUs much larger
than those typically available in current Internet paths to be
discovered and utilized as more links with larger MTUs are deployed.</t>
<t>Finally, and perhaps most importantly, the IRON system provides
in-built mobility management, multihoming and traffic engineering
capabilities that allow end user devices and networks to move about
freely while both imparting minimal oscillations in the routing system
and maintaining generally shortest-path routes. This mobility management
is afforded through the very nature of the IRON customer/provider
relationship, and therefore requires no adjunct mechanisms. The mobility
management and multihoming capabilities are further supported by
forward-path reachability detection that provides "hints of forward
progress" in the same spirit as for IPv6 Neighbor Discovery (ND).</t>
</section>
<section anchor="research" title="Additional Considerations">
<t>Considerations for the scalability of Internet Routing due to
multihoming, traffic engineering, and provider-independent addressing
are discussed in <xref target="RADIR"></xref>. Other scaling
considerations specific to IRON are discussed in Appendix B.</t>
<t>Route optimization considerations for mobile networks are found in
<xref target="RFC5522"></xref>.</t>
</section>
<section anchor="init" title="Related Initiatives">
<t>IRON builds upon the concepts of the RANGER architecture <xref
target="RFC5720"></xref> , and therefore inherits the same set of
related initiatives. The Internet Research Task Force (IRTF) Routing
Research Group (RRG) mentions IRON in its recommendation for a routing
architecture <xref target="RFC6115"></xref>.</t>
<t>Virtual Aggregation (VA) <xref target="GROW-VA"></xref> and
Aggregation in Increasing Scopes (AIS) <xref target="EVOLUTION"></xref>
provide the basis for the Virtual Prefix concepts.</t>
<t>Internet Vastly Improved Plumbing (Ivip) <xref
target="IVIP-ARCH"></xref> has contributed valuable insights, including
the use of real-time mapping. The use of Servers as mobility anchor
points is directly influenced by Ivip's associated TTR mobility
extensions <xref target="TTRMOB"></xref>.</t>
<t><xref target="RO-CR"></xref> discusses a route optimization approach
using a Correspondent Router (CR) model. The IRON Server construct is
similar to the CR concept described in this work; however, the manner in
which Clients coordinate with Servers is different and based on the
redirection model associated with NBMA links <xref
target="RFC5214"></xref>.</t>
<t>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 <xref
target="SAMPLE"></xref>.</t>
<t>The IRON Client-Server relationship is managed in essentially the
same way as for the Tunnel Broker model <xref target="RFC3053"></xref>.
Numerous existing tunnel broker provider networks (e.g., Hurricane
Electric, SixXS, freenet6, etc.) provide existence proofs that IRON-like
overlay network services can be deployed and managed on a global basis
<xref target="BROKER"></xref>.</t>
</section>
<section anchor="secure" title="Security Considerations">
<t>Security considerations that apply to tunneling in general are
discussed in <xref target="V6OPS-TUN-SEC"></xref>. Additional
considerations that apply also to IRON are discussed in RANGER <xref
target="RFC5720"></xref> , VET <xref target="INTAREA-VET"></xref> and
SEAL <xref target="INTAREA-SEAL"></xref>.</t>
<t>The IRON system further depends on mutual authentication of IRON
Clients to Servers and Servers to Relays. This is accomplished through
initial authentication exchanges that establish tunnel-neighbor NBR_ID
values that can be used to detect off-path attacks. As for all Internet
communications, the IRON system also depends on Relays acting with
integrity and not injecting false advertisements into the BGP (e.g., to
mount traffic siphoning attacks).</t>
<t>IRON Servers must ensure that any changes in a Client's locator
addresses are communicated only through an authenticated exchange that
is not subject to replay. For this reason, Clients periodically send
digitally-signed SRS messages to the Server. If the Client's locator
address stays the same, the Server can accept the SRS message without
verifying the signature as long as the NBR_ID of the SRS matches the
Client. If the Client's locator address changes, the Server must verify
the SRS message's signature before accepting the message. Once the
message has been authenticated, the Server updates the Client's locator
address to the new address.</t>
<t>Each IRON instance requires a means for assuring the integrity of the
interior routing system so that all Relays and Servers in the overlay
have a consistent view of Client<->Server bindings. Finally,
Denial-of-Service (DoS) attacks on IRON Relays and Servers can occur
when packets with spoofed source addresses arrive at high data rates.
However, this issue is no different than for any border router in the
public Internet today.</t>
<t>Middleboxes can interfere with tunneled packets within an IRON
instance in various ways. For example, a middlebox may alter a packet's
contents, change a packet's locator addresses, inject spurious packets,
replay old packets, etc. These issues are no different than for
middlebox interactions with ordinary Internet communications. If
man-in-the-middle attacks are a matter for concern in certain
deployments, however, IRON Agents can use IPsec to protect the
authenticity, integrity and (if necessary) privacy of their tunneled
packets.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The ideas behind this work have benefited greatly from discussions
with colleagues; some of which appear on the RRG and other IRTF/IETF
mailing lists. Robin Whittle and Steve Russert co-authored the TTR
mobility architecture, which strongly influenced IRON. Eric Fleischman
pointed out the opportunity to leverage anycast for discovering
topologically close Servers. Thomas Henderson recommended a quantitative
analysis of scaling properties.</t>
<t>The following individuals provided essential review input: Jari
Arkko, Mohamed Boucadair, Stewart Bryant, John Buford, Ralph Droms,
Wesley Eddy, Adrian Farrel, Dae Young Kim, and Robin Whittle.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc rfcedstyle="no" ?>
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.2460"?>
</references>
<references title="Informative References">
<!-- <?rfc include="reference.I-D.ietf-grow-va"?> -->
<reference anchor="GROW-VA">
<front>
<title>FIB Suppression with Virtual Aggregation</title>
<author fullname="Paul Francis" initials="P" surname="Francis">
<organization></organization>
</author>
<author fullname="Xiaohu Xu" initials="X" surname="Xu">
<organization></organization>
</author>
<author fullname="Hitesh Ballani" initials="H" surname="Ballani">
<organization></organization>
</author>
<author fullname="Dan Jen" initials="D" surname="Jen">
<organization></organization>
</author>
<author fullname="Robert Raszuk" initials="R" surname="Raszuk">
<organization></organization>
</author>
<author fullname="Lixia Zhang" initials="L" surname="Zhang">
<organization></organization>
</author>
<date day="22" month="February" year="2011" />
<abstract>
<t>The continued growth in the Default Free Routing Table (DFRT)
stresses the global routing system in a number of ways. One of the
most costly stresses is FIB size: ISPs often must upgrade router
hardware simply because the FIB has run out of space, and router
vendors must design routers that have adequate FIB. FIB
suppression is an approach to relieving stress on the FIB by NOT
loading selected RIB entries into the FIB. Virtual Aggregation
(VA) allows ISPs to shrink the FIBs of any and all routers, easily
by an order of magnitude with negligible increase in path length
and load. FIB suppression deployed autonomously by an ISP
(cooperation between ISPs is not required), and can co-exist with
legacy routers in the ISP. There are no changes from the 03
version.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?rfc include="reference.I-D.zhang-evolution"?> -->
<reference anchor="EVOLUTION">
<front>
<title>Evolution Towards Global Routing Scalability</title>
<author fullname="Beichuan Zhang" initials="B" surname="Zhang">
<organization></organization>
</author>
<author fullname="Lixia Zhang" initials="L" surname="Zhang">
<organization></organization>
</author>
<author fullname="L. Wang" initials="L" surname="Wang">
<organization></organization>
</author>
<date day="26" month="October" year="2009" />
<abstract>
<t>Internet routing scalability has long been considered a serious
problem. Although many efforts have been devoted to address this
problem over the years, the IETF community as a whole is yet to
achieve a shared understanding on what is the best way forward. In
this draft, we step up a level to re-examine the problem and the
ongoing efforts. we conclude that, to effectively solve the
routing scalability problem, we first need a clear understanding
on how to introduce solutions to the Internet which is a global
scale deployed system. In this draft we sketch out our reasoning
on the need for an evolutionary path towards scaling the global
routing system, instead of attempting to introduce a brand new
design.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?rfc include="reference.I-D.whittle-ivip-arch"?> -->
<reference anchor="IVIP-ARCH">
<front>
<title>Ivip (Internet Vastly Improved Plumbing) Architecture</title>
<author fullname="Robin Whittle" initials="R" surname="Whittle">
<organization></organization>
</author>
<date day="8" month="March" year="2010" />
<abstract>
<t>Ivip (Internet Vastly Improved Plumbing) is a Core-Edge
Separation solution to the routing scaling problem, for both IPv4
and IPv6. It provides portable address "edge" address space which
is suitable for multihoming and inbound traffic engineering (TE)
to end-user networks of all types and sizes - in a manner which
imposes far less load on the DFZ control plane than the only
current method of achieving these benefits: separately advertised
PI prefixes. Ivip includes two extensions for ITR-to-ETR tunneling
without encapsulation and the Path MTU Discovery problems which
result from encapsulation - one for IPv4 and the other for IPv6.
Both involve modifying the IP header and require most DFZ routers
to be upgraded. Ivip is a good basis for the TTR (Translating
Tunnel Router) approach to mobility, in which mobile hosts retain
an SPI micronet of one or more IPv4 addresses (or IPv6 /64s) no
matter what addresses or access network they are using, including
behind NAT and on SPI addresses. TTR mobility for both IPv4 and
IPv6 involves generally optimal paths, works with unmodified
correspondent hosts and supports all application protocols.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<?rfc include="reference.RFC.1070"?>
<?rfc include="reference.RFC.3053"?>
<?rfc include="reference.RFC.4192"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.4548"?>
<?rfc include="reference.RFC.5214"?>
<?rfc include="reference.RFC.5522"?>
<!-- <?rfc include="reference.I-D.templin-intarea-seal"?> -->
<reference anchor="INTAREA-SEAL">
<front>
<title>The Subnetwork Encapsulation and Adaptation Layer
(SEAL)</title>
<author fullname="Fred Templin" initials="F" role="editor"
surname="Templin">
<organization></organization>
</author>
<date day="8" month="February" year="2011" />
<abstract>
<t>For the purpose of this document, a subnetwork is defined as a
virtual topology configured over a connected IP network routing
region and bounded by encapsulating border nodes. These virtual
topologies are manifested by tunnels that may span multiple IP
and/or sub-IP layer forwarding hops, and can introduce failure
modes due to packet duplication and/or links with diverse Maximum
Transmission Units (MTUs). This document specifies a Subnetwork
Encapsulation and Adaptation Layer (SEAL) that accommodates such
virtual topologies over diverse underlying link technologies.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?rfc include="reference.I-D.templin-intarea-vet"?> -->
<reference anchor="INTAREA-VET">
<front>
<title>Virtual Enterprise Traversal (VET)</title>
<author fullname="Fred Templin" initials="F" role="editor"
surname="Templin">
<organization></organization>
</author>
<date day="19" month="January" year="2011" />
<abstract>
<t>Enterprise networks connect hosts and routers over various link
types, and often also connect to provider networks and/or the
global Internet. Enterprise network nodes require a means to
automatically provision addresses/prefixes and support
internetworking operation in a wide variety of use cases including
Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks
(MANETs), ISP networks, multi-organizational corporate networks
and the interdomain core of the global Internet itself. This
document specifies a Virtual Enterprise Traversal (VET)
abstraction for autoconfiguration and operation of nodes in
enterprise networks.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<?rfc include="reference.RFC.5720"?>
<?rfc include="reference.RFC.5743"?>
<?rfc include="reference.RFC.5887"?>
<?rfc include="reference.RFC.4605"?>
<!-- <?rfc include="reference.I-D.irtf-rrg-recommendation"?> -->
<?rfc include="reference.RFC.6115"?>
<!-- <?rfc include="reference.I-D.russert-rangers"?> -->
<?rfc include="reference.RFC.6139"?>
<!-- <?rfc include="reference.I-D.ietf-v6ops-tunnel-security-concerns"?> -->
<reference anchor="V6OPS-TUN-SEC">
<front>
<title>Security Concerns With IP Tunneling</title>
<author fullname="Suresh Krishnan" initials="S" surname="Krishnan">
<organization></organization>
</author>
<author fullname="Dave Thaler" initials="D" surname="Thaler">
<organization></organization>
</author>
<author fullname="James Hoagland" initials="J" surname="Hoagland">
<organization></organization>
</author>
<date day="25" month="October" year="2010" />
<abstract>
<t>A number of security concerns with IP tunnels are documented in
this memo. The intended audience of this document includes network
administrators and future protocol developers. The primary intent
of this document is to raise the awareness level regarding the
security issues with IP tunnels as deployed today.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?rfc include="reference.I-D.narten-radir-problem-statement"?> -->
<reference anchor="RADIR">
<front>
<title>On the Scalability of Internet Routing</title>
<author fullname="Thomas Narten" initials="T" surname="Narten">
<organization></organization>
</author>
<date day="17" month="February" year="2010" />
<abstract>
<t>There has been much discussion over the last years about the
overall scalability of the Internet routing system. Some have
argued that the resources required to maintain routing tables in
the core of the Internet are growing faster than available
technology will be able to keep up. Others disagree with that
assessment. This document attempts to describe the factors that
are placing pressure on the routing system and the growth trends
behind those factors.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?rfc include="reference.I-D.carpenter-softwire-sample"?> -->
<reference anchor="SAMPLE">
<front>
<title>Legacy NAT Traversal for IPv6: Simple Address Mapping for
Premises Legacy Equipment (SAMPLE)</title>
<author fullname="Brian Carpenter" initials="B" surname="Carpenter">
<organization></organization>
</author>
<author fullname="Sheng Jiang" initials="S" surname="Jiang">
<organization></organization>
</author>
<date day="7" month="June" year="2010" />
<abstract>
<t>IPv6 deployment is delayed by the existence of millions of
subscriber network address translators (NATs) that cannot be
upgraded to support IPv6. This document specifies a mechanism for
traversal of such NATs. It is based on an address mapping and on a
mechanism whereby suitably upgraded hosts behind a NAT may obtain
IPv6 connectivity via a stateless server, known as a SAMPLE
server, operated by their Internet Service Provider. SAMPLE is an
alternative to the Teredo protocol.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?rfc include="reference.I-D.bernardos-mext-nemo-ro-cr"?> -->
<reference anchor="RO-CR">
<front>
<title>Correspondent Router based Route Optimisation for NEMO
(CRON)</title>
<author fullname="Carlos Bernardos" initials="C"
surname="Bernardos">
<organization></organization>
</author>
<author fullname="Maria Calderon" initials="M" surname="Calderon">
<organization></organization>
</author>
<author fullname="Ignacio Soto" initials="I" surname="Soto">
<organization></organization>
</author>
<date day="7" month="July" year="2008" />
<abstract>
<t>The Network Mobility Basic Support protocol enables networks to
roam and attach to different access networks without disrupting
the ongoing sessions that nodes of the network may have. By
extending the Mobile IPv6 support to Mobile Routers, nodes of the
network are not required to support any kind of mobility, since
packets must go through the Mobile Router-Home Agent (MRHA)
bi-directional tunnel. Communications from/to a mobile network
have to traverse the Home Agent, and therefore better paths may be
available. Additionally, this solution adds packet overhead, due
to the encapsulation. This document describes an approach to the
Route Optimisation for NEMO, based on the well-known concept of
Correspondent Router. The solution aims at meeting the currently
identified NEMO Route Optimisation requirements for Operational
Use in Aeronautics and Space Exploration. Based on the ideas that
have been proposed in the past, as well as some other extensions,
this document describes a Correspondent Router based solution,
trying to identify the most important open issues. The main goal
of this first version of the document is to describe an initial
NEMO RO solution based on the deployment of Correspondent Routers
and trigger the discussion within the MEXT WG about this kind of
solution. This document (in an appendix) also analyses how a
Correspondent Router based solution fits each of the currently
identified NEMO Route Optimisation requirements for Operational
Use in Aeronautics and Space Exploration.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<reference anchor="BGPMON">
<front>
<title>BGPmon.net - Monitoring Your Prefixes,
http://bgpmon.net/stat.php</title>
<author fullname="BGPmon.net" initials="B" surname="net">
<organization></organization>
</author>
<date month="June" year="2010" />
</front>
</reference>
<reference anchor="TTRMOB">
<front>
<title>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</title>
<author fullname="Robin Whittle" initials="R" surname="Whittle">
<organization></organization>
</author>
<author fullname="Steven Russert" initials="S" surname="Russert">
<organization></organization>
</author>
<date month="August" year="2008" />
</front>
</reference>
<reference anchor="BROKER">
<front>
<title>List of IPv6 Tunnel Brokers,
http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers</title>
<author fullname="Wikipedia" initials="W" surname="Wikipedia">
<organization></organization>
</author>
<date month="August" year="2011" />
</front>
</reference>
</references>
<?rfc rfcedstyle="yes" ?>
<section title="IRON VPs over Internetworks with Different Address Families">
<t>The IRON architecture leverages the routing system by providing
generally shortest-path routing for packets with EPA addresses from VPs
that match the address family of the underlying Internetwork. When the
VPs are of an address family that is not routable within the underlying
Internetwork, however, (e.g., when OSI/NSAP <xref
target="RFC4548"></xref> VPs are used within an IPv4 Internetwork) a
global VP mapping database is required. The mapping database allows the
Relays of the local IRON instance to map VPs belonging to other IRON
instances to companion prefixes taken from address families that are
routable within the Internetwork. For example, an IPv6 VP (e.g.,
2001:DB8::/32) could be paired with a companion IPv4 prefix (e.g.,
192.0.2.0/24) so that encapsulated IPv6 packets can be forwarded over
IPv4-only Internetworks.</t>
<t>In that case, every VP must be represented in a globally distributed
Master VP database (MVPd) that maintains VP-to-companion prefix mappings
for all VPs in the IRON. 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.</t>
<t>Upon startup, each Relay advertises an IPv4 companion prefix (e.g.,
192.0.2.0/24) into the internetwork IPv4 routing system and/or an IPv6
companion prefix (e.g., 2001:DB8::/64) into the internetwork IPv6
routing system for the IRON instance that it serves. The Relay then
configures the host number '1' in the IPv4 companion prefix (e.g., as
192.0.2.1) and the interface identifier '0' in the IPv6 companion prefix
(e.g., as 2001:DB8::0), and assigns the resulting addresses as "Relay
anycast" addresses for the IRON instance.</t>
<t>The Relay then discovers the full set of VPs for all other IRON
instances by reading the MVPd. The Relay reads the MVPd from a nearby
server and periodically checks the server for deltas since the database
was last read. After reading the MVPd, the Relay has a full list of
VP-to-companion prefix mappings. The Relay can then forward packets
toward EPAs belonging to other IRON instances by encapsulating them in
an outer header of the companion prefix address family and using the
Relay anycast address as the outer destination address.</t>
<t>Possible encapsulations in this model include IPv6-in-IPv4,
IPv4-in-IPv6, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.</t>
</section>
<section title="Scaling Considerations">
<t>Scaling aspects of the IRON architecture have strong implications for
its applicability in practical deployments. Scaling must be considered
along multiple vectors, including Interdomain core routing scaling,
scaling to accommodate large numbers of customer EUNs, traffic scaling,
state requirements, etc.</t>
<t>In terms of routing scaling, each VSP will advertise one or more VPs
into the global Internet routing system from which EPs are delegated to
customer EUNs. Routing scaling will therefore be minimized when each VP
covers many EPs. For example, the IPv6 prefix 2001:DB8::/32 contains
2^24 ::/56 EP prefixes for assignment to EUNs; therefore, the IRON could
accommodate 2^32 ::/56 EPs with only 2^8 ::/32 VPs advertised in the
interdomain routing core. (When even longer EP prefixes are used, e.g.,
/64s assigned to individual handsets in a cellular provider network,
considerable numbers of EUNs can be represented within only a single
VP.)</t>
<t>In terms of traffic scaling for Relays, each Relay represents an ASBR
of a "shell" enterprise network that simply directs arriving traffic
packets with EPA destination addresses towards Servers that service
customer EUNs. Moreover, the Relay sheds traffic destined to EPAs
through redirection, which removes it from the path for the vast
majority of traffic packets. On the other hand, each Relay must handle
all traffic packets forwarded between its customer EUNs and the non-IRON
Internet. The scaling concerns for this latter class of traffic are no
different than for ASBR routers that connect large enterprise networks
to the Internet. In terms of traffic scaling for Servers, each Server
services a set of the VSP customer EUNs. The Server services all traffic
packets destined to its EUNs but only services the initial packets of
flows initiated from the EUNs and destined to EPAs. Therefore, traffic
scaling for EPA-addressed traffic is an asymmetric consideration and is
proportional to the number of EUNs each Server serves.</t>
<t>In terms of state requirements for Relays, each Relay maintains a
list of all Servers in the IRON instance as well as FIB entries for all
customer EUNs that each Server serves. This state is therefore dominated
by the number of EUNs in the IRON instance. Sizing the Relay to
accommodate state information for all EUNs is therefore required during
overlay network planning. In terms of state requirements for Servers,
each Server maintains tunnel-neighbor state only for the customer EUNs
it serves, and not for the customers served by other Servers in the IRON
instance. Finally, neither Relays nor Servers need keep state for final
destinations of outbound traffic.</t>
<t>Clients source and sink all traffic packets originating from or
destined to the customer EUN. Therefore, traffic scaling considerations
for Clients are the same as for any site border router. Clients also
retain unidirectional tunnel state for the Servers for final
destinations of outbound traffic flows. This can be managed as soft
state, since stale entries purged from the cache will be refreshed when
new traffic packets are sent.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:50:21 |