Introducing Windows Server 2008

One area in which networking has been improved in Windows Server 2008 is its implementation of DHCP. The following sidebar has been excerpted with permission from a couple of posts on the Microsoft Windows DHCP Team Blog found at http://blogs.technet.com/teamdhcp/ . It provides an overview of DHCPv6 support in both Windows Server 2008 and Windows Vista:

Windows Vista introduces support for DHCPv6. The DHCPv6 client implementation in Windows Vista is compliant with RFC 3315. It supports two modes of operation: Stateless and Stateful.

• DHCPv6 Stateless mode is the mode in which the host uses a non-DHCPv6 method to obtain an IPv6 address and uses DHCPv6 only to obtain other configuration parameters, such as the IPv6 address of the DNS server. Typically, in this mode, clients use the IPv6 prefix from a router advertisement to auto-configure an IPv6 address for the network interface.

• DHCPv6 Stateful mode is the mode in which a client uses DHCPv6 to obtain an IPv6 address from the DHCPv6 server along with other configuration parameters.

  The DHCPv6 client mode of operation in Windows Vista is controlled by router advertisements. When the TCP/IP stack in Windows Vista receives a Media Connect event on a network interface, it sends a router solicitation. The router advertisement received in response determines the behavior of the DHCPv6 client on that interface. If both the M and O flags in the router advertisement are set, the client assumes that it should use DHCPv6 Stateful mode. If the O flag is set but the M flag is not set, the DHCPv6 client uses the Stateless mode of operation.

  DHCPv6 Stateless and Stateful Servers in Windows Server 2008

  In Windows Server 2008, Microsoft has also introduced DHCPv6 functionality to the DHCP server. The Windows Server 2008 DHCP server includes support for both the DHCPv6 Stateless and the DHCPv6 Stateful Server functionality. In the DHCPv6 stateless mode, clients use DHCPv6 only to obtain network configuration parameters other than the IPv6 address. In this scenario, clients configure an IPv6 address through a non-DHCPv6-based mechanism (possibly through IPv6 address auto-configuration based on the IPv6 prefixes included in router advertisements, or through static configuration). In DHCPv6 Stateful mode, clients acquire both the IPv6 address and other network configuration parameters through DHCPv6.

  In Windows Server 2008 Beta 3, Microsoft has now included the following DHCPv6 features:

• Administrators can create IPv6 address scopes by simply specifying an IPv6 subnet prefix. The Windows DHCPv6 Stateful server automatically generates an IPv6 address for allocation to the client.

• The addresses generated by the DHCPv6 server are sparsely distributed over the available address space for that subnet. By randomly distributing the address over the large address range made available by a 64-bit IPv6 prefix, the Windows DHCP server makes it much harder to guess IPv6 network addresses.

• Clients can acquire a nontemporary address and a temporary address through DHCPv6. A nontemporary IPv6 address can be used for Dynamic DNS registration so that the client is “known” by that address. A temporary IPv6 address, on the other hand, can be used for establishing outgoing connections in scenarios where the client needs privacy for its nontemporary address.

• Administrators can simplify the deployment by using the router advertisements to provide hints on whether to use DHCPv6 in Stateless or Stateful mode.

• The Windows DHCPv6 server provides support for server authorization in Active Directory. This helps reduce the possibility of a rogue server in managed domain environments.

• Microsoft recommends that administrators add reservations for clients with statically configured IPv6 addresses so that those addresses are not inadvertently allocated to clients. In addition, administrators can configure a certain range of addresses as exclusions to ensure that these addresses are not assigned to clients.

