[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-mif-problem-statement

Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Informational                          December 9, 2008
Expires: June 12, 2009

                 Multiple Interfaces Problem Statement

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 12, 2009.


   A multi-homed host receives node configuration information from each
   of its access networks.  Some configuration objects are global to the
   node, some are local to the interface.  Various issues arise when
   multiple configuration objects that are global to the node are
   received on the many interfaces the multi-homed host has.  This
   document describes these issues.

Blanchet                  Expires June 12, 2009                 [Page 1]

Internet-Draft    Multiple Interfaces Problem Statement    December 2008

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Split DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Address Selection Policy  . . . . . . . . . . . . . . . . . . . 4
   5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   10. Discussion home for this draft  . . . . . . . . . . . . . . . . 5
   11. Informative References  . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7

Blanchet                  Expires June 12, 2009                 [Page 2]

Internet-Draft    Multiple Interfaces Problem Statement    December 2008

1.  Introduction

   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be 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.

   In this document, the multi-homed host does not forward any packet
   between its interfaces.  Therefore forwarding devices are out of
   scope of this document.

   A multi-homed 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 (default gateway), DNS
   servers IP addresses and address selection policies.

   When the received node-scoped configuration objects have different
   values from each access network, 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.  A document discusses (TBD: reference MRW doc) how some
   current implementations manage these cases.

   Several issues regarding how the node-scoped configuration objects
   are used in a multi-homed node environment have been raised.  The
   following sections describe the issues regarding DNS, routing and
   address selection policy.

2.  Split DNS

   A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses, as stated in
   [I-D.savolainen-6man-fqdn-based-if-selection].  This split DNS may
   occur when a VPN connection to an enterprise network is setup or in a
   service provider's network for subscribers-only services.  These
   private names and addresses are only relevant to a specific
   interface.  Therefore the traffic related to these names and
   addresses has to go through the right interface.  However, a typical
   IP stack does not maintain a binding of the origin of the DNS name
   resolution with its routing table.  Therefore the trafic might go to
   the wrong interface and never reach the destination.

Blanchet                  Expires June 12, 2009                 [Page 3]

Internet-Draft    Multiple Interfaces Problem Statement    December 2008

3.  Routing

   A multi-homed 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-6man-fqdn-based-if-selection] and
   [I-D.hui-ip-multiple-connections-ps], a service provider might want
   to influence the routing table of the host connecting to its network.
   (TBD: expand)

   A host usually has a node-scoped routing table.  Therefore, when a
   multi-homed host is connected to multiple networks and 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 multi-homed host might want a local policy to
   influence which interface will be used based on various conditions.

   On a multi-homed 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 multi-homed 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 and reply packets might never
   come back to the source.

4.  Address Selection Policy

   An address selection policy [RFC3484] is used to choose the right
   source and destination address for a new connection.  It is
   implemented globally in the node IP stack.

   As discussed in [RFC4291], a multi-homed host with IPv4 and IPv6
   connectivity might need to receive an update of its default address
   selection policy.  However, that policy is only valid within the
   context of the interface it received it from.  Each network on which
   the node is connected might have a different address policy to push
   to the connecting nodes" The received policies might be conflicting.
   There is currently no standard mechanism to determine what should be
   the behavior of the stack in such case.

5.  Summary

   A multi-homed host receives node configuration information from each

Blanchet                  Expires June 12, 2009                 [Page 4]

Internet-Draft    Multiple Interfaces Problem Statement    December 2008

   of its access networks.  Some configuration objects are global to the
   node, some are local to the interface.  Various issues arise when
   multiple configuration objects that are global to the node are
   received on the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IP stack and
   possibly define protocols to manage these cases.

6.  Security Considerations

   The problems discussed in this document have direct security
   implications, since the packets that are sent on the wrong interface
   might be leaking some confidential information.  Moreover, the
   undetermined behavior of IP stacks in the multi-homed context bring
   additional threats where an interface on a multi-homed host might be
   used to conduct attacks targeted to the networks connected by the
   other interfaces.

7.  IANA Considerations

   This document has no actions for IANA.

8.  Authors


9.  Acknowledgements

   NAMES have provided input and suggestions to this document.

10.  Discussion home for this draft

   This document is intended to define the problem space discussed in
   the mif@ietf.org mailing list.

11.  Informative References

              Hui, M. and H. Deng, "Problem Statement and Requirement of
              Simple IP Multi-homing of the Host",
              draft-hui-ip-multiple-connections-ps-01 (work in
              progress), November 2008.

Blanchet                  Expires June 12, 2009                 [Page 5]

Internet-Draft    Multiple Interfaces Problem Statement    December 2008

              Savolainen, T., "Domain name based network interface
              draft-savolainen-6man-fqdn-based-if-selection-00 (work in
              progress), October 2008.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

Author's Address

   Marc Blanchet
   2600 boul. Laurier, suite 625
   Quebec, QC  G1V 4W1

   Email: Marc.Blanchet@viagenie.ca
   URI:   http://www.viagenie.ca

Blanchet                  Expires June 12, 2009                 [Page 6]

Internet-Draft    Multiple Interfaces Problem Statement    December 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Blanchet                  Expires June 12, 2009                 [Page 7]

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