One document matched: draft-cao-mif-analysis-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc category="info" ipr="trust200902" docName="draft-cao-mif-analysis-00">
<front>
<title abbrev="MIF Solution Analysis">MIF Current Practice Analysis</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="Qualcomm Inc.">
Qualcomm Incorporated
</organization>
<address> <postal>
<street>5775 Morehouse Drive
</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>USA</country>
</postal>
<phone>+1 858 858 3538</phone>
<email>julienl@qualcomm.com</email>
</address>
</author>
<author initials="G." surname="Montenegro" fullname="Gabriel Montenegro"><organization>Microsoft
</organization><address>
<email>gmonte@microsoft.com</email></address>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<code>FI-02600 Espoo</code>
<country>FINLAND</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author initials="T" surname="Savolainen" fullname="Teemu Savolainen">
<organization>Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720 Tampere</code>
<country>FINLAND</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author initials="Z." surname="Cao" fullname="Zhen Cao"><organization>China
Mobile</organization><address>
<email>zehn.cao@chinamobile.com</email></address>
</author>
<date year="2010"/><area>Internet</area><workgroup>MIF
Working Group</workgroup>
<abstract>
<t>This document
presents the analysis of the problems encountered by a multi-homed host
and the gap analysis of current solutions
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
A multihomed host have multiple provisioning domains via physical
and/or virtual interfaces.
A multihomed host receives node configuration information from each
of its access networks, through various mechanisms such as DHCP, PPP
and IPv6 Router Advertisements.
When the received node-scoped configuration objects have different
values from each administration domains, such as different DNS servers
IP addresses, different default gateways or different address
selection policies, the node has to decide which it will use or how
it will merge them.
</t>
<t>
Issues regarding how the multi-homed host uses the configuration
objects have been addresses in <xref target="I.D-MIF-PS" />.
Current practices of how the various implementations handle these problems are
introduced in <xref target="I.D-MIF-CP" />.
This document
presents the analysis of those problems as well as the gap analysis of
the current practices.
</t>
</section>
<section title="Problem Analysis">
<t>
We divide the problems raised in <xref target="I.D-MIF-PS" />
into five categories as below.
</t>
<section anchor="name" title="Problems w.r.t. Naming and Addressing">
<t> Problems with respect to naming and addressing are listed as below:
<list style="hanging" hangIndent="6">
<t hangText=" o"> DNS server addresses and other configuration objects (NTP
servers, ...) are usually node-scoped.
</t>
<t hangText=" "> Note: DNS server addresses are domain scoped: (provided by e.g. DHCP)
is only reachable as per routing entries from one provisioning domain and/or using source
address from same provisioning domain. A solution is introduced in <xref target="I.D-MIF-DNS" />
</t>
<t hangText=" o"> DNS answers are usually not kept with the interface from which
the answer comes from.
</t>
<t hangText=" "> Note: DNS answers are domain scoped: give addresses that are
only reachable as per routing entries from one provisioning domain and/or using
source address from same provisioning domain. </t>
<t hangText=" o">RFC1918 addresses are domain scoped.
</t>
<t hangText=" "> Note:
Nodes assumes global scope for IPv4 addresses: node assume that there's
a single IPv4 addressing space while in reality there are many overlapping
RFC1918 address spaces. Such RFC1918 addresses should be provisioning domain
scoped when used as source or destination address. For examples it should be
possible that a host has the same RFC1918 address assigned to two different
interfaces (e.g., on two PDP context connected to two different APNs.)
</t>
</list>
</t>
</section>
<section anchor="routing" title="Problems w.r.t. Routing">
<t> Configuration with respect to routing is another issue for
multiple homed hosts.
<list style="hanging" hangIndent="5">
<t hangText=" o"> Routing tables are usually node-scoped, introducing
the following problems:
<list style="hanging" hangIndent="3">
<t hangText=" a."> Routing tables are domain scoped:
nodes have node-scoped or interface-scoped routing tables.
This causes issues when node has two entries for same destination
with same metric. There are also interactions with Addressing/a above
in case there’s a route to an RFC1918 prefix e.g., 192.168.0.0/24. </t>
<t hangText=" b."> Ingress filtering: is an issue where connectivity
is restricted to use of given source addresses from the provisioning domain </t>
<t hangText=" c."> Domain-scoped connectivity: many nodes assumes
there is such a thing as internet connectivity, i.e., a default route
on an interface allows to reach any destination. However there are walled
gardens and APNs in the cellular world where connectivity through one
provisioning domain is restricted to a set of destination and barred to others.
</t>
</list>
</t>
<t hangText=" o"> Host implementations usually do not implement the [RFC1122]
model where the Type-of-Service are in the routing table.
</t>
<t hangText=" ">
Note: What would be needed is domain scoped routing tables.
</t>
<t hangText=" o">Host implementations usually do not keep path characteristics,
user or provider preferences in the routing table.
</t>
<t hangText=" ">
Note: Path characteristics would be useless absent an interface
that let applications specify their QoS requirement.
As to user/provider preferences, that can be done today in a routing
table by playing with the routing metric.
</t>
</list>
</t>
</section>
<section anchor="dosel" title="Problems w.r.t. Domain Selection">
<t>Application usually does not specify domain, how to select it? Is it per host
default, or more dynamic selection based on e.g., result from name resolution
and route lookup across multiple domains, and final selection based on what works?
</t>
<t>Note: Some applications require domain affinity. There should be some way to set it
either by the application itself or by the system on behalf of the application.
Therefore the system should be cognizant of domains.
</t>
</section>
<section anchor="addsel" title="Problems w.r.t. Address Selection ">
<t> Address selection is issue for MIF-enabled nodes, including:
<list style="hanging" hangIndent="8">
<t hangText=" o"> Default Address Selection policies are usually node-scoped. </t>
<t hangText=" "> Note: What would be needed it seems is domain scoped policies. </t>
<t hangText=" o"> Default Address Selection policies may differ when received on
different provisioning domains.
</t>
<t hangText=" "> Note: What would be needed it seems is domain scoped policies. </t>
<t hangText=" o">Host implementations usually do not implement the [RFC1122]
strong model where the source address is in the routing table.
</t>
<t hangText=" "> Note: Having the source address in the routing table would avoid
issues with ingress filtering. But this seems chicken and egg. Currently the
source address selection occurs as a result of a route lookup. So it seems
it makes more sense to first select a domain, then lookup the route in the
domain-scoped route, and finally perform source address selection as per this domain policies.
</t>
<t hangText=" o">Applications usually do not use advanced APIs to specify the
source IP address or to set preferences on the address selection
policies.
</t>
<t hangText=" ">Note: having application specify source IP address is overkill.
An application is primarily interested on connecting to a destination,
thus it needs a connectivity provider. Once the connectivity provider
has been selected the source address can be picked automatically as a result of the route lookup.
</t>
</list>
</t>
</section>
<section anchor="conf" title="Problems w.r.t. Configuration and Policy">
<t> Problems with respect to configuration and policy include:
<list style="hanging" hangIndent="4">
<t hangText=" o"> Same configuration objects (e.g., DNS server addresses, NTP server
addresses, ..) received from multiple provisioning domains are
usually overwritten.
</t>
<t hangText=" o"> Host implementations usually do not keep separate network
configuration (such as DNS server addresses) per provisioning
domain.
</t>
<t hangText=" o"> There’s no way yet to handle multiple policies coming
from different domains. E.g., corporate node usage typically means that the
corporation issues some policy on that Wi-Fi interface (and others as well).
In this case, the carrier and corporation domains and their policies will
overlap over the Wi-Fi interface. Having a common policy language might
help to detect and reason about such conflicts, but conflict resolution
is another problem. Ultimately, the issue are the different authorities
on these domains (e.g., “user” at home, admin at corporation and carrier
for wireless broadband) and how they resolve their conflicts in the overlap situations.
</t>
<t hangText=" "> Note:
Domains and their policies may span multiple interfaces.
There is a fixed hierarchy of domains and their authorities,
but the top authority may decide to delegate to others certain
parts of the system and to their policies, as long as these don't
conflict with his. A conflict resolution that respects the hierarchy is needed.
</t>
</list>
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD.</t>
</section>
<section title="IANA Considerations">
<t>This document does not require any IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?xml version='1.0' encoding='UTF-8'?>
<reference anchor="I.D-MIF-PS"
target="draft-ietf-mif-problem-statement-01.txt (work in progress)">
<front>
<title>Multiple Interfaces Problem Statement</title>
<author initials="M." surname="Blanchet">
<organization>Viagenie</organization>
</author>
<author initials="P. " surname="Seite">
<organization>France Telecom</organization>
</author>
<date month="Oct" year="2009" />
</front>
</reference>
<reference anchor="I.D-MIF-CP"
target="draft-ietf-mif-current-practices-00.txt (work in progress)">
<front>
<title>Current Practices for Multiple Interface Hosts</title>
<author initials="M." surname="Wasserman">
<organization>Sandstorm</organization>
</author>
<date month="December" year="2009" />
</front>
</reference>
<reference anchor="I.D-MIF-DNS"
target="draft-savolainen-mif-dns-server-selection-02.txt (work in progress)">
<front>
<title>DNS Server Selection on Multi-Homed Hosts</title>
<author initials="T." surname="Savolainen">
<organization>Nokia</organization>
</author>
<date month="February" year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:37:40 |