Individual Submission T. Savolainen
Internet Draft Nokia
Intended status: Experimental October 23, 2008
Expires: April 2009
Domain name based network interface selection
draft-savolainen-6man-fqdn-based-if-selection-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.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
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 April 23, 2009.
Savolainen Expires April 23, 2009 [Page 1]
Internet-Draft FQDN based interface selection October 2008
Abstract
A multi-homed host with multiple physical and/or virtual network
interfaces has to select which one of the network interfaces to use
for a new outgoing IPv4 or IPv6 connection. This document describes a
method to select an interface by using destination's fully qualified
domain name and DNS suffix information received dynamically for each
network interface. The method is useful, for example, in split
horizon DNS and walled garden scenarios, where right network
interface has to be selected even before DNS resolution is conducted.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Problem descriptions...........................................4
3.1. Split horizon DNS.........................................4
3.2. Firewalled walled gardens.................................5
3.3. Seemingly equal interfaces................................5
4. DNS suffix based interface selection...........................6
4.1. Learning of the DNS suffixes..............................6
4.2. Changes to DNS resolution procedures......................8
4.3. Changes to host's address selection procedures............9
5. Network operator considerations...............................10
6. Further considerations........................................10
7. Security Considerations.......................................10
8. IANA Considerations...........................................11
9. Acknowledgments...............................................11
10. References...................................................11
10.1. Normative References....................................11
10.2. Informative References..................................12
Author's Address.................................................12
Savolainen Expires April 23, 2009 [Page 2]
Internet-Draft FQDN based interface selection October 2008
1. Introduction
A host initiating an IP connection commonly uses destination's fully
qualified domain name (FQDN). The FQDN has to be first resolved into
an IP address with help of DNS, and afterwards the connection is
created to one of the resolved IP addresses. The source and
destination IP addresses that are used for the connection are
determined by host's address selection algorithms, like the one
defined for IPv6 in [RFC3484].
A multi-homed host may do network interface selection as part of
host's source address selection algorithm. A host may also be
configured to use only single network interface at any given time or
for a given application.
This document identifies three problematic scenarios a multi-homed
host may encounter and for which solutions are needed. The problems
are listed below and described in detail in chapter 3:
1. Split horizon DNS
2. Firewalled walled gardens
3. Seemingly equal interfaces
An example of an application facing these problems is a web browser,
which in multi-homed environments may need to dynamically access
content over different network interfaces.
As a possible solution for these problems a method is described in
chapter 4 that uses DNS suffixes for determining the best network
interface for DNS resolution and for connecting to a given FQDN.
The solution presented in this memo is intended to be fully backwards
compatible and one that can be fully ignored by hosts and networks
that are not experiencing the described problem scenarios.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Savolainen Expires April 23, 2009 [Page 3]
Internet-Draft FQDN based interface selection October 2008
3. Problem descriptions
This chapter describes three multi-homing related problem scenarios
for which the DNS suffix based network interface selection solution
described in chapter 4 is targeted at. The scenarios are not
excluding each other, but shown separately for sake of simplicity.
3.1. Split horizon DNS
A multi-homed host may be connecting to one or more networks that are
using private fully qualified domain names. For example, the host may
have simultaneously open a wireless LAN (WLAN) connection to open
Internet, cellular (3GPP) connection to an operator network, and
virtual private network (VPN) connection to a corporate network. When
an application initiates connection to a FQDN, the host needs to be
able to choose the right network interface for making successful DNS
query. This is illustrated in figure 1. If the FQDN is for a public
name, in figure 1 scenario it could be resolved with any DNS server
in any network interface, but if the FQDN would be corporation's or
operator's service's private name, the host would need to be able to
correctly select the right network interface for DNS procedures, i.e.
already before destination's IP address is known.
+---------------+ |
| DNS server w/ | | Corporate
+---------+ | public + |----| Intranet
| | | corporation's | |
| |===== VPN =======| private names | |
| | +---------------+ +---+
|A multi- | |FW |
| homed | +---+
| host | +---------------| |
| |----- WLAN ------| DNS server w/ |----| Public
| | | public names | | Internet
| | +---------------+ +---+
| | |FW |
| | +---------------+ +---+
| |----- 3GPP ------| DNS server w/ | |
+---------+ | public + | | Operator
| operator's |----| Intranet
| private names | |
+---------------+ |
Figure 1 Split horizon DNS and firewalled walled
gardens scenarios illustrated
Savolainen Expires April 23, 2009 [Page 4]
Internet-Draft FQDN based interface selection October 2008
3.2. Firewalled walled gardens
The firewalled walled gardens scenario is similar to what was
described in 3.1 and figure 1, except that all DNS resolutions could
be conducted with any DNS server over any network interface. However,
for the actual IP connection creation to succeed right interface must
be chosen, as otherwise firewalls at the edge of walled garden would
block the incoming connection request. For example, a name of a
server in operator's private network could be resolved to an IP
address with any DNS server, but it could be contacted only over
direct access to operator's network.
3.3. Seemingly equal interfaces
In third problematic scenario there are no firewalls and all DNS
servers have all information, but traffic for certain destinations
are preferred to be transmitted over certain network interface rather
than others. The reasons can be, for example, route optimization or
quality of service related. For example, if a host has two seemingly
equal network interfaces from its point of view, the network
operator(s) of both or one of the network(s) may be interested to
guide a host to make better network interface selection decisions.
Figure 2 illustrates an example case where a multi-homed host should
choose network interface A for contacting server 1 but interface B
for contacting server 2, in order to select shortest path. This can
be important e.g. if the two paths have significant geographical
distance differences and thus different cost incurred for the network
operator(s). A host sticking to using only interface A would be able
to access both servers 1 and 2, but it would be suboptimal
performance and network load/cost-wise.
----+------Internet--------+----
| |
"costly hop"->| |<- "costly hop"
| |
+----------+ | | +----------+
| Server 1 +----+-- --+------+ Server 2 |
+----------+ | | +----------+
-+---+-- --+---+--
(A)| +------+ |(B)
+---+ host +---+
+------+
Figure 2 A multi-homed host with two seemingly equal
network interfaces (from IP point of view)
Savolainen Expires April 23, 2009 [Page 5]
Internet-Draft FQDN based interface selection October 2008
Figure 3 illustrates case where a multi-homed host should choose
network interface A for contacting real-time service 1 but interface
B for non-real-time service 2. A host could contact service 1 via
either interface, but using interface A provides better experience
for real-time services (e.g. low latency) while interface B provides
better experience for non-real-time services (e.g. high bandwidth).
Real-time service 1 Non-real-time service 2
| |
---+----+-------Internet-------+------+---
| |
low latency (A) | +------+ | (B) high latency
low bandwidth +-------+ host +-------+ high bandwidth
higher cost/bit +------+ lower cost/bit
Figure 3 A multi-homed host with two network interfaces
having different characteristics
It is worth noting that in IPv4 domain both A and B network
interfaces, of figures 2 and 3, may be using private IPv4 [RFC1918]
addresses, which makes IPv4 address based interface selection
difficult. In IPv6 domain source address selection mechanisms such as
defined in [RFC3484] and worked on e.g. in [MATS2008] and [FUJI2008]
can be used to tackle seemingly equal interfaces problem.
4. DNS suffix based interface selection
This chapter contains a solution approach and a solution for the
problems described in chapter 3.
A host SHOULD learn which DNS suffixes in particular are resolvable,
and accessible, via each network interface. By default a host MUST
assume all FQDNs can be resolved and accessed via any network
interface. When a connection is to be created to a FQDN, a host
SHOULD prioritize available network interfaces for DNS resolution and
address selection purposes based on possibly matching DNS suffix
information.
This document describes how existing DHCP(v6) DNS search list options
can be used for this purpose.
4.1. Learning of the DNS suffixes
A host can learn the DNS suffixes of attached network interfaces from
DHCP search list options; DHCPv4 Domain Search Option number 119
[RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646].
Savolainen Expires April 23, 2009 [Page 6]
Internet-Draft FQDN based interface selection October 2008
This is illustrated in example message flow 1 below.
Application Host DHCP server of DHCP server of
WLAN interface cellular interface
| | |
| +-----------+ |
(1) | | open | |
| | interface | |
| +-----------+ |
| | |
(2) | |---option REQ-->|
| |<--option RESP--|
| | |
| +-----------+ |
(3) | | store | |
| | suffixes | |
| +-----------+ |
| | |
| +-----------+ |
(4) | | open | |
| | interface | |
| +-----------+ |
| | | |
(5) | |---option REQ------------------->|
| |<--option RESP-------------------|
| | | |
| +----------+ | |
(6) | | store | | |
| | suffixes | | |
| +----------+ | |
| | | |
Message flow 1: Learning DNS suffixes
Flow explanations:
(1) A host opens its first network interface, say WLAN
(2) The host obtains DNS suffix information for the new WLAN
interface from DHCP server
(3) The host stores the learned DNS suffixes for later use
(4) The host opens its seconds network interface, say cellular
Savolainen Expires April 23, 2009 [Page 7]
Internet-Draft FQDN based interface selection October 2008
(5) The host obtains DNS suffix, say "operator.com" information for
the new cellular interface from DHCP server
(6) The host stores the learned DNS suffixes for later use
4.2. Changes to DNS resolution procedures
When a DNS resolver in a host is requested by an application to do
DNS resolution for a FQDN to an IP address, the host SHOULD look if
any of the available network interfaces is known to advertise DNS
suffix matching to the FQDN. If there is a matching DNS suffix, then
that particular interface should be used for name resolution
procedures. This is illustrated in example message flow 2 below.
Application Host DHCP server of DHCP server of
WLAN interface cellular interface
| | | |
(1) |--Name REQ-->| | |
| | | |
| +-----------+ | |
(2) | | Choose | | |
| | interface | | |
| +-----------+ | |
| | | |
(3) | |------------DNS resolution------>|
| |<--------------------------------|
| | | |
(4) |<--Name resp-| | |
| | | |
Message flow 2: Choosing interface based on DNS suffix
Flow explanations:
(1) An application makes a request for resolving a FQDN, e.g.
"private.operator.com"
(2) A host looks at stored DNS suffix information and chooses
interface to use for DNS resolution
(3) The host has chosen cellular interface, as from DHCP it was
learned that the cellular interface has DNS suffix
"operator.com", and resolves the requested name using cellular
interface's DNS server to IP 192.0.2.1
(4) The host replies to application with resolved address 192.0.2.1
Savolainen Expires April 23, 2009 [Page 8]
Internet-Draft FQDN based interface selection October 2008
4.3. Changes to host's address selection procedures
To avoid problems described in chapter 3, in addition to logic for
conducting successful DNS query, the host's source IP address
selection algorithms must be able to choose the IP address of the
right network interface when application is providing only a
destination IP address to connect to.
The source address selection algorithm SHOULD do either or both of
the following procedures:
A) The algorithm to make reverse DNS lookup for the destination IP
address on host's own DNS cache, which should contain
corresponding record if the IP address was earlier resolved
from a FQDN. From this record FQDN matching the IP address is
learned, and based on that FQDN network interface with
corresponding DNS suffix can be chosen.
B) The algorithm to consult host's address selection policy table,
which may have been dynamically received as described in
[MATS2008] and [FUJI2008].
This is illustrated in example message flow 3 below.
Application Host DHCP server of DHCP server of
WLAN interface cellular interface
| | | |
(1) |--Connect--->| | |
| | | |
| +-----------+ | |
(2) | | Choose | | |
| | interface | | |
| +-----------+ | |
| | | |
(3) | |------------Connect------------->|
| |<--------------------------------|
| | | |
(4) |<--Con resp--| | |
| | | |
Message flow 3: Choosing interface for outgoing connection
Flow explanations:
(1) An application initiates new connection to an IP address, e.g.
192.0.2.1
Savolainen Expires April 23, 2009 [Page 9]
Internet-Draft FQDN based interface selection October 2008
(2) The host either:
a. Consults host's internal DNS cache with reverse DNS lookup
query and learns that FQDN "private.operator.com" is matching
IP 192.0.2.1 and therefore cellular network interface with
matching DNS suffix "operator.com" shall be selected
b. Consults dynamically received address selection policy table
and learns that for destination IP 192.0.2.1 cellular
interface should be used
(3)and (4) Connection is established over selected network interface
5. Network operator considerations
An operator of a network can continue to use DHCP DNS search list
options as before, but the operator should take into account that
multi-homed hosts may use the DNS suffix information also for
interface selection purposes.
An operator wishing to assist hosts in network interface selection
should configure DHCP servers with proper DNS suffix information,
which hosts then can use as hints for improved operation.
Furthermore, the operator should configure DHCP servers with IP
address selection policies ([MATS2008], [FUJI2008]) that are
corresponding to the configured DNS suffix information.
6. Further considerations
Overloading of existing DNS search list options is not without
problems, though: hosts would obviously use the DNS suffixes learned
from search lists also for name resolution purposes. This may not be
a problem in deployment cases where DNS search list options already
contain few DNS suffixes like "intranet.corporation.com", but can
become a problem in other deployment scenarios.
An obvious alternative would be to define new DHCP options for
distributing DNS suffix information designed only for network
interface selection purposes.
7. Security Considerations
An attacker may try to lure traffic from multi-homed host to his
network by advertising DNS suffixes attacker wishes to intercept or
deny service. The host's security should not be based on correct
functionality of source/destination address selection, but risks of
this attack can be mitigated by properly prioritizing network
Savolainen Expires April 23, 2009 [Page 10]
Internet-Draft FQDN based interface selection October 2008
interfaces with conflicting DNS suffix advertisements. The
prioritization can be based on trust level of a network interface
over which DNS suffix was learned from:
o VPN interfaces being most trustworthy
o Managed networks being on the middle
o Unmanaged networks having lowest priority
Now, for example, if all of the three abovementioned networks would
indicate access for "corporation.com", the host would choose to use
the VPN for connections destined to "corporation.com" domain.
8. IANA Considerations
No considerations identified at this point. TBD: if new DHCP options
are defined instead, situation changes.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3397] Aboba, B., Cheshire, S., "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", RFC 3397, November
2002
[RFC3646] Ed., Droms, R., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot,
G., Lear, E., "Address Allocation for Private Internets",
RFC1918, February 1996
[MATS2008] Matsumoto, A., Fujisaki, T., Hiromi, R., Kanayama, K.,
"Solution approaches for address-selection problems", June
2008, draft-ietf-6man-addr-select-sol-01.txt
Savolainen Expires April 23, 2009 [Page 11]
Internet-Draft FQDN based interface selection October 2008
[FUJI2008] Fujisaki, T., Niinobe, S., Hiromi, R., Kanayama, K., "
Distributing Address Selection Policy using DHCPv6", June
2008, draft-fujisaki-dhc-addr-select-opt-06.txt
10.2. Informative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003
Author's Address
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 TAMPERE
FINLAND
Email: teemu.savolainen@nokia.com
Savolainen Expires April 23, 2009 [Page 12]
Internet-Draft FQDN based interface selection October 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 Statement
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.
Savolainen Expires April 23, 2009 [Page 13]