Besides the US government and certain Asian countries, IPv6 has not really caught on yet, especially here in the US. So how does IIS7 stack up as far as IPv6 support is concerned? Let's walk through the IIS7 feature set to evaluate this. For comparison against IIS 6 you can check out the TechNet article here.
IPv6 Bindings in IIS7
The default binding is a '*' binding and does not have an IP address, so IPv6 does not come into the picture. However if you were to create a binding for your site from 'inetmgr' (IIS 7 configuration tool), the drop down list for IP Address would pre-populate with your server's IP addresses, including IPv6 address. Here's a screen shot of what this looks like.
When you are selecting an IPv6 address from the list, make sure you don't accidentally bind to the 'Temporary IPv6 Address'. Temporary addresses are IPv6 interface identifiers that provide a level of anonymity for outbound traffic. If your machine is domain joined, it is possible for the DC to assign a temporary address (with the same global prefix) to your machine and this address may change frequently, say every day. In that case your binding will be broken every time such a change occurs.
Sounds good so far, but can I manually enter an IP address? And if I do, will it check the validity of the address? Yes and yes. Here's what I get when I enter an invalid IP address.
Back in IIS 6 site/server limits like MaxBandwidth and MaxGlobalBandwidth metabase properties did not apply to responses sent over IPv6 addresses. IIS 7 has equivalents to these limits as well that reside under system.applicationHost/sites/Limits. These settings apply to responses sent over both IPv4 and IPv6 for IIS 7.
IP Address and Domain Restrictions
If you have brought up the configuration manager for IIS 7 (inetmgr) you probably noticed that the restriction list is preceded by "IPv4".
And drilling down further to add a deny rule list shows IPv4 specific entries only.
So does this mean that there is no support for IPv6 in the IP restrictions list? Well, note really. The way the restriction list currently works is that it applies a specified mask to an incoming requests address to figure out if an address is on the restriction list. In the case of IPv6 masks are specified as a bit offset like 2001:8989::/16. But there is no reason why you could not specify a subnet style mask for IPV6 like ffff::. The inetmgr UI has an artificial restriction for allowing only IPv4 addresses and this is mostly because of test constraints on our part. However, you can easily configure this in our configuration file (applicationHost.config), and here are what entries look like for both a specific address and an address range for both IPv4 and IPV6 .
<ipSecurity allowUnlisted="true"> <add ipAddress="10.199.199.199" allowed="false" /> <add ipAddress="220.127.116.11" subnetMask="255.255.0.0" allowed="false" /> <add ipAddress="2001:4898:2a:5:c4ad:9291:22b1:c870" subnetMask="ffff:ffff::" allowed="false" /> </ipSecurity >
All we had to do to specify an IPV6 address is to use a subnet mask style filter for ranges and it should just work. The bonus here is that once you do this in the configuration file, you will see the entry appear accurately in the inetmgr UI as shown below.
There are some additional details that are worth mentioning here.
- Grant/Deny rules using 127.0.0.1 will automatically apply to both IPv4 and IPv6 address.
- Also, 127.0.0.1 and ::1 can be used interchangeably and is protocol version agnostic.
Another important fact to remember here is that adding an IP restriction rule is evaluated against that specific IP address and not a client. So if a client has both an IPV4 address and an IPV6 address, and you add a deny rule for the IPV4 address, it can still connect via its IPV6 address.
FTP Publishing Service for IIS 7.0
The new version of FTP (7.0) fully supports IPv6 besides supporting other marked improvements like SSL. Both IPv4 and IPv6 clients can connect to a server that could have either an IPv4 or IPv6 address.
One major point of confusion that I should clarify here is that the version of FTP on the box with Windows Server 2008 is NOT FTP 7. It is in fact the older version. The new version of FTP shipped out of band and can be downloaded here for x86 version or here for x64 version.
FTP has its own IP restriction list and even its configuration UI (which is integrated with IIS configuration) does not let you specify IPv6 addresses. Here is what you will see when you enter an IPv6 address.
In case you were wondering if IP restrictions is any different for FTP than for IIS, it's not. In fact, if you open up the same applicationHost.config file you will see a section like the one below.
<system.ftpServer> ... <security> ... <ipSecurity> <add ipAddress="18.104.22.168" allowed="false" /> <add ipAddress="22.214.171.124" subnetMask="255.255.0.0" allowed="false" /> </ipSecurity> </security> </system.ftpServer>
And this is exactly the same schema as the one for IIS. So everything I mentioned above applies here as well.
IIS 7.0's tracing and logging mechanisms are fully IPv6 aware as well. So whether you are generating Failed Request Traces or looking at the HTTP error logs, you will see IPv6 addresses. Even at an OS and programmability level there is much greater support for IPv6, which makes it easier to work with even from a developer's perspective.