• Administrators also have access to other DHCP server functionality, such as the capability for audit logging and use of the export/import commands to migrate DHCP server configuration and state information.

  DHCPv6 Deployment Considerations

  In the use of IPv6 address auto-configuration, the administrator has no control over the actual IPv6 addresses being used by the client. DHCPv6 Stateless deployment in conjunction with IPv6 address auto-configuration may hence be suitable for scenarios where there are no requirements to audit the use of addresses by clients, such as on public networks and in home scenarios. With DHCPv6 Stateful deployments, the administrator has control over the IPv6 address used by the client and can audit the IPv6 addresses being used by the clients on the network. A DHCPv6 Stateful deployment may hence be more appropriate in scenarios where such logging/auditing capability is needed, such as in Enterprise deployments.

  –Santosh Chandwani

  Windows Enterprise Networking

Another networking improvement in Windows Server 2008 (one that will also be included in Windows Vista Service Pack 1) is in the area of virtual private networking and remote access. I’ll bet there have been times when you’ve been at a hotel somewhere and your PPTP-based or L2TP-based VPN connection couldn’t go through, either because of a PPTP GRE port-blocking or an L2TP ESP port-blocking issue caused by some firewall or NAT router along the path between your client computer and the remote VPN server you were trying to connect to. And I’ll bet you probably muttered something like, “Why can’t IP-based VPN connections just work?” Well guess what-your wish has been granted!

Windows Server 2008 and Windows Vista SP1 will include a new type of VPN tunnel called Secure Socket Tunneling Protocol (SSTP), which enables VPN tunnel connectivity across any scenario. For example, if your client computer or the remote server is behind NAT routers, firewalls, or Web proxies, SSPT will make your VPN connection just work. Plus, it will work just the same as before-that is, it will have the same end-user remote-access experience (such as using a RAS dialer) and also the same network administration experience (such as using a RRAS server).

This an exciting new feature, so we’re going have two sidebars on this topic. The first sidebar provides an overview of what SSTP is and what it can do:

A virtual private network (VPN) provides a way of connecting to your corporate network remotely over the Internet. Prior to SSTP, Windows 2003 Server included support for PPTP-based and L2TP/IPSec-based VPN tunnels. If the remote access user is behind a firewall, these VPN tunnels require specific ports to be opened inside the firewalls (such as TCP port 1723 and IP protocol type GRE for allowing PPTP connection). There are scenarios (like visiting a customer, partner site, or hotel) where only Web access (TCP port 80 and 443) is given and all other ports are blocked. As a result, remote users in these scenarios run into VPN connectivity issues, thereby increasing help desk calls and reducing productivity for the employees.

Secure Socket Tunneling Protocol (SSTP) is a new VPN tunnel introduced in Windows Server 2008 that solves these VPN connectivity problems. It does this by using HTTPS as the transport layer so that VPN connections can traverse commonly configured firewalls, NATs, and Web proxy servers. Because an HTTPS connection (that is, TCP port 443) is normally used for accessing protected Internet sites such as Internet commerce sites, it is normally opened on firewalls and can traverse Web proxies and NAT routers.

A computer running Windows Server 2008 and Routing and Remote Access is an SSTP-based VPN server listening for SSTP connections. The SSTP server must have a computer certificate with the Server Authentication Enhanced Key Usage (EKU) property installed. This computer certificate is used to authenticate the SSTP server to the SSTP client during the establishment of an SSL session. The SSTP client validates the computer certificate of the SSTP server. To trust the computer certificate, the root Certification Authority (CA) of the issuing CA of the SSTP server’s computer certificate must be installed on the SSTP client.

From a protocol-layering perspective, an SSTP-based VPN tunnel acts as a peer-to-L2TP and PPTP-based VPN tunnel. This means PPP is encapsulated over SSTP, which then sends the traffic over HTTPS connections. As a result of this, all the other features of the VPN tunnel-such as the NAP-based health check, carrying IPv6 traffic on top of the VPN tunnel, different authentication algorithms such as username and smartcard, integrated VPN client, and connection manager–based VPN client-remain the same for SSTP, PPTP, and L2TP. This gives the administrator a good migration path for moving from L2TP/PPTP to SSTP.

