Network Working Group G. Montenegro Internet Draft D. Thaler Intended status: Informational Shyam Seshadri Microsoft Corporation Expires: September 4, 2009 March 4, 2009 Multiple Interfaces on Windows draft-montenegro-mif-multihoming-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. 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 September 4, 2009. Montenegro, et al Expires September 4, 2009 [Page 1] Internet-Draft Multiple Interfaces on Windows March 2009 Copyright Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Increasingly, hosts have more than one network interface active at any given point in time. Such multiplicity of interfaces leads to multiple and potentially conflicting (or overlapping) sets of configuration information and policies. How these are arbitrated and managed influence how the host resolves DNS queries, and-with respect to outgoing packets-how it selects a source address and an outgoing interface. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 1.2. Terminology...............................................3 2. Default Router Selection.......................................3 3. Selecting the Proper Interface for Outgoing or Incoming Packets4 4. DNS Configuration..............................................4 4.1. Host-wide DNS configuration...............................4 4.2. Interface-specific DNS configuration......................5 5. DNS Names and Dynamic DNS Behavior.............................5 6. DNS Query Behavior.............................................5 7. Security Considerations........................................6 8. IANA Considerations............................................6 9. Acknowledgments................................................6 10. References....................................................6 10.1. Normative References.....................................6 10.2. Informative References...................................7 1. Introduction Increasingly, hosts have more than one network interface active at any given point in time. In such scenarios, it is important Montenegro, et al. Expires August 4, 2009 [Page 2] Internet-Draft Multiple Interfaces on Windows March 2009 to distinguish between host-wide and interface-specific networking configuration information and policies. In addition to these (hopefully) disjoint sets, such multiplicity of interfaces may lead to potentially conflicts or overlaps. The arbitration and management of these sets of policy or configuration influence how the host behaves: e.g., how it selects a source address and an outgoing interface with respect to outgoing packets, and how it resolves DNS queries. This document explains how the Microsoft Windows family of operating systems handles multi-homing for hosts. Furthermore, it only discusses host behavior, not router behavior. It is offered to aid discussion with respect to the MIF BoF [MIFPS], and is not guaranteed to be correct nor complete. More detailed and authoritative information on Microsoft Corporation's protocol implementations can be found in other sources such as MSDN (http://msdn.microsoft.com/en-us/default.aspx), the MCPP (http://www.microsoft.com/protocols/mcpp.mspx) or WSPP (http://www.microsoft.com/protocols/wspp/wspp.mspx) Protocol Documentation series. 1.1. Requirements Language 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]. 1.2. Terminology Preferred interface - This is the first interface bound to the TCP/IP stack during bootup, but this ordering can be changed programmatically or via user interface. The preferred interface has been used in previous versions of Windows for routing and is also used for DNS query purposes. 2. Default Router Selection It is possible to configure default routes for different interfaces, leading to more than one default router. This is not desirable, as it may lead to inconsistent results, given that interfaces may connect to disjoint networks. If there are multiple such default routes, the usual routing precedence decides which one is used. First, the interface with the lowest metric is preferred (generally, the faster Montenegro, et al. Expires August 4, 2009 [Page 3] Internet-Draft Multiple Interfaces on Windows March 2009 an interface, the lower its metric). If multiple interfaces share the same metric (e.g., because they have equal or very similar nominal speeds), then behavior changed starting with Windows Vista. Previously, the default route on the preferred interface is used. With Windows Vista, such preferred interface is not used for routing. Instead, host-to-router load sharing [RFC4311] is used for both IPv4 and IPv6. For more information, refer to [DefGateway]. 3. Selecting the Proper Interface for Outgoing or Incoming Packets For outgoing packets whose source address has not been determined previously by applications, the stack chooses from addresses assigned to its interfaces. Similarly, for incoming packets, valid destination addresses must match the address of one of its interfaces. Per host requirements [RFC1122], such choices depend on whether a host implements the strong or weak host model. Windows has implemented the weak host model on IPv4 as follows: Windows 2000, Windows XP and Windows Server 2003. IPv6 has always implemented the strong host model (starting with Windows XP and Windows Server 2003). Starting with Windows Vista and Windows Server 2008, the strong host model became the default for IPv4 as well, although the weak model is still possible via per-interface configuration. For IPv6, Windows follows [RFC3484]. Starting in Vista, Windows follows 3484 for IPv4 as well. Prior to Vista, IPv4 would choose the first address on the outgoing interface for all traffic where the application didn't specify a source address. For more information, see [StrongAndWeakHost] and [SrcDstSel]. 4. DNS Configuration A Windows host has host-wide as well as interface-specific configuration items. 4.1. Host-wide DNS configuration Host-wide DNS configuration is input either via static configuration or via Microsoft's Group Policy. The latter, however, is available only within deployments that make use of Active Directory (e.g., within corporate or enterprise environments). Upon joining an Active Directory domain, clients may receive such configuration. The host-wide DNS configuration comprises the following: Montenegro, et al. Expires August 4, 2009 [Page 4] Internet-Draft Multiple Interfaces on Windows March 2009 . Primary DNS suffix - This is typically set to the domain name of the Active Directory in environments in which the host joins a domain. Otherwise, this can be set via static configuration. This can be set to something other than the Active Directory domain, and is sometimes unavoidable (e.g., upon corporate mergers), but is not recommended. . Host-wide suffix list - Host-wide list of suffixes that can be appended to names being queried (see "DNS Query Behavior" below). Prior to Windows Vista, this would be appended to any unqualified multi-label query (e.g., to names not ending in a "."). As of Vista, this is by default only appended to single-label queries (although the previous behavior is still configurable). Before Windows Vista and Windows Server 2008 there used to be a global DNS servers configuration which took precedence over the per- interface DNS servers (see below). This global value is now deprecated. 4.2. Interface-specific DNS configuration Interface-specific DNS configuration is input either via static configuration or via DHCP. . Interface-specific suffix list . List of DNS server IP addresses - The first one is the "primary" with all others being secondary. 5. DNS Names and Dynamic DNS Behavior TBD 6. DNS Query Behavior The DNS Client service queries the DNS servers in the following order: 1. The DNS Client service sends the name query to the first DNS server on the preferred interface's list of DNS servers and waits one second for a response. 2. If the DNS Client service does not receive a response from the first DNS server within one second, it sends the name query to the Montenegro, et al. Expires August 4, 2009 [Page 5] Internet-Draft Multiple Interfaces on Windows March 2009 first DNS servers on all interfaces that are still under consideration and waits two seconds for a response. 3. If the DNS Client service does not receive a response from any DNS server within two seconds, the DNS Client service sends the query to all DNS servers on all interfaces that are still under consideration and waits another two seconds for a response. 4. If the DNS Client service still does not receive a response from any DNS server, it sends the name query to all DNS servers on all interfaces that are still under consideration and waits four seconds for a response. 5. If it the DNS Client service does not receive a response from any DNS server, the DNS client sends the query to all DNS servers on all interfaces that are still under consideration and waits eight seconds for a response. More information is available at sources such as [DNSWorks] (See, for example, "Overview of DNS Query Process" or [DNSClient]. 7. Security Considerations TBD. 8. IANA Considerations This document has no IANA considerations. 9. Acknowledgments The authors would like to acknowledge the following people for their feedback and interesting discussions. 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. Montenegro, et al. Expires August 4, 2009 [Page 6] Internet-Draft Multiple Interfaces on Windows March 2009 10.2. Informative References [DefGateway] Default Gateway Behavior for Windows TCP/IP: http://technet.microsoft.com/en- us/library/bb878104.aspx [DNSClient] Domain Name System Client Behavior in Windows Vista: http://technet.microsoft.com/en- us/library/bb727035.aspx [DNSWorks] How DNS Works: http://technet.microsoft.com/en- us/library/cc772774.aspx [MIFPS] Blanchet, M., "Multiple Interfaces Problem Statement",draft-blanchet-mif-problem-statement-00.txt (work in progress), December 2008. [RFC1122] Braden, R., "Requirements for Internet Hosts- communication Layers", STD 3, RFC 1122, October 1989. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4191] R. Draves, D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4311] R. Hinden, D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005. [SrcDstSel] Source and Destination Address Selection for IPv6: http://microsoft.com/technet/community/columns/cablegu y/cg0206.mspx [StrongAndWeakHost] Strong and Weak Host Models http://technet.microsoft.com/en- us/magazine/2007.09.cableguy.aspx Montenegro, et al. Expires August 4, 2009 [Page 7] Internet-Draft Multiple Interfaces on Windows March 2009 Author's Addresses Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: Email: gabriel.montenegro@microsoft.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: Email: dthaler@microsoft.com Shyam Seshadri Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: Email: sseshad@microsoft.com Montenegro, et al. Expires August 4, 2009 [Page 8]