IPv6 Dictionary for DirectAccess from technet
Connectivity
DirectAccess clients maintain constant connectivity with the intranet, and Internet Protocol version 6 (IPv6) provides the end-to-end addressing necessary to accomplish this. Since many organizations do not have IPv6 deployed, DirectAccess includes IPv6 transition technologies to help ensure IPv6 connectivity. For more information, see IPv6 on the Microsoft Web site.
Teredo, 6to4, and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) are examples of IPv6 transition technologies. These technologies allow you to use IPv6 even if your DirectAccess clients are on the IPv4 Internet and your network infrastructure does not yet support native IPv6 routing. IPv6 transition technologies can simplify and reduce the costs of an IPv6 deployment. For more information, see IPv6 Transition Technologies.
The following table lists possible DirectAccess client configurations and their corresponding method of sending IPv6 traffic to the DirectAccess server. These methods are discussed in the following sections.
| If the client is assigned: | Preferred connectivity method: |
|---|---|
| Globally routable IPv6 address | Globally routable IPv6 address |
| Public IPv4 address | 6to4 |
| Private (NAT) IPv4 address | Teredo |
| If the client cannot connect through the previous methods | IP-HTTPS |
IP-HTTPS is typically used only if the client is unable to connect to the DirectAccess server using the other IPv6 connectivity methods or if Force Tunneling has been enabled.
 Note |
