[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49BFBFF4.5060206@cosmosbay.com>
Date: Tue, 17 Mar 2009 16:21:24 +0100
From: Eric Dumazet <dada1@...mosbay.com>
To: Felix von Leitner <felix-kernel@...e.de>
CC: Vlad Yasevich <vladislav.yasevich@...com>,
Brian Haley <brian.haley@...com>, netdev@...r.kernel.org
Subject: Re: socket api problem: can't bind an ipv6 socket to ::ffff:0.0.0.0
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 :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists