Network Working Group M. Blanchet
Internet-Draft Viagenie
Intended status: Informational December 9, 2008
Expires: June 12, 2009
Multiple Interfaces Problem Statement
draft-blanchet-mif-problem-statement-00.txt
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 12, 2009.
Abstract
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
TBD
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
[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-01 (work in
progress), November 2008.
Blanchet Expires June 12, 2009 [Page 5]
Internet-Draft Multiple Interfaces Problem Statement December 2008
[I-D.savolainen-6man-fqdn-based-if-selection]
Savolainen, T., "Domain name based network interface
selection",
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
Viagenie
2600 boul. Laurier, suite 625
Quebec, QC G1V 4W1
Canada
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Blanchet Expires June 12, 2009 [Page 7]