[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 6179

Internet Research Task Force                             F. Templin, Ed.
(IRTF)                                      Boeing Research & Technology
Internet-Draft                                             June 23, 2010
Intended status: Informational
Expires: December 25, 2010


              The Internet Routing Overlay Network (IRON)
                       draft-templin-iron-06.txt

Abstract

   Since the Internet must continue to support escalating growth due to
   increasing demand, it is clear that current routing architectures and
   operational practices must be updated.  This document proposes an
   Internet Routing Overlay Network for supporting sustainable growth
   through Provider Independent addressing while requiring no changes to
   end systems and no changes to the existing routing system.  This
   document is a product of the IRTF Routing Research Group (RRG).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 25, 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



Templin                 Expires December 25, 2010               [Page 1]


Internet-Draft                    IRON                         June 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Internet Routing Overlay Network (IRON)  . . . . . . . . .  5
     3.1.  IR(EP)s - IRON Routers That Connect End User Networks
           to the IRON  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  IR(VP)s - IRON Routers That Serve Virtual Prefixes . . . .  7
     3.3.  IR(GW)s - IRON Routers that Connect VPC Networks to
           the Internet . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  IRON Organizational Principles . . . . . . . . . . . . . . . .  9
   5.  IRON Initialization  . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  IR(VP) and IR(GW) Initialization . . . . . . . . . . . . . 10
     5.2.  IR(EP) Initialization  . . . . . . . . . . . . . . . . . . 11
   6.  IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  IR(EP) Operation . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  IR(VP) Operation . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 14
     6.4.  IRON Reference Operating Scenarios . . . . . . . . . . . . 14
       6.4.1.  Two Hosts in Different IRON EUNs . . . . . . . . . . . 14
       6.4.2.  Mixed IRON and Non-IRON Hosts  . . . . . . . . . . . . 16
     6.5.  Mobility, Multihoming and Traffic Engineering
           Considerations . . . . . . . . . . . . . . . . . . . . . . 18
       6.5.1.  Mobility Management  . . . . . . . . . . . . . . . . . 18
       6.5.2.  Multihoming  . . . . . . . . . . . . . . . . . . . . . 18
       6.5.3.  Inbound Traffic Engineering  . . . . . . . . . . . . . 18
       6.5.4.  Outbound Traffic Engineering . . . . . . . . . . . . . 18
     6.6.  Renumbering Considerations . . . . . . . . . . . . . . . . 19
     6.7.  NAT Traversal Considerations . . . . . . . . . . . . . . . 19
   7.  Open Research Areas  . . . . . . . . . . . . . . . . . . . . . 20
   8.  Related Initiatives  . . . . . . . . . . . . . . . . . . . . . 20
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23








Templin                 Expires December 25, 2010               [Page 2]


Internet-Draft                    IRON                         June 2010


1.  Introduction

   Growth in the number of entries carried in the Internet routing
   system has led to concerns for unsustainable routing scaling
   [I-D.narten-radir-problem-statement].  Operational practices such as
   increased use of multihoming with IPv4 Provider-Independent (PI)
   addressing are resulting in more and more fine-grained prefixes
   injected into the routing system from more and more end user
   networks.  Furthermore, the forthcoming depletion of the public IPv4
   address space has raised concerns for both increased deaggregation
   (leading to yet further routing table entries) and an impending
   address space run-out scenario.  At the same time, the IPv6 routing
   system is beginning to see growth in IPv6 Provider-Aggregated (PA)
   prefixes [BGPMON] which must be managed in order to avoid the same
   routing scaling issues the IPv4 Internet now faces.  Since the
   Internet must continue to scale to accommodate increasing demand, it
   is clear that new routing methodologies and operational practices are
   needed.

   Several related works have investigated routing scaling issues and
   proposed solutions.  Virtual Aggregation (VA) [I-D.ietf-grow-va] and
   Aggregation in Increasing Scopes (AIS) [I-D.zhang-evolution] are
   global routing proposals that introduce routing overlays with Virtual
   Prefixes (VPs) to reduce the number of entries required in each
   router's Forwarding Information Base (FIB) and Routing Information
   Base (RIB).  Routing and Addressing in Networks with Global
   Enterprise Recursion (RANGER) [RFC5720] examines recursive
   arrangements of enterprise networks that can apply to a very broad
   set of use case scenarios [I-D.russert-rangers].  In particular,
   RANGER supports encapsulation and secure redirection by treating each
   layer in the recursive hierarchy as a virtual non-broadcast, multiple
   access (NBMA) "link".  RANGER is an architectural framework that
   includes Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet]
   and the Subnetwork Adaptation and Encapsulation Layer (SEAL)
   (including the SEAL Control Message Protocol (SCMP))
   [I-D.templin-intarea-seal] as its functional building blocks.

   This document proposes an Internet Routing Overlay Network (IRON)
   with goals of supporting sustainable growth while requiring no
   changes to the existing routing system.  IRON borrows concepts from
   VA, AIS and RANGER, and further borrows concepts from the Internet
   Vastly Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture
   proposal.  IRON specifically seeks to provide scalable PI addressing
   without changing the current BGP [RFC4271] routing system.  IRON
   observes the Internet Protocol standards [RFC0791][RFC2460].  Other
   network layer protocols that can be encapsulated within IP packets
   (e.g., OSI/CLNP [RFC1070], etc.) are also within scope.




Templin                 Expires December 25, 2010               [Page 3]


