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

[uuuyuqi]

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 fix(nacos): correct network interface filter logic in InetIPv6Utils #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 fix(nacos): correct network interface filter logic in InetIPv6Utils #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: IPv6 interface filtering logic appears too permissive in findFirstValidIPv6Address() #4354
• Fix merged into 2025.1.x: fix(nacos): correct network interface filter logic in InetIPv6Utils #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.

[EmaniPreethika]

Hey this seems to be an easy one!! I am a beginner and have closed a few small PRs....can this be assigned to me

[xuxiaowei-com-cn]

Hey this seems to be an easy one!! I am a beginner and have closed a few small PRs....can this be assigned to me

You got it! Just assigned this to you. Awesome to see you building momentum with those small PRs. Happy coding!

[EmaniPreethika]

please check out #4367

[oss-sentinel-ai]

Issue Evaluation

Category: kind/bug (backport) | Status: Confirmed

The reported issue is valid. PR #4355 (commit 18cf2a0) fixed the overly permissive IPv6 network-interface filtering in InetIPv6Utils.findFirstValidIPv6Address() on the 2025.1.x branch, but the same flawed condition still exists on 2025.0.x.

Root Cause: The logical OR join of isUp(), isVirtual(), and isLoopback() in InetIPv6Utils causes any interface to pass the filter when at least one predicate is true, defeating the purpose of the check.

Impact: Nacos Discovery on 2025.0.x may register incorrect IPv6 addresses when virtual or loopback interfaces are present.

Severity: medium — affects environments with multiple network interfaces on 2025.0.x.

A backport PR to 2025.0.x will be generated. Reply /approve to proceed, /revise to request changes, or /reject to decline.

---

Automated evaluation by github-manager-bot

[EmaniPreethika]

Issue Evaluation

Category: kind/bug (backport) | Status: Confirmed

The reported issue is valid. PR #4355 (commit 18cf2a0) fixed the overly permissive IPv6 network-interface filtering in InetIPv6Utils.findFirstValidIPv6Address() on the 2025.1.x branch, but the same flawed condition still exists on 2025.0.x.

Root Cause: The logical OR join of isUp(), isVirtual(), and isLoopback() in InetIPv6Utils causes any interface to pass the filter when at least one predicate is true, defeating the purpose of the check.

Impact: Nacos Discovery on 2025.0.x may register incorrect IPv6 addresses when virtual or loopback interfaces are present.

Severity: medium — affects environments with multiple network interfaces on 2025.0.x.

A backport PR to 2025.0.x will be generated. Reply /approve to proceed, /revise to request changes, or /reject to decline.

Automated evaluation by github-manager-bot

/approve

[EmaniPreethika]

@xuxiaowei-com-cn Please can you address the below message. I dont understand. Would my PR be accepted or not? The bot has been a bit of an inconvenience. Will my PR not be merged?

Hi @EmaniPreethika,

I need to apologize and close this PR. I discovered that issue https://github.com/alibaba/spring-cloud-alibaba/issues/4364 was already assigned to you on July 17th, and you had already submitted PR https://github.com/alibaba/spring-cloud-alibaba/pull/4367 to address it.

This PR (https://github.com/alibaba/spring-cloud-alibaba/pull/4374) was created by an automation mis-trigger on my end. My issue-scan workflow incorrectly evaluated the issue and then the feedback-polling workflow misinterpreted activity as a signal to start the issue-to-pr pipeline, resulting in this competing PR.

This was entirely my mistake. Your PR https://github.com/alibaba/spring-cloud-alibaba/pull/4367 is the correct one, and I should not have created this duplicate.

Closing this PR in favor of your work on https://github.com/alibaba/spring-cloud-alibaba/pull/4367.

Again, I apologize for the noise and any confusion this caused. Thank you for your contribution to Spring Cloud Alibaba.

Best regards,
github-manager (oss-sentinel-ai)