One document matched: draft-templin-ironbis-10.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-10.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="19" month="December" 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. In addition to routing scaling,
IRON further addresses other important issues including mobility
management, mobile networks, multihoming, traffic engineering, NAT
traversal and security. 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="RFC4984"></xref><xref target="RADIR"></xref>. Operational
practices such as the increased use of multihoming with
Provider-Independent (PI) addressing are resulting in more and more
de-aggregated 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 de-aggregation
(leading to yet further routing system 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 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> the Subnetwork Adaptation and Encapsulation
Layer (SEAL) <xref target="INTAREA-SEAL"></xref> and Asymmetric Extended
Route Optimization <xref target="AERO"></xref> as its functional
building blocks.</t>
<t>This document proposes an Internet Routing Overlay Network (IRON)
architecture with goals of supporting scalable routing and addressing
while requiring no changes to the Internet's Border Gateway Protocol
(BGP) interdomain routing system <xref target="RFC4271"></xref>. 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 <xref target="RFC0994"></xref>, etc.) are also within
scope.</t>
<t>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 is a global virtual routing system comprising Virtual Service
Provider (VSP) overlay networks that service Aggregated Prefixes (APs)
from which more-specific Client Prefixes (CPs) are delegated. IRON is
motivated by a growing end user demand for mobility management, mobile
networks, multihoming, traffic engineering, NAT traversal and security
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 Internets as virtual NBMA links for tunneling
inner network layer packets within outer network layer headers (see
Section 3). Each IRON instance requires deployment of a small number of
relays and servers in the Internet, as well as client devices that
connect End User Networks (EUNs). No modifications to hosts, and no
modifications to existing 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="Aggregated Prefix (AP):"><vspace />a short
network-layer prefix (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). The term "Aggregated
Prefix (AP)" used in this document is the equivalent to the term
"Virtual Prefix (VP)" used in Virtual Aggregation (VA) <xref
target="GROW-VA"></xref>.</t>
<t hangText="Client Prefix (CP):"><vspace />a more-specific
network-layer prefix (e.g., an IPv4 /28, an IPv6 /56, etc.) derived
from an AP and delegated to a client end user network.</t>
<t hangText="Client Prefix Address (CPA):"><vspace />a network-layer
address belonging to a CP and assigned to an interface in an End
User Network (EUN).</t>
<t hangText="End User Network (EUN):"><vspace />an edge network that
connects an end user's devices (e.g., computers, routers, printers,
etc.) to the Internet. IRON EUNs are mobile networks, and can change
their ISP attachments without having to renumber.</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 within outer headers. Each IRON instance appears as a
virtual enterprise network, and connects to the global Internet the
same as for any Autonomous System (AS).</t>
<t
hangText="IRON Client Router/Host ("Client"):"><vspace />a
customer device that logically connects EUNs to an IRON instance via
an NBMA tunnel virtual interface. The device is normally a router,
but may instead be a host if the "EUN" is a singleton end
system.</t>
<t hangText="IRON Serving Router ("Server"):"><vspace />a
VSP's IRON instance router that provides forwarding and mapping
services for Clients.</t>
<t hangText="IRON Relay Router ("Relay"):"><vspace />a
VSP's router that acts as a relay between the IRON instance and the
(native) Internet.</t>
<t hangText="IRON Agent (IA):"><vspace />generically refers to any
of an IRON Client/Server/Relay.</t>
<t hangText="IRON Instance:"><vspace />a set of IRON Agents deployed
by a VSP to service EUNs through automatic tunneling over the
Internet.</t>
<t hangText="Internet Service Provider (ISP):"><vspace />a service
provider that connects an IA to the Internet. In other words, an ISP
is responsible for providing IAs with data link services for basic
Internet connectivity.</t>
<t hangText="Locator:"><vspace />an IP address assigned to the
interface of a router or end system connected to a public or private
network over which tunnels are formed. Locators taken from public IP
prefixes are routable on a global basis, while locators taken from
private IP prefixes <xref target="RFC1918"></xref> 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 identification fields
and control messages 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="Asymmetric Extended Route Optimization (AERO):"><vspace />a
means for a destination IA to securely inform a source IA of a more
direct path.</t>
<t hangText="Virtual Service Provider (VSP):"><vspace />a company
that owns and manages a set of APs from which it delegates CPs to
EUNs.</t>
<t hangText="VSP Overlay Network:"><vspace />the same as defined
above for IRON Instance.</t>
</list></t>
</section>
<section anchor="iron" title="The Internet Routing Overlay Network">
<t>The Internet Routing Overlay Network (IRON) is the union of all
Virtual Service Provider (VSP) overlay networks (also known as "IRON
instances"). IRON provides a number of important services to End User
Networks (EUNs) that are not well supported in the current Internet
architecture, including routing scaling, mobility management, mobile
networks, multihoming, traffic engineering and NAT traversal. While the
principles presented in this document are discussed within the context
of the public global Internet, they can also be applied to any other
form of autonomous internetwork (e.g., corporate enterprise networks,
civil aviation networks, tactical military networks, etc.). Hence, the
terms "Internet" and "internetwork" are used interchangeably within this
document.</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 network layer
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 CPA addresses ~ --> ~ with CPA addresses ~
| (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) |
+-------------------------+ +-------------------------+
| | --> | |
~ Inner Packet Body ~ --> ~ Inner Packet Body ~
| | --> | |
+-------------------------+ +-------------------------+
| SEAL Trailer |
+-------------------------+
Inner packet before Outer packet after
encapsulation encapsulation]]></artwork>
</figure></t>
<t>VET specifies automatic tunneling and tunnel neighbor coordination
mechanisms, where IAs appear as neighbors on an NBMA tunnel virtual
link. SEAL specifies the format and usage of the SEAL encapsulating
header and trailer. Additionally, Asymmetric Extended Route Optimization
(AERO) <xref target="AERO"></xref> specifies the method for reducing
routing path stretch. Together, these documents specify elements of a
SEAL Control Message Protocol (SCMP) used to deterministically exchange
and authenticate neighbor discovery messages, route redirections,
indications of Path Maximum Transmission Unit (PMTU) limitations,
destination unreachables, etc.</t>
<t>Each IRON instance comprises a set of IAs distributed throughout the
Internet to provide internetworking services for a set of Aggregated
Prefixes (APs). (The APs may be owned either by the VSP, or by an
enterprise network customer the hires the VSP to manage its APs.) VSPs
delegate sub-prefixes from APs, which they provide to end users as
Client Prefixes (CPs). In turn, end users assign CPs to Client 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 end
users obtain their basic Internet connectivity. In that case, the VSP
can service its end users without the need to coordinate its activities
with ISPs or other VSPs. Further details on VSP business considerations
are out of scope for this document.</t>
<t>IRON requires no changes to end systems or to existing routers.
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 router or host that
logically connects EUNs to the VSP's IRON instance via tunnels, as
shown in <xref target="IREP"></xref>. Clients obtain CPs from their
VSPs and use them to number subnets and interfaces within the
EUNs.</t>
<t>Each Client connects to one or more Servers in the IRON instance
which serve as default routers. The Servers in turn consider this
class of Clients as "dependent" Clients. Clients also dynamically
discover destination-specific Servers through the receipt of Redirect
messages. These destination-specific Servers in turn consider this
class of Clients as "visiting" Clients.</t>
<t>A Client can be deployed on the same physical platform that also
connects EUNs to the end user's ISPs, but it may also be deployed as a
separate router 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 Connecting EUN to IRON Instance">
<artwork><![CDATA[ .-.
,-( _)-.
+--------+ .-(_ (_ )-.
| Client |--(_ ISP )
+---+----+ `-(______)-'
| <= T \ .-.
.-. u \ ,-( _)-.
,-( _)-. n .-(_ (- )-.
.-(_ (_ )-. n (_ Internet )
(_ EUN ) e `-(______)-
`-(______)-' l ___
| s => (:::)-.
+----+---+ .-(::::::::)
| Host | .-(::: IRON :::)-.
+--------+ (:::: Instance ::::)
`-(::::::::::::)-'
`-(::::::)-']]></artwork>
</figure>
</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 CPs that have been delegated to end user Clients. In typical
deployments, a VSP will deploy many Servers for the IRON instance in a
globally distributed fashion (e.g., as depicted in <xref
target="IRVE"></xref>) around the Internet so that Clients can
discover those that are nearby.</t>
<t><figure anchor="IRVE"
title="IRON Server 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. The Server
forms bidirectional tunnel neighbor relationships with each of its
dependent Clients, and can also serve as the unidirectional tunnel
neighbor egress for dynamically discovered visiting Clients. (The
Server can also form bidirectional tunnel neighbor relationships with
visiting Clients, e.g., if a security association can be formed.) Each
Server also forms bidirectional tunnel neighbor relationships with a
set of Relays that can forward packets from the IRON instance 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
connects the VSP's IRON instance to the Internet as an Autonomous
System (AS). The Relay therefore 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 VSP's APs
into the IPv4 and/or IPv6 global Internet routing systems. Each Relay
associates with the VSP's IRON instance Servers, e.g., via tunnel
virtual links over the IRON instance, via a physical 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 |
_|| | +--------+
(:::)-. (Physical Interconnects)
.-(::::::::)
+--------+ .-(::: 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 the Internet. Each such IRON instance represents a distinct "patch"
on the underlying 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 connects to the Internet as an AS in the Internet
routing system using a public BGP Autonomous System Number (ASN). The
IRON instance maintains a set of Relays that serve as ASBRs as well as a
set of Servers that provide routing and addressing services to Clients.
<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
underlying IPv4 and/or IPv6 Internets via external BGP (eBGP) peerings
with neighboring ASes. It also advertises the IPv4 APs managed by the
VSP into the IPv4 Internet routing system and advertises the IPv6 APs
managed by the VSP into the IPv6 Internet routing system. Relays will
therefore receive packets with CPA destination addresses sent by end
systems in the Internet and forward them to a Server that connects the
Client to which the corresponding CP has been delegated. Finally, the
IRON instance Relays maintain synchronization by running interior BGP
(iBGP) between themselves the same as for ordinary ASBRs.</t>
<t>In a simple VSP overlay network arrangement, each Server can be
configured as an ASBR for a stub AS using a private ASN <xref
target="RFC1930"></xref> to peer with each IRON instance Relay the same
as for an ordinary eBGP neighbor. (The Server and Relay functions can
instead be deployed together on the same physical platform as a unified
gateway.) Each Server maintains a working set of dependent Clients for
which it caches CP-to-Client mappings in its forwarding table. Each
Server also, in turn, propagates the list of CPs in its working set to
its neighboring Relays via eBGP. Therefore, each Server only needs to
track the CPs for its current working set of dependent Clients, while
each Relay will maintain a full CP-to-Server forwarding table that
represents reachability information for all CPs in the IRON
instance.</t>
<t>Each Client obtains its basic Internet connectivity from ISPs, and
connects to Servers to attach its 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. Clients may additionaly 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
or more Servers through an initial exchange followed by periodic
keepalives.</t>
<t>After a Client connects to Servers, it forwards initial outbound
packets from its EUNs by tunneling them to a Server, which may, in turn,
forward them to a nearby Relay within the IRON instance. The Client may
subsequently receive Redirect messages informing it of a more direct
route through a different IA within the IRON instance that serves the
final destination EUN.</t>
<t>IRON can also be used to support APs 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 APs of one address family over Internetworks
based on different address families are discussed in Appendix A.</t>
</section>
<section anchor="initialization" title="IRON Control Plane Operation">
<t>Each IRON instance supports routing through the control plane startup
and runtime dynamic routing operation of IAs. The following sub-sections
discuss control plane considerations for initializing and maintaining
the IRON instance routing system.</t>
<section anchor="EUN" title="IRON Client Operation">
<t>Each Client obtains one or more CPs in a secured exchange with the
VSP as part of the initial end user registration. Upon startup, the
Client discovers a list of nearby VSP Servers via, e.g., a location
broker, a well known website, a static map, etc.</t>
<t>After the Client obtains a list of nearby Servers, it initiates
short transactions to connect to one or more Servers, e.g., via
secured TCP connections. During the transaction, each Server provides
the Client with a CP and a symmetric secret key that the Client will
use to sign and authenticate messages. The Client in turn provides the
Server with a set of link identifiers ("LINK_ID"s) that represent the
Client's ISP connections. The protocol details of the transaction are
specific to the VSP, and hence out of scope for this document.</t>
<t>After the Client connects to Servers, it configures default routes
that list the Servers as next hops on the tunnel virtual interface.
The Client may subsequently discover more-specific routes through
receipt of Redirect messages.</t>
</section>
<section title="IRON Server Operation">
<t>In a simple VSP overlay network arrangement, each IRON Server is
provisioned with the locators for Relays within the IRON instance. The
Server is further configured as an ASBR for a stub AS and uses eBGP
with a private ASN to peer with each Relay.</t>
<t>Upon startup, the Server reports the list of CPs it is currently
serving to the overlay network Relays. The Server then actively
listens for Clients that register their CPs as part of their
connection establishment procedure. When a new Client connects, the
Server announces the new CP routes to its neighboring Relays; when an
existing Client disconnects, the Server withdraws its CP
announcements. This process can often be accommodated through standard
router configurations, e.g., on routers that can announce and withdraw
prefixes based on kernel route additions and deletions.</t>
</section>
<section title="IRON Relay Operation">
<t>Each IRON Relay is provisioned with the list of APs that it will
serve, as well as the locators for Servers within the IRON instance.
The Relay is also provisioned with eBGP peerings with neighboring ASes
in the Internet -- the same as for any ASBR.</t>
<t>In a simple VSP overlay network arrangement, each Relay connects to
each Server via IRON instance-internal eBGP peerings for the purpose
of discovering CP-to-Server mappings, and connects to all other Relays
using iBGP either in a full mesh or using route reflectors. (The Relay
only uses iBGP to announce those prefixes it has learned from AS
peerings external to the IRON instance, however, since all Relays will
already discover all CPs in the IRON instance via their eBGP peerings
with Servers.) The Relay then engages in eBGP routing exchanges with
peer ASes in the IPv4 and/or IPv6 Internets the same as for any
ASBR.</t>
<t>After this initial synchronization procedure, the Relay advertises
the APs to its eBGP peers in the Internet. In particular, the Relay
advertises the IPv6 APs into the IPv6 Internet routing system and
advertises the IPv4 APs into the IPv4 Internet routing system, but it
does not advertise the full list of the IRON overlay's CPs to any of
its eBGP peers. The Relay further advertises "default" via eBGP to its
associated Servers, then engages in ordinary packet-forwarding
operations.</t>
</section>
</section>
<section anchor="operation" title="IRON Forwarding Plane Operation">
<t>Following control plane initialization, IAs engage in the cooperative
process of receiving and forwarding packets. IAs forward encapsulated
packets over the IRON instance using the mechanisms of VET <xref
target="INTAREA-VET"></xref>, AERO <xref target="AERO"></xref> and SEAL
<xref target="INTAREA-SEAL"></xref>, while Relays additionally forward
packets to and from the native IPv6 and/or 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 connecting to Servers as specified in Section 5.1, the Client
registers its active ISP connections with each Server. Thereafter, the
Client 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 (each
represented by a different LINK_ID), the CP itself is used to
represent the bidirectional Client-to-Server tunnel neighbor
association. The CP therefore names this "bundle" of 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
disconnects from the failing Server and connects to a new nearby
Server. The act of disconnecting from old servers and connecting to
new servers will soon propagate the appropriate routing information
among the IRON instance's Relays.</t>
<t>When an end system in an EUN sends a flow of packets to a
correspondent in a different network, 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 its default router. 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.</t>
<t>The Client uses the mechanisms specified in VET and SEAL to
encapsulate each packet to be forwarded, and uses the redirection
procedures described in AERO to coordinate route optimization. The
Client further accepts SCMP protocol messages from its Servers,
including neighbor coordination exchanges, indications of PMTU
limitations, Redirects and other control messages. When the Client is
redirected to a foreign Server that serves a destination CP, it forms
a unidirectional tunnel neighbor association with the foreign Server
as the new next hop toward the CP. (The visiting Client can also form
a bidirectional tunnel neighbor association with the foreign Server,
e.g., if it can establish a security association.)</t>
<t>Note that Client-to-Client tunneling is also possible when both
Clients are within the same connected addressing region. In that case,
the foreign Server can allow the final destination Client to return
the redirection message, and both Clients can engage in a peer-to-peer
bidirectional tunnel neighbor relationship, e.g., through the
establishment of a security association.</t>
</section>
<section title="IRON Server Operation">
<t>After the Server associates with nearby Relays, it accepts Client
connections and authenticates the SRS messages it receives from its
already-connected 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 dependent Clients, it uses normal longest-prefix-match rules to
locate a forwarding table entry that matches the packet's inner
destination address. The Server then re-encapsulates the packet (i.e.,
it removes the outer header and replaces it with a new outer header),
sets the outer destination address to the locator address of the next
hop and forwards the packet to the next hop.</t>
<t>When the Server receives a SEAL-encapsulated data packet from a
visiting Client, it accepts the packet only if the packet's signature
is correct; otherwise, it silently drops the packet. The Server then
locates a forwarding table entry that matches the packet's inner
destination address. If the destination does not correspond to one of
the Server's dependent Clients, the Server silently drops the packet.
Otherwise, the Server re-encapsulates the packet and forwards it to
the correct dependent Client. If the Client is in the process of
disconnecting (e.g., due to mobility), the Server also returns a
Redirect message listing a NULL next hop to inform the visiting Client
that the dependent Client has moved.</t>
<t>When the Server receives a SEAL-encapsulated data packet from a
Relay, it again locates a forwarding table entry that matches the
packet's inner destination. If the destination does not correspond to
one of the Server's dependent Clients, the Server drops the packet and
sends a destination unreachable message. Otherwise, the Server
re-encapsulates the packet and forwards it to the correct dependent
Client.</t>
</section>
<section title="IRON Relay Operation">
<t>After each Relay has synchronized its APs (see Section 5.3) it
advertises them in the IPv4 and/or IPv6 Internet routing systems.
These APs will be represented as ordinary routing information in the
interdomain routing system, and any packets originating from the IPv4
or IPv6 Internet destined to an address covered by one of the APs will
be forwarded to one of the VSP's Relays.</t>
<t>When a Relay receives a packet from the Internet destined to a CPA
covered by one of its APs, it behaves as an ordinary IP router.
Specifically, the Relay looks in its forwarding table to discover a
locator of a Server that serves the CP covering the destination
address. The Relay then simply forwards the packet to the Server,
e.g., via SEAL encapsulation over a tunnel virtual link, via a
physical interconnect, etc.</t>
<t>When a Relay receives a packet from a Server destined to a CPA
serviced by a different Server, the Relay forwards the packet toward
the correct Server while also sending a "predirect" indication as the
initial leg in the AERO redirection procedure. When the target Server
returns a Redirect message, the Relay proxies the Redirect by
re-encapsulating it and forwarding it to the previous hop.</t>
</section>
</section>
<section title="IRON Reference Operating Scenarios">
<t>IRON supports communications when one or both hosts are located
within CP-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 IRON Client. The Client
then tunnels the packets to the Server, which simply re-encapsulates
and forwards 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 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) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) (_ 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 encapsulates
them in outer IP/SEAL/* headers with its locator address as the
outer source address, the locator address of Server(S) as the outer
destination address, and the identifying information associated with
its tunnel neighbor state as the identity. Client(A) then simply
forwards the encapsulated packets into the 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 forwarding table 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 identification 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>
</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) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) (_ 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 IP/SEAL/* headers that use the source address,
destination address, and identification parameters associated with
the tunnel neighbor state for Server(A). Client(A) then forwards the
encapsulated packets into the ISP network connection that provided
its locator, which 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) and
consults its forwarding table to determine that the most-specific
matching route is via Relay(R) as the next hop. Server(A) then
re-encapsulates the packets in outer headers that use the source
address, destination address, and identification parameters
associated with Relay (R), and forwards them into the Internet where
routing will direct them to Relay(R). (Note that the Server could
instead forward the packets directly to the Relay without
encapsulation when the Relay is directly connected, e.g., via a
physical interconnect.)</t>
<t>Relay(R) receives the forwarded packets from Server(A) then
checks its forwarding table to discover a CP entry that covers inner
destination address B with Server(B) as the next hop. Relay(R) then
sends a "predirect" indication forward to Server(B) to inform the
server that a Redirect message must be returned (the "predirect" may
be either a separate control message or an indication setting on the
data packet itself). Relay(R) finally re-encapsulates the packets in
outer headers that use the source address, destination address, and
identification parameters associated with Server(B), then forwards
them into the Internet where routing will direct them to Server(B).
(Note again that the Relay could instead forward the packets
directly to the Server, e.g., via a physical interconnect.)</t>
<t>Server(B) receives the "predirect" indication and forwarded
packets from Relay(R), then checks its forwarding table to discover
a CP entry that covers destination address B with Client(B) as the
next hop. Server(B) returns a Redirect message to Relay(R), which
proxies the message back to Server(A), which then proxies the
message back to Client(A).</t>
<t>Server(B) then re-encapsulates the packets in outer headers that
use the source address, destination address, and identification
parameters associated with Client(B), then forwards them 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>After the initial flow of packets, Client(A) will have received
one or more Redirect messages listing Server(B) as a better next
hop, and will establish unidirectional tunnel neighbor state listing
Server(B) as the next hop toward the CP 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) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) (_ EUN B |)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ ----> == Native +----+---+ |
+-| Host A | ====> == Tunnel | Host B |<+
+--------+ +--------+]]></artwork>
</figure></t>
</section>
<section title="Client-to-Client Tunneling">
<t>In the scenarios shown in Sections 7.1.1 and 7.1.2, if the
foreign Server has knowledge that a source Client is within the same
addressing realm as the target dependent Client, and the Server also
knows that the two Clients are capable of coordinating any security
associations and mobility events, then the Server can allow the
dependent Client to return the redirection message. In that case,
the two Clients become peers in either a unidirectional or
bidirectional tunnel neighbor relationship as shown in <xref
target="example3"></xref>:</t>
<t><figure anchor="example3" title="Client-to-Client Tunneling">
<artwork><![CDATA[ ________________________________________
.-( )-.
.-( )-.
.-( )-.
.( ).
.( ).
.( ).
( +=======================================================+ )
( // \\ )
( // .-. .-. \\ )
( //,-( _)-. ,-( _)-\\ )
( .||_ (_ )-. .-(_ (_ ||. )
((_|| ISP A .) (__ ISP B ||_))
( ||-(______)-' `-(______)|| )
( vv | | vv )
( +-----+-----+ +-----+-----+ )
| Client(A) | | Client(B) |
+-----+-----+ VSP IRON Instance +-----+-----+
^ | ( (Overlaid on the Native Internet) ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) (_ 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) |
+-----+-----+ +-----+-----+
^ | ( ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) ( 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 forwards them into the
Internet routing system where they will be directed to
Server(A).</t>
<t>Server(A) receives the encapsulated packets from Client(A) then
forwards them to Relay(A), which simply 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 for simplicity Server(A) and Relay(A) are depicted in <xref
target="example5"></xref> as two concatenated "half-routers", and
the forwarding between the two halves is via encapsulation, via a
physical interconnect, via a shared memory operation when the two
halves are within the same physical platform, etc.)</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) |
+-----+-----+ +-----+-----+
| | ( ) | |
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) ( 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).</t>
<t>Server(A) will then check its forwarding table to discover an
entry that covers destination address A with Client(A) as the next
hop. Server(A) then (re-)encapsulates the packets and forwards them
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 +-----+-----+
^ | ( ) | ^
| .-. .-( .-) .-. |
| ,-( _)-. .-(________________________)-. ,-( _)-. |
.|(_ (_ )-. .-(_ (_ )|
(_| EUN A ) (_ EUN B |)
|`-(______)-' `-(______)-|
| | Legend: | |
| +---+----+ <---> == Native +----+---+ |
+>| Host A | <===> == Tunnel | Host B |<+
+--------+ +--------+]]></artwork>
</figure></t>
</section>
</section>
<section title="Mobility, Multiple Interfaces, Multihoming, and Traffic Engineering">
<t>While IRON Servers and Relays are typically arranged 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
Clients.</t>
<section title="Mobility Management and Mobile Networks">
<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 bidirectional tunnel neighbors of
any locator changes. This operation is performance sensitive and
should be conducted immediately to avoid packet loss. This aspect of
mobility can be classified as a "localized mobility event".</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. If the Client's current Server is no longer
close by, 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. This aspect of mobility can be
classified as a "global mobility event".</t>
<t>To move to a new Server, the Client first engages in the CP
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 CP advertisements from the IRON instance
routing system and retain the (stale) forwarding table entries until
their lifetime expires. In the interim, the former 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>
<t>Note that the Client may be either a mobile host or a mobile
router. In the case of a mobile router, the Client's EUN becomes a
mobile network, and can continue to use the Client's CPs without
renumbering even as it moves between different network attachment
points.</t>
</section>
<section title="Multiple Interfaces and Multihoming">
<t>A Client may register multiple ISP connections with each Server
such that multiple interfaces are naturally supported. This feature
results in the Client "harnessing" its multiple ISP connections into a
"bundle" that is represented as a single entity at the network layer,
and therefore allows for ISP independence at the link-layer.</t>
<t>A Client may further register with multiple Servers for fault
tolerance and reduced routing stretch. In that case, the Client should
register its full bundle of ISP connections with each of its Servers
unless it has a way of carefully coordinating its ISP-to-Server
mappings.</t>
<t>Client registration with multiple Servers results in
"pseudo-multihoming", in which the multiple homes are within the same
VSP IRON instance and hence share fate with the health of the IRON
instance itself.</t>
</section>
<section title="Traffic Engineering">
<t>A Client can dynamically adjust its ISP-to-Server mappings 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>
<t>A Client can select outgoing ISPs, 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, end
users will be motivated to select their basic Internet connectivity
solutions through healthy competition between ISPs. If an end user's
network-layer addresses are tied to a specific ISP, however, they may be
forced to undergo a painstaking renumbering even if they wish to change
to a different ISP <xref target="RFC4192"></xref><xref
target="RFC5887"></xref>.</t>
<t>When an end user Client obtains CPs from a VSP, it can change between
ISPs seamlessly and without need to renumber the CPs. IRON therefore
provides ISP independence at the link layer. If the end user is later
compelled to change to a different VSP, however, it would be obliged to
abandon its CPs and obtain new ones from the new VSP. In that case, the
Client would again be required to engage in a painstaking renumbering
event.</t>
<t>In order to avoid all future renumbering headaches, a Client that is
part of a cooperative collective (e.g., a large enterprise network)
could join together with the collective to obtain a suitably large PI
prefix then and hire a VSP to manage the prefix on behalf of the
collective. If the collective later decides to switch to a new VSP, it
simply revokes its PI prefix registration with the old VSP and activates
its registration with the new VSP.</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 an IRON 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 encapsulation format to use a transport
protocol that supports NAT traversal, e.g., UDP, TCP, etc.</t>
<t>Since the Server maintains state about its dependent Clients, it can
discover locator information for each Client by examining the transport
port number and IP address in the outer headers of the Client's
encapsulated 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 transport 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>In order to keep NAT and Server connection state alive, the Client
sends periodic beacons to the server, e.g., by sending an SRS message to
elicit an SRA message from the Server. IRON does not otherwise 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.) are out of scope and will be
discussed in a future document.</t>
</section>
<section title="Nested EUN Considerations">
<t>Each Client configures a locator that may be taken from an ordinary
non-CPA address assigned by an ISP or from a CPA address taken from a CP
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 CPA(B) taken from
the CP assigned to EUN(B). Client(B) in turn configures a locator CPA(C)
taken from the CP assigned to EUN(C). Finally, Client(C) configures a
locator ISP(D) taken from a non-CPA address delegated by an ordinary
ISP(D).</t>
<t>Using this example, the "nested-IRON" case must be examined in which
a Host A, which configures the address CPA(A) within EUN(A), exchanges
packets with Host Z located elsewhere in a different IRON instance
EUN(Z).</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 ___
| CPA(C) s => (:::)-.
+-----+-----+ .-(::::::::)
| Client(B) | .-(: Multiple :)-. +-----------+
+-----+-----+ (:::::: IRON ::::::) | Relay(Z) |
| `-(: Instances:)-' +-----------+
.-. `-(::::::)-' +-----------+
,-( _)-. | Server(Z) |
.-(_ (_ )-. +---------------+ +-----------+
(_ EUN(B) ) |Relay/Server(C)| +-----------+
`-(______)-' +---------------+ | Client(Z) |
| CPA(B) +---------------+ +-----------+
+-----+-----+ |Relay/Server(B)| |
| Client(A) | +---------------+ .-.
+-----------+ +---------------+ ,-( _)-.
| |Relay/Server(A)| .-(_ (_ )-.
.-. +---------------+ (_ EUN(Z) )
,-( _)-. CPA(A) `-(______)-'
.-(_ (_ )-. +--------+ +--------+
(_ EUN(A) )---| Host A | | Host Z |
`-(______)-' +--------+ +--------+]]></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 CPA(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
CPA(B) as the outer source address and Server(A) as the outer
destination address then forwards the once-encapsulated packet into
EUN(B).</t>
<t>Routing within EUN(B) will direct the packet to Client(B), which
encapsulates it in an outer header with CPA(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 via the Internet to Server(C).</t>
<t>When Server(C) receives the triple-encapsulated packet, it forwards
it to Relay(C) which removes the outer layer of encapsulation and
forwards the resulting twice-encapsulated packet into the Internet to
Server(B). Next, Server(B) forwards the packet to Relay(B) which
removes the outer layer of encapsulation and forwards the resulting
once-encapsulated packet into the Internet to Server(A). Next,
Server(A) forwards the packet to Relay(A), which decapsulates it and
forwards the resulting inner packet via the Internet to Relay(Z).
Relay(Z), in turn, forwards the packet to Server(Z), which
encapsulates and forwards the packet to Client(Z), which decapsulates
it and forwards the inner packet to Host Z.</t>
</section>
<section title="Host Z Sends Packets to Host A">
<t>When Host Z sends a packet to Host A, forwarding in EUN(Z) will
direct it to Client(Z), which encapsulates and forwards the packet to
Server(Z). Server(Z) will forward the packet to Relay(Z), which will
then decapsulate and forward the inner packet into the Internet.
Internet routing will convey the packet to Relay(A) as the next-hop
towards CPA(A), which then forwards it to Server(A).</t>
<t>Server (A) encapsulates the packet and forwards it to Relay(B) as
the next-hop towards CPA(B) (i.e., the locator for CPA(A)). Relay(B)
then forwards the packet to Server(B), which encapsulates it a second
time and forwards it to Relay(C) as the next-hop towards CPA(C) (i.e.,
the locator for CPA(B)). Relay(C) then forwards the packet to
Server(C), which encapsulates it a third time and forwards it to
Client(C).</t>
<t>Client(C) then decapsulates the packet and forwards the resulting
twice-encapsulated packet via EUN(C) to Client(B). Client(B) in turn
decapsulates the packet and forwards the resulting once-encapsulated
packet via EUN(B) to Client(A). Client(A) finally decapsulates and
forwards the inner packet to Host A.</t>
</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 as long as they are
appropriately managed to provide acceptable service levels to end
users.</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 work seamlessly with existing and emerging services
within the native Internet. In particular, end users serviced by an IRON
instance will receive the same service enjoyed by end users serviced by
non-IRON service providers. Internet services already deployed within
the native Internet also need not make any changes to accommodate IRON
end users.</t>
<t>The IRON system operates between IAs within the Internet and EUNs.
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, IAs 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, mobile networks, 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
service model, 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>
<t>In order to ensure acceptable end user service levels, the VSP should
conduct a traffic scaling analysis and distribute sufficient Relays and
Servers for the IRON instance globally throughout the Internet.</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 NBMA
virtual link model <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="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.</t>
</section>
<section anchor="secure" title="Security Considerations">
<t>Security considerations that apply to tunneling in general are
discussed in <xref target="RFC6169"></xref>. Additional considerations
that apply also to IRON are discussed in RANGER <xref
target="RFC5720"></xref><xref target="RFC6139"></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. As for all Internet
communications, the IRON system also depends on Relays acting with
integrity and not injecting false advertisements into the Internet
routing system (e.g., to mount traffic siphoning attacks).</t>
<t>IRON Servers must perform source address verification on the packets
they accept from IRON Clients. Clients must therefore include a
signature on each packet that the Server can use to verify that the
Client is authorized to use the source address. Source address
verification considerations are discussed in <xref
target="I-D.ietf-savi-framework"></xref>.</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. 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 CP<->Server bindings. Also,
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 <xref
target="RFC4301"></xref> or TLS/SSL <xref target="RFC5246"></xref> 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>
<t>Discussions with colleagues following the publication of RFC6179 have
provided useful insights that have resulted in significant improvements
to this, the Second Edition of IRON.</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.I-D.ietf-savi-framework"?>
<?rfc ?>
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.1930"?>
<?rfc include="reference.RFC.3053"?>
<?rfc include="reference.RFC.4192"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.0994"?>
<?rfc include="reference.RFC.5214"?>
<?rfc include="reference.RFC.5522"?>
<!-- <?rfc include="reference.I-D.templin-aero"?> -->
<reference anchor="AERO">
<front>
<title>Asymmetric Extended Route Optimization (AERO)</title>
<author fullname="Fred Templin" initials="F" role="editor"
surname="Templin">
<organization></organization>
</author>
<date day="23" month="June" year="2011" />
<abstract>
<t>Nodes (i.e., gateways, routers and hosts) attached to link
types such as multicast-capable, shared media and non-broadcast
multiple access (NBMA), etc. can exchange packets as neighbors on
the link. Each node should therefore be able to discover a
neighboring gateway that can provide default routing services to
reach off-link destinations, and should also accept redirection
messages from the gateway informing it of a neighbor that is
closer to the final destination. This redirect function can
provide a useful route optimization, since the triangular path
from the ingress link neighbor, to the gateway, and finally to the
egress link neighbor may be considerably longer than the direct
path between the neighbors. However, ordinary redirection may lead
to operational issues on certain link types and/or in certain
deployment scenarios. This document therefore introduces an
Asymmetric Extended Route Optimization (AERO) capability that
addresses the issues.</t>
</abstract>
</front>
<seriesInfo name="Work in" value="Progress" />
</reference>
<!-- <?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.4984"?>
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.5246"?>
<?rfc include="reference.RFC.5720"?>
<?rfc include="reference.RFC.5743"?>
<?rfc include="reference.RFC.5887"?>
<?rfc include="reference.RFC.4605"?>
<?rfc include="reference.RFC.6115"?>
<?rfc include="reference.RFC.6139"?>
<?rfc include="reference.RFC.6169"?>
<!-- <?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 Operation over Internetworks with Different Address Families">
<t>The IRON architecture leverages the routing system by providing
generally shortest-path routing for packets with CPA addresses from APs
that match the address family of the underlying Internetwork. When the
APs are of an address family that is not routable within the underlying
Internetwork, however, (e.g., when OSI/NSAP <xref
target="RFC0994"></xref> APs are used over an IPv4 Internetwork) a
global Master AP mapping database (MAP) is required. The MAP allows the
Relays of the local IRON instance to map APs belonging to other IRON
instances to addresses taken from companion prefixes of address families
that are routable within the Internetwork. For example, an IPv6 AP
(e.g., 2001:DB8::/32) could be paired with one or more companion IPv4
prefixes (e.g., 192.0.2.0/24) so that encapsulated IPv6 packets can be
forwarded over IPv4-only Internetworks. (In the limiting case, the
companion prefixes could themselves be singleton addresses, e.g.,
192.0.2.1/32).</t>
<t>The MAP is maintained by a globally managed authority, e.g. 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 MAP can be replicated across multiple servers for load balancing
using common Internetworking server hierarchies, e.g., the DNS caching
resolvers, ftp mirror servers, etc.</t>
<t>Upon startup, each Relay advertises IPv4 companion prefixes (e.g.,
192.0.2.0/24) into the IPv4 Internetwork routing system and/or IPv6
companion prefixes (e.g., 2001:DB8::/64) into the IPv6 Internetwork
routing system for the IRON instance that it serves. The Relay then
selects singleton host numbers within the IPv4 companion prefixes (e.g.,
192.0.2.1) and/or IPv6 companion prefixes (e.g., as 2001:DB8::0), and
assigns the resulting addresses to its Internetwork interfaces. (When
singleton companion prefixes are used (e.g., 192.0.2.1/32), the Relay
does not advertise a the companion prefixes but instead simply assigns
them to its Internetwork interfaces and allows standard Internet routing
to direct packets to the interfaces.)</t>
<t>The Relay then discovers the APs for other IRON instances by reading
the MAP, either a priori or on-demand of data packets addressed to other
AP destinations. The Relay reads the MAP from a nearby MAP server and
periodically checks the server for deltas since the database was last
read. The Relay can then forward packets toward CPAs 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. Details of how
the DNS can be used as a MAP are given in Section 5.4 of VET <xref
target="INTAREA-VET"></xref>.</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 EUNs, traffic scaling, state
requirements, etc.</t>
<t>In terms of routing scaling, each VSP will advertise one or more APs
into the global Internet routing system from which CPs are delegated to
end users. Routing scaling will therefore be minimized when each AP
covers many CPs. For example, the IPv6 prefix 2001:DB8::/32 contains
2^24 ::/56 CP prefixes for assignment to EUNs; therefore, the VSP could
accommodate 2^32 ::/56 CPs with only 2^8 ::/32 APs advertised in the
interdomain routing core. (When even longer CP prefixes are used, e.g.,
/64s assigned to individual handsets in a cellular provider network,
many more EUNs can be represented within only a single AP.)</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 CPA destination addresses towards Servers that service the
corresponding Clients. Moreover, the Relay sheds traffic destined to
CPAs through redirection, which removes it from the path for the
majority of traffic packets between Clients within the same IRON
instance. On the other hand, each Relay must handle all traffic packets
forwarded between the CPs it manages and the rest of the 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
CPs. The Server services all traffic packets destined to its own CPs but
only services the initial packets of flows initiated from its own CPs
and destined to other CPs. Therefore, traffic scaling for CPA-addressed
traffic is an asymmetric consideration and is proportional to the number
of CPs each Server serves.</t>
<t>In terms of state requirements for Relays, each Relay maintains a
list of Servers in the IRON instance as well as forwarding table entries
for the CPs that each Server handles. This Relay state is therefore
dominated by the total number of CPs handled by the Relay's associated
Servers. Keeping in mind that current day core router technologies are
only capable of handling fast-path FIB cache sizes of O(1M) entries, a
large-scale deployment may require that the total CP database for the
VSP overlay be spread between the FIBs of a mesh of Relays rather than
fully-resident in the FIB of each Relay. In that case, the techniques of
Virtual Aggregation (VA) may be useful in bridging together the mesh of
Relays. Alternatively, each Relay could elect to keep some or all CP
prefixes out of the FIB and maintain them only in a slow-path forwarding
table. In that case, considerably more CP entries could be kept in each
Relay at the cost of incurring slow-path processing for the initial
packets of a flow.</t>
<t>In terms of state requirements for Servers, each Server maintains
state only for the CPs it serves, and not for the CPs handled 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 CP. Therefore, traffic scaling considerations for
Clients are the same as for any site border router. Clients also retain
tunnel neighbor state 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 05:26:24 |