Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational June 7, 2010
Expires: December 9, 2010
The Internet Routing Overlay Network (IRON)
draft-templin-iron-03.txt
Abstract
The Internet routing system is experiencing a growth profile that has
led many to express concerns for unsustainable routing scaling.
Operational practices such as increased use of multihoming with IPv4
Provider-Independent (PI) addressing are resulting in more and more
fine-grained prefixes injected into the routing system from more and
more end user networks. Furthermore, depletion of the remaining
public IPv4 address space has raised concerns for both increased
deaggregation (leading to yet further routing scaling) and an
impending address space runout scenario. At the same time, the IPv6
routing system is finally beginning to see significant growth in IPv6
Provider-Aggregated (PA) prefixes but there does not seem to be a
solution on the near term horizon for IPv6 PI addressing. Since the
Internet must continue to support escalating growth due to increasing
demand, it is clear that current mechanisms and operational practices
are reaching a tipping point where something must be done. This
document proposes an Internet Routing Overlay Network (IRON) for
supporting sustainable growth through PI addressing while requiring
no changes to end systems and no changes to the existing routing
system.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2010.
Templin Expires December 9, 2010 [Page 1]
Internet-Draft IRON June 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IRON Routers . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5
5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 6
5.1. IR(VP) and IR(GW) Initialization . . . . . . . . . . . . . 6
5.2. IR(EUN) Initialization . . . . . . . . . . . . . . . . . . 7
6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. IR(EUN) Operation . . . . . . . . . . . . . . . . . . . . 8
6.2. IR(VP) Operation . . . . . . . . . . . . . . . . . . . . . 9
6.3. IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 10
6.4. IRON Example Scenario . . . . . . . . . . . . . . . . . . 10
6.5. Mobility Management . . . . . . . . . . . . . . . . . . . 12
7. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Templin Expires December 9, 2010 [Page 2]
Internet-Draft IRON June 2010
1. Introduction
The Internet routing system is experiencing a growth profile that has
led many to express concerns for unsustainable routing scaling.
Operational practices such as increased use of multihoming with IPv4
Provider-Independent (PI) addressing are resulting in more and more
fine-grained prefixes injected into the routing system from more and
more end user networks. Furthermore, depletion of the remaining
public IPv4 address space has raised concerns for both increased
deaggregation (leading to yet further routing scaling) and an
impending address space runout scenario. At the same time, the IPv6
routing system is finally beginning to see significant growth in IPv6
Provider-Aggregated (PA) prefixes but there does not seem to be a
solution on the near term horizon for IPv6 PI addressing. Since the
Internet must continue to support escalating growth due to increasing
demand, it is clear that current mechanisms and operational practices
are reaching a tipping point where something must be done.
Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in
Increasing Scopes (AIS) [I-D.zhang-evolution] are global routing
proposals that introduce routing overlays using Virtual Prefixes
(VPs) to reduce router Forwarding Information Base (FIB) and Routing
Information Base (RIB) scaling. Routing and Addressing in Networks
with Global Enterprise Recursion (RANGER) [RFC5720] examines
recursive arrangements of enterprise networks that can apply to a
very broad set of use case scenarios [I-D.russert-rangers]. In
particular, RANGER supports encapsulation and secure redirection by
treating each layer in the recursive hierarchy as a virtual non-
broadcast, multiple access (NBMA) "link". RANGER is an architectural
framework that includes Virtual Enterprise Traversal (VET)
[I-D.templin-intarea-vet] and the Subnetwork Adaptation and
Encapsulation Layer (SEAL) [I-D.templin-intarea-seal] as its
functional building blocks.
This document proposes an Internet Routing Overlay Network (IRON) for
supporting sustainable growth while requiring no changes to the
existing routing system. IRON borrows concepts from VA, AIS and
RANGER, and further borrows concepts from the Internet Vastly
Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture
proposal. IRON specifically seeks to enable scalable Provider-
Independent (PI) addressing without changing the current BGP
[RFC4271] routing systems of the IPv4 and IPv6 Internets in any way.
IRON uses the IPv4 and IPv6 global Internet routing systems as
virtual NBMA links for tunneling inner network protocol packets that
use End User Network (EUN) addresses within outer IPv4 or IPv6
packets that use Routing LOCator (RLOC) addresses. Moreover, inner
packets can be either IPv4 or IPv6 without regard to the address
Templin Expires December 9, 2010 [Page 3]
Internet-Draft IRON June 2010
family used in the outer packet, and inner packets can even be non-IP
protocols such as OSI. The following sections discuss details of the
IRON architecture.
2. Terminology
The following abbreviations correspond to terms used within this
document and elsewhere in common Internetworking nomenclature:
EP - End User Network PI Prefix
ETE - Egress Tunnel Endpoint
EUN - End User Network
ISP - Internet Service Provider
ITE - Ingress Tunnel Endpoint
NBMA - Non-Broadcast, Multiple Access
PA - Provider Aggregated
PI - Provider Independent
SCMP - the SEAL Control Message Protocol
SEAL_ID - an Identification value, randomly initialized and
monotonically incremented for each SEAL protocol packet
TE - Tunnel Endpoint (i.e., either ingress or egress)
VP - Virtual Prefix
3. IRON Routers
IRON introduces a new class of routers called IRON Routers (IRs) that
can be deployed on platforms ranging from high-end enterprise routers
to simple commodity servers. Moreover, IRs can be introduced
incrementally and without affecting existing infrastructure. The
purpose of these new IRs is to provide waypoints (or "cairns") for
navigating the IRON so that packets with destination addresses taken
from End User Network PI prefixes (EPs) can be delivered to the
correct End User Networks (EUNs) through the use of encapsulation
with minimum path stretch for initial packets and optimized routes
for non-initial packets. The different categories of IRs includes:
Templin Expires December 9, 2010 [Page 4]
Internet-Draft IRON June 2010
o IR - an IRON Router of any kind
o IR(VP) - a tunnel endpoint router that is owned by a VP company
and that aggregates VPs from which it sub-delegates more-specific
EPs to EUNs.
o IR(EUN) - a tunnel endpoint router (or host with embedded gateway
function) that obtains an EP from a VP company, and that connects
an EUN to the IRON. An IR(EUN) will typically be a customer
premises equipment (CPE) device that connects the EUN to its
ISP(s), but may also be a router or even a singleton host within
the EUN.
o IR(GW) - a router that acts as a gateway between the IRON and the
non-IRON Internet. Each VP company configures one or more IR(GWs)
which advertise the company's VPs into the IPv4 and/or IPv6 global
Internet DFZs. An IR(GW) may be configured on the same physical
platform as IR(VPs), or as a separate standalone platform. An
IR(GW) will typically be a BGP router that is capable of sourcing
encapsulated packets.
IRON observes the Internet Protocol standards [RFC0791][RFC2460].
Other network layer protocols that can be encapsulated within IP
packets (e.g., OSI/CLNP [RFC1070], etc.) are also within scope.
4. The Internet Routing Overlay Network (IRON)
The Internet Routing Overlay Network (IRON) consists of IRON Routers
(IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork
Encapsulation and Adaptation Layer (SEAL) for the purpose of
forwarding encapsulated inner network layer packets over the IPv4 and
IPv6 Internets. Each such IR views the IPv4 and IPv6 global
Internets as monolithic virtual NBMA "links", and connects to the
links via a VET interface used for automatic tunneling. Each IR
therefore sees all other IRs as virtual single-hop neighbors on the
link from the standpoint of the inner network layer protocol, while
they may be separated by many physical outer IP hops. IRs are
deployed incrementally and without disturbing the existing Internet
routing system.
The IRON is manifested through a business model in which VP companies
own and manage a set of IR(VPs) that are dispersed throughout the
Internet and that serve a set of highly-aggregated VPs. Each VP
company sets up a service in which it leases EPs taken from the VPs
to customer EUNs. These EUNs may be located on the same network as
the VP company's IR(VP) routers, or they may be located elsewhere
within the Internet. The VP company acts as a virtual enterprise
Templin Expires December 9, 2010 [Page 5]
Internet-Draft IRON June 2010
network which EUNs loosely consider as their "home" network even
though they physically arrange for basic connectivity via one or more
ISP networks that may have no affiliation with the VP company. VP
companies can therefore open for business and begin serving their
customers immediately without the need to coordinate their activities
with ISPs or with other VP companies.
Each VP company also establishes a set of IR(GW) routers that connect
to the IPv4 and/or IPv6 Internet DFZs. The IR(GW) advertises all of
the vendor's IPv4 VPs into the IPv4 DFZ and advertises all of its
IPv6 VPs into the IPv6 DFZ. Each IR(GW) forwards any packets coming
from the DFZ to an IR(VP) that can encapsulate the packet and forward
it to the appropriate IR(EUN). In this way, end systems that use PA
addresses can communicate with other end systems that use PI
addresses taken from an IRON VP.
EUNs establish at least one IR(EUN) that connects the EUN to the
IRON. The IR(EUN) uses encapsulation to forward packets with PI
source addresses to an IR(VP) belonging to its VP company as a
default router. The VP company's IR(VP) then forwards the packets
toward their final destination, and returns a SEAL Control Message
Protocol (SCMP) redirect message to inform the IR(EP) of a better
next hop if necessary. In this way, IR(EPs) experience reasonable
path stretch for initial packets and can discover route-optimized
paths for subsequent packets.
In a typical scenario, an IR(EUN) 'A' forwards initial packets
addressed to another IR(EUN) 'B' through an IR(VP) in its home
network. The IR(VP) in 'A's home network then forwards the packet to
an IR(VP) in 'B's home network, then sends a redirect message to 'A'.
'A' will forward subsequent packets through an IR(VP) in 'B's home
network, which will forward the packets to IR(EUN) 'B' and return a
redirect message to 'A'. Following these redirections, subsequent
packets will flow directly from 'A' to 'B'.
5. IRON Initialization
IRON initialization entails the startup actions of VP company and EUN
equipment. The following sections discuss these startups procedures:
5.1. IR(VP) and IR(GW) Initialization
Upon startup, each IR(VP) and IR(GW) owned by the VP company
discovers the full set of VPs for the IRON. These VPs may be IPv4 or
IPv6, but they may also be prefixes of other network layer protocols
(e.g., OSI NSAP [RFC4548], etc.). Each VP is maintained in a Master
VP (MVP) flat file that consists of the union of all VPs in the IRON.
Templin Expires December 9, 2010 [Page 6]
Internet-Draft IRON June 2010
The MVP file is maintained by a globally-managed assigned numbers
authority in exactly the same manner as the Internet Assigned Numbers
Authority (IANA) currently maintains the master list of all top-level
IPv4 and IPv6 delegations. (Indeed, the IANA is proposed as the
primary registration authority for the MVP file.) Each VP in the MVP
file is encoded as the tuple: "{address family, prefix/length,
FQDN}", where:
o "address family" is one of IPv4, IPv6, OSI/CLNP, etc.
o "prefix/length" is the VP and its associated length, e.g., 2001:
DB8::/32 (IPv6), 192.2/16 (IPv4), etc.
o FQDN is a DNS Fully-Qualified Domain Name
Each IR(VP/GW) reads the MVP from a nearby server upon startup time,
and periodically checks for deltas on the server since the MVP was
last read. (The MVP can be replicated across multiple servers for
load balancing much in the same way that FTP mirror sites are used to
manage software distributions.) Upon reading the MVP, the IR(VP/GW)
resolves the FQDN corresponding to each VP into a list of DNS Well-
Known Service (WKS) resource records with an IRON-specific format (to
be specified) that includes the address family, RLOC address, and
geographic (Latitude/Longitude) coordinates at which the IR(VP) is
physically located. Each RLOC address is an IPv4 or IPv6 RLOC
address of an IR(VP) within the DFZ.
For each VP, the IR(VP/GW) sorts the list of RLOCs in order of
"geographic closeness", and inserts each "VP->RLOC" mapping into its
Forwarding Information Base (FIB) with a priority corresponding to
geographic closeness. Specifically, the FIB entries must be
configured such that packets with destination addresses covered by
the VP are forwarded to the corresponding RLOC using encapsulation of
the inner network layer packet in an outer IP header. Note that the
VP and RLOC may be of different address families; hence, possible
encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6,
IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. After each
IR(VP/GW) reads in the list of VPs and sorts the information
accordingly, it is said to be "synchronized with the IRON". Each
IR(VP) next installs all EPs derived from its VPs into its FIB based
on the mapping information received from each EUN that owns a prefix.
5.2. IR(EUN) Initialization
Upon startup, each IR(EUN) must register its EP-to-RLOC binding with
the company that owns the corresponding VP, where the RLOC is an IPv4
or IPv6 address assigned to the IR(EUN) by an ISP network. For
example, if an IR(EUN) owns the EP 192.2.1/24 (IPv4) and the RLOC
Templin Expires December 9, 2010 [Page 7]
Internet-Draft IRON June 2010
assigned to the IR(EUN) by the ISP is 2001:DB8::1 (IPv6), the IR(EUN)
informs the VP company that the route 192.2.1/24 with 2001:DB8::1 as
the L2 address of the next-hop must be added to the FIB in each of
its IR(VPs) that aggregates the EP. The IR(EUN) typically informs
the VP company by using an authenticated short transaction protocol
(e.g., http(s) with username/password) to register its EP-to-RLOC
mapping information. (The exact specification for the short
transaction is up to the VP company and need only be communicated to
the IR(EUN); the IR(EUN) also uses the same EP-to-RLOC registration
procedure to inform its VP company of a change in RLOC, e.g., due to
a mobility event.) After the IR(EUN) registers its mapping
information, the VP company then propagates it to each of its IR(VPs)
that aggregates the EP, e.g., via a routing protocol that all of the
VP company's IR(VP)s engage in.
After the IR(EUN) informs the VP company of its EP->RLOC mapping, it
resolves a FQDN for the VP company in order to discover the RLOC
addresses and geographic locations of the IR(VPs) owned by the
company. (This resolution is analogous to the ISATAP Potential
Router List (PRL) resolution procedure [RFC5214].) The IR(EUN) then
selects the closest subset of these RLOC addresses (typically 2-4
routers chosen, e.g., based on geographic distance), and adds them to
a default router list of FIB entries that each points to a tunnel
virtual interface with the RLOC as the L2 address of the next-hop.
The IR(EP) will then use these routes in the default router list as
the means for forwarding encapsulated packets with EID source
addresses toward the final destination via encapsulation.
6. IRON Operation
Following IRON initialization, IRs engage in the steady-state process
of receiving and forwarding packets. Except in instances when it
forwards an unencapsulated packet to the public Internet, the IR
encapsulates each forwarded packet using the mechanisms of VET
[I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal]. IRs
also use the SEAL Control Message Protocol (SCMP) to test liveness of
other IRs and to receive redirects informing them of a better next
hop. Each IR operates as specified in the following sections:
6.1. IR(EUN) Operation
After an IR(EUN) is initialized, it sends periodic beacons to at
least 2-4 of its VP company's IR(VP)s which serve as default routers.
Each beacon is a SEAL Control Message Protocol (SCMP) Router
Solicitation (RS) message, and will elicit an SCMP Router
Advertisement (RA) message from the IR(VP). If the IR(EUN) ceases to
receive RA messages from an IR(VP), it marks that IR(VP) as
Templin Expires December 9, 2010 [Page 8]
Internet-Draft IRON June 2010
unreachable and selects a different IR(VP). If the IR(EUN) ceases to
receive RA message from multiple IR(VPs), it marks the ISP connection
as failed/failing and uses an RLOC assigned by a different ISP to re-
register its EP-to-RLOC mapping.
When an end system in an EUN has a packet to send, the packet is
forwarded through the EUN until it reaches the IR(EUN). The source
IR(EUN) then forwards the packet either to an IR(VP) or to a
destination IR(EUN). The source IR(EUN) first checks its FIB for the
longest matching prefix. If the longest matching prefix is more-
specific than "default", the source IR(EUN) forwards the packet to
the next-hop the same as for ordinary IP forwarding. If the longest
match is "default", however, the source IR(EUN) forwards the packet
to one of its default routers.
The source IR(EUN) uses VET and SEAL to encapsulate each forwarded
packet in an outer IP header with the IP address of the next-hop IR
as the destination address. The source IR(EUN) further uses SCMP to
test liveness and/or to accept redirect messages from the next-hop
IR. When the source IR(EUN) receives an SCMP redirect, it checks the
SEAL_ID field of the encapsulated message to verify that the redirect
corresponds to a packet that it had previously sent to the neighbor
and accepts the redirect if there is a match. Thereafter, subsequent
packets forwarded by the source IR(EUN) will follow a route-optimized
path.
An IR(EUN) that accepts redirects may be redirected by an IR(VP) in
its home VP company network to one or more IR(VP)s in a "foreign"
network. In that case, the IR(EUN) has no way of knowing if these
foreign IR(VP)s are reachable and able to process encapsulated
packets. Therefore, the IR(EUN) should select multiple foreign
IR(VPs) (e.g., 2-4) and send "live" packets to one of them while
sending corresponding "blank" packets to the others. In turn, each
foreign IR(VP) accepts and forwards "live" packets, but drops "blank"
packets after sending a redirect. In this way, even if the original
packet is lost due to short- or long-term outage, the IR(EUN) should
receive a redirect from at least one of the foreign IR(VP)s.
6.2. IR(VP) Operation
After an IR(VP) is initialized, it sends RA responses to the periodic
RS beacons sent by IR(EUNs) as described in Section 6.1. When the
IR(VP) receives an encapsulated packet from another IR, it examines
the inner destination address then forwards the packet as follows:
o If the inner destination address matches an EP in its FIB, the
IR(VP) 'A' re-encapsulates the packet using VET/SEAL and forwards
it to the next-hop IR(EUN) 'B'. If the source IR 'C' is accepting
Templin Expires December 9, 2010 [Page 9]
Internet-Draft IRON June 2010
redirects, 'A' also sends an SCMP redirect message back to 'C'.
'C' will then send subsequent packets directly to 'B'.
o If the inner destination address does not match an EP but matches
a VP in its FIB, the IR(VP) 'A' re-encapsulates the packet using
VET/SEAL and forwards it to the next-hop IR(VP) 'B' . If the
source IR 'C' is accepting redirects, 'A' also sends an SCMP
redirect message back to 'C'. 'C' will then send subsequent
packets directly to 'B'.
o if the inner destination address does not match an EP or a VP in
the FIB, the IR(VP) decapsulates the packet and forwards it to the
public Internet via a default or more-specific route.
An IR(VP) that accepts redirects may need to forward encapsulated
packets via the IR(VP)s of a "foreign" network. In that case, the
IR(VP) can send a "live" packet in parallel with corresponding
"blanks" the same as for an IR(EUN).
6.3. IR(GW) Operation
Each VP company must establish one or more IR(GW) routers which
advertise the full set of the company's VP's into the IPv4 and/or
IPv6 Internet BGP. The VPs will be seen as ordinary routing
information in the BGP, and any packets originating from the non-IRON
IPv4 or IPv6 Internet will be forwarded into the VP company's network
by an IR(GW). When an IR(GW) receives a packet from the non-IRON
Internet but destined to an EP destination, it consults its FIB to
determine the best next-hop toward the final destination. The IR(GW)
then either forwards the packet to an IR(VP) within the home network
or acts as an IR(VP) itself to forward the packet further.
6.4. IRON Example Scenario
With respect to the previous sections, a path between two EUNs can
potentially involve both the two IR(EUNs) and the IR(VP)s of the two
VP companies that serve the EUNs. Route optimization based on
redirection will allow shortcuts that eliminate the IR(VP)s from the
path. The following figure depicts a simple example IRON scenario
for communications between two EUNs:
Templin Expires December 9, 2010 [Page 10]
Internet-Draft IRON June 2010
+------------+ +------------+
| | | |
/======>+ IR(VP(A)) +======>+ IR(VP(B)) +======\
// | | | | \\
// +------------+ +------------+ \\
// V
+-----+-----+ +-----+-----+
| IR(EUN(A))| ........................................>| IR(EUN(B))|
+-----+-----+ +-----+-----+
| |
........ ........
( EUN B ) ( EUN B )
........ ........
| |
+---+----+ +---+----+
| Host A | | Host B |
+--------+ +--------+
Figure 1: Example IRON Scenario
In this example scenario, VP companies A and B have established
IR(VP)s within the Internet that serve EPs to EUNs. EUN A has
procured an EP from VP company A, while EUN B has procured an EP from
VP company B. The hosts in both EUNs have assigned addresses taken
from their corresponding EPs on their EUN-interior interfaces, and
the IR(EUNs) have assigned provider-aggregated addresses taken from
their ISPs on their WAN interfaces.
When Host A in EUN A has a packet to send to Host B in EUN B, normal
routing conveys the packet from Host A to IR(EUN(A)). If IR(EUN(A
))does not have a more-specific route, it encapsulates the packet and
forwards it to an IR(VP) owned by VP company A. IR(VP(A ))
decapsulates the packet and checks its FIB for a route toward the
packet's destination address. If IR(VP(A)) does not have an EP route
to B in its FIB, it consults its full table of VP-to-RLOC mappings to
discover that the next-hop toward Host B is via IR(VP(B)). IR(VP(A))
then re-encapsulates the packet and sends it to IR(VP(B)) which has
an EP route B via IR(EUN(B)). IR(VP(B)) then re-encapsulates the
packet and sends it to IR(EUN(B)), which decapsulates the packet and
forwards it via EUN B to Host B.
In this process, when an IR(VP) re-encapsulates the packet and
forwards it to a next-hop IR, it also returns an SCMP redirect
message to the previous hop IR if the previous hop is willing to
accept redirects. The previous hop IR will then install a route in
its FIB that uses a more optimal next hop. For example, if
IR(EUN(A)) is accepting redirects IR(VP(A)) will return a redirect
message when it forwards a packet to IR(VP(B)). IR(EUN(A)) will then
Templin Expires December 9, 2010 [Page 11]
Internet-Draft IRON June 2010
send subsequent packets directly to IR(VP(B)), which will return a
redirect message when it forwards the packets to IR(EUN(B)).
Finally, IR(EUN(A)) will have an optimized route that lists
IR(EUN(B)) as the next hop (shown as "....>" in the diagram).
A more interesting redirection scenario arises when IR(VP(A)) is
itself willing to accept redirects. In that case, IR(EUN(A)) may
discover IR(EUN(B)) as a better next hop toward EUN A based solely on
a redirect message from IR(VP(A)) and without involving IR(VP(B)).
Note however that this may require IR(VP(A)) to carry thousands or
even millions of EP entries in its FIB for all EUNs that it has sent
packets to recently.
6.5. Mobility Management
When an IR(EUN) moves to a new topological location and/or changes
its primary ISP, it receives a new RLOC address. The IR(EUN) then
registers the new EP-to-RLOC mapping with its VP company the same as
during its initialization phase as described in Section 5.2.
Next, the IR(EUN) sends Neighbor Advertisement (NA) messages to each
neighboring IR from which it has received packets recently. The NA
message includes the new RLOC as the outer source address and
includes the previous RLOC within an NA option field. The
neighboring IR will update its neighbor cache so that subsequent
packets will flow through the new RLOC.
Further details on these mobility management procedures are specified
in [I-D.templin-intarea-vet] and [I-D.templin-intarea-seal].
7. Related Initiatives
IRON builds upon the concepts RANGER architecture [RFC5720], and
therefore inherits the same set of related initiatives.
Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in
Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for
the Virtual Prefix concepts.
Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has
contributed valuable insights, including the use of real-time
mapping.
8. IANA Considerations
The IANA is instructed to create a Master Virtual Prefix (MVP)
Templin Expires December 9, 2010 [Page 12]
Internet-Draft IRON June 2010
registry for IRON.
9. Security Considerations
Security considerations for RANGER apply also to IRON.
10. Acknowledgements
This ideas behind this work have benefited greatly from discussions
with colleagues; some of which appear on the RRG and other IRTF/IETF
mailing lists.
11. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
11.2. Informative References
[I-D.ietf-grow-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-ietf-grow-va-02 (work in progress), March 2010.
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "Operational
Scenarios for IRON and RANGER", draft-russert-rangers-03
(work in progress), June 2010.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-14 (work in
progress), June 2010.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-13 (work in progress),
June 2010.
[I-D.whittle-ivip-arch]
Templin Expires December 9, 2010 [Page 13]
Internet-Draft IRON June 2010
Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
Architecture", draft-whittle-ivip-arch-04 (work in
progress), March 2010.
[I-D.zhang-evolution]
Zhang, B. and L. Zhang, "Evolution Towards Global Routing
Scalability", draft-zhang-evolution-02 (work in progress),
October 2009.
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as
a subnetwork for experimentation with the OSI network
layer", RFC 1070, February 1989.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code
Point (ICP) Assignments for NSAP Addresses", RFC 4548,
May 2006.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires December 9, 2010 [Page 14]
