IRON Applicability for Multiple Interface Nodes
draft-templin-mif-ironapp-00.txt

Abstract

The Internet Routing Overlay Network (IRON) is a new internetworking and routing architecture that addresses important issues including routing scaling, network renumbering, mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. In this document, we focus on IRON's applicability for multiple interface (mif) nodes.

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 July 05, 2012.

Copyright Notice

Copyright (c) 2012 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
• 2. The IRON Interface
• 3. Related Work
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

The Internet Routing Overlay Network (IRON) [IRON] is a new internetworking and routing architecture that addresses numerous important issues including routing scaling, network renumbering, mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. IRON further provides a new interface type that augments the collection of interfaces available to a multiple interface (mif) node.

Mif nodes are presented with the problem of managing a collection of multiple interfaces; each of which connects to an Internet Service Provider (ISP) and its respective provisioning domain [RFC6418][RFC6419]. Each such ISP interface receives a configuration that is specific to the ISP's provisioning domain, including network-layer addresses and prefixes, DNS server addresses, etc. In operational practice, the mif node may receive overlapping provisioning information, e.g., if multiple ISPs supply the node with configuration information from the same private addressing plan. Moreover, each ISP interface's provisioning information may change over time, e.g., if the node is mobile. It is therefore essential that the mif node select the correct interface for communications with services within a specific ISP provisioning domain and/or with correspondents in the global Internet.

In this document, we focus on IRON's applicability for mif nodes with these ISP interface characteristics. We show that IRON presents a new interface type that complements the mif node's ISP interface collection, i.e., the mif node need not use the IRON interface exclusively but instead views it as "just another interface" albeit with certain desirable properties not commonly supported by ISP interfaces. IRON further observes the Internet Protocol (IP) standards [RFC0791][RFC2460], i.e., the same as for ordinary ISP interfaces.

2. The IRON Interface

The IRON interface is a non-broadcast, multiple access (NBMA) tunnel virtual interface that is configured over one or several ISP interfaces and coordinated with a Virtual Service Provider (VSP) server that may or may not be independent of any of the mif node's ISPs. Example ISPs include 3GPP and BBF providers, but the IRON domain of applicability extends to all ISP network connection interface types. While the IRON interface is configured over ISP interfaces, it appears to the mif node as "just another interface" in addition to the ISP interfaces.

IRON is based on Virtual Enterprise Traversal (VET) [INTAREA-VET], the Subnetwork Encapsulation and Adaptation Layer (SEAL) [INTAREA-SEAL] and Asymmetric Extended Route Optimization [AERO] as its functional building blocks. VET defines the IRON NBMA tunnel virtual interface model and specifies autoconfiguration and internetworking operation over the interface (including IRON interface neighbor coordination). SEAL specifies the encapsulation format used by the IRON interface for deterministic error messaging as well as optional authentication, integrity and anti-replay capabilities. Finally, AERO specifies a route optimization capability that the mif node can use to dynamically discover an IRON interface neighbor that is close to the final destination.

The IRON interface receives persistent provisioning domain configuration information (including IP addresses/prefixes) from a VSP, and uses a nearby VSP server located in the Internet as a default router for reaching Internet correspondents. The VSP provisioning information remains stable even if the mif node's ISP interface configurations change. The IRON interface therefore appears as a virtual direct connection to the Internet independent of any ISPs as shown in Figure 1:

                         _______________
                        (:::::::::::::::)-.
                    .-(::::::::::::::::::::)
                 .-(::::::::::::::: VSP ::::)-.
                (:::: Internet ::: Server <====)======+
                 ^`-(:::::::::::::::::::::::)-'      ||
            +-------> (::::::::::::::::::) <--+      ||
            |            ^                    |      ||
            |            |                    |      || 
       .-.  |           .v.              .-.  |      ||
    ,-(  _'-v        ,-(  _)-.        ,-(  _)-v      ||
 .-(_    (_  )-.  .-(_    (_  )-.  .-(_    (_  )-.   ||
(__    ISP1    _)(__    ISP2    _)(__    ISP3    _)  ||
   `-(__^___)-'     `-(__^___)-'     `-(__^___)-'    ||
        |                |                |          ||
        +-------+        |         +------+          ||
                |        |         |                 ||
                |        |         |                 ||
             +--v--------v---------v--+              ||
             |  <- ISP Interfaces ->  |              ||
             |                        |              ||
             |        MIF Node        |              ||
             |                        |              ||
             |     IRON Interface ->  <===============+
             +------------------------+

A common mif node scenario involves a mobile device such as a handset with both 3GPP and WiFi interfaces, where the 3GPP interface connects to a cellular service provider and the WiFi interface connects to a wireless network serviced by a BBF cable modem provider. In that case, the IRON interface can provide simultaneous operation over both underlying interfaces even if both interfaces receive overlapping IP address and prefix information. This is due to the fact that the IRON interface operates based on interface identifiers and not IP addresses as the means for keeping the underlying interfaces separate.

The IRON interface therefore becomes just another candidate for interface selection the same as the ISP interfaces, and can be selected for communications in which a stable addressing configuration is necessary. As a result, the IRON interface is a new interface type that should be accounted for by mif node interface selection standards.

3. Related Work

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 [RFC6139]. These same use-case scenarios apply also to IRON.

4. IANA Considerations

There are no IANA considerations for this document.

5. Security Considerations

Security considerations appear in the IRON, VET, SEAL and AERO documents.

6. Acknowledgements

This work was motivated through discussions on the IETF Multiple Interfaces (mif) working group mailing list.

7. References

7.1. Normative References

7.2. Informative References

Author's Address