spring-cloud / spring-cloud/spring-cloud-commons
InetUtils doesn't return IPv6 addresses
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 751
- Forks
- 744
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 9
Description
Describe the bug
I'm using version 2.1.4. In the function InetUtils.findFirstNonLoopbackAddress, the code only seems to return IPv4 addresses. I believe this code is incorrect, since most systems have multiple IP addresses. In my case, my system has multiple interfaces, each of which has one 1 IPv4 address, and multiple IPv6 addresses. The snippet of interest:
if (!ignoreInterface(ifc.getDisplayName())) {
for (Enumeration<InetAddress> addrs = ifc
.getInetAddresses(); addrs.hasMoreElements();) {
InetAddress address = addrs.nextElement();
if (address instanceof Inet4Address
&& !address.isLoopbackAddress()
&& isPreferredAddress(address)) {
this.log.trace("Found non-loopback interface: " + ifc.getDisplayName());
result = address;
}
}
}
It's probably not as simple as removing the instanceof check, since many programs are not yet ready for IPv6 usage. However, I think making it possible (via configuration perhaps) to return IPv6 addresses would ease the transition from a pure IPv4 only world to a dual stack world.
Longer term, it would be nice to make the HostInfo class, which encapsulates the address, able to express multiple addresses. This would make the code align with realistic networking configuration, where the hosts typically do have multiple addresses.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at InetUtils.findFirstNonLoopbackAddress and inspect the HostInfo class that encapsulates the address. Trace how interface addresses are filtered and represented, then determine how IPv6 or multiple addresses should be exposed without breaking IPv4 users. Done means the intended address behavior is defined and verified for dual-stack systems.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100