Re: socket api problem: can't bind an ipv6 socket to ::ffff:0.0.0.0

Felix von Leitner a écrit :

quoted

Sorry, I just don't buy this.  You imply that you don't want the overhead
of storing IPv6 addresses, but you still get this with ::ffff:0.0.0.0.
In fact, now your overhead is even worse since ever IPv4 address will be
stored stored and interpreted as IPv6 128 bit address.

quoted

If you really care about overhead, run 2 services.  Your IPv6 service
will only track real IPv6 addresses and will reduce you total overhead.

I am worried about the overhead of storing the IPv6 addresses.
I am not storing them in the IPv4 case.

But the socket code has been rewritten to use IPv6 addresses only,
precisely because IPv4-mapped addresses exist.

quoted

If you don't care about overhead, just bind a single socket to :: and
you will get behavior identical for the ::fff:0.0.0.0 case, but with
the added benefit of tracking real ipv6 addresses as well.

You probably mean well but please stick to the problem at hand and don't
speculate about my app.

quoted

Having written support for ::ffff:0.0.0.0, I've always thought it was
a bastardized case that didn't provide any benefits.  It was like saying:
"I've got IPv6 on my system, but I don't really support it, even though
I pretend that I do."

The app has a command line option to specify which address to bind to.
The app understands IPv4 addresses and converts them to ipv4 mapped
addresses so it can only deal with sockaddr_in6 when talking to the
kernel and does not need to store info on what kind of socket family it
is dealing with.

If someone specifies 0.0.0.0, it does not work.  It's that easy.

Now it may be a fascinating side discussion on whether you think IPv4
mapped 0.0.0.0 is useful or not, but rest assured: it is useful to at
least one high profile app that is so far running on Linux.

quoted

quoted

Why would you say that?

Because that case doesn't provide any benefits.

You may not see it but it does.

quoted

It only has the drawback that you have to deal with ipv4-mapped IPv6
addresses witch is the overhead of the whole thing.

That is not a drawback.  On the contrary.  It greatly simplifies how the
app deals with the socket API.

quoted

If you are prepared to deal with it, you might as well deal with real ipv6 addresses
at the same time and mitigate your overhead somewhat.

You are currently proving all the snide remarks by the BSD people about
the Linux IP stack true, and the "professionalism" snide remarks of the
Solaris people.  Great work, man.

Trying to understand why you seem furious, lets try to be pragmatic.

Most users of your great program wont have a fix for this until next year.

I am afraid you have no choice but change your program, or loose users.

Still I dont get your point. Having TCP V6 sockets is much more expensive
at kernel level (same for UDP), and bittorrent is known to stress network a bit, so
having application use an IPV4 socket where it can is a win for your
program getting more users, and computers spend less power.

grep TCP /proc/slabinfo

tw_sock_TCPv6          0      0    192   21    1 : tunables    0    0    0 : slabdata      0      0      0
TCPv6                140    140   1600   20    8 : tunables    0    0    0 : slabdata      7      7      0
tw_sock_TCP          256    256    128   32    1 : tunables    0    0    0 : slabdata      8      8      0
TCP                  197    198   1472   22    8 : tunables    0    0    0 : slabdata      9      9      0


Gasp, OSX having this "::ffff:0.0.0.0" right is probably the reason why more computers
 run OSX than linux. Sometime dont implement RFC too literally :)