Boeing Research & Technology

P.O. Box 3707 MC 7L-49 Seattle WA 98124 USA fltemplin@acm.org

Network Working Group I-D Internet-Draft 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.

The Internet Routing Overlay Network (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 . 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 , i.e., the same as for ordinary ISP interfaces.

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) , the Subnetwork Encapsulation and Adaptation Layer (SEAL) and Asymmetric Extended Route Optimization 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 :

(::::::::::::::::::) <--+ || | ^ | || | | | || .-. | .v. .-. | || ,-( _'-v ,-( _)-. ,-( _)-v || .-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-. || (__ ISP1 _)(__ ISP2 _)(__ ISP3 _) || `-(__^___)-' `-(__^___)-' `-(__^___)-' || | | | || +-------+ | +------+ || | | | || | | | || +--v--------v---------v--+ || | <- ISP Interfaces -> | || | | || | MIF Node | || | | || | 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. 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.

Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) examines recursive arrangements of enterprise networks that can apply to a very broad set of use-case scenarios . These same use-case scenarios apply also to IRON.

There are no IANA considerations for this document.

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

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

Nodes (i.e., gateways, routers and hosts) attached to link types such as multicast-capable, shared media and non-broadcast multiple access (NBMA), etc. can exchange packets as neighbors on the link. Each node should therefore be able to discover a neighboring gateway that can provide default routing services to reach off-link destinations, and should also accept redirection messages from the gateway informing it of a neighbor that is closer to the final destination. This redirect function can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the gateway, and finally to the egress link neighbor may be considerably longer than the direct path between the neighbors. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. For the purpose of this document, a subnetwork is defined as a virtual topology configured over a connected IP network routing region and bounded by encapsulating border nodes. These virtual topologies are manifested by tunnels that may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. Enterprise networks connect hosts and routers over various link types, and often also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.