Internet-Draft                    IRON                         June 2010


   The IRON is a global overlay network routing system comprising
   Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes
   (VPs) from which End User Network (EUN) PI prefixes (EPs) are
   delegated to customer sites.  The IRON is motivated by a growing
   customer demand for multihoming, mobility management and traffic
   engineering while using stable PI addressing to avoid network
   renumbering [RFC4192][RFC5887].  The IRON uses the existing IPv4 and
   IPv6 global Internet routing systems as virtual links for tunneling
   inner network protocol packets within outer IPv4 or IPv6 headers
   (see: Section 3).  The IRON requires deployment of a small number of
   new routers that are simple commodity hardware platforms.  No
   modifications to hosts, and no modifications to most routers are
   required.

   Note: This document is offered in compliance with Internet Research
   Task Force (IRTF) document stream procedures [RFC5743]; it is not an
   IETF product and is not a standard.  The views in this document were
   considered controversial by the IRTF Routing Research Group (RRG) but
   the RG reached a consensus that the document should still be
   published.  The document will undergo a period of review within the
   RRG and through selected expert reviewers prior to publication.  The
   following sections discuss details of the IRON architecture.


2.  Terminology

   This document makes use of the following terms:

   End User Network (EUN)
      an edge network that connects an organization's devices (e.g.,
      computers, routers, printers, etc.) to the Internet and possibly
      also the IRON.

   Internet Service Provider (ISP)
      a service provider which physically connects customer EUNs to the
      Internet.

   Provider Assigned (PA) prefix
      a network layer address prefix delegated to an EUN by a service
      provider.

   Provider Independent (PI) prefix
      a network layer address prefix delegated to an EUN by a third
      party independently of the EUN's ISP arrangements.







Templin                 Expires December 25, 2010               [Page 4]


Internet-Draft                    IRON                         June 2010


   Virtual Prefix (VP)
      a highly-aggregated PI prefix block (e.g., an IPv4 /16, an IPv6
      /20, etc.) that is owned and managed by a Virtual Prefix Company
      (VPC).

   Virtual Prefix Company (VPC)
      a company that owns and manages one or several VPs from which it
      delegates End User Network PI Prefixes (EPs) to EUNs

   Master Virtual Prefix database (MVPd)
      a distributed database that maintains VP-to-locator mappings for
      all VPs in the IRON.

   End User Network PI prefix (EP)
      a more-specific PI prefix derived from a VP (e.g., an IPv4 /28, an
      IPv6 /56, etc.) and delegated to an EUN by a VPC.

   EP Address (EPA)
      a network layer address taken from an EP address range and
      assigned to the interface of an end system in an EUN.  EPAs are
      routable only within EUNs.

   locator
      an IP address taken from a non-EP address range and assigned to
      the interface of a router or end system within a public or private
      network.  Locators taken from public IP address spaces are
      routable within the global Internet while locators taken from
      private IP address spaces are routable only within the network
      where the private IP addressing plan is deployed.

   Internet Routing Overlay Network (IRON)
      an overlay network configured over the global Internet.  The IRON
      supports routing through encapsulation of inner packets with EPA
      addresses within outer headers that use locator addresses.


