Network Working Group M. Blanchet
Internet-Draft Viagenie
Intended status: Informational P. Seite
Expires: February 12, 2011 France Telecom - Orange
August 11, 2010
Multiple Interfaces Problem Statement
draft-ietf-mif-problem-statement-06.txt
Abstract
A multihomed host receives node configuration information from each
of its provisioning domain. Some configuration objects are global to
the node, some are local to the interface. Various issues arise when
multiple conflicting node-scoped configuration objects are received
on multiple interfaces. Similar situations also happen with single
interface host connected to multiple networks. This document
describes these issues.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 12, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Blanchet & Seite Expires February 12, 2011 [Page 1]
Internet-Draft Multiple Interfaces Problem Statement August 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4
3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4
3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 5
3.3. Mobility and other IP protocols . . . . . . . . . . . . . 5
3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 5
3.5. Finding and Sharing IP Addresses with Peers . . . . . . . 6
3.6. Socket API and connection manager . . . . . . . . . . . . 6
4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 7
4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 9
4.4. Single Interface on Multiple Provisioning Domains . . . . 9
5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. Informative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Blanchet & Seite Expires February 12, 2011 [Page 2]
Internet-Draft Multiple Interfaces Problem Statement August 2010
1. Introduction
A multihomed host have multiple provisioning domains (via physical
and/or virtual interfaces). For example, a node may be
simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G
cell network, one or multiple VPN connections or one or multiple
automatic or manual tunnels. Current laptops and smartphones
typically have multiple access network interfaces and, thus, may be
simultaneously connected to different provisioning domains.
A multihomed host receives node configuration information from each
of its access networks, through various mechanisms such as DHCPv4
[RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router
Advertisements [RFC4861]. Some received configuration objects are
specific to an interface such as the IP address and the link prefix.
Others are typically considered by implementations as being global to
the node, such as the routing information (e.g. default gateway), DNS
servers IP addresses and address selection policies.
When the received node-scoped configuration objects have different
values from each provisioning 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.
Several issues regarding how the node-scoped configuration objects
are used in a multihomed node environment have been raised. The
following sections define the MIF host and the scope of this
document, describe related work, list the symptoms and then the
underlying problems.
A companion document [I-D.ietf-mif-current-practices] discusses
current practices.
2. Terminology
Administrative domain
A group of hosts, routers, and networks operated and managed by a
single organization [RFC1136].
Provisioning domain
A set of consistent configuration information (e.g. Default
router, Network prefixes, DNS,...). One administrative domain can
contain multiple provisioning domains.
Blanchet & Seite Expires February 12, 2011 [Page 3]
Internet-Draft Multiple Interfaces Problem Statement August 2010
A MIF (Multiple InterFaces) host has the following characteristics:
o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host
o A MIF host is configured with more than one IP addresses
(excluding loopback, link-local)
o A MIF host can attach to more than one provisioning domains, as
presented to the IP stack.
o The interfaces may be logical, virtual or physical.
o Configuration objects come from one or more administrative
domains.
o The IP addresses may be from the same or from different address
families, such as IPv4 and IPv6.
o Communications using these IP addresses may happen simultaneously
and independently.
o Some communications using these IP addresses are possible on all
the provisioning domains, while some are only possible on a
smaller set of the provisioning domains.
o While the MIF host may forward packets between its interfaces,
forwarding packets is not taken into account in this definition.
Reference to IP version
When a protocol keyword such as IP, PPP, DHCP is used without any
reference to a specific IP version, then it implies both IPv4 and
IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is
specific to that IP version.
3. Scope and Existing Work
This section describes existing related work and defines the scope of
the problem.
3.1. Below IP Interaction
Network discovery and selection on lower layers as defined by
[RFC5113] is out of scope of this document. Moreover, lower layer
interaction such as IEEE 802.21 is also out of scope.
Some mechanisms (e.g., based on a logical IP interface)
allow sharing a single IP address across multiple interfaces
(e.g., WiMAX and CDMA, LTE and HSPA, etc.) to disparate networks.
From the IP stack view on the node, there is only a single interface
and single IP address. Therefore, this situation is out of scope of
this current problem statement. Furthermore, link aggregation done
under IP where a single interface is shown to the IP stack is also
out of scope.
Blanchet & Seite Expires February 12, 2011 [Page 4]
Internet-Draft Multiple Interfaces Problem Statement August 2010
3.2. Hosts Requirements
The requirements for Internet Hosts [RFC1122] describe the multihomed
host as if it has multiple IP addresses, which may be associated with
one or more physical interfaces connected to the same or different
networks.
The host maintains a route cache table where each entry contains the
local IP address, the destination IP address, Type-of-Service and
Next-hop gateway IP address. The route cache entry would have data
about the properties of the path, such as the average round-trip
delay measured by a transport protocol.
As per [RFC1122], two models are defined:
o The "Strong" host model defines a multihomed host as a set of
logical hosts within the same physical host. In this model a
packet must be sent on an interface that corresponds to the source
address of that packet.
o The "Weak" host model describes a host that has some embedded
gateway functionality. In the weak host model, the host can send
and receive packets on any interface.
The multihomed host computes routes for outgoing datagrams
differently depending on the model. Under the strong model, the
route is computed based on the source IP address, the destination IP
address and the Type-of-Service. Under the weak model, the source IP
address is not used, but only the destination IP address and the
Type-of-Service.
3.3. Mobility and other IP protocols
This document is only concerned with the situation where the hosts
implement [RFC1122] for IPv4 and [RFC4294] for IPv6 and not special-
purpose support for transport layers, mobility, multi-homing, or
identifier-locator split mechanisms. Dealing with multiple
interfaces with such mechanisms is somewhat separate problem and
under active study elsewhere in the IETF [RFC4960], [RFC5206],
[RFC5533], [RFC5648], [I-D.ietf-mptcp-architecture].
3.4. Address Selection
The Default Address Selection specification [RFC3484] defines
algorithms for source and destination IP address selections. It is
mandatory to be implemented in IPv6 nodes, which also means dual-
stack nodes. A node-scoped policy table managed by the IP stack is
defined. Provisions are made to change or update the policy table,
however, no mechanism is defined.
Blanchet & Seite Expires February 12, 2011 [Page 5]
Internet-Draft Multiple Interfaces Problem Statement August 2010
Issues on using the Default Address Selection were found in [RFC5220]
and [RFC5221] in the context of multiple prefixes on the same link.
New work [I-D.ietf-6man-addr-select-sol] discusses the multiple
attached networks scenarios and how to update the policy table.
3.5. Finding and Sharing IP Addresses with Peers
Interactive Connectivity Establishment (ICE [RFC5245]) is a technique
for NAT traversal for UDP-based (and TCP) media streams established
by the offer/answer model. The multiplicity of IP addresses and
ports in SDP offers are tested for connectivity by peer-to-peer
connectivity checks. The result is candidate IP addresses and ports
for establishing a connection with the other peer. However, ICE does
not solve issues when incompatible configuration objects are received
on different interfaces.
Some application protocols do referrals of IP addresses and port
numbers for further exchanges. For instance, applications can
provide reachability information to itself or to a third party. The
general problem of referrals is related to the multiple interface
problem, since, in this context, referrals must provide consistent
information depending on which provisioning domain is used. The
general referral problem has been studied in
[I-D.carpenter-behave-referral-object] and
[I-D.ietf-shim6-app-refer], but no solutions exist today.
3.6. Socket API and connection manager
Application Programming Interface (API) may expose objects that user
applications may use for dealing with multiple interfaces. For
example, [RFC3542] shows how an application using the Advanced
sockets API can specify the interface or the source IP address,
through simple bind() operation or IPV6_PKTINFO socket option.
There are other examples of API dealing with similar issues to MIF.
For instance, [RFC5014] defines API to influence the default address
selection mechanism by specifying attributes of the source addresses
it prefers. [I-D.ietf-shim6-multihome-shim-api] gives another
example in a multihoming context, by defining a socket API enabling
interactions between applications and the multihoming shim layer for
advanced locator management, and access to information about failure
detection and path exploration.
In the MIF context, some implementations, specially in the mobile
world, rely on higher-level connection managers to deal with issues
brought by multiple provisioning domains. Typically, the connection
manager can select the provisioning domain when application is domain
scoped. Connection managers usually leverage on API to gather
Blanchet & Seite Expires February 12, 2011 [Page 6]
Internet-Draft Multiple Interfaces Problem Statement August 2010
information and/or for control purpose. However, there is no
standardized high level API, and implementations differ also in the
functionality that they provide. In addition, these mechanisms do
not necessarily behave the same way across different platform and OS
in the presence of the MIF problems [I-D.ietf-mif-current-practices].
This lack of harmonization is an issue since it may lead to multiple
instantiation of a cross platform/OS connection manager or
application.
4. Symptoms
This section describes the various symptoms found using a MIF host
that has already received configuration objects from its various
provisioning domains. They occur, for example, when:
1. one interface is on the Internet and one is on a corporate
private network. The latter may be through VPN.
2. one interface is on one access network (i.e. wifi) and the other
one is on another access network (3G) with specific services.
4.1. DNS resolution issues
A MIF host (H1) has an active interface(I1) connected to a network
(N1) which has its DNS server (S1) and another active interface (I2)
connected to a network (N2) which has its DNS server (S2). S1 serves
with some private namespace "private.example.com". The user or the
application uses a name "a.private.example.com" which is within the
private namespace of S1 and only resolvable by S1. Any of the
following situations may occur:
1. H1 stack, based on its routing table, uses I2 to reach S1 to
resolve "a.private.example.com". H1 never reaches S1. The name
is not resolved.
2. H1 keeps only one set of DNS server addresses from the received
configuration objects and kept S2 address. H1 sends the DNS A
query for a.private.example.com to S2. S2 responds with an error
for an non-existent domain (NXDOMAIN). The name is not resolved.
3. H1 keeps only one set of DNS server addresses from the received
configuration objects and kept S2 address. H1 sends the DNS A
query for a.private.example.com to S2. S2 asks its upstream DNS
and gets an IP address for a.private.example.com. However, the
IP address is not the same one S1 would have given. Therefore,
the application tries to connect to the wrong destination host,
or to the wrong interface of the latter, which may imply security
issues or result in lack of service.
Blanchet & Seite Expires February 12, 2011 [Page 7]
Internet-Draft Multiple Interfaces Problem Statement August 2010
4. S1 or S2 has been used to resolve "a.private.example.com" to an
[RFC1918] address. Both N1 and N2 are [RFC1918] addressed
networks. IPv4 source address selection may face challenges, as
due address overlapping the source/destination IP addresses do
not necessarily provide enough information for making proper
address selection decisions.
5. H1 has resolved an FQDN to locally valid IP address when
connected to N1. After movement from N1 to N2, the host tries to
connect to the same IP address as earlier, but as the address was
only locally valid, connection setup fails.
6. H1 requests AAAA record from a DNS server on a network that uses
protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the
H1 receives synthesized AAAA record, it is guaranteed to be valid
only on the network it was learned from. If the H1 uses
synthesized AAAA on an network interface it is not valid on, the
packets will be dropped by the network.
A MIF host may also be provisioned with a Interface-specific suffix
search list ([I-D.ietf-mif-current-practices]). In this situation,
if H1 sends DNS query on I1 using the search list tied to I2, the
namespace could be not valid on I1 and the name could be not
resolved.
4.2. Routing
A MIF host (H1) has an active interface(I1) connected to a network
(N1) and another active interface (I2) connected to a network (N2).
The user or the application is trying to reach an IP address (IP1).
Any of the following situations may occur:
1. For IP1 , H1 has one default route (R1) via network (N1). So,
trying to reach IP1, H1 stack uses R1 and sends through I1. If
IP1 is only reachable by N2, IP1 is never reached or is not the
right target.
2. For the IP1 address family, H1 has one default route (R1, R2) per
network (N1, N2). IP1 is reachable by both networks, but N2 path
has better characteristics, such as better round-trip time, least
cost, better bandwidth, etc.... These preferences could be
defined by user, by the provider, by discovery or else. H1 stack
uses R1 and tries to send through I1. IP1 is reached but the
service would be better by I2.
3. For the IP1 address family, H1 has a default route (R1), a
specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a
default route (R2) to N2. IP1 is reachable by N2 only, but the
prefix (X.0.0.0/8) is used in both networks. Because of the most
specific route R1B, H1 stack sends through I2 and never reach the
target.
Blanchet & Seite Expires February 12, 2011 [Page 8]
Internet-Draft Multiple Interfaces Problem Statement August 2010
A MIF host may have multiple routes to a destination. However, by
default, it does not have any hint concerning which interface would
be the best to use for that destination. For example, a service
provider might want to influence the routing table of the host
connecting to its network.
A host usually has a node-scoped routing table. Therefore, when a
MIF host is connected to multiple provisioning domains where each
service provider wants to influence the routing table of the host,
then conflicts might arise from the multiple routing information
being pushed to the host.
A user on such multihomed host might want a local policy to influence
which interface will be used based on various conditions.
On a MIF host, some source addresses are not valid if used on some
interfaces. For example, an RFC1918 source address might be
appropriate on the VPN interface but not on the public interface of
the MIF host. If the source address is not chosen appropriately,
then sent packets might be filtered in the path if source address
filtering is in place ([RFC2827],[RFC3704]) and reply packets might
never come back to the source.
4.3. Address Selection Policy
Even if not yet specified, the distribution of address selection
policy is sometimes evoked. If deployed, such a mechanism could
bring specific issue in a multiple provisioning domain context. Lets
consider a MIF host(H1) with an active interface(I1) connected to a
network (N1) and another active interface (I2) connected to a network
(N2). When the user or the application is trying to reach an IP
address (IP1), the following situations may occur:
H1 receives from both networks (N1 and N2) an update of its
default address selection policy. However, the policies are
specific to each network. The policies are merged by H1 stack.
Based on the merged policy, the chosen source address is from N1
but packets are sent to N2. The source address is not reachable
from N2, therefore the return packet is lost.
Merging address selection policies may have important impacts on
routing.
4.4. Single Interface on Multiple Provisioning Domains
When a MIF host using a single interface is connected to multiple
networks with different default routers, similar issues as described
above happen. Even with a single interface, a node may wish to
connect to more than one configuration domain: that node may use more
Blanchet & Seite Expires February 12, 2011 [Page 9]
Internet-Draft Multiple Interfaces Problem Statement August 2010
than one IP source address and may have more than one default router.
The node may want to access services that can only be reached using
one of the provisioning domain, so it needs to use the right outgoing
source address and default gateway to reach that service. In this
situation, that node may also need to use different DNS servers to
get domain names in those different provisioning domains.
5. Problems
This section lists the underlying problems leading to the issues
discussed in the previous section. The problems can be divided into
five categories: 1) Configuration 2) DNS resolution 3) Routing 4)
Address selection and 5) connection management and API. They are
shown as below:
1. Configuration. In a MIF context, configuration information
specific to a provisioning domain may be ignored because:
1. Configuration objects (e.g. DNS servers, NTP servers, ...)
are node-scoped. So the IP stack is not able to maintain the
mapping between information and corresponding provisioning
domain.
2. Same configuration objects (e.g. DNS server addresses, NTP
server addresses, ..) received from multiple provisioning
domains may be overwritten.
3. Host implementations usually do not keep separate network
configuration (such as DNS server addresses) per provisioning
domain.
2. DNS resolution
1. Some FQDN can be resolvable only via a specific interface
(e.g. intranet services). However, DNS query could be send
to the wrong interface because DNS server addresses may be
node-scoped.
2. A DNS answer can be valid only on a specific interface but
applications may be not aware of that mapping because DNS
answers may be not kept with the interface from which the
answer comes from.
3. Routing
1. In the MIF context, routing information could be specific to
each interface. This could lead to routing issue because, in
current host implementations, routing tables are node-scoped.
2. Interfaces of a MIF host can provide different
characteristics (e.g. round-trip time, least cost, better
bandwidth, etc....). So, user, applications or network
provider may wish to influence routing to take benefit of
this heterogeneity. However, with current host
implementations, neither the Type-of-Service nor path
characteristics can be taken into account in the routing
Blanchet & Seite Expires February 12, 2011 [Page 10]
Internet-Draft Multiple Interfaces Problem Statement August 2010
table.
4. Address selection
1. Default Address Selection policies may be specific to their
corresponding provisioning domain. However, a MIF host may
not be able to manage per-provisioning domain address
selection policies because default Address Selection policy
is node-scoped.
2. On a MIF host, some source addresses are not valid if used on
some interfaces or even on some default routers on the same
interface. In this situation, the source address should be
taken into account in the routing table; but current host
implementations do not support such a feature.
3. Source address or address selection policies could be
specified by applications. However, there is no advanced
APIs to allow applications realizing such operations.
5. Connection management and API
1. Some implementations, specially in the mobile world, have
higher-level API and/or connection manager to address MIF
issues. These mechanisms are not standardized and do not
necessarily behave the same way across different OS, and/or
platforms, in the presence of the MIF problems. This lack of
consistency is an issue for user and operator who could
experience different connection manager behaviors depending
on the terminal.
2. Provisioning domain selection is a feature of connection
management. Domain selection can be tricky due to lot of
different situations and selection criteria: some
applications are domain-scoped, or may have a preferred
provisioning domain (e.g. according to available QoS). Each
actor (end-user, operator, service provider, etc.) may also
have their preferred provisioning domains (e.g. single out
lower cost domain), possibly per application.
3. The different actors may provide different, and sometimes
contradictory, domain selection policies to the connection
management function. The connection manager can typically
address the issue, but not all connection managers are able
to.
4. A MIF host can support different connection managers, which
may have contradictory ways to solve the MIF issues. For
instance, because of different selection algorithms, two
different connection managers could select different domains
in a same context. Or, when dealing with different domain
selection policies, a connection manager may give precedence
to user policy while another could favor mobile operator
policy.
Blanchet & Seite Expires February 12, 2011 [Page 11]
Internet-Draft Multiple Interfaces Problem Statement August 2010
6. Summary
A MIF host receives node configuration information from each of its
provisioning domains. Some configuration objects are global to the
node, some are local to the interface. Various issues arise when
multiple conflicting node-scoped configuration objects are received
via multiple provisioning domains. Similar situations also happen
with single interface host connected to multiple networks.
Therefore, there is a need to define the appropriate behavior of an
IP stack and possibly define protocols to manage these cases.
7. Security Considerations
The problems discussed in this document have security implications,
such as when the packets sent on the wrong interface might be leaking
some confidential information. Moreover, the undetermined behavior
of IP stacks in the multihomed context bring additional threats where
an interface on a multihomed host might be used to conduct attacks
targeted to the networks connected by the other interfaces.
Additional security concerns raise up when information is provided to
the host so that it could make a more intelligent decision (e.g.
provide selection policies to the connection manager). This
additional information should be protected in some manner.
8. IANA Considerations
This document has no actions for IANA.
9. Authors
This document is a joint effort with authors of the MIF requirements
draft [I-D.yang-mif-req]. The authors of this document, in
alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick
Seite, Carl Williams and Peny Yang.
10. Acknowledgements
The initial Internet-Drafts prior to the MIF working group and the
discussions during the MIF BOF meeting and on the mailing list around
the MIF charter scope on the mailing list brought very good input to
the problem statement. This draft steals a lot of text from these
discussions and initial drafts (e.g. [I-D.yang-mif-req],
[I-D.hui-ip-multiple-connections-ps],
Blanchet & Seite Expires February 12, 2011 [Page 12]
Internet-Draft Multiple Interfaces Problem Statement August 2010
[I-D.savolainen-mif-dns-server-selection]). Therefore, the editor
would like to acknowledge the following people (in no specific
order), from which some text has been taken from: Jari Arkko, Keith
Moore, Sam Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie
Volz, Giyeong Son, Gabriel Montenegro, Julien Laganier, Teemu
Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui
Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis-
Courmont, Alexandru Petrescu, Zhen Cao. Sorry if some contributors
have not been named.
11. Informative References
[I-D.carpenter-behave-referral-object]
Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and
K. Moore, "A Generic Referral Object for Internet
Entities", draft-carpenter-behave-referral-object-01 (work
in progress), October 2009.
[I-D.hui-ip-multiple-connections-ps]
Hui, M. and H. Deng, "Problem Statement and Requirement of
Simple IP Multi-homing of the Host",
draft-hui-ip-multiple-connections-ps-02 (work in
progress), March 2009.
[I-D.ietf-6man-addr-select-sol]
Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution
approaches for address-selection problems",
draft-ietf-6man-addr-select-sol-03 (work in progress),
March 2010.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-10 (work in progress), July 2010.
[I-D.ietf-mif-current-practices]
Wasserman, M. and P. Seite, "Current Practices for
Multiple Interface Hosts",
draft-ietf-mif-current-practices-02 (work in progress),
June 2010.
[I-D.ietf-mptcp-architecture]
Ford, A., Raiciu, C., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development",
draft-ietf-mptcp-architecture-01 (work in progress),
June 2010.
Blanchet & Seite Expires February 12, 2011 [Page 13]
Internet-Draft Multiple Interfaces Problem Statement August 2010
[I-D.ietf-shim6-app-refer]
Nordmark, E., "Shim6 Application Referral Issues",
draft-ietf-shim6-app-refer-00 (work in progress),
July 2005.
[I-D.ietf-shim6-multihome-shim-api]
Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
"Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13
(work in progress), February 2010.
[I-D.savolainen-mif-dns-server-selection]
Savolainen, T., "Improved DNS Server Selection for Multi-
Homed Hosts", draft-savolainen-mif-dns-server-selection-03
(work in progress), June 2010.
[I-D.yang-mif-req]
Yang, P., Seite, P., Williams, C., and J. Qin,
"Requirements on multiple Interface (MIF) of simple IP",
draft-yang-mif-req-00 (work in progress), March 2009.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing
Domains: A model for routing in the Internet", RFC 1136,
December 1989.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[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.
Blanchet & Seite Expires February 12, 2011 [Page 14]
Internet-Draft Multiple Interfaces Problem Statement August 2010
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
Issues", RFC 4477, May 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network
Discovery and Selection Problem", RFC 5113, January 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
[RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Requirements for Address Selection Mechanisms", RFC 5221,
July 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
Blanchet & Seite Expires February 12, 2011 [Page 15]
Internet-Draft Multiple Interfaces Problem Statement August 2010
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
Authors' Addresses
Marc Blanchet
Viagenie
2600 boul. Laurier, suite 625
Quebec, QC G1V 4W1
Canada
Email: Marc.Blanchet@viagenie.ca
URI: http://www.viagenie.ca
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
Blanchet & Seite Expires February 12, 2011 [Page 16]
