The IPV6_PROTECTION_LEVEL socket option enables developers to place access restrictions on IPv6 sockets. Such restrictions enable an application running on a private LAN to simply and robustly harden itself against external attacks. The IPV6_PROTECTION_LEVEL socket option widens or narrows the scope of a listening socket, enabling unrestricted access from public and private users when appropriate, or restricting access only to the same site, as required.
IPV6_PROTECTION_LEVEL currently has three defined protection levels.
Used by applications designed to operate across the Internet, including applications taking advantage of IPv6 NAT traversal capabilities built into Windows (Teredo, for example). These applications may bypass IPv4 firewalls, so applications must be hardened against Internet attacks directed at the opened port.
Used by applications designed to operate across the Internet. This setting does not allow NAT traversal using the Windows Teredo implementation. These applications may bypass IPv4 firewalls, so applications must be hardened against Internet attacks directed at the opened port.
Used by intranet applications that do not implement Internet scenarios. These applications are generally not tested or hardened against Internet-style attacks.
This setting will limit the received traffic to link-local only.
The following code example provides the defined values for each:
#define PROTECTION_LEVEL_UNRESTRICTED 10 /* for peer-to-peer apps */ #define PROTECTION_LEVEL_EDGERESTRICTED 20 /* Same as unrestricted, except for Teredo */ #define PROTECTION_LEVEL_RESTRICTED 30 /* for Intranet apps */
These values are mutually exclusive, and cannot be combined in a single setsockopt function call. Other values for this socket option are reserved. These protection levels apply only to incoming connections. Setting this socket option has no effect on outbound packets or connections.
On Windows 7 and Windows Server 2008 R2, the default value for IPV6_PROTECTION_LEVEL is unspecified and PROTECTION_LEVEL_DEFAULT is defined to -1, an illegal value for IPV6_PROTECTION_LEVEL.
On Windows Vista and Windows Server 2008, the default value for IPV6_PROTECTION_LEVEL is PROTECTION_LEVEL_UNRESTRICTED and PROTECTION_LEVEL_DEFAULT is defined to -1, an illegal value for IPV6_PROTECTION_LEVEL.
On Windows Server 2003 and Windows XP, the default value for IPV6_PROTECTION_LEVEL is PROTECTION_LEVEL_EDGERESTRICTED and PROTECTION_LEVEL_DEFAULT is defined to be PROTECTION_LEVEL_EDGERESTRICTED.
Note The IPV6_PROTECTION_LEVEL socket option should be set before the socket is bound. Otherwise, packets received between bind and setsockopt calls will conform to PROTECTION_LEVEL_EDGERESTRICTED, and may be delivered to the application.
The following table describes the effect of applying each protection level to a listening socket.
|Protection level||Incoming traffic permitted|
|Same site||External||NAT traversal (Teredo)|
In the table above, the Same site column is a combination of the following:
- Link local addresses
- Site Local addresses
- Global addresses known to belong to the same site (matching the site prefix table)
On Windows 7 and Windows Server 2008 R2, the default value for IPV6_PROTECTION_LEVEL is unspecified. If there is no edge-traversal aware firewall software installed on the local computer (Windows firewall is disabled or some other firewall is installed that ignores Teredo traffic), you will receive Teredo traffic only if you set the IPV6_PROTECTION_LEVEL socket option to PROTECTION_LEVEL_UNRESTRICTED. However, Windows firewall or any edge-traversal aware firewall policy may ignore this option based on policy settings for the firewall. By setting this socket option to PROTECTION_LEVEL_UNRESTRICTED, the application is communicating its explicit intent to receive edge traversed traffic by the host firewall installed on the local machine. So if there is an edge-traversal aware host firewall installed, it will have the final decision on accepting a packet. By default, without any socket option set:
- o If Windows firewall is enabled (or another edge-traversal aware host firewall is installed) on the local computer, whatever it enforces will be observed. Typical edge-traversal aware host firewall will block Teredo traffic by default. Therefore applications will observe the default as if it was PROTECTION_LEVEL_EDGERESTRICTED.
- o If Windows firewall is not enabled and no other edge-traversal aware host firewall is installed on the local system, the default will be PROTECTION_LEVEL_EDGERESTRICTED.
On Windows Vista and Windows Server 2008, the default value for IPV6_PROTECTION_LEVEL is PROTECTION_LEVEL_UNRESTRICTED. But the effective value depends on whether Windows firewall is enabled. The Windows firewall is edge-traversal aware (Teredo aware), no matter what value is set for the IPV6_PROTECTION_LEVEL and ignores if IPV6_PROTECTION_LEVEL is PROTECTION_LEVEL_UNRESTRICTED. So the effective value depends on the firewall policy. When Windows firewall is disabled and no other edge-traversal aware firewall is installed on the local computer, the default value for IPV6_PROTECTION_LEVEL is PROTECTION_LEVEL_UNRESTRICTED.
On Windows Server 2003 and Windows XP, the default value for IPV6_PROTECTION_LEVEL is PROTECTION_LEVEL_EDGERESTRICTED. Unless you have set the IPV6_PROTECTION_LEVEL socket option to PROTECTION_LEVEL_UNRESTRICTED, you would not receive any Teredo traffic.
Depending on the IPV6_PROTECTION_LEVEL, an application that requires unsolicited traffic from the Internet may not be capable of receiving unsolicited traffic. However, these requirements are not necessary for receiving solicited traffic over the Windows Teredo interface. For more details on the interaction with Teredo, see Receiving Solicited Traffic Over Teredo.
When incoming packets or connections are refused due to the set protection level, rejection is handled as if no application was listening on that socket.
The IPV6_PROTECTION_LEVEL socket option does not necessarily place access restrictions on IPv6 sockets or restrict NAT traversal using some method other than Windows Teredo or even using another implementation of Teredo by another vendor.
Build date: 11/16/2013