One document matched: draft-williams-mif-problem-scenarios-00.txt
Internet Engineering Task Force C. Williams
Internet-Draft J. Qin
Intended status: Informational ZTE
Expires: January 7, 2010 July 6, 2009
MIF Problem Requirements and Scenarios
draft-williams-mif-problem-scenarios-00.txt
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 January 7, 2010.
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.
Abstract
This document provides the problem statement requirements and
scenarios for MIF. These requirements and use case scenarios are
intended to define an approach to solving common problems presented
Williams & Qin Expires January 7, 2010 [Page 1]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
in MIF. These MIF requirements and scenarios are based around the
common and prevalent problem of adaptation of a host to attach to
multiple networks simultaneously. Such a host not only has to make
decisions about selection of service parameters but also how to deal
with issues relating to contradictory configuration objects. These
MIF scenarios are intended to be part of a set of such scenarios that
together define the purpose, scope and requirements for proposed and
realized capabilities.
1. Introduction
Currently most of the network hosts (such as mobile phones, note PCs,
etc) are equipped 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 global to the node.
Various issues arise when multiple configuration parameters are
global to the node are received on the many interfaces the multihomed
host has.
When a host has multiple network connections, problems arise within
the network stack. Such hosts receive configuration parameters from
multiple sources, such as from any set of default routers, DHCP
servers, and manual configurations. Questions of how are conflicting
parameters for host or interface configuration reconciled with each
other, or, if not reconcilable, which parameters have precedence?
Hosts with multiple interfaces are more likely to be confronted with
this issue, but the issue may also come up for hosts with a single
interface.
It is important therefore to detail the various scenarios cases to
provide a framework for understanding the implications on problem
statement requirements for defining the appropriate behavior of an
IPv4 or IPv6 stack and what protocols would be to manage these cases.
Below these scenarios are enumerated. They will help in
understanding better the requirements and implications for solutions
to these requirements.
2. Problem Statement Requirements
The MIF problem statement requirements are enumerated as:
2.1. General Requirements
o R0 - MIF must work with both IPv4 and IPv6 addresses. Any of
these combinations of addresses must be supported. For example,
Williams & Qin Expires January 7, 2010 [Page 2]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
one network connection may be IPv4 and another IPv6.
o R1 - MIF must support one or more network interfaces which can be
physical, logical or virtual.
o R2 - Network configuration parameters may come from different
administrative domains. MIF must be able to handle network
connection services that may be administered by different
organizations. In some deployments, the network services may not
be administered by the same organization or people, such as in a
community wireless environment. This poses challenges for the
host to have consistency of data offered by network connection
services.
o R3 - MIF solution must be compatible with existing IPv4, IPv6
architecture and protocols.
o R4 - MIF does not require to support IP mobility management
protocols (e.g. MIPv6, MIPv4) and is not part of the problem
scope.
o R5 - MIF must support the ability of communication to happen
simultaneously or independently over multiple network connections.
2.2. Requirements on merging of IP layer autoconfiguration
o R6 - MIF must be capable of collecting the global/local
configuration objects from different interfaces.
o R7 - MIF must support specific policies to merge the configuration
objects when they are conflicting
o R8 - MIF must provide the way to users/network to exchange the
policies for merging of configurations
o R9 - MIF node must provide the way to update the configurations.
2.3. Split DNS
o R10 - MIF must be able to get DNS services from different
networks.
o R11 - MIF must be configured with policies for DNS service access.
o R12 - MIF must provide the way to users/network to change the
policies for DNS access.
Williams & Qin Expires January 7, 2010 [Page 3]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
o R13 - MIF must provide the way to update the policies of DNS
service access.
3. Scenarios 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 scenarios of 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.
3.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
3.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. In this case a host has one Internet
connection and one VPN connection through which only private network
and services can be reached.
Williams & Qin Expires January 7, 2010 [Page 4]
Internet-Draft MIF Problem Requirements and Scenarios July 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
3.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
3.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.
Williams & Qin Expires January 7, 2010 [Page 5]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
_______
/ B \
/ ____ \
( / \ )
( ( A ) )
\ \____/ /
\_______/
Case IV: Inclusion
Figure 4
3.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.
4. Implication of usage scenarios on Multi-homed requirements
Analysis of these case scenarios will enable a more meaningful
perspective on the requirement solution space. Requirement
implications include:
o The host with multiple network interfaces must be able to handle
configuration information that may be gathered from multiple
sources.
o The host must be able handle per-node and per-interface settings.
Per interface settings can be complex because a client node needs
to know from which interface system settings came from. And it
may not be apparent which setting should be used, if e.g. if the
service setting is received on multiple interfaces, potentially
over different protocols.
o The host must be able to handle network connection services that
may be administered by different organizations. In some
Williams & Qin Expires January 7, 2010 [Page 6]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
deployments, the network services may not be administered by the
same organization or people, such as in a community wireless
environment. This poses problems for consistency of data offered
by network connection services.
o Mutli-interface fixed nodes may start, stop and dynamically change
flows and connection status. The host must be able to handle
these dynamic changes that may be both host wide as well as
interface specific. In addition, the host must be able to handle
protocol startup sequence that may result from such changes.
o Different requirements of different applications can result in a
different preference of the interface (physical or logical) that
should be used. Network connections should be placed in the best
possible interface based on these requirements. A fixed node
should not only be enabled to connect to different networks
simultaneously but also based on policies be able to dynamically
assign desired flows to the best interface.
5. Related IETF Works
5.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].
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.
5.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
[RFC5113], the routing of data packets, in the situation where
Williams & Qin Expires January 7, 2010 [Page 7]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
mechanisms more advanced than destination-based routing are thought
to be necessary. But, it explicitly specified that payload routings
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 discovery and attachment must be finished beforehand by
way of [RFC5113] . In this sense, MIF will not cover the network
selection and discovery at all.
5.3. PMIPv6 & Monami6
As discussed in early section, 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 interfaces
solutions of generic simple IP model. Furthermore, from an IP
perspective, there is only a single interface with PMIPv6 and any
network changes happen within the network. However, some experiences
in these working groups will be good references in MIF as well.
5.4. Default address selection (RFC3484)
[RFC3484] proposed default address selection and destination address
for IPv6 could be a reference to MIF work. On-going work is being
done with issues of default address selection in
[I-D.chown-addr-select-considerations]
5.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 SHIM6 only schedules the interfaces for the purposes of
redundancy, load sharing, etc.
o SHIM6 is more on switching the prefixes without the involvement 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.
Williams & Qin Expires January 7, 2010 [Page 8]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
6. 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.
This document doesn't intend to provide the MIF security analysis but
one will be required.
7. IANA Considerations
This document makes no requests to IANA.
8. Informative References
[I-D.blanchet-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-blanchet-mif-problem-statement-01 (work
in progress), June 2009.
[I-D.chown-addr-select-considerations]
Chown, T., "Considerations for IPv6 Address Selection
Policy Changes", draft-chown-addr-select-considerations-02
(work in progress), March 2009.
[I-D.savolainen-6man-fqdn-based-if-selection]
Savolainen, T., "Domain name based network interface
selection",
draft-savolainen-6man-fqdn-based-if-selection-00 (work in
progress), October 2008.
[I-D.savolainen-mif-dns-server-selection]
Savolainen, T., "DNS Server Selection on Multi-Homed
Hosts", draft-savolainen-mif-dns-server-selection-00 (work
in progress), February 2009.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
Williams & Qin Expires January 7, 2010 [Page 9]
Internet-Draft MIF Problem Requirements and Scenarios July 2009
[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.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network
Discovery and Selection Problem", RFC 5113, January 2008.
Authors' Addresses
Carl Williams
ZTE
Consultant
Palo Alto
United States
Email: carl.williams@mcsr-labs.org
Jacni Qin
ZTE
Shanghai
China
Email: jacniq@gmail.com
Williams & Qin Expires January 7, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:16 |