[
https://issues.apache.org/jira/browse/GEODE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9290:
----------------------------------
Labels: pull-request-available (was: )
> LocalHostUtil.getMyAddresses should not return IPv4-mapped IPv6 addresses
> -------------------------------------------------------------------------
>
> Key: GEODE-9290
> URL: https://issues.apache.org/jira/browse/GEODE-9290
> Project: Geode
> Issue Type: Bug
> Components: membership
> Reporter: Kamilla Aslami
> Assignee: Kamilla Aslami
> Priority: Major
> Labels: pull-request-available
>
> This issue was found on RedHat8. While running a test that creates a
> partitioned region with redundancy 1 and does various entry operations, we
> noticed this warning in the logs:
> Configured redundancy level could not be satisfied. Advise you to start
> enough data store nodes to satisfy redundancy for the region. Partitioned
> Region name = /partitionedRegion Redundancy level set to 1 . Number of
> available data stores: 10 . Number successfully allocated = 1 .
> Additional logging showed that Geode thinks all the hosts are equivalent,
> i.e. the values of {{equivalentHosts}} map in {{ClusterDistributionManager}}
> contain localhost addresses:
> {noformat}
> {/10.32.110.176=[/10.32.110.176, /127.0.0.1], /127.0.0.1=[/10.32.109.148,
> /127.0.0.1], /10.32.109.148=[/10.32.109.148, /127.0.0.1],
> /0:0:0:0:0:ffff:7f00:1%lo=[/10.32.109.148, /0:0:0:0:0:ffff:7f00:1%lo]}
> {noformat}
> Further analysis revealed that the issue is related to
> {{LocalHostUtil.getMyAddresses()}} method. Additional logging showed that
> this method always returns an IPv4 and this IPv6
> address:{{0:0:0:0:0:ffff:7f00:1%lo}} . Looking closer at the IPv6 address, we
> realized that it is in fact an IPv4-mapped IPv6 address that represents
> {{127.0.0.1}}. The problem with {{0:0:0:0:0:ffff:7f00:1%lo}} is that
> isLoopbackAddress() method returns false for this address because the IPv6
> loopback address is {{/0:0:0:0:0:0:0:1%lo}}. This part of the [Inet6Address
> documentation|https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#format]:
> {quote}IPv4-mapped address:
> Of the form::ffff:w.x.y.z, this IPv6 address is used to represent an IPv4
> address. It allows the native program to use the same address data structure
> and also the same socket when communicating with both IPv4 and IPv6 nodes.In
> InetAddress and Inet6Address, it is used for internal representation; it has
> no functional role. Java will never return an IPv4-mapped address. These
> classes can take an IPv4-mapped address as input, both in byte array and text
> representation. However, it will be converted into an IPv4 address.
> {quote}
> claims that {{Java will never return an IPv4-mapped address}}. And the
> implementation of {{InetAddress.getByAddress()}} and
> {{InetAddress.getByName()}} methods is consistent with this claim because
> both internally call {{IPAddressUtil.convertFromIPv4MappedAddress()}} that
> converts an IPv4-mapped IPv6 address to IPv4 address. However,
> {{NetworkInterface.getInetAddresses()}} method (which is used in
> {{LocalHostUtil.getMyAddresses()}}) should also not return an IPv4-mapped
> IPv6 address, but it does.
> Although this looks like a bug in the jdk, we can avoid IPv4 mapped IPv6
> addresses by manually converting them to IPv4 addresses in
> {{LocalHostUtil.getMyAddresses()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
