idnits 2.17.1 draft-montenegro-mif-multihoming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2009) is 5525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4191' is defined on line 293, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-blanchet-mif-problem-statement-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Montenegro 2 Internet Draft D. Thaler 3 Intended status: Informational Shyam Seshadri 4 Microsoft Corporation 5 Expires: September 4, 2009 March 4, 2009 7 Multiple Interfaces on Windows 8 draft-montenegro-mif-multihoming-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance 13 with the provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before 17 November 10, 2008. The person(s) controlling the copyright in 18 some of this material may not have granted the IETF Trust the 19 right to allow modifications of such material outside the IETF 20 Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, 23 and derivative works of it may not be created outside the IETF 24 Standards Process, except to format it for publication as an RFC 25 or to translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 4, 2009. 46 Copyright 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license- 54 info). Please review these documents carefully, as they describe 55 your rights and restrictions with respect to this document. 57 Abstract 59 Increasingly, hosts have more than one network interface active 60 at any given point in time. Such multiplicity of interfaces 61 leads to multiple and potentially conflicting (or overlapping) 62 sets of configuration information and policies. How these are 63 arbitrated and managed influence how the host resolves DNS 64 queries, and-with respect to outgoing packets-how it selects a 65 source address and an outgoing interface. 67 Table of Contents 69 1. Introduction...................................................2 70 1.1. Requirements Language.....................................3 71 1.2. Terminology...............................................3 72 2. Default Router Selection.......................................3 73 3. Selecting the Proper Interface for Outgoing or Incoming Packets4 74 4. DNS Configuration..............................................4 75 4.1. Host-wide DNS configuration...............................4 76 4.2. Interface-specific DNS configuration......................5 77 5. DNS Names and Dynamic DNS Behavior.............................5 78 6. DNS Query Behavior.............................................5 79 7. Security Considerations........................................6 80 8. IANA Considerations............................................6 81 9. Acknowledgments................................................6 82 10. References....................................................6 83 10.1. Normative References.....................................6 84 10.2. Informative References...................................7 86 1. Introduction 88 Increasingly, hosts have more than one network interface active 89 at any given point in time. In such scenarios, it is important 90 to distinguish between host-wide and interface-specific 91 networking configuration information and policies. In addition 92 to these (hopefully) disjoint sets, such multiplicity of 93 interfaces may lead to potentially conflicts or overlaps. The 94 arbitration and management of these sets of policy or 95 configuration influence how the host behaves: e.g., how it 96 selects a source address and an outgoing interface with respect 97 to outgoing packets, and how it resolves DNS queries. 99 This document explains how the Microsoft Windows family of 100 operating systems handles multi-homing for hosts. Furthermore, 101 it only discusses host behavior, not router behavior. It is 102 offered to aid discussion with respect to the MIF BoF [MIFPS], 103 and is not guaranteed to be correct nor complete. More detailed 104 and authoritative information on Microsoft Corporation's 105 protocol implementations can be found in other sources such as 106 MSDN (http://msdn.microsoft.com/en-us/default.aspx), the MCPP 107 (http://www.microsoft.com/protocols/mcpp.mspx) or WSPP 108 (http://www.microsoft.com/protocols/wspp/wspp.mspx) Protocol 109 Documentation series. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described 116 in RFC 2119 [RFC2119]. 118 1.2. Terminology 120 Preferred interface - This is the first interface bound to the 121 TCP/IP stack during bootup, but this ordering can be 122 changed programmatically or via user interface. The 123 preferred interface has been used in previous versions 124 of Windows for routing and is also used for DNS query 125 purposes. 127 2. Default Router Selection 129 It is possible to configure default routes for different interfaces, 130 leading to more than one default router. This is not desirable, as it 131 may lead to inconsistent results, given that interfaces may connect 132 to disjoint networks. If there are multiple such default routes, the 133 usual routing precedence decides which one is used. First, the 134 interface with the lowest metric is preferred (generally, the faster 135 an interface, the lower its metric). If multiple interfaces share the 136 same metric (e.g., because they have equal or very similar nominal 137 speeds), then behavior changed starting with Windows Vista. 138 Previously, the default route on the preferred interface is used. 140 With Windows Vista, such preferred interface is not used for routing. 141 Instead, host-to-router load sharing [RFC4311] is used for both IPv4 142 and IPv6. 144 For more information, refer to [DefGateway]. 146 3. Selecting the Proper Interface for Outgoing or Incoming Packets 148 For outgoing packets whose source address has not been determined 149 previously by applications, the stack chooses from addresses assigned 150 to its interfaces. Similarly, for incoming packets, valid destination 151 addresses must match the address of one of its interfaces. Per host 152 requirements [RFC1122], such choices depend on whether a host 153 implements the strong or weak host model. 155 Windows has implemented the weak host model on IPv4 as follows: 156 Windows 2000, Windows XP and Windows Server 2003. IPv6 has always 157 implemented the strong host model (starting with Windows XP and 158 Windows Server 2003). Starting with Windows Vista and Windows Server 159 2008, the strong host model became the default for IPv4 as well, 160 although the weak model is still possible via per-interface 161 configuration. 163 For IPv6, Windows follows [RFC3484]. Starting in Vista, Windows 164 follows 3484 for IPv4 as well. Prior to Vista, IPv4 would choose the 165 first address on the outgoing interface for all traffic where the 166 application didn't specify a source address. 168 For more information, see [StrongAndWeakHost] and [SrcDstSel]. 170 4. DNS Configuration 172 A Windows host has host-wide as well as interface-specific 173 configuration items. 175 4.1. Host-wide DNS configuration 177 Host-wide DNS configuration is input either via static configuration 178 or via Microsoft's Group Policy. The latter, however, is available 179 only within deployments that make use of Active Directory (e.g., 180 within corporate or enterprise environments). Upon joining an Active 181 Directory domain, clients may receive such configuration. 183 The host-wide DNS configuration comprises the following: 185 . Primary DNS suffix - This is typically set to the domain name of 186 the Active Directory in environments in which the host joins a 187 domain. Otherwise, this can be set via static configuration. This 188 can be set to something other than the Active Directory domain, 189 and is sometimes unavoidable (e.g., upon corporate mergers), but 190 is not recommended. 192 . Host-wide suffix list - Host-wide list of suffixes that can be 193 appended to names being queried (see "DNS Query Behavior" below). 194 Prior to Windows Vista, this would be appended to any unqualified 195 multi-label query (e.g., to names not ending in a "."). As of 196 Vista, this is by default only appended to single-label queries 197 (although the previous behavior is still configurable). 199 Before Windows Vista and Windows Server 2008 there used to be a 200 global DNS servers configuration which took precedence over the per- 201 interface DNS servers (see below). This global value is now 202 deprecated. 204 4.2. Interface-specific DNS configuration 206 Interface-specific DNS configuration is input either via static 207 configuration or via DHCP. 209 . Interface-specific suffix list 211 . List of DNS server IP addresses - The first one is the "primary" 212 with all others being secondary. 214 5. DNS Names and Dynamic DNS Behavior 216 TBD 218 6. DNS Query Behavior 220 The DNS Client service queries the DNS servers in the following 221 order: 223 1. The DNS Client service sends the name query to the first DNS 224 server on the preferred interface's list of DNS servers and waits 225 one second for a response. 227 2. If the DNS Client service does not receive a response from the 228 first DNS server within one second, it sends the name query to the 229 first DNS servers on all interfaces that are still under 230 consideration and waits two seconds for a response. 232 3. If the DNS Client service does not receive a response from any DNS 233 server within two seconds, the DNS Client service sends the query 234 to all DNS servers on all interfaces that are still under 235 consideration and waits another two seconds for a response. 237 4. If the DNS Client service still does not receive a response from 238 any DNS server, it sends the name query to all DNS servers on all 239 interfaces that are still under consideration and waits four 240 seconds for a response. 242 5. If it the DNS Client service does not receive a response from any 243 DNS server, the DNS client sends the query to all DNS servers on 244 all interfaces that are still under consideration and waits eight 245 seconds for a response. 247 More information is available at sources such as [DNSWorks] (See, for 248 example, "Overview of DNS Query Process" or [DNSClient]. 250 7. Security Considerations 252 TBD. 254 8. IANA Considerations 256 This document has no IANA considerations. 258 9. Acknowledgments 260 The authors would like to acknowledge the following people for 261 their feedback and interesting discussions. 263 10. References 265 10.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 10.2. Informative References 272 [DefGateway] Default Gateway Behavior for Windows TCP/IP: 273 http://technet.microsoft.com/en- 274 us/library/bb878104.aspx 276 [DNSClient] Domain Name System Client Behavior in Windows Vista: 277 http://technet.microsoft.com/en- 278 us/library/bb727035.aspx 280 [DNSWorks] How DNS Works: http://technet.microsoft.com/en- 281 us/library/cc772774.aspx 283 [MIFPS] Blanchet, M., "Multiple Interfaces Problem 284 Statement",draft-blanchet-mif-problem-statement-00.txt 285 (work in progress), December 2008. 287 [RFC1122] Braden, R., "Requirements for Internet Hosts- 288 communication Layers", STD 3, RFC 1122, October 1989. 290 [RFC3484] Draves, R., "Default Address Selection for Internet 291 Protocol version 6 (IPv6)", RFC 3484, February 2003. 293 [RFC4191] R. Draves, D. Thaler, "Default Router Preferences and 294 More-Specific Routes", RFC 4191, November 2005. 296 [RFC4311] R. Hinden, D. Thaler, "IPv6 Host-to-Router Load 297 Sharing", RFC 4311, November 2005. 299 [SrcDstSel] Source and Destination Address Selection for IPv6: 300 http://microsoft.com/technet/community/columns/cablegu 301 y/cg0206.mspx 303 [StrongAndWeakHost] Strong and Weak Host Models 304 http://technet.microsoft.com/en- 305 us/magazine/2007.09.cableguy.aspx 307 Author's Addresses 309 Gabriel Montenegro 310 Microsoft Corporation 311 One Microsoft Way 312 Redmond, WA 98052 313 USA 315 Phone: 316 Email: gabriel.montenegro@microsoft.com 318 Dave Thaler 319 Microsoft Corporation 320 One Microsoft Way 321 Redmond, WA 98052 322 USA 324 Phone: 325 Email: dthaler@microsoft.com 327 Shyam Seshadri 328 Microsoft Corporation 329 One Microsoft Way 330 Redmond, WA 98052 331 USA 333 Phone: 334 Email: sseshad@microsoft.com