One document matched: draft-cao-mif-analysis-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1918 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml'>
<!ENTITY RFC4193 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY RFC1122 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml'>
<!ENTITY I-D.ietf-mif-problem-statement PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-problem-statement.xml'>
<!ENTITY I-D.ietf-mif-current-practices PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-current-practices.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">
<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 analyzes whether the problems encountered by a multi-homed host are satisfactorily addressed
by mechanisms currently implemented in operating systems.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
A multihomed host have multiple provisioning domains via virtual and/or
physical interfaces. A multihomed host receives node configuration
information from each of its access networks, through various mechanisms
such as DHCP, PPP's IPCP and IPv6 Router Advertisements. When the
multihomed host receives various configuration objects (e.g., DNS server
address, default gateway, address selection policies) with values that
differ from one administrative domain to another, the node has to decide
which one to use or how to reconcile them.
</t>
<t>
Issues regarding how the multi-homed host uses the configuration objects have
been addressed in <xref target="I-D.ietf-mif-problem-statement" />. Current
practices of how the various implementations handle these problems are
introduced in <xref target="I-D.ietf-mif-current-practices" />. This
document analyzes whether the problems encountered by a multi-homed host are
satisfactorily addressed by mechanisms implemented in operating systems.
</t>
</section>
<section title="Terminology">
<t>
The following terms are used throughout this document:
<list>
<t>
Multihomed Host: A host that is attached to one or more networks via one or more virtual and/or physical interfaces.
</t>
</list>
</t>
</section>
<section title="Problem Analysis">
<t>
We group the problems raised in <xref target="I-D.ietf-mif-problem-statement" />
into specific categories as per the subsections below.
</t>
<section anchor="name" title="Naming and Addressing">
<t>
<list style="numbers">
<t>
The operating systems has node-scoped DNS server addresses but the
DNS server addresses provided by a given domain are only reachable
through that domain.
</t>
<t>
The answers to DNS queries returned by the DNS server of a given
domain are only valid and/or reachable within that domain (e.g.,
split horizon DNS) but the operating system treats these answers as
valid on any domain.
</t>
<t>
Private IPv4 addresses <xref target="RFC1918"/> and Unique Local
IPv6 Unicast Addresses <xref target="RFC4193"/> are reachable from
within a given domain (i.e., they are site-scoped) but the operating
system doesn't know the domain boundary and treats these as
reachable on any domain (i.e., they have global scope.)
</t>
<t>
Private IPv4 addresses <xref target="RFC1918"/> are only
unambiguous within a given domain but the operating system doesn't
know the domain boundary and cannot associate a Private IPv4 Address
to a given domain and thus treats those as valid on any domain.
</t>
</list>
</t>
</section>
<section anchor="routing" title="Routing">
<t>
<list style="numbers">
<t>
Routing tables entries to ambiguous subnet prefixes in <xref
target="RFC1918"/> addressing space are only
unambiguous within a given domain but the operating system
doesn't distinguish routes to the same prefixes belonging to
different communication domains, thus leading to use of the
wrong outbound interface and wrong destincation gateway.
</t>
<t>
Routing tables entries with an ambiguous next hop IP address
in <xref target="RFC1918"/> addressing space are only to be
used within a given domain but the operating system doesn't
necessarily know which was the communication domain thus
leading to use of the wrong outbound interface and wrong
destination gateway, and/or communication failure if no
destination gateway is reachable at the destination address
or if the destination gateway has no upstream route to the
final destination of the packet.
</t>
<t>
Host implementations usually do not implement the [RFC1122]
model where the Type-of-Service are in the routing table which
could be use to choose between routes with same longest prefix
match and same metrics but different Type-of-Service
characteristics, e.g., low delay, high throughput.
</t>
</list>
</t>
</section>
<section title="Reachability">
<t>
<list style="numbers">
<t>
Ingress filtering can prevent communication when a node sends
packets from a source address allocated from a given domain
to a (default) router in another domain.
</t>
<t>
Strong host model implementaion can cause incoming packets
to be discarded when they are sent to a destination address
assigned to one of the interface of the node that is not the
interface on which the packet is incoming.
</t>
<t>
There is no interface between a router and a host for the
router to indicate that there is no default route but only
specific routes to some prefixes. As a result, a node
that discovers a router assumes that any destination is
reachable, which might not always be the case: in some case
only connectivity to destination in the domain is available,
and other destinations are unreachable, e.g., walled
gardens, corporate intranets, etc.
</t>
<!-- <t>Host implementations usually do not keep path characteristics,
user or provider preferences in the routing table.
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="Domain Selection">
<t>
<list style="numbers">
<t>
Application usually does not specify to which domain they want
to communicate. When the destination has an unambiguous address
the domain can sometimes be derived from that. This is however
not the case when the destination is an ambiguous address from
<xref target="RFC1918"/>.
</t>
<t>
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>
</list>
</t>
</section>
<!--
<section anchor="addsel" title="Address Selection ">
<t>
<list style="numbers">
<t> Default Address Selection policies are usually node-scoped. </t>
<t> Note: What would be needed it seems is domain scoped policies. </t>
<t> Default Address Selection policies may differ when received on
different provisioning domains.
Note: What would be needed it seems is domain scoped policies. </t>
<t>Host implementations usually do not implement the [RFC1122]
strong model where the source address is in the routing table.
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>Applications usually do not use advanced APIs to specify the
source IP address or to set preferences on the address selection
policies.
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="Configuration and Policy">
<t>
<list style="numbers">
<t>
Operating system does not keep separate, per domain copies
of same configuration objects (e.g., DNS server addresses,
NTP server addresses, ..) and thus these are either
overwritten by the operating system when received from
multiple provisioning domains, or ignored when not received
on a so-called primary interface.
</t>
<t>
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. 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 title="Current Practice Analysis">
<section title="Mobile Handset Operating Systems">
<section title="Nokia S60 3rd Edition, Feature Pack 2">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="Microsoft Windows Mobile 2003 Second Edition">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="RIM BlackBerry">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="Google Android">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="Qualcomm AMSS">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="Arena Connection Manager">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="Access Selection">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
</section>
<section title="Computer Operating Systems">
<section title=" Microsoft Windows">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
<section title="Linux and BSD-based Operating Systems">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing: 1, 2, 3, 4
</t>
<t>
Routing: 1, 2, 3
</t>
<t>
Reachability: 1, 2, 3
</t>
<t>
Domain Selection: 1, 2
</t>
<t>
Configuration and Policy: 1, 2
</t>
</list>
</t>
</section><section title="Apple MacOS X">
<t>
The following problems occurs:
<list>
<t>
Naming and Addressing:
</t>
<t>
Routing:
</t>
<t>
Reachability:
</t>
<t>
Domain Selection:
</t>
<t>
Configuration and Policy:
</t>
</list>
</t>
</section>
</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="Informative References">
&RFC1918;
&RFC4193;
&I-D.ietf-mif-problem-statement;
&I-D.ietf-mif-current-practices;
<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:22:02 |