[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-blanchet-mif-problem-statement) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 6418

Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Informational                                  P. Seite
Expires: November 18, 2010                       France Telecom - Orange
                                                            May 17, 2010


                 Multiple Interfaces Problem Statement
                draft-ietf-mif-problem-statement-04.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 November 18, 2010.

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 November 18, 2010               [Page 1]

Internet-Draft    Multiple Interfaces Problem Statement         May 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


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 . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.7.  Above IP Layers  . . . . . . . . . . . . . . . . . . . . .  7
   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  . . . . 10
   5.  Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. Informative References . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15









Blanchet & Seite        Expires November 18, 2010               [Page 2]

Internet-Draft    Multiple Interfaces Problem Statement         May 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 mechanims 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,...). 0ne administrative domain can
      contain multiple provisioning domains.




Blanchet & Seite        Expires November 18, 2010               [Page 3]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


   A MIF host is defined as:

   o  A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host
   o  Configured with more than one IP addresses (excluding loopback,
      link-local)
   o  On one or more provisioning domains, as presented to the IP stack.
   o  The interfaces may be logical, virtual or physical.
   o  The IP addresses come from more than one 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  Communications using these IP addresses may be tied on all the
      possible provisioning domains, or, at least, on a limited number
      of 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 November 18, 2010               [Page 4]

Internet-Draft    Multiple Interfaces Problem Statement         May 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 assumes hosts only implementing [RFC1122] for IPv4 and
   [RFC4294] for IPv6, and not using any kind of new transport
   protocols.  It is not required for the host to support additional IP
   mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP,
   HIP, RRG, LISP or else.  Moreover, the peer of the connection is also
   not required to use these mechanisms.

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.

   Issues on using the Default Address Selection were found [RFC5220] in



Blanchet & Seite        Expires November 18, 2010               [Page 5]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


   the context of multiple prefixes on the same link.  New work
   [I-D.chown-addr-select-considerations] 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 [I-D.ietf-mmusic-ice]) 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.  ICE does not solve the MIF issues, such as the incompatible
   configuration objects received on different interfaces.  However, ICE
   may be of use for address selection if the application is ICE-
   enabled.

   Some application protocols do referrals (i.e. provides reachability
   information to itself or to a third-part) of IP addresses and port
   numbers for further exchanges.  Grobj
   [I-D.carpenter-behave-referral-object] defines the problem with
   referrals in today's IP networks.  While referrals feature does not
   solve the MIF issues, it is related since, in a multiple provisioning
   domain context, referrals must provide consistent information
   depending on which provisioning domain is used.

3.6.  Socket API

   Application Programming Interface (API) may expose objects that user
   applications may use for the MIF purpose.  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 November 18, 2010               [Page 6]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


   information and/or for control purpose.  If examples exist, as
   reminded above, there is no set of high level API to provide all
   required services for a connection manager expected to address IP
   configuration issues in a context of multiple provisioning domains.
   Moreover, various operation system implementations deliver different
   sets of high level API.  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.

3.7.  Above IP Layers

   The MIF issues discussed in this document assume no changes in
   transport protocols or applications.  However, fixing the issues
   might involve these layers.  For instance, an application may
   implement the connection management function (as decribed in
   preceding section).


4.  Symptoms

   This section describes the various symptoms found using a MIF host
   that has already received configuration objects from its various
   provisioning domains.

   These situations are also described in
   [I-D.savolainen-mif-dns-server-selection], [I-D.yang-mif-req] and
   [RFC4477].  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.




Blanchet & Seite        Expires November 18, 2010               [Page 7]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


   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-existant 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.
   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.

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 characterictics, 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.





Blanchet & Seite        Expires November 18, 2010               [Page 8]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


   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.

   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, as discussed
   in [I-D.savolainen-mif-dns-server-selection],
   [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], 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

   A MIF host (H1) has 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.




Blanchet & Seite        Expires November 18, 2010               [Page 9]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


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
   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 tries to list the underlying problems corresponding 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.  They are
   shown as below:

   1.  Configuration
       1.  Configuration objects (e.g.  DNS servers, NTP servers, ...)
           are usually node-scoped.
       2.  Same configuration objects (e.g.  DNS server addresses, NTP
           server addresses, ..) received from multiple provisioning
           domains are usually overwritten.
       3.  Host implementations usually do not keep separate network
           configuration (such as DNS server addresses) per provisioning
           domain.
       4.  Referrals must provide consistent information depending on
           which provisioning domain is concerned.
   2.  DNS resolution
       1.  DNS server addresses are usually node-scoped.
       2.  DNS answers are usually not kept with the interface from
           which the answer comes from.
   3.  Routing
       1.  Routing tables are usually node-scoped.
       2.  Host implementations usually do not implement the [RFC1122]
           models where the Type-of-Service are in the routing table.
       3.  Host implementations usually do not keep path
           characteristics, user or provider preferences in the routing
           table.
   4.  Address selection
       1.  Default Address Selection policies are usually node-scoped.





Blanchet & Seite        Expires November 18, 2010              [Page 10]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


       2.  Default Address Selection policies may differ when received
           on different provisioning domains.
       3.  Host implementations usually do not implement the strong host
           model [RFC1122] where the source address is in the routing
           table.
       4.  Applications usually do not use advanced APIs to specify the
           source IP address or to set preferences on the address
           selection policies.
   5.  Connection management
       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
           platorms, in the presence of the MIF problems.
       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 avalaible 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 favour mobile operator
           policy.


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.




Blanchet & Seite        Expires November 18, 2010              [Page 11]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


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.


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 the initial drafts.  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.chown-addr-select-considerations]



Blanchet & Seite        Expires November 18, 2010              [Page 12]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


              Chown, T., "Considerations for IPv6 Address Selection
              Policy Changes", draft-chown-addr-select-considerations-03
              (work in progress), July 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-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-09 (work in progress), March 2010.

   [I-D.ietf-mif-current-practices]
              Wasserman, M., "Current Practices for Multiple Interface
              Hosts", draft-ietf-mif-current-practices-00 (work in
              progress), October 2009.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [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., "DNS Server Selection on Multi-Homed
              Hosts", draft-savolainen-mif-dns-server-selection-02 (work
              in progress), February 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,



Blanchet & Seite        Expires November 18, 2010              [Page 13]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


              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.

   [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.

   [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.




Blanchet & Seite        Expires November 18, 2010              [Page 14]

Internet-Draft    Multiple Interfaces Problem Statement         May 2010


   [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.


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 November 18, 2010              [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/