3.  The Internet Routing Overlay Network (IRON)

   The Internet Routing Overlay Network (IRON) consists of IRON Routers
   (IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork
   Encapsulation and Adaptation Layer (SEAL) to encapsulate inner
   network layer packets within outer IP headers (see: Figure 1) for
   transmission over the global Internet.  Each such IR connects to the
   IRON via a VET tunnel virtual 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.




Templin                 Expires December 25, 2010               [Page 5]


Internet-Draft                    IRON                         June 2010


                                         +-------------------------+
                                         |   Outer Packet Header   |
                                         ~  with locator addresses ~
                                         |     (IPv4 or IPv6)      |
       +-------------------------+       +-------------------------+
       |   Inner Packet Header   |  -->  |   Inner Packet Header   |
       ~    with EP addresses    ~  -->  ~    with EP addresses    ~
       | (IPv4, IPv6, OSI, etc.) |  -->  | (IPv4, IPv6, OSI, etc.) |
       +-------------------------+       +-------------------------+
       |                         |  -->  |                         |
       ~    Inner Packet Body    ~  -->  ~    Inner Packet Body    ~
       |                         |  -->  |                         |
       +-------------------------+       +-------------------------+

          Inner packet before                Outer packet after
          before encapsulation               after encapsulation

     Figure 1: Encapsulation of Inner Packets Within Outer IP Headers

   The IRON is manifested through a business model in which Virtual
   Prefix Companies (VPCs) own and manage a set of IRs that are
   distributed throughout the Internet and serve highly-aggregated
   Virtual Prefixes (VPs).  VPCs delegate sub-prefixes from their VPs
   which they lease to customers as End User Network PI prefixes (EPs).
   The customers in turn assign the EPs to their customer premises IRs
   which connect their End User Networks (EUNs) to the IRON.  VPCs may
   have no affiliation with the ISP networks from which customers obtain
   their basic connectivity.  Therefore, VPCs can open for business and
   begin serving their customers immediately without the need to
   coordinate their activities with ISPs or with other VPCs.

   The IRON requires no changes to end systems and no changes to most
   routers in the Internet.  Instead, the IRON comprises IRs that are
   deployed either as new platforms or as modifications to existing
   platforms.  IRs may be deployed incrementally without disturbing the
   existing Internet routing system, and act as waypoints (or "cairns")
   for navigating the IRON.  The functional roles of IRs are described
   in the following sections.

3.1.  IR(EP)s - IRON Routers That Connect End User Networks to the IRON

   An "IR(EP)" is a tunnel endpoint router (or host with embedded
   gateway function) that logically connects its EUNs to the IRON via
   tunnels.  IR(EP)s obtain EPs from VPCs and use them to number subnets
   and interfaces within their EUNs.  An IR(EP) can be deployed as a
   Customer Premises Equipment (CPE) router that also physically
   connects its EUNs to its ISPs, but it may also be a router or even a
   singleton end system within the EUN when the CPE is a legacy router.



Templin                 Expires December 25, 2010               [Page 6]


Internet-Draft                    IRON                         June 2010


   (This model applies even if the CPE router is a Network Address
   Translator (NAT) - see Section 6.7).  An IR(EP) connects its EUNs to
   the IRON via tunnels as shown in Figure 2:
                           .-.
                        ,-(  _)-.
        +--------+   .-(_    (_  )-.
        | IR(EP) |--(_     ISP      )
        +---+----+     `-(______)-'
            |   <= T         \     .-.
           .-.       u        \ ,-(  _)-.
        ,-(  _)-.       n     .-(_    (-  )-.
     .-(_    (_  )-.      n  (_   Internet   )
    (_     EUN      )       e   `-(______)-
       `-(______)-'           l          ___
            |                   s =>    (:::)-.
       +----+---+                   .-(::::::::)
       |  Host  |                .-(::::::::::::)-.
       +--------+               (:::: The IRON ::::)
                                 `-(::::::::::::)-'
                                    `-(::::::)-'

                Figure 2: IR(EP) Connecting EUN to the IRON

3.2.  IR(VP)s - IRON Routers That Serve Virtual Prefixes

   An "IR(VP)" is a tunnel endpoint router that is managed by a VPC and
   that services one or more VPs from which it delegates EPs to
   customers.  In typical deployments, a VPC will deploy several IR(VP)s
   (e.g., 10-20) for each VP.  These IR(VP)s maintain a distributed
   database of EP-to-customer mappings that allow correspondents to
   navigate the IRON.

   IR(VP)s connect to the IRON in a globally-distributed fashion as
   shown in Figure 3 so that mapping service clients can discover a
   server that is nearby.  IR(VP)s typically forward only initial
   packets while redirecting traffic flows, and often will require only
   a single physical network interface.  Hence, IR(VP)s may be deployed
   on a variety of hardware platforms ranging from traditional high-end
   routers to commodity general-purpose processors.












Templin                 Expires December 25, 2010               [Page 7]


Internet-Draft                    IRON                         June 2010


             +--------+    +--------+
             | IR(VP) |    | IR(VP) |
             | Boston |    | Tokyo  |
             +--------+    +--------+
     +--------+
     | IR(VP) |       ___
     | Seattle|      (:::)-.       +--------+
     +--------+  .-(::::::::)      | IR(VP) |
              .-(::::::::::::)-.   | Paris  |
             (:::: The IRON ::::)  +--------+
              `-(::::::::::::)-'
   +--------+    `-(::::::)-'        +--------+
   | IR(VP) |                        | IR(VP) |
   | Moscow |     +--------+         | Sydney |
   +--------+     | IR(VP) |         +--------+
                  | Cairo  |
                  +--------+

               Figure 3: IR(VP) Global Distribution Example

3.3.  IR(GW)s - IRON Routers that Connect VPC Networks to the Internet

   An "IR(GW)" is a tunnel endpoint router that is managed by a VPC and
   that acts as a gateway between the VPC's IR(VP)s and the non-IRON
   Internet (i.e., the portion of the Internet used for routing of
   prefixes that are not derived from VPs).  Each VPC configures one or
   more IR(GW)s which advertise the company's VPs into the IPv4 and/or
   IPv6 global Internet BGP routing systems.  An IR(GW) may be
   configured on the same physical platform as an IR(VP), or as a
   separate standalone platform.  An IR(GW) will typically be a BGP
   router that is capable of exchanging both encapsulated packets over
   the IRON and unencapsulated packets over the native Internet.  The
   role of an IR(GW) is depicted in Figure 4:


















Templin                 Expires December 25, 2010               [Page 8]


Internet-Draft                    IRON                         June 2010


                   ,-(  _)-.
                .-(_    (_  )-.
               (_   Internet   )
                  `-(______)-'
                        |
                   +----+---+
                   | IR(GW) |
                   +----+---+
                       _|_
                      (:::)-.
                  .-(::::::::)
   +--------+  .-(::::::::::::)-.  +--------+
   | IR(VP) | (:::: The IRON ::::) | IR(VP) |
   +--------+  `-(::::::::::::)-'  +--------+
                  `-(::::::)-'

                   +--------+
                   | IR(VP) |
                   +--------+

            Figure 4: IR(GW) Connecting VPC to Native Internet


4.  IRON Organizational Principles

   Each VPC in the IRON manages a set of IR(VP)s that service one or
   more VPs from which EPs are delegated to IR(EP)s.  The set of IR(VP)s
   that service the same VP forms a logical subnetwork for the VP.  Each
   IR(VP) in the logical subnetwork exchanges routing/mapping
   information via a dynamic routing protocol instance in order to
   maintain synchronized Forwarding Information Bases (FIBs).

   The VP company also maintains a set of IR(GW)s that connect the
   logical subnetworks to the IPv4 and/or IPv6 Internets.  Each IR(GW)
   advertises the VPC's IPv4 VPs into the IPv4 BGP routing system and
   advertises the VPC's IPv6 VPs into the IPv6 BGP routing system.
   IR(GW)s forward packets coming from the Internet and destined to an
   EPA address into the IRON.  In the reverse direction, IR(GW)s forward
   packets coming from the IRON and destined to a locator address into
   the Internet.  In this way, end systems that use locator addresses
   can communicate with other end systems that use EPA addresses.

   EUNs establish at least one IR(EP) to connect the EUN to the IRON.
   The IR(EP) uses encapsulation to forward packets with EP addresses to
   an IR(VP) belonging to its VP subnetwork as a default router.  The
   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.



Templin                 Expires December 25, 2010               [Page 9]


Internet-Draft                    IRON                         June 2010


   The IRON additionally requires a global mapping database to allow IRs
   to map VPs to locators which are assigned to the interfaces of other
   IRs.  Each VP in the IRON is therefore represented in a globally
   distributed Master VP database (MVPd).  The MVPd is maintained by a
   globally-managed assigned numbers authority in the same manner as the
   Internet Assigned Numbers Authority (IANA) currently maintains the
   master list of all top-level IPv4 and IPv6 delegations.  The database
   can be replicated across multiple servers for load balancing much in
   the same way that FTP mirror sites are used to manage software
   distributions.  Each VP in the MVPd is encoded as the tuple:
   "{address family, prefix, prefix-length, FQDN}", where:

   o  "address family" is one of IPv4, IPv6, OSI/CLNP, etc.

   o  "prefix" is the VP, e.g. - 2001:DB8::/32 (IPv6) [RFC3849],
      192.2/16 (IPv4) [RFC5737], etc.

   o  "prefix-length" is the length (in bits) of the associated VP

   o  FQDN is a DNS Fully-Qualified Domain Name

   For each VP entry in the MVPd, the VPC maintains a FQDN in the DNS to
   map the VP to a list of IR(VP)s that serve it.  IR(VP)s in other VPC
   networks and IR(EP)s that hold EP delegations from the VP discover
   the mappings by resolving the FQDN into a list of resource records.
   Each resource record corresponds to an individual IR(VP), and encodes
   the tuple : "{address family, locator, WGS 84 coordinates}" where
   "address family" is the address family of the locator, "locator" is
   the routing locator assigned to an IR(VP) interface, and "WGS 84
   coordinates" identify the physical location of the IR(VP).  Together,
   the MVPd and the FQDNs in the global DNS provide sufficient mapping
   capabilities to support navigation of the IRON.


5.  IRON Initialization

   IRON initialization entails the startup actions of VPC 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) managed by the VPC discovers the
   full set of VPs for the IRON by reading the MVPd (see Section 4).
   These VPs may be IPv4 or IPv6, but they may also be prefixes of other
   network layer protocols (e.g., OSI/CLNP NSAP [RFC4548], etc.).  Each
   IR(VP) and IR(GW) reads the MVPd from a nearby server upon startup
   time, and periodically checks the server for deltas since the
   database was last read.  Upon reading the MVPd, each IR(VP) and



Templin                 Expires December 25, 2010              [Page 10]


Internet-Draft                    IRON                         June 2010


   IR(GW) resolves the FQDN corresponding to each VP into a list of
   locators.  Each locator is a routable IPv4 or IPv6 address assigned
   to an interface of an IR(VP) that serves the VP.

   For each VP, each IR(VP) and IR(GW) sorts the list of locators to
   determine a priority ranking (e.g., based on distance from the
   locator) and inserts each "VP->locator" mapping into its FIB in order
   of priority.  The FIB entries must be configured such that packets
   with destination addresses covered by the VP are forwarded to the
   corresponding locator using encapsulation of the inner network layer
   packet in an outer IP header.  This is accomplished by configuring
   the routing table entry to use the locator addresses as the L2
   address corresponding to an imaginary L3 next-hop address.

   Note that the VP and locator may be of different address families;
   hence, possible encapsulations include IPv6-in-IPv4, IPv4-in-IPv6,
   IPv6-in-IPv6, IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc.
   After each IR(VP) and IR(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 of its
   EUN customers.

5.2.  IR(EP) Initialization

   Before its first operational use, each IR(EP) must obtain one or more
   EPs from a VPC along with a FQDN that can be resolved into a list of
   locators for the IR(VP)s that service the EPs.  The IR(EP) must also
   obtain a certificate and a public/private key pair from the VPC that
   it can later use to prove ownership of its EPs.  This implies that
   the VPC must run its own key infrastructure to be used only for the
   purpose of verifying a customer's claimed right to use an EP.  Hence,
   the VPC need not coordinate its key infrastructure with any other
   organizations.

   Upon startup, each IR(EP) resolves a FQDN for the VP in order to
   discover the locators of the company's IR(VPs).  (This resolution
   closely resembles the ISATAP Potential Router List (PRL) resolution
   procedure [RFC5214].)  The IR(EP) then selects the closest subset of
   these locators (typically 2-4 routers chosen, e.g., based on
   topological distance) and adds them to a default router list of FIB
   entries that each points to a VET interface with the locator as the
   L2 address of the next-hop.  The IR(EP) will then use the default
   router list for forwarding inner packets with EPA source addresses
   toward the final destination via encapsulation.






Templin                 Expires December 25, 2010              [Page 11]


Internet-Draft                    IRON                         June 2010


6.  IRON Operation

   Following IRON initialization, IRs engage in the steady-state process
   of receiving and forwarding packets.  All IRs forward encapsulated
   packets over the IRON using the mechanisms of VET
   [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal], while
   IR(GW)s additionally forward unencapsulated packets to and from the
   native IPv6 and IPv4 Internets.  IRs also use the SEAL Control
   Message Protocol (SCMP) to test liveness of other IRs and to receive
   redirect messages informing them of better routes.  Each IR operates
   as specified in the following sub-sections.

6.1.  IR(EP) Operation

   After an IR(EP) is initialized, it must register its EP-to-locator
   binding with the IR(VP)s that it has selected as default routers by
   sending periodic beacons with signed certificates and prefix
   information to prove ownership of its EPs.  Each beacon is a SEAL
   Control Message Protocol (SCMP) Router Solicitation (SRS) message,
   and will elicit an SCMP Router Advertisement (SRA) message from the
   IR(VP).  If the IR(EP) ceases to receive SRA messages from an IR(VP),
   it marks the IR(VP) as unreachable and selects a different IR(VP).
   If the IR(EP) ceases to receive SRA messages from multiple IR(VP)s,
   it marks the ISP connection as failed/failing and sends its SRS
   beacons through a different ISP.  The IR(EP) also uses the same SRS/
   SRA beaconing procedure to inform its IR(VP)s of a change in locator,
   e.g., due to a mobility event, a change in its primary ISP, etc.

   When an end system in an EUN has a packet to send, the packet is
   forwarded through the EUN until it reaches an IR(EP).  This source
   IR(EP) then forwards the packet either to an IR(VP) or to a
   destination IR(EP).  The source IR(EP) first checks its FIB for the
   longest matching prefix.  If the longest matching prefix is more-
   specific than "default", the source IR(EP) forwards the packet to the
   next-hop the same as for ordinary IP forwarding.  If the longest
   match is "default", however, the source IR(EP) forwards the packet to
   one of the IR(VP)s serving as its default routers.

   The source IR(EP) 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(EP) further uses SCMP to
   test liveness and/or to accept redirect messages from the next-hop
   IR.  When the source IR(EP) receives an SCMP redirect, it checks the
   identification field of the encapsulated message to verify that the
   redirect corresponds to a packet that it had previously sent to the
   neighbor and accepts the redirect if there is a match.  Thereafter,
   subsequent packets forwarded by the source IR(EP) will follow a
   route-optimized path.



Templin                 Expires December 25, 2010              [Page 12]


Internet-Draft                    IRON                         June 2010


   An IR(EP) that accepts redirects may be redirected by an IR(VP) in
   its home VPC network to one or more IR(VP)s in a "foreign" network.
   In that case, the IR(EP) has no way of knowing if these foreign
   IR(VP)s are reachable and able to process encapsulated packets.  In
   that case, the IR(EP) 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 congestion or a short-term outage, the IR(EP) will
   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 responds to SRSs by sending SRAs
   as described in Section 6.1.  The IR(VP) then propagates the mapping
   information conveyed in the SRS message to each of its peer IR(VP)s
   within the logical subnetwork, e.g., via a dynamic routing protocol
   instance that all of the VP company's IR(VP)s engage in.

   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(EP) '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 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) forwards the packet to the public Internet
      either directly or via an IR(GW).

   An IR(VP) that accepts redirects may need to forward initial 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(EP).






Templin                 Expires December 25, 2010              [Page 13]


Internet-Draft                    IRON                         June 2010


6.3.  IR(GW) Operation

   Each VPC 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 routing systems.  The VPs will be seen as ordinary routing
   information in the BGP, and any packets originating from the non-IRON
   IPv4 or IPv6 Internet toward a VP will be forwarded into the VPC'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 Reference Operating Scenarios

   The two major reference operating scenarios that may arise for IRON
   are 1) when both hosts are within separate IRON EUNs, and 2) when one
   host is within an IRON EUN and the other is within a non-IRON EUN.
   The following two sections discuss these reference operating
   scenarios.

