Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Informational January 04, 2012 Expires: July 7, 2012 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 7, 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 Templin Expires July 7, 2012 [Page 1] Internet-Draft IRON January 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The IRON Interface . . . . . . . . . . . . . . . . . . . . . . 3 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Templin Expires July 7, 2012 [Page 2] Internet-Draft IRON January 2012 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. Templin Expires July 7, 2012 [Page 3] Internet-Draft IRON January 2012 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: Templin Expires July 7, 2012 [Page 4] Internet-Draft IRON January 2012 _______________ (:::::::::::::::)-. .-(::::::::::::::::::::) .-(::::::::::::::: VSP ::::)-. (:::: Internet ::: Server <====)======+ ^`-(:::::::::::::::::::::::)-' || +-------> (::::::::::::::::::) <--+ || | ^ | || | | | || .-. | .v. .-. | || ,-( _'-v ,-( _)-. ,-( _)-v || .-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-. || (__ ISP1 _)(__ ISP2 _)(__ ISP3 _) || `-(__^___)-' `-(__^___)-' `-(__^___)-' || | | | || +-------+ | +------+ || | | | || | | | || +--v--------v---------v--+ || | <- ISP Interfaces -> | || | | || | MIF Node | || | | || | IRON Interface -> <===============+ +------------------------+ Figure 1: MIF Node with IRON Interface The IRON interface provides the mif node with a stable "handle" for connecting to correspondents in the Internet. Since the IRON interface configuration remains stable even if the underlying ISP interface configurations change, the interface supports mobility management, multihoming and traffic engineering. However, the IRON interface need not be used for communications between the mif node and services within a specific ISP network, since the ISP interface itself may be better positioned to access those services. 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. Templin Expires July 7, 2012 [Page 5] Internet-Draft IRON January 2012 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 [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. 7.2. Informative References [AERO] Templin, F., Ed., "Asymmetric Extended Route Optimization (AERO)", Work in Progress, December 2011. Templin Expires July 7, 2012 [Page 6] Internet-Draft IRON January 2012 [INTAREA-SEAL] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, December 2011. [INTAREA-VET] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", Work in Progress, December 2011. [IRON] Templin, F., Ed., "The Internet Routing Overlay Network (IRON)", Work in Progress, December 2011. [RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010. [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios", RFC 6139, February 2011. [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011. [RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011. 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 July 7, 2012 [Page 7]