There have been more than a few occasions that site local addresses (which was deprecated by RFC 3879 way back in 2004) have been brought up to me lately, specifically around a feature that Windows has had for a very long time. This feature is the automatic use of three well know site local DNS name server entries if no IPv6 name server is provided to an interface. The three IPv6 addresses are:
fec0:0:0:0:ffff::1
fec0:0:0:0:ffff::2
fec0:0:0:0:ffff::3
You can see these in use on interfaces on the Windows client or server machine, especially for interfaces you might not be aware of on a given host. For instance, you might have ISATAP tunnel interfaces or a Bluetooth interface that display these. You can check using the following PowerShell:
PS C:\> Get-DnsClientServerAddress | ft
That will display all the client DNS server information for all the interfaces on a given Windows host. From that you will see something like:
InterfaceAlias Interface Address ServerAddresses
Index Family
-------------- --------- ------- ---------------
Local Area Connection 2 24 IPv4 {}
Local Area Connection 2 24 IPv6 {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
isatap.{7901A47F-5E03-43A... 39 IPv4 {}
isatap.{7901A47F-5E03-43A... 39 IPv6 {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3} Bluetooth Network Connection 6 IPv4 {}
Bluetooth Network Connection 6 IPv6 {fec0:0:0:ffff::1, fec0:0:0:ffff::2, fec0:0:0:ffff::3}
<>
There have been expressed some concerns about this being a vector of exploit because if someone sets up a DNS service on those IPv6 address space they could potentially lie to your host because you will use that as the preferred DNS resolver. This actually isn't the case and it has to do with the prefix policy table. So lets look at some more details.
One of the reason there is no concern around the misuse of site local to exploit a system is due to how the classification of site local is handled in the prefix policy table. You can view the local prefix policy table with the following PowerShell:
PS C:\> Get-NetPrefixPolicy
And the output is:
Prefix Precedence Label
------ ---------- -----
3ffe::/16 1 12
fec0::/10 1 11
::/96 1 3
fc00::/7 3 13
2001::/32 5 5
2002::/16 30 2
::ffff:0:0/96 35 4
::/0 40 1
::1/128 50 0
The precedence of 1 means it is the least preferred, the same as the former 6bone network of 3ffe::/16 for instance which is no longer in use. The important thing to notice is that ::ffff:0:0/96 has a higher precedence based off the recommendations in RFC 6724. This means that IPv4 traffic and therefore DNS name resolver selection is preferred over site local. So if you have no IPv6 DNS server information even if you did have a site local DNS name server you would not use it if an IPv4 DNS name server option was available. This is the only use case that you might have an issue because if you are using any IPv6 and publishing an IPv6 DNS name resolver then you will prefer that IPv6 DNS name resolver right away. So the only use case where you might potentially use site local is if you actually assign a host an site local address. It makes no sense to do that at all but that is the one case where you might have a problem. So, the simple conclusion is...
Don't use site local, which is obvious, since it was depricated way back in 2004.
Hope this helps to address some concerns around this.
- Ed