You are right that our method of determining the suitable IP address is not ideal. However, RFC 3484 does not actually say that client should just prefer IPv6 to IPv4 either. RFC 3484 states that "a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior". However, it does not prohibit this behavior, even though it advises against it. This is what it states:
As a consequence, we intend that implementations of getaddrinfo()
will use the destination address selection algorithm specified here
to sort the list of IPv6 and IPv4 addresses that they return.
Well-behaved applications SHOULD iterate through the list of
addresses returned from getaddrinfo() until they find a working
We differ here because we use the poor behavior instead (and simply preferring IPv6 would be equally poor). But we would not call this a bug because the meaning of "SHOULD" is defined by RFC 2119 as follows:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
(Wording of RFC 6724, which obsoleted RFC 3484, is slightly different, but the core of its meaning is the same.)
So how have we ended with the poor behavior? When we first added support for IPv6 more than 10 years ago, we found out that the recommended very often produced undesirable results (comparable to this). In the end, after carefully weighting pros and cons, we decided to use the poor behavior because it turned out to produce better results in practice. We were not happy about this decision, but we don't regret it because we have not received any complaints (until now)
Of course, that decision was made in 2007. Now, it would almost certainly be better to use the recommended approach. However, that would involve changing an existing behavior, which might potentially break applications based on Rebex libraries. That is undesirable as well and lot of our clients would not like that.
So instead, we are now considering the following approach:
We will add an option to Rebex libraries that will enable the behavior recommended by RFC 3484 / RFC 6724.
Forthcoming binaries for .NET 4.6 and .NET Standard 2.0 will use the recommended behavior by default.
This is a high-priority issue and we will address it very soon. If you would like to get a link to a hotfix when it's ready, please let us know.
Also, thanks for bringing this to or attention.