6.4.1.  Two Hosts in Different IRON EUNs

   The initial path when both hosts are within separate IRON EUNs
   involves both the two IR(EPs) 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.  Figure 5
   depicts the IRON reference operating scenario for communications
   between hosts within two separate IRON EUNs:






















Templin                 Expires December 25, 2010              [Page 14]


Internet-Draft                    IRON                         June 2010


                 ________________________________________
              .-(                                        )-.
           .-(      +------------+       +------------+     )-.
        .-(         |            |       |            |        )-.
      .(    +======>+  IR(VP(A)) +======>+  IR(VP(B)) +=====+     ).
    .(    //        |            |       |            |      \\     ).
  .(     //         +------------+       +------------+       \\      ).
  (     //    <-------------   Initial Path -------------->    \\      )
  (    //                                                       \\     )
  (   //  .-.        ................................        .-. \\    )
  (  //,-(  _)-.    .                                .    ,-(  _)-\\   )
  ( .||_    (_  )-..   <-- Route Optimized Path -->   ..-(_    (_  ||. )
  ( _||  ISP A    .)                                  (.    ISP B  || ))
  (  ||-(______)-.                                      .`-(______)||- )
  (  ||    |    .                                        v    |    vv  )
   ( +-----+ ----+              The IRON                +-----+-----+ )
     | IR(EP(A)) |  (Overlaid on the native Internet)   | IR(EP(B)) |
     +-----+-----+                                      +-----+-----+
           |    (                                         )   |
          .-.     .-(                                .-)     .-.
       ,-(  _)-.      .-(________________________)-.      ,-(  _)-.
    .-(_    (_  )-.                                    .-(_    (_  )-.
   (_  IRON EUN A  )                                  (_  IRON EUN B  )
      `-(______)-'                                       `-(______)-'
           |                                                  |
       +---+----+                                         +---+----+
       | Host A |                                         | Host B |
       +--------+                                         +--------+

              Figure 5: Communications Between Two IRON Hosts

   In this reference scenario, VP companies A and B have established
   IR(VP)s within the Internet that serve EPs to EUNs.  EUN A has
   procured EP(A) from VPC A, while EUN B has procured EP(B) from VPC B.
   The hosts in both EUNs have assigned EPAs taken from their
   corresponding EPs on their EUN-interior interfaces, and the IR(EPs)
   have assigned locators 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(EP(A)).  If IR(EP(A ))
   does not have a more-specific route, it encapsulates the packet and
   forwards it to an IR(VP) managed by VPC A. (The encapsulated packet
   uses the locator address of IR(EP(A)) as the outer source address and
   the locator address of IR(VP(A)) as the outer destination address.)
   When IR(VP(A)) receives the encapsulated packet, it checks its FIB
   for a route toward the packet's inner destination address (i.e.,
   'B').  If IR(VP(A)) does not have an entry for EP(B) in its FIB, it
   consults its full table of VP-to-locator mappings to discover that



Templin                 Expires December 25, 2010              [Page 15]


Internet-Draft                    IRON                         June 2010


   the next-hop toward EP(B) is via IR(VP(B)).  IR(VP(A)) then re-
   encapsulates the packet and sends it to IR(VP(B)) which has an entry
   for EP(B) in its FIB with IR(EP(B)) as the next hop.  IR(VP(B)) then
   re-encapsulates the packet and sends it to IR(EP(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 better next hop.  For example, if IR(EP(A)) is
   accepting redirects IR(VP(A)) will return a redirect message when it
   forwards a packet to IR(VP(B)).  IR(EP(A)) will then send subsequent
   packets directly to IR(VP(B)), which will return a redirect message
   when it forwards the packets to IR(EP(B)).  Finally, IR(EP(A)) will
   have an optimized route that lists IR(EP(B)) as the next hop.

   Another redirection scenario arises when IR(VP(A)) is itself willing
   to accept redirects.  In that case, IR(EP(A)) may discover IR(EP(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,
   which may negatively impact scalability.

6.4.2.  Mixed IRON and Non-IRON Hosts

   When one host is within an IRON EUN and the other is in a non-IRON
   EUN (i.e., one that connects to the native Internet instead of the
   IRON), communications must involve an IR(GW) within the IRON host's
   VPC.  Figure 6 depicts the IRON reference operating scenario for
   communications between Host A in an IRON EUN and Host B in a non-IRON
   EUN:


















Templin                 Expires December 25, 2010              [Page 16]


Internet-Draft                    IRON                         June 2010


                  _______________________________________
               .-(         )-.                             )-.
            .-(      +-------)----+                           )-.
         .-(         |            |                             )-.
       .(    +======>+  IR(GW(A)) +---------------+                ).
     .(    //        |            |                \                ).
   .(     //         +--------)---+                 \                 ).
   (     //                   )                      \                 )
   (    //      The IRON      )                       \                )
   (   //  .-.                )                        \      .-.      )
   (  //,-(  _)-.             )                         \ ,-(  _)-.    )
   ( .||_    (_  )-.          ) The Native Internet    .-|_    (_  )-. )
   ( _||  ISP A     )         )                       (_ |  ISP B     ))
   (  ||-(______)-'           )                          |-(______)-'  )
   (  ||    |             )-.                            v    |        )
    ( +-----+ ----+    )-.                               +-----+-----+ )
      | IR(EP(A)) |)-.                                   |  Router B |
      +-----+-----+                                      +-----+-----+
            |  (                                            )  |
           .-.   .-(____________________________________)-.   .-.
        ,-(  _)-.                                          ,-(  _)-.
     .-(_    (_  )-.                                    .-(_    (_  )-.
    (_  IRON EUN A  )                                  (_ non-IRON EUN )
       `-(______)-'                                       `-(___B___)-'
            |                                                  |
        +---+----+                                         +---+----+
        | Host A |                                         | Host B |
        +--------+                                         +--------+

     Figure 6: Communications Between Hosts in IRON and Non-IRON EUNs

   In this reference scenario, when Host A sends a flow of packets to
   Host B, IR(EP(A)) encapsulates and forwards them to an IR(VP) from
   its VPC as a default router.  In the simple case, the IR(VP) also
   acts as an IR(GW) (depicted here as IR(GW)(A))) that decapsulates
   packets coming from IR(EP(A)) and forwards them into the native
   Internet.  In this scenario, no route optimization is possible since
   EUN B is not connected to the IRON.

   In the reverse direction, when Host B sends a flow of packets to Host
   A, normal Internet routing conveys the packets over the native
   Internet to IR(GW(A)) since IR(GW(A)) advertises the VP that covers
   EP(A) into the BGP routing system.  IR(GW(A)) will then encapsulate
   the packets and forward them over the IRON to IR(EP(A)), which in
   turn delivers them to Host A.






Templin                 Expires December 25, 2010              [Page 17]


Internet-Draft                    IRON                         June 2010


6.5.  Mobility, Multihoming and Traffic Engineering Considerations

   While IR(VP)s can be considered as fixed infrastructure, IR(EP)s may
   need to move between different network points of attachment, connect
   to multiple ISPs, or explicitly manage their traffic flows.  The
   following sections discuss mobility, multi-homing and traffic
   engineering considerations for IR(EP)s.

6.5.1.  Mobility Management

   When an IR(EP) changes its network point of attachment (e.g., due to
   a mobility event), it configures a new locator.  The IR(EP) then
   registers the new EP-to-locator mapping with its VPC by sending SRS
   messages the same as described in Section 6.2.  (For further study
   are performance characteristics of various mechanisms that could be
   used to propagate these registration updates within the VPC network.)

   The IR(EP) also sends Neighbor Advertisement (NA) messages as
   registration updates to each neighboring IR from which it has
   received packets recently.  The NA message includes the new locator
   as the outer source address and includes the previous locator within
   an NA option field.  The neighboring IR will update its neighbor
   cache so that subsequent packets will flow through the new locator.

6.5.2.  Multihoming

   An IR(EP) registers only the locator of its primary ISP with its VPC
   even if it connects to multiple ISPs.  If the IR(EP) later needs to
   select a different ISP as its primary, it simply repeats the EP-to-
   locator registration process the same as if it were reacting to a
   mobility event as described above.

6.5.3.  Inbound Traffic Engineering

   When an IR(EP) receives packets via its primary ISP (i.e., the ISP
   for which it is currently registered with the VPC), it may wish to
   balance the load of incoming traffic between multiple ISP
   connections.  In that case, the IR(EP) may send NA messages to
   certain neighboring IRs the same as in the case of a mobility event
   as described in Section 6.5.1.  In that way, the IR(EP) can manage
   its incoming traffic flows for best utilization of its multiple ISPs.

6.5.4.  Outbound Traffic Engineering

   IR(EP)s maintain a list of IR(VP)s that serve as default routers for
   VET interface encapsulation of inner packets with source addresses
   taken from an EP prefix.  IR(EP)s also maintain a list of neighbors
   on underlying interfaces that serve as default routers for packets



Templin                 Expires December 25, 2010              [Page 18]


Internet-Draft                    IRON                         June 2010


   with non-EP source addresses.  If the inner and outer protocols are
   of different versions (e.g., OSI/CLNP as the inner version and IPv4
   as the outer version) then the default routes of both versions are
   mutually exclusive and no special arrangements are needed.

   If the inner and outer protocol versions are the same, however (e.g.,
   IPv6 as both the inner and outer protocol) then a special treatment
   of the default route is necessary.  In particular, the IR(EP) must
   examine the source address of a packet to be forwarded to determine
   the proper handling of "default".  If the packet uses a source
   address taken from an EP prefix, the IR(EP) forwards it to an IR(VP)
   using encapsulation via a VET interface; otherwise, the IR(EP)
   forwards the packet to a next hop on an underlying link.

   Using this arrangement of default, when an IR(EP) forwards a packet
   with an EP source address it can forward it to any of its associated
   IR(VP)s using VET interface encapsulation over any of its underlying
   interfaces.  The choice of underlying interface can be managed, and
   the source address assigned to the underlying interface will be used
   as the outer source address of the encapsulated packet.  Each
   encapsulated packet can therefore be directed through the desired ISP
   using a topologically-correct outer source address.

6.6.  Renumbering Considerations

   As better link layer technologies and service plans emerge, customers
   will be motivated to select their service providers through healthy
   competition between ISPs.  If a customer's EUN addresses are tied to
   a specific ISP, however, the customer may be forced to undergo a
   painstaking EUN renumbering process if it wishes to changes to a
   different ISP [RFC4192][RFC5887].

   When a customer obtains EP prefixes from a VPC, it can change between
   ISPs seamlessly and without need to renumber.  If the VPC itself
   applies unreasonable costing structures for use of the EPs, however,
   the customer may be compelled to seek a different VPC and would again
   be required to confront a renumbering scenario.  The strength of the
   IRON approach therefore lies within a tradeoff between the
   requirement for VPCs to conduct ethical business practices with
   reasonable rates and the ability for customers to painlessly renumber
   their EUNs.

6.7.  NAT Traversal Considerations

   The Internet today consists of a global public IPv4 routing and
   addressing system with non-IRON EUNs that use either public or
   private IPv4 addressing.  The latter class of EUNs connect to the
   public IPv4 Internet via Network Address Translators (NATs).  When an



Templin                 Expires December 25, 2010              [Page 19]


Internet-Draft                    IRON                         June 2010


   IR(EP) is located behind a NAT, its selects IR(VP)s using the same
   procedures as for IR(EP)s with public addresses, i.e., it will send
   SRS messages to IR(VP)s in order to get SRA messages in return.  The
   only requirement is that the IR(EP) must configure its SEAL
   encapsulation to use a transport protocol that supports NAT
   traversal, namely UDP.

   Since the IR(VP) maintains state about its IR(EP) customers, it can
   discover locator information for each IR(EP) by examining the UDP
   port number and IPv4 address in the outer headers of SRS messages.
   When there is a NAT in the path, the UDP port number and IPv4 address
   in the SRS message will correspond to state in the NAT box and might
   not correspond to the actual values assigned to the IR(EP).  The
   IR(VP) can then encapsulate packets destined to hosts serviced by the
   IR(EP) within outer headers that use this IPv4 address and UDP port
   number.  The NAT box will receive the packets, translate the values
   in the outer headers to match those assigned to the IR(EP), then
   forward the packets to the IR(EP).


7.  Open Research Areas

   A number of open research areas exist which would need to be explored
   in taking the IRON concept into large-scale deployment.
   Considerations for the scalability of Internet Routing due to
   multihoming, traffic engineering and provider-independent addressing
   are discussed in [I-D.narten-radir-problem-statement].  Route
   optimization considerations for mobile networks are found in
   [RFC5522].  Finally, security implications for tunneling over large-
   scale Internetworks and feasibility analysis for maintaining a
   globally distributed mapping service bear further investigation.


8.  Related Initiatives

   IRON builds upon the concepts RANGER architecture [RFC5720], and
   therefore inherits the same set of related initiatives.

   Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in
   Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for
   the Virtual Prefix concepts.

   Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has
   contributed valuable insights, including the use of real-time
   mapping.






Templin                 Expires December 25, 2010              [Page 20]


Internet-Draft                    IRON                         June 2010


9.  IANA Considerations

   There are no IANA considerations for this document.


10.  Security Considerations

   Security considerations that apply to tunneling in general are
   discussed in [I-D.ietf-v6ops-tunnel-security-concerns].  Additional
   considerations that apply also to IRON are discussed in RANGER
   [RFC5720], VET [I-D.templin-intarea-vet] and SEAL
   [I-D.templin-intarea-seal].

   IRON assumes that the mapping system (including the MVPd and
   corresponding FQDNs in the DNS) be well-managed and not vulnerable to
   subversion.  This assumption is no different than for the current
   state of affairs for client-server communications in the Internet
   today.

   IR(EP)s require a means for securely registering their EP-to-locator
   bindings with their VPC and with correspondent nodes.  Each VPC
   provides its customer IR(EP)s with a secure means for registering and
   re-registering their mappings, and the use of SEAL encapsulation
   provides a nonce with each packet to allow correspondent nodes to
   authenticate binding updates from IR(EP)s.


11.  Acknowledgements

   This ideas behind this work have benefited greatly from discussions
   with colleagues; some of which appear on the RRG and other IRTF/IETF
   mailing lists.  Mohamed Boucadair, Wesley Eddy and Robin Whittle
   provided review input.


12.  References

12.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.







Templin                 Expires December 25, 2010              [Page 21]


Internet-Draft                    IRON                         June 2010


12.2.  Informative References

   [BGPMON]   Analyses, B., "BGPmon.net - Monitoring Your Prefixes,
              http://bgpmon.net/stat.php", June 2010.

   [I-D.ietf-grow-va]
              Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
              L. Zhang, "FIB Suppression with Virtual Aggregation",
              draft-ietf-grow-va-02 (work in progress), March 2010.

   [I-D.ietf-v6ops-tunnel-security-concerns]
              Hoagland, J., Krishnan, S., and D. Thaler, "Security
              Concerns With IP Tunneling",
              draft-ietf-v6ops-tunnel-security-concerns-02 (work in
              progress), March 2010.

   [I-D.narten-radir-problem-statement]
              Narten, T., "On the Scalability of Internet Routing",
              draft-narten-radir-problem-statement-05 (work in
              progress), February 2010.

   [I-D.russert-rangers]
              Russert, S., Fleischman, E., and F. Templin, "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-15 (work in
              progress), June 2010.

   [I-D.templin-intarea-vet]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-intarea-vet-15 (work in progress),
              June 2010.

   [I-D.whittle-ivip-arch]
              Whittle, R., "Ivip (Internet Vastly Improved Plumbing)
              Architecture", draft-whittle-ivip-arch-04 (work in
              progress), March 2010.

   [I-D.zhang-evolution]
              Zhang, B. and L. Zhang, "Evolution Towards Global Routing
              Scalability", draft-zhang-evolution-02 (work in progress),
              October 2009.

   [RFC1070]  Hagens, R., Hall, N., and M. Rose, "Use of the Internet as
              a subnetwork for experimentation with the OSI network



Templin                 Expires December 25, 2010              [Page 22]


Internet-Draft                    IRON                         June 2010


              layer", RFC 1070, February 1989.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4548]  Gray, E., Rutemiller, J., and G. Swallow, "Internet Code
              Point (ICP) Assignments for NSAP Addresses", RFC 4548,
              May 2006.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [RFC5522]  Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
              Route Optimization Requirements for Operational Use in
              Aeronautics and Space Exploration Mobile Networks",
              RFC 5522, October 2009.

   [RFC5720]  Templin, F., "Routing and Addressing in Networks with
              Global Enterprise Recursion (RANGER)", RFC 5720,
              February 2010.

   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
              Reserved for Documentation", RFC 5737, January 2010.

   [RFC5743]  Falk, A., "Definition of an Internet Research Task Force
              (IRTF) Document Stream", RFC 5743, December 2009.

   [RFC5887]  Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
              Still Needs Work", RFC 5887, May 2010.














Templin                 Expires December 25, 2010              [Page 23]


Internet-Draft                    IRON                         June 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 25, 2010              [Page 24]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/