The first-returned IP address is incorrect when you use the getaddrinfo function on a multi-homed computer that is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2

Consider the following scenario:

• Multiple network adapters are installed on a computer.
• One network adapter is configured to use an Automatic Private Internet Protocol Addressing (APIPA) IP address.
• Another network adapter is configured to use a non-APIPA IP address.
• The interface metric is smaller on the second network adapter than the metric that is configured on the first network adapter.
• An application calls the getaddrinfo function on the computer.

In this scenario, the first-returned IP address is the APIPA IP address.

Notes

• This issue prevents network applications that use only the first-returned local IP address by calling the getaddrinfo function (such as a Java-based application that calls the GetLocalHost Java API) from connecting to network resources.
• This issue occurs on a computer that is running one of the following operating systems:
  • Windows Vista Service Pack 2 (SP2)
  • Windows Server 2008 Service Pack 2 (SP2)
  • Windows 7
  • Windows 7 Service Pack 1 (SP1)
  • Windows Server 2008 R2
  • Windows Server 2008 R2 Service Pack 1 (SP1)

The issue occurs because the TCP/IP driver (Tcpip.sys) incorrectly ignores the interface metric when it determines which IP address should be returned first. The expected behavior is that the first-returned IP address should be the interface that has the smallest metric and is therefore the highest priority.

This hotfix is to partly restore the previous sorting behavior that was implemented in the release version of Windows Server 2008. For both IPv4 and IPv6 scenarios, IP addresses will first be sorted by the interface metric. However, if there are two or more network adapters that have identical interface metrics, then the address "scope" value will be used to sort IP addresses. According to RFC 3484, the APIPA IP addresses (169.254.x.x) are favored over the global IP addresses. �

Note The IPv6 address sorting method is also changed because the same sorting algorithm is used for both IPv4 and IPv6 addresses.

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site: Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, you must be running one of the following operating systems:

• Windows Vista Service Pack 2 (SP2)
• Windows Server 2008 Service Pack 2 (SP2)
• Windows 7
• Windows 7 Service Pack 1 (SP1)
• Windows Server 2008 R2
• Windows Server 2008 R2 Service Pack 1 (SP1)

For more information about how to obtain a Windows Vista service pack, click the following article number to view the article in the Microsoft Knowledge Base: For more information about how to obtain a Windows Server 2008 service pack, click the following article number to view the article in the Microsoft Knowledge Base: For more information about how to obtain a Windows 7 or Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:

Registry information

To use the hotfix in this package, you do not have to make any changes to the registry.

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows Vista and Windows Server 2008 file information notes

Important Windows Vista hotfixes and Windows Server 2008 hotfixes are included in the same packages. However, only "Windows Vista" is listed on the Hotfix Request page. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under "Windows Vista" on the page. Always refer to the "Applies To" section in articles to determine the actual operating system that each hotfix applies to.

• The files that apply to a specific product, SR_Level (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.

  Version	Product	SR_Level	Service branch
  6.0.600 2 . 22xxx	Windows Vista and Windows Server 2008	SP2	LDR

• The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the "Additional file information for Windows Server 2008 and for Windows Vista" section. MUM files and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

For all supported x86-based versions of Windows Server 2008 and of Windows Vista

For all supported x64-based versions of Windows Server 2008 and of Windows Vista

For all supported IA-64-based versions of Windows Server 2008

Windows 7 and Windows Server 2008 R2 file information notes

• The files that apply to a specific product, milestone (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table:

  Version	Product	Milestone	Service branch
  6.1.760 0.16xxx	Windows 7 and Windows Server 2008 R2	RTM	GDR
  6.1.760 0.21xxx	Windows 7 and Windows Server 2008 R2	RTM	LDR
  6.1.760 1.17xxx	Windows 7 and Windows Server 2008 R2	SP1	GDR
  6.1.760 1.21xxx	Windows 7 and Windows Server 2008 R2	SP1	LDR

• GDR service branches contain only those fixes that are widely released to address widespread, extremely important issues. LDR service branches contain hotfixes in addition to widely released fixes.
• The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the "Additional file information for Windows Server 2008 R2 and for Windows 7" section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

For all supported x86-based versions of Windows 7

For all supported x64-based versions of Windows 7 and of Windows Server 2008 R2

For all supported IA-64-based versions of Windows Server 2008 R2

To work around this issue, add an explicit entry for the local node name into the hosts file. For example, if a local host is named "Server123" and is configured by using a static IPv4 address of 157.59.120.69 (global IP address) and a dynamic IPv4 address of 169.254.20.10 (APIPA IP address), the following line should be added to the hosts file that is located under C:\Windows\System32\drivers\etc\:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

Starting from Windows Server 2008 SP2, a change was made in the behavior of sorting local IP addresses that are returned by the getaddrinfo API call. This change causes the IPv4 APIPA IP address to always be the first address that is returned by the getaddrinfo API call.

Notes

• The GetLocalHost Java API is mapped to the getaddrinfo API in Windows.
• The getaddrinfo API does not specify any specific sorting behavior. Therefore, these affected applications implicitly assumed a sorting order. Microsoft does not guarantee any particular destination address sorting order by using the getaddrinfo API.

The interface metric was previously implemented to sort the IP addresses that are returned by the getaddrinfo API call. However, this behavior was changed because of an unrelated hotfix that was implemented in Dec 2008. This hotfix fixed the sorting method of IPv6 destination addresses in order to comply with RFC 3484. Instead of the interface metric, a different sorting method was implemented. This method has become the default method starting from Windows Server 2008 SP2. This hotfix corrected an issue in which Windows incorrectly favored an Intra-site Automatic Tunnel Addressing Protocol�(ISATAP) address over a native IPv6 address. Therefore, the sorting method for IPv4 addresses was changed because a common sorting routine was implemented in Tcpip.sys that handles both IPv6 and IPv4 addresses (in an address-agnostic manner). This hotfix changes the sorting method to use the address "scope" value instead of the interface metric to sort IP addresses (IPv4 APIPA IP addresses are favored over global IP addresses).

For more information about the interface metric values that are implemented in Windows, click the following article number to view the article in the Microsoft Knowledge Base: Notes

• You can directly configure the interface metric value for an interface by using the netsh command at an administrative command prompt. The interface metric can be set for a specific interface. For example, the following command sets the interface metric for "Local Area Connection" interface to 15:
  netsh interface ipv4 set interface "Local Area Connection" metric=15
• You can list all interfaces by using the following command:
  netsh interface ipv4 show interfaces
• You can view the current interface values of the "Local Area Connection" interface by using the following command:
  netsh interface ipv4 show interface "Local Area Connection"

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

Additional file information

Additional file information for Windows Vista and for Windows Server 2008

Additional files for all supported x86-based versions of Windows Vista and of Windows Server 2008

Additional files for all supported x64-based versions of Windows Vista and of Windows Server 2008

Additional files for all supported IA-64-based versions of Windows Server 2008

Additional file information for Windows 7 and for Windows Server 2008 R2

Additional files for all supported x86-based versions of Windows 7

Additional files for all supported x64-based versions of Windows 7 and of Windows Server 2008 R2

Additional files for all supported IA-64-based versions of Windows Server 2008 R2