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

[Eric Dumazet <dada1@cosmosbay.com>]

Felix von Leitner a écrit :
>> 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.
> 
>> 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.
> 
>> 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.
> 
>> 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.
> 
>>> Why would you say that?
>> Because that case doesn't provide any benefits.
> 
> You may not see it but it does.
> 
>> 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.
> 
>> 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 :)