–Samir Jain

Lead Program Manager, Windows Enterprise Networking (RRAS)

–Kadirvel C. Vanniarajan

Software Design Engineer, Windows Enterprise Networking (RRAS)

And now in our second sidebar, our experts from the product team are going to dig deeper and provide us with an explanation of how this new feature works:

SSTP works on top of HTTPS, which amounts to nothing but HTTP using Secure Socket Layer (SSL) for information confidentiality. SSL also provides the mechanism to authenticate the endpoints as required when using Public Key Infrastructure (PKI). SSTP uses the SSL for authenticating the server to the client, and it relies on PPP running on top of it for authenticating the client to the server. That is, the server gets authenticated by the client by means of certificates, and the client gets authenticated by the server through the existing suite of authentication protocols supported by PPP. The information confidentiality is provided by the SSL.

When a client connects to the Remote Access Server using SSTP as the tunneling protocol, SSTP establishes the HTTPS session to the remote server at port 443 at a specific URL. The HTTP proxy settings configured through Internet Explorer will be used for establishing this connectivity. As with any HTTPS sessions, this involves the client trusting the certificate provided by the server. For this to happen, the appropriate trusted root certificate should be present in the machine certificate store. Once the certificate validation completes, the SSL handshake is complete and the HTTP session is established on top of it. After this, the SSTP layer is used to negotiate parameters between the client and the server. Once the SSTP layer is also established, the PPP negotiation starts on top of this, which provides the mechanism to authenticate the client to the server and also to tunnel the data. From this point on, the steps involved are just like PPP over PPTP/L2TP. A tunnel interface gets created on the client, and packets routed through this tunnel interface travel over the SSTP tunnel to the network beyond the Remote Access Server.

Let’s take a closer look at the steps involved by using the following scenario.

A client with IP address 192.168.0.100 is behind a Web proxy with IP address192.168.0.10:8080. It is trying to establish an SSTP tunnel to a Remote Access Server (supporting SSTP) that has the public IP address 202.54.175.68. This server is published with the domain contoso.com, and the client has a trusted root certificate that trusts this domain in its machine certificate store. Let 172.23.0.0/24 be the subnet address that will be shared between the SSTP clients and the intranet.

Following are the steps that occur when setting up the tunnel:

1. The client connects to the Remote Access Server as https://contoso.com/ sra_{}/.

2. This request is sent through the Web proxy. A CONNECT request is sent to the proxy server with the server name and URI noted in step 1. The proxy server establishes the TCP connection to port 443 of the server.

3. The SSL handshake happens on top of this. While this is happening, the server provides its certificate to the client and the client validates it against the trusted root certificates present in the machine certificate store.

4. The client sends the HTTP request to the server to establish the HTTPS session.

5. SSTP negotiates parameters on top of the HTTPS session.

6. PPP starts on top of SSTP, providing the client authentication and negotiation of other parameters such as the tunnel IP address and so on.

7. A virtual interface gets created on the client machine with the IP address from the pool 172.23.0.0/24. This address is allocated by the Remote Access Server as a part of the PPP’s NCP phase.

8. Any data traffic destined to travel over the aforementioned virtual interface is tunneled to the Remote Access Server and reaches the intranet.

   For SSTP also, the PPP and the stack above it remains the same as that of PPTP/L2TP-based VPN tunnels.

   –Kadirvel C. Vanniarajan

   Software Design Engineer, Windows Enterprise Networking (RRAS)

   –Samir Jain

   Lead Program Manager, Windows Enterprise Networking (RRAS)

For additional information on networking enhancements in Windows Vista and Windows Server 2008, see the page titled “New Networking Features in Windows Server “Longhorn” and Windows Vista” found on Microsoft TechNet at http://www.microsoft.com/technet/network/evaluate/new_network.mspx . Note that this page has been updated since its original version was posted, so it should be an up-to-date source of information on networking improvements in these platforms.