|---|
| ISATAP may also be used to provide IPv6 connectivity when the client is at a remote location. ISATAP deployments can either connect to the IPv6 Internet or use 6to4 to transfer IPv6 traffic across the IPv4 Internet. |
6to4 (defined in RFC 3056) is an IPv6 transition technology that provides IPv6 connectivity across the IPv4 Internet for hosts or sites that have a public IPv4 address. For more information, see IPv6 Transition Technologies.
Teredo (defined in RFC 4380) is an IPv6 transition technology that provides IPv6 connectivity across the IPv4 Internet for hosts that are located behind an IPv4 network address translation (NAT) device and are assigned a private IPv4 address. For more information, see Teredo Overview.
IP-HTTPS is a new protocol for Windows 7 and Windows Server 2008 R2 that allows hosts behind a Web proxy server or firewall to establish connectivity by tunneling IPv6 packets inside an IPv4-based HTTPS session. HTTPS is used instead of HTTP so that Web proxy servers will not attempt to examine the data stream and terminate the connection.
Performance of IP-HTTPS may not be as good as the other DirectAccess connection protocols. There are multiple steps that can be taken to improve performance. For example, additional IP-HTTPS servers can be added and load-balanced. IPsec encryption between the DirectAccess client and DirectAccess server can be disabled to further improve performance of this protocol. Microsoft® is looking at additional ways to improve the performance of this protocol in future versions of Windows.
For the details of IP-HTTPS, see the IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification.
| Note |
|---|
| To use IP-HTTPS diagnostics to troubleshoot IP-HTTPS connectivity problems, you must configure firewall rules to allow the IP-HTTPS server to respond to Echo Request messages. |
DirectAccess clients can only communicate with intranet servers and resources that are reachable with IPv6. There are three ways to achieve this intranet IPv6 connectivity:
- Configure your intranet routing infrastructure to support native IPv6. Intranet servers and applications that support IPv6 are then reachable. Computers running Windows Vista®, Windows Server 2008, Windows 7, and Windows Server 2008 R2 are configured to use IPv6 by default. Although few organizations today have a native IPv6 infrastructure, this is the preferred and recommended connectivity method. Although not technically required for DirectAccess, organizations should begin planning for a native IPv6 infrastructure.
- Deploy ISATAP on your intranet. Even without a native IPv6 infrastructure, you can use ISATAP to make intranet servers and applications reachable by tunneling IPv6 traffic over your IPv4-only intranet. Computers running Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 support ISATAP host functionality.
- Deploy Network Address Translation–Protocol Translation (NAT-PT) devices on your intranet. NAT-PTs perform IPv6/IPv4 translation services for traffic between your DirectAccess clients that are using IPv6 and intranet servers and applications that can only use IPv4.
| Note |
|---|
| Without a NAT-PT device, IPv4-only resources on your network cannot be reached by DirectAccess clients. The workaround is to use a VPN connection. |
ISATAP (RFC 4214) is an IPv6 transition technology that is used to provide IPv6 connectivity between IPv6/IPv4 hosts across an IPv4-only intranet. ISATAP can be used for DirectAccess to provide IPv6 connectivity to ISATAP hosts across your intranet.
For more information about ISATAP, see IPv6 Transition Technologies.
A NAT-PT device (RFC 2766) can be deployed to make IPv4-only resources on your intranet available to DirectAccess clients. A NAT-PT is typically configured to provide coverage for a particular DNS namespace. Once deployed, the NAT-PT will make the necessary IPv6-to-IPv4 translations, allowing DirectAccess clients to access any IPv4-only resources located within that namespace.
Although Windows Server 2003 includes the IPv6 protocol, many built-in applications and system services do not support IPv6. Therefore, a NAT-PT device is typically required to reach resources that are running on servers running Windows Server 2003. Additionally, resources on servers running non-Windows operating systems need a NAT-PT unless the server and its applications support IPv6 connectivity.
Because Windows Server 2008 R2 does not provide NAT-PT functionality, the configuration of NAT-PT is beyond the scope of this paper. NAT-PT devices are typically available from Layer 2 and Layer 3 switch and router vendors.
To separate Internet traffic from intranet traffic, Windows 7 includes the Name Resolution Policy Table (NRPT), a new feature that allows the following:
- DNS servers can be defined per DNS namespace rather than per interface.
- DNS queries for specific namespaces can be optionally secured using IPsec (and other actions can be specified).
The NRPT stores a list of DNS namespaces and corresponding configuration settings that define the DNS client’s behavior for that namespace. While a DirectAccess client is remote, each name query request is compared against the namespaces stored in the NRPT. If a match is found, the request is processed according to the settings in the NRPT entry. The settings determine whether that query will be encrypted (to protect from packet sniffing and other man-in-the-middle attacks) and which DNS servers to which the request will be sent.
If a name query request does not match a namespace listed in the NRPT, it is sent to the DNS servers configured in the TCP/IP settings for the specified network interface. For a remote client, this will typically be the Internet DNS servers as configured through the Internet service provider (ISP). For a DirectAccess client on the intranet, this will typically be the intranet DNS servers as configured through DHCP.
Single-label names, such as http://internal, will typically have configured DNS search suffixes appended to the name before they are checked against the NRPT. If no DNS search suffixes are configured and the single-label name does not match any other single-label name entries in the NRPT, the request will be sent to the DNS servers specified in the client’s TCP/IP settings.
Namespaces, such as .internal.contoso.com, are entered into the NRPT followed by the DNS servers to which requests matching that namespace should be directed. If an IP address is entered for the DNS server, then all DNS requests will be sent directly to the DNS server over the DirectAccess connection. There is no need to specify any additional security for this configuration.
However, if a name is specified for the DNS server (such as dns.contoso.com) in the NRPT, then that name must be publicly resolvable when the client queries the DNS servers specified in its TCP/IP settings. To prevent an attacker from hijacking this external name query request and injecting a bogus reply, enabling IPsec protection is strongly recommended in this configuration.
The NRPT allows DirectAccess clients to use intranet DNS servers for name resolution (dedicated DNS servers are not required). DirectAccess is designed to prevent the exposure of your intranet namespace to the Internet.
There are some names that need to be treated differently from all others with regards to name resolution; these names must not be resolved using intranet DNS servers. To ensure that these names are resolved with the DNS servers specified in the client’s TCP/IP settings, you must add them as NRPT exemptions.
If no DNS server addresses are specified in the NRPT entry, the entry is an exemption. If a DNS name matches an entry in the NRPT that does not contain addresses of DNS servers or does not match an entry in the NRPT, the DirectAccess client sends the name query to the DNS servers specified in the client’s TCP/IP settings.
If any of the following servers have a name suffix that matches an NRPT entry for the intranet namespace, that server name must be an NRPT exemption:
- WPAD servers
- Network location servers
- All quarantine servers
These servers must always be resolved with the DNS servers specified in the client’s TCP/IP settings.
Because DirectAccess clients rely on the NRPT to determine whether the FQDN of a server name should be sent to an intranet or Internet DNS server, proper configuration of domain suffixes is very important for reliable DirectAccess operation. Before setting up DirectAccess, ensure that DirectAccess clients are configured with DNS search suffixes for all of the domains containing the servers that users on DirectAccess clients will access.
The Windows Internet Name Service (WINS) is an IPv4-only name resolution service. If your organization does not deploy NAT-PT, DirectAccess clients should not use WINS as a fallback name resolution mechanism. At this time, the DNS servers used by remote DirectAccess clients should not have WINS forwarding enabled. Additional details will be released before the release of Windows 7 and Windows Server 2008 R2 providing the best practice for configuring DA clients to utilize WINS servers if NAT-PT devices are present.
No comments:
Post a Comment