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]