[Backport][Nacos] Correct IPv6 network interface filtering on 2025.0.x

Which Component

Nacos Discovery (spring-cloud-starter-alibaba-nacos-discovery), InetIPv6Utils

Describe the bug

PR #4355 has been merged into 2025.1.x and fixes the overly permissive IPv6 network-interface filtering reported in #4354.

However, the latest 2025.0.x branch at the time of verification (b8403af4b2d94460e54dd53552d2e87c7f6265c0) still contains the same condition in InetIPv6Utils.findFirstValidIPv6Address():

if (ifc.isUp() || !ifc.isVirtual() || !ifc.isLoopback()) {

Because these predicates are joined with logical OR, an interface is processed whenever any one of them is true:

isUp()	isVirtual()	isLoopback()	Current result
false	false	false	true
true	true	false	true
true	false	true	true

Consequently, a down, virtual, or loopback network interface may still supply the IPv6 address selected by InetIPv6Utils when it contains an otherwise usable global IPv6 address.

This issue tracks the backport of #4355 to 2025.0.x.

Simplest demo

The focused regression test added in #4355 provides a deterministic reproduction:

https://github.com/alibaba/spring-cloud-alibaba/blob/18cf2a06c94b4b16fd58fd3ec13791542d26aba6/spring-cloud-alibaba-starters/spring-cloud-starter-alibaba-nacos-discovery/src/test/java/com/alibaba/cloud/nacos/util/InetIPv6UtilsTests.java

The test mocks NetworkInterface.getNetworkInterfaces() and verifies that:

• a down interface is ignored;
• a virtual interface is ignored;
• a loopback interface is ignored;
• an up, non-virtual, non-loopback interface with a valid IPv6 address is selected.

No Nacos Server is required.

To Reproduce

1. Check out 2025.0.x at b8403af4b2d94460e54dd53552d2e87c7f6265c0.
2. Port only InetIPv6UtilsTests from #4355 without changing the production code.
3. Run:

./mvnw \
  -pl spring-cloud-alibaba-starters/spring-cloud-starter-alibaba-nacos-discovery \
  -am \
  -Dtest=InetIPv6UtilsTests \
  -Dsurefire.failIfNoSpecifiedTests=false \
  test

4. With the current OR condition, the result is:

Tests run: 4, Failures: 3, Errors: 0, Skipped: 0

The down, virtual, and loopback cases each return [2001:db8:0:0:0:0:0:1] instead of null; the valid-interface case passes.

5. Replace the OR condition with the AND condition from #4355 and rerun the test. All four tests pass.

Expected behavior

Only active, non-virtual, and non-loopback network interfaces should be considered when searching for a usable IPv6 address:

if (ifc.isUp() && !ifc.isVirtual() && !ifc.isLoopback()) {

Addresses from down, virtual, or loopback interfaces should be ignored, while a valid IPv6 address from a normal interface should still be selected.

Suggested implementation

Please use the merged PR #4355 as the reference:

1. Backport the production fix to 2025.0.x.
2. Backport the focused InetIPv6UtilsTests regression coverage.
3. Open a separate PR targeting 2025.0.x and link this issue.

Contributions are welcome. If you would like to work on this issue, please leave a comment first to avoid duplicated effort.

Screenshots

Not applicable. The focused regression test demonstrates the problem deterministically.

Additional context

• Target branch: 2025.0.x
• Verified commit: b8403af4b2d94460e54dd53552d2e87c7f6265c0
• Spring Cloud Alibaba: 2025.0.0.1-SNAPSHOT
• Spring Cloud: 2025.0.0
• Spring Boot: 3.5.0
• JDK: 17.0.10
• Original issue: #4354
• Fix merged into 2025.1.x: #4355
• Before the fix: 4 tests, 3 failures, 0 errors
• After applying the fix: 4 tests, 0 failures, 0 errors
• No existing 2025.0.x backport issue or PR for this InetIPv6Utils problem was found before creating this issue.