One document matched: draft-montenegro-mif-multihoming-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:47:07 |