Individual Submission                                     T. Savolainen
Internet Draft                                                    Nokia
Intended status: Experimental                          October 23, 2008
Expires: April 2009

               Domain name based network interface selection

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-

   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 April 23, 2009.

Savolainen              Expires April 23, 2009                 [Page 1]

Internet-Draft      FQDN based interface selection         October 2008


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

                         |                      |
           "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
                   |                                  |
                        |                      |
      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

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

   (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
        "", and resolves the requested name using cellular
        interface's DNS server to IP

   (4) The host replies to application with resolved address

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.

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 "" is matching
          IP and therefore cellular network interface with
          matching DNS suffix "" shall be selected

        b. Consults dynamically received address selection policy table
          and learns that for destination IP 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 "", 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 "", the host would choose to use
   the VPN for connections destined to "" 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

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

   [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
   Hermiankatu 12 D
   FI-33720 TAMPERE


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

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

   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

Savolainen              Expires April 23, 2009                [Page 13]