Network Working Group P. Yang Internet-Draft Hitachi (China) R&D Corp Intended status: Standards Track P. Seite Expires: August 31, 2009 France Telecom C. Williams J. Qin ZTE February 27, 2009 Requirements on multiple Interface (MIF) of simple IP draft-yang-mif-req-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Yang, et al. Expires August 31, 2009 [Page 1] Internet-Draft mif-req February 2009 Abstract This draft makes a summary on the requirements of supporting multiple interfaces (MIF) in hosts with simple IP. These requirements result from examining scenarios for multiple interface host usages. The differentiation between MIF and other related IETF works are interpreted as well. Table of Contents 1. introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Challenges for multi-homed simple IP support . . . . . . . 6 2. Scenarios of service sets for Multi-interfaced Hosts . . . . . 7 2.1. Sets of services are the same . . . . . . . . . . . . . . 7 2.2. Set of services are different . . . . . . . . . . . . . . 7 2.3. Set of services are partially overlapping . . . . . . . . 8 2.4. Inclusion of a set of services . . . . . . . . . . . . . . 8 2.5. Combination of services . . . . . . . . . . . . . . . . . 9 3. Requirements of MIF . . . . . . . . . . . . . . . . . . . . . 10 3.1. General Requirements . . . . . . . . . . . . . . . . . . . 10 3.2. Requirements on MIF routing . . . . . . . . . . . . . . . 10 3.3. Requirements on merging of IP layer autoconfiguration . . 11 3.4. split DNS . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Related IETF works . . . . . . . . . . . . . . . . . . . . . . 13 4.1. relationship with current internet hosts (RFC1122) . . . . 13 4.2. Network Discovery and Selection Problem (RFC5113) . . . . 13 4.3. PMIPv6 & Monami6 . . . . . . . . . . . . . . . . . . . . . 13 4.4. Default address selection (RFC3484) . . . . . . . . . . . 14 4.5. Site Multi-homing of IPv6 (SHIM6) . . . . . . . . . . . . 14 4.6. Default Router Preferences (RFC4191) . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Yang, et al. Expires August 31, 2009 [Page 2] Internet-Draft mif-req February 2009 1. introduction Currently most of the network hosts (such as mobile phones, note PCs, etc) are equiped with multiple interfaces physically or virtually. The interfaces may connect with same or different network domains. Such scenarios result in connectivity issues as configuration information may be local to the interface or gobal to the node. Various challenges arise when multiple configuration objects that are global to the node are received on the many interfaces the multi- homed host has. for example, as figure 1 shows, a mobile phone may connect with multiple access networks at the same time. Another example is given by figure 2. A notePC could reach the Internet via If1 for web browsing, while maintaining a VPN connection to the remote private Multi-homing problem in Monami6/MEXT has been discussed for issues related to simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6,etc). NETLMM WG also has the work to support the mobile nodes with multiple interfaces in proxy mobile IPv6. However, the solutions of both multihoming support in MEXT and PMIPv6 leverage on a mobility anchor (Home Agent (HA) or Local Mobility Anchor (LMA)). +-------------+ | Destination | | Peers | +-------------+ | *** *** *** *** * ** ** ** * * * * Internet * //* *\\ // * ** ** ** * \\ // *** *** *** *** \\ // // \\ \\ \\ +----+ +----+ +----+ +------+ +----+ | GW | |GGSN| | GW | |ASN-GW| | AR | +----+ +----+ +----+ +------+ +----+ | | | | | | | | | | +----+ +----+ +----+ +-----+ +-----+ |WiFi| |HSPA| |LTE | + 16e | |Wired| |AP | |NB | |eNB | + BS | |CPE | +----+ +----+ +----+ +-----+ +-----+ Yang, et al. Expires August 31, 2009 [Page 3] Internet-Draft mif-req February 2009 \ \ | / | \ \ | / / + + + + / | | | | | +---+--------------+------+------+-----+----+ | | | | | | | | +-+-+ +-----+ +---+ +---+ +---+ +---+ | | |if0| | if2 If3| |If4| |If5| |Ifn| | | +---+ |(VPN)| +---+ +---+ +---+ +---+ | | | +-----+ | | | | | | | | | | | | | ++-----+-------+------+------+-----+-+ | | | MIF | | | | (Interface monitoring and control) | | | +--.---------------------------------+ | | | | | | +......................+ | | | : Mobility management : | | | : protocols (MIP,...): | | | : (not in MIF Scope) : | | | +......................+ | | | | | +--'---------------------------------+ | | | MIF | | | | (address selection, policies | | | | management, .... | | | +------------+------------------- ---+ | | | | | +--------'---------+ | | | Applications | | | +------------------+ | +-------------------------------------------+ Mobile Terminal Figure 1: Mobile Terminals connected to multiple networks ** *** ** * * * * * Private * * Network * * * * * +-------------+ ** *** ** | Destination | \\ | Peers | +-----+ +-------------+ | VPN | \ +-----+ \ // Yang, et al. Expires August 31, 2009 [Page 4] Internet-Draft mif-req February 2009 \ *** *** *** *** * ** ** ** * * * * Internet * * * * ** ** ** * *** *** *** *** || \\ +-----+ +-----+ | NW2 | | NW1 | +-----+ +-----+ / | | | | | +----+----------------------+----------+ | | | | | +--+----+ +--------+ --+---+ | | | if0 | | if2 | If1 | | | +--.----+ | (VPN) | ---.--+ | | | +--------+ | | | | | | | ++-----------------------+---+ | | | MIF | | | | (Interface monitoring and | | | | control) | | | +--.-------------------------+ | | | | | | +......................+ | | | : Mobility management : | | | : protocols (MIP,...): | | | : (not in MIF Scope) : | | | +......................+ | | | | | +--'---------------------------+ | | | MIF | | | | (address selection, policies | | | | management, .... | | | +------------+-----------------+ | | | | | | | | +--------'---------+ | | | Applications | | | | | | | +------------------+ | +--------------------------------------+ VPN client Yang, et al. Expires August 31, 2009 [Page 5] Internet-Draft mif-req February 2009 Figure 2: clients interconnect with Internet and VPN server Some problem statements ([hui08] and [Blanchet08]) have been proposed for MIF problems as well. In MIF framework, different interfaces of MIF node will have different addresses, which may be allocated from different networks. 1.1. Challenges for multi-homed simple IP support Several issues below are considered for multi-homed simple IP host. o selection of access networks: which network(s) to attach to using the physical interface(s) that the host has. Already covered in RFC 5113. o Flow-based Routing: access networks may be different in bandwidth, delay, pricing, etc. if a host is attached to a number of different point of attachment, there should have the way to help decide the right interfaces and source addresses for specific flows of application. o Configuration reconciliation: A multi-homed host receives node configuration information from each of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple configuration objects that are global to the node are received on the many interfaces the multi-homed host has. o Split DNS: If a host is attached to a number of different interfaces, how does it resolve a FQDN if more than one interface has provided a DNS server address? [Savolainen08] gives an example on solving this issue. o Protocols for Policy delivery: the MN and the network should support mechanisms, e.g. [802.21], to communicate about interface management policies. Yang, et al. Expires August 31, 2009 [Page 6] Internet-Draft mif-req February 2009 2. Scenarios of service sets for Multi-interfaced Hosts The MIF work is looking at a multi-homed host whereby it receives node configuration information from each of its access networks. This section enumerates scnearios of service sets for multi-homed hosts so that analysis can be made to the problem goals of the IETF work. Combinations of the above - configurations with both multiple network interfaces and multiple IP addresses assigned to some or all of these interfaces - are also possible. 2.1. Sets of services are the same Here the host has two or more unlimited Internet Connections. The sets of services for these connections are the same. A and B are Internet connections both having the same set of services. ___________ / \ / \ ( A, B ) ( ) \ / \___________/ Case I: Same set of services Figure 1 2.2. Set of services are different Next on the list of complexity is the scenario case a host has multiple Internet connections but the set of services for these are different. Here the host for example may have a physical and/or logical VPN connection to different private networks and services. Another example is connecting a host to 2 logically separate but physically connected networks. Here a host has one Internet connection and one VPN connection through which only private network and services can be reached. Yang, et al. Expires August 31, 2009 [Page 7] Internet-Draft mif-req February 2009 In the diagram A and B are the Internet Connections of a host each having a different set of services associated with them. ______ ______ / \ / \ / \ / \ ( A ) ( B ) ( ) ( ) \ / \ / \______/ \______/ Case II: Different set of services Figure 2 2.3. Set of services are partially overlapping Here the multi-connected host networking services are partially overlapping. Connection A and B having overlapping services. _____ _____ / \/ \ / / \ \ ( A ( ) B ) ( ( ) ) \ \ / / \______/_____/ Case III: Partially overlapping set of services Figure 3 2.4. Inclusion of a set of services In this usage scenario services provided by one network the host connects to are completely included by the provision of another. For example, the host has one Internet connection and one VPN connection, while it can also access the Internet services through NATs and proxies provided in the VPN besides some private services. Yang, et al. Expires August 31, 2009 [Page 8] Internet-Draft mif-req February 2009 _______ / B \ / ____ \ ( / \ ) ( ( A ) ) \ \____/ / \_______/ Case IV: Inclusion Figure 4 2.5. Combination of services A realistic scenario is the combination of the above mentioned scenarios. A multi-homed host has multiple network interfaces both physical and logical. If the host has all physical connections, the host may be connected to different networks through various ways, for instance, wired LAN, 802.11 LAN or a 3G cellular network. For the case that multiple interfaces on the same network, connection issues should be handled by lower-layer protocols, the MIF focuses on upper- layer routing and service reachability. If there is one logical connection the host may have logical connections built on its physical connection, this may be handled by some third-party tools. While the data forwarding process needs to be defined further such as in a BCP document. Yang, et al. Expires August 31, 2009 [Page 9] Internet-Draft mif-req February 2009 3. Requirements of MIF In accord with the considerations in section 1, new requirements arise for MIF from the following aspects: o Packet routing in MIF o Merging of autoconfigurations in MIF o Split DNS o the way to communicate the policies between MIF node and network. DHCP ([rfc2131] and [rfc3315]) may be a possible way to do it. 3.1. General Requirements Note: the items in this sub-section are applicable for all the scenarios in section 2. R0 - MIF nodes must have at least two physical/virtual interfaces, which may be interconnecting with same/different domains R1 - MIF MUST cover IPv4 only, IPv6 only, and dual-stack MIF node. R2 - MIF solution must compatible with existing IPv4, IPv6 architecture and protocols. R3 - MIF covers routing issues with multihomed nodes. This includes multicast routing, knowing that multicast mobility is not in the scope (see R4). R4 - MIF does not require to support IP mobily management protocols (e.g. MIPv6, MIPv4). 3.2. Requirements on MIF routing Note: the items in this sub-section are applicable for all the scenarios in section 2. R5 - MIF must decide the interface for a specific outgoing IP flow, before the default route is applied, if applications are agnostic of MIF functions. R6 - MIF should provide support for interface selection according different applications needs (in term of QoS required, etc.), if applications have interfaces with MIF. R7 - MIF must not remove the default route mechanism as defined by Yang, et al. Expires August 31, 2009 [Page 10] Internet-Draft mif-req February 2009 RFC1122. R8 - MIF must provide applications/users the inforamtion related to the interfaces. R9 - MIF must have the protocols to communicate the routing policies between MIF node and network. R10 - MIF must be able to get information from interfaces in order to feed the access selection process. R11 - MIF nodes may start, stop and dynamically change flows and connection status. 3.3. Requirements on merging of IP layer autoconfiguration Note: the items in this sub-section are applicable for all the scenarios in section 2. R12 - MIF must be capable of collecting the global/local configuration objects from different interfaces R13 - MIF must support specific policies to merge the configuration objects when they are conflicting R14 - MIF must provide the way to users/network to exchange the policies for merging of configurations. R15 - MIF node must provide the way to update the configurations. 3.4. split DNS Note: the items in this sub-section are not necessary for the scenario in section 2.1, wherein the service sets of different interfaces are same. The other scenarios in section 2 have the requirements in this sub-section R16 - MIF must be able to get DNS services from different networks. R17 - MIF must be configured with policies for DNS service access. R18 - MIF must provide the way to users/network to change the policies for DNS access. R19 - MIF must provide the way to update the policies of DNS service access. R20 - MIF must have the protocols to communicate the DNS access Yang, et al. Expires August 31, 2009 [Page 11] Internet-Draft mif-req February 2009 policies between MIF node and network. Yang, et al. Expires August 31, 2009 [Page 12] Internet-Draft mif-req February 2009 4. Related IETF works 4.1. relationship with current internet hosts (RFC1122) RFC1122 specified the requirements on the internet host softwares related to link layer, IP layer, and transport layer. MIF will not change the basic routing policies of outbound packets in RFC1122. On the contrary, MIF will add new ways to decide the route of outbound packets before the default route is applied. As for multihoming support, if the datagram is sent in response to a received datagram, MIF will also select the source address for the response SHOULD be the specific-destination address of the request, which is the same as the definition of RFC1122. Otherwise, more rules will be provided by MIF besides the specified rules to select the source addresses. The rules of MIF are applicable for both strong and weak end systems (ES). In MIF, An application is not required to explicitly specify the source address for initiating a connection or a request. 4.2. Network Discovery and Selection Problem (RFC5113) RFC5113 defines the ways to help users to select which network to connect to and how to authenticate with that network, when multiple access networks are available. Basically, it divides the problems of network discovery and selection into multiple sub- problems, including Discovery of Points of Attachment, Identity Selection, AAA Routing, Network Capabilities Discovery, etc. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed as well. In RFC 5113, the routing of data packets, in the situation where mechanisms more advanced than destination-based routing are thought to be necessary. But, it explicitly specified that payload routingis not discussed further in RFC5113. MIF will have solution for this issue. MIF will rely on RFC5113 for network discovery and selection. Before the MIF works for routing/configuration/split DNS, the network discrovery and attachment must be finished beforehand by ways of RFC5113. In this sense, MIF will not cover the network selection and discovery at all. 4.3. PMIPv6 & Monami6 As discussed in section 1, the solutions of both multihoming support in MEXT and NetLMM need the support from Home Agent (HA) or Local Mobility Anchor (LMA). MIF will work on multiple interface solutions of generic simple IP model. Anyhow, some experiences in these WG will be good references in MIF as well. Yang, et al. Expires August 31, 2009 [Page 13] Internet-Draft mif-req February 2009 4.4. Default address selection (RFC3484) RFC 3484 proposed default address selection and destination address for IPv6 could be a refernce to MIF work. 4.5. Site Multi-homing of IPv6 (SHIM6) SHIM6 provides multi-homed site with a new sub-layer (shim) into the IP stack of end-system hosts, for the purposes of redundancy, load sharing, operational policy or cost. It will enable hosts on multi- homed sites to use a set of provider-assigned IP address prefixes and switch between them without upsetting transport protocols or applications. It's different from MIF in the following two items: o MIF will handling the routing of multiple flows via multiple interfaces based on the MIF policies. SHIM6 only schedules the interfaces for the purposes of redundancy, load sharing, etc. o SHIM6 is more on swtiching the prefixes without the invovlement of transport protocols or applications. o SHIM6 assumes the configuration of multiple interfaces has been done beforehand. MIF will work on the reconciliation of these configuration objects. 4.6. Default Router Preferences (RFC4191) RFC 4191 already specify to extend RA to communicate the prefernce and specific routing prefix. However, considering the requirements of MIF, it doesn't cover a full fledges information for a routing and also not include for DHCP support. Yang, et al. Expires August 31, 2009 [Page 14] Internet-Draft mif-req February 2009 5. Security Considerations MIF must have the security capabilities to protect MIF node from any malicious attempts caused by security holes such as denial of service attacks. - The MIF solution must not compromise the security architecture of the basic IPv4/IPv6 networks. - MIF is required to provide an admission control mechanism to regulate any MIF events. - MIF could rely on the security mechanism of each interface on MIF node. - Mechanisms used by MIF to exchange policies MUST support security feature to protect this flow of information. Yang, et al. Expires August 31, 2009 [Page 15] Internet-Draft mif-req February 2009 6. Conclusion This draft is basically about the requirements on MIF. The related considerations are given firstly, followed by the requirements of MIF on different aspect. Lastly, the relationship and differentiation are made between perspective work of MIF and the related IETF work. Yang, et al. Expires August 31, 2009 [Page 16] Internet-Draft mif-req February 2009 7. IANA Considerations This document makes no requests to IANA. Yang, et al. Expires August 31, 2009 [Page 17] Internet-Draft mif-req February 2009 8. Normative References [802.21] "IEEE 802.21 Standard for Local and Metropolitan Area Networks: Media Independent Handover Services". [Blanchet08] Blanchet, M., "Multiple Interfaces Problem Statement", draft-blanchet-mif-problem-statement-00.txt (work in progress), December 2008. [Nordmark09] Nordmark, E., "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-12.txt (work in progress), February 2009. [OMA-DM] "Enabler Test Specification for Device Management v1.2", Open Mobile Alliance OMA-ETS-DM-V1_2-20080718-C, July 2008. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [Savolainen08] Savolainen , T., "Domain name based network interface selection", IETF Internet-draft draft-savolainen-6man-fqdn-based-if-selection-00.txt, October 2008. [Wakikawa09] Yang, et al. Expires August 31, 2009 [Page 18] Internet-Draft mif-req February 2009 Wakikawa , R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-11 (work in progress), January 2009. [hui08] Hui, M., "Problem Statement and Requirement of Simple IP Multi-homing of the Host", draft-hui-ip-multiple-connections-ps-01 (work in progress), November 2008. Yang, et al. Expires August 31, 2009 [Page 19] Internet-Draft mif-req February 2009 Authors' Addresses Peng Yang Hitachi (China) R&D Corp Email: peng.yang.chn@gmail.com Pierrick Seite France Telecom Email: pierrick.seite@orange-ftgroup.com Carl Williams ZTE Consultant Palo Alto United States Email: carl.williams@mcsr-labs.org Jacni Qin ZTE Shanghai China Email: jacniq@gmail.com Yang, et al. Expires August 31, 2009 